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