技術趨勢的背后 虛擬化對網絡宣戰
虛擬化對網絡提出挑戰
如果一項新技術被“發酵”為一種趨勢，那它將變得不可被阻擋。虛擬化技術雖然已經不再讓人感到那么的新鮮，但對它我們是否依然感覺陌生?操作系統在應用虛擬化技術以后物理硬件不見了，服務器硬件變成了“籃子”，而籃子里放著的一個個雞蛋就是以前運行在服務器硬件上的操作系統。
這種變化可以說是革命性的，它的好處顯而易見，例如可以大幅提升服務器硬件的利用率，甚至可以成倍的縮減以往購買服務器硬件的成本;同時服務器管理也變得更加高效且可控，像管理員可以隨時對虛擬機(VM)進行快照，遷移等操作。
應用虛擬化技術前后對比
虛擬化技術帶來的變化不僅在操作系統層面，其實從上圖中我們還可以看出另一種明顯的變化——網絡層面的變化。在非虛擬化環境中，一臺物理服務器中運行著一個OS，經由一條鏈路或多條鏈路連接到交換機，這種環境下網絡鏈路中的流量幾乎全部為業務數據流量，流量的大小當然要看具體的應用是什么，但一般來講，這個流量是不高的。
但在虛擬化環境下，這一切發生了很大的變化，簡單的講，此時交換機與物理服務器之間的鏈路中傳輸的數據流量變得遠比以前復雜得多。首選，這一物理鏈路中將同時傳輸來自多個虛擬機(VM)中的數據，另外，除了業務數據流量，鏈路中還增加了虛機機運行時所需要的系統流量，而這部分流量是以往非虛擬化環境中所不存在的。
讓我們簡單總結一下這一變化，在非虛擬化環境中，物理服務器與交換機之間的關系是一對一的關系，而在虛擬化環境中，由于一臺物理服務器中運行著多個虛擬機(VM)，從邏輯結構角度講，這時服務器與交換機之間其實是“多”對一的關系;隨著服務器(操作系統)與交換機之間邏輯結構的變化，物理鏈路中的流量也由一對一變為了“多”對一的關系，此外，還包括了以往非虛擬化環境中所不存在的虛擬機系統流量。
虛擬化后物理網絡產生瓶頸
在虛擬化環境中，上面所提到的流量變化其實是可以在交換機端口上監控得到的，但還有一部分流量在交換機上我們是監控不到的，請看下圖，我們來簡單說一下。
#p#
虛擬交換機
虛擬服務器(這里指的是ESX)會在OS與網卡物理硬件之間創建一個中間層——虛擬交換機(Virtual Switch)，就是說，一臺物理服務器上的各個虛機(OS)通過虛擬交換機可直接進行通信，這部分流量并不會出現在物理交換機上，而是在物理服務器內部被消化掉了。
這就給故障排查帶來了一些新的挑戰，在物理交換機端口上看似正常的流量，而問題可能是被虛擬交換機給掩蓋掉了。VMware VirtualCenter是一個很有效的管理工具，管理員可以通過它對ESX SERVER進行各種管理工作，查看運行狀況等，關于VC我們將在隨后的文章中對其進行更為詳細的介紹，而本文側重于虛擬化對物理網絡鏈路帶來的影響。
服務器進行虛擬化之后，物理網絡產生的瓶頸問題變得更為突出，這個以往可能并不存在的問題一下子成了必須要考慮并需要解決的問題。到底虛擬化會對物理網絡產生怎樣的影響?影響有多大?我們可以通過幾個并不復雜的實驗來說明它。
我們搭建了一個虛擬化的實驗場景，邏輯拓撲圖如下圖所示。交換機的19#端口與存儲相連，我們將17#端口認置為鏡像端口，鏡像19#端口上的所有流量并與監控電腦相連接。我們在虛似機(VM)上運行不同的應用，在監控電腦上使用流量監控軟件跟蹤其數據流量變化。
邏輯拓撲圖
在這一測試環境中，各虛擬機(VM)的實體文件是存放在存儲設備上的，就是說，無論物理交換機左側的邏輯結構如何，在其右側與存儲設備相連的那根網線中，基本上只存在兩種數據流量，一是業務應用流量，二是虛擬機本身的系統流量。這種環境下在交換機與存儲之間的鏈路上就不可避免的會產生傳輸瓶頸。以上都是我們進行的邏輯推論，但問題到底有多嚴重?我們將用測試截圖來一步步說明。 #p#
ERP測試流量
場景一：ERP流量
我們在一個VM上發起ERP查詢請求，ERP服務器為另一個同在當前物理服務器上的VM，雖然在這種情況下有一部分網絡流量被“消化”在了當前物理服務器內部，不過沒關系，我們要關心的并不是這部分內容，我們關心的是在物理鏈路上產生的流量變化。
ERP基礎流量
此處的ERP基礎流量其實是大量的數據庫查詢操作，X軸為時間軸(180秒)，Y軸為數據流量(單位是Byte)。由于ERP查詢腳本比較“單純”，可以看到，流量曲線也比較有規則，其非峰值流量并不大，基本在1MBps以下。
隨著ERP并發數的增加網絡流量產生的變化
上圖是我們測試的第二個ERP腳本，可看到，隨著并發數的增加，峰值流量曲線基本上是一路走高，瞬間最高達到了50MBps。但非峰值曲線并沒有大的變化，總體來說，網絡流量依然不高。
持續ERP壓力下的流量
ERP測試退出中(不斷關閉會話)
ERP測試正式退出，退出時出現了一個流量峰值達到了120MBps
ERP測試退出后的基礎流量(系統流量)，基本在200KBps左右
虛擬機(VM)重起
測試完ERP的兩個腳本后，我們重起了兩次虛擬機(VM)，VM的重起速度是非常快的，從截圖中也可以看到，兩次峰值流量的持續時間都只有不到10秒。由于VM的實體文件其實是存放在存儲設備中的，VM在重起時必定會從存儲中讀取大量數據，不過從測試截圖來看，重起VM所產生的流量對網絡造成的沖擊并不高。#p#
疊加流量、總結
場景二：各種流量疊加
在本場景中，我們將ERP流量作為基礎流量(必要流量)，一、對當前VM進行快照，二、在另一個VM中(不同物理服務器上)對存儲設備使用IOMETER進行吞吐測試。
ERP(基礎)流量峰值平均在5MBps左右
VM快照 所謂快照就是將VM當前的狀態進行“拍照”，主要包括當前VM的內存數據、CPU狀態等信息。上圖中55MBps處的峰值是快照啟動時的流量，在快照進行中，流量基本維持在10MBps左右，雖然10MBps的流量并不高，但要知道，這一流量在非虛擬化環境中是不存在的。并且這僅是對一個VM進行快照，如果多臺VM同時進行快照，這一流量將不容小視，因為這一流量是疊加在業務應用流量之上的。
VM快照進行中，流量穩定在10MBps左右。
VM快照結束，此時的流量僅為ERP流量。
IOMETER吞吐測試起動
IOMETER吞吐測試起動后網絡流量達到了45MBps左右，此時的ERP流量被徹底淹沒了，最左端的VM快照流量也顯得有些微不足道。
IOMETER測試持續中
IOMETER測試結束后
從上面這些截圖中我們可以看到，服務器虛擬化以后，流量疊加所產生的問題不容小視，我們所搭建的測試環境其實很簡單，所產生的網絡流量也相對“單純”，但這已經可以說明問題。
我們要做的當然是要避免這些問題的發生，首先，也是最重要的，在您設計全局虛擬化拓撲結構時，要比以往發費更多精力關注由于網絡結構變化帶來的新性能瓶頸點，如何能讓整個網絡運行得高效且穩定，初期設計變得尤為重要，一個大的方向就是將應用網絡與系統網絡相分離。另外，對于一些大流量的應用，例如對VM進行快照，雖然技術上支持任何時間進行，但為了避免對業務應用造成沖擊，這類操作應當盡量選擇在網絡空閑時進行。
【編輯推薦】
