虛擬化技術目前來講已經(jīng)不像開始那樣新奇和陌生了，操作系統(tǒng)在應用虛擬化技術后，一些物理硬件消失，服務器就變成了個儲物柜，儲物柜中放的就是原來運行在服務器硬件上的操作系統(tǒng)。

　　這種變化可以說是革命性的，它的好處顯而易見，例如可以大幅提升服務器硬件的利用率，甚至可以成倍的縮減以往購買服務器硬件的成本;同時服務器管理也變得更加高效且可控，像管理員可以隨時對虛擬機(VM)進行快照，遷移等操作。

　　應用虛擬化技術前后對比

　　虛擬化技術帶來的變化不僅在操作系統(tǒng)層面，其實從上圖中我們還可以看出另一種明顯的變化——網(wǎng)絡層面的變化。在非虛擬化環(huán)境中，一臺物理服務器中運行著一個OS，經(jīng)由一條鏈路或多條鏈路連接到交換機，這種環(huán)境下網(wǎng)絡鏈路中的流量幾乎全部為業(yè)務數(shù)據(jù)流量，流量的大小當然要看具體的應用是什么，但一般來講，這個流量是不高的。

　　但在虛擬化環(huán)境下，這一切發(fā)生了很大的變化，簡單的講，此時交換機與物理服務器之間的鏈路中傳輸?shù)臄?shù)據(jù)流量變得遠比以前復雜得多。首選，這一物理鏈路中將同時傳輸來自多個虛擬機(VM)中的數(shù)據(jù)，另外，除了業(yè)務數(shù)據(jù)流量，鏈路中還增加了虛機機運行時所需要的系統(tǒng)流量，而這部分流量是以往非虛擬化環(huán)境中所不存在的。

　　讓我們簡單總結一下這一變化，在非虛擬化環(huán)境中，物理服務器與交換機之間的關系是一對一的關系，而在虛擬化環(huán)境中，由于一臺物理服務器中運行著多個虛擬機(VM)，從邏輯結構角度講，這時服務器與交換機之間其實是“多”對一的關系;隨著服務器(操作系統(tǒng))與交換機之間邏輯結構的變化，物理鏈路中的流量也由一對一變?yōu)榱?ldquo;多”對一的關系，此外，還包括了以往非虛擬化環(huán)境中所不存在的虛擬機系統(tǒng)流量。。

　　在虛擬化環(huán)境中，上面所提到的流量變化其實是可以在交換機端口上監(jiān)控得到的，但還有一部分流量在交換機上我們是監(jiān)控不到的，請看下圖，我們來簡單說一下。

　　虛擬交換機

　　虛擬服務器(這里指的是ESX)會在OS與網(wǎng)卡物理硬件之間創(chuàng)建一個中間層——虛擬交換機(VirtualSwitch)，就是說，一臺物理服務器上的各個虛機(OS)通過虛擬交換機可直接進行通信，這部分流量并不會出現(xiàn)在物理交換機上，而是在物理服務器內(nèi)部被消化掉了。

　　這就給故障排查帶來了一些新的挑戰(zhàn)，在物理交換機端口上看似正常的流量，而問題可能是被虛擬交換機給掩蓋掉了。VMwareVirtualCenter是一個很有效的管理工具，管理員可以通過它對ESXSERVER進行各種管理工作，查看運行狀況等，關于VC我們將在隨后的文章中對其進行更為詳細的介紹，而本文側重于虛擬化對物理網(wǎng)絡鏈路帶來的影響。

　　服務器進行虛擬化之后，物理網(wǎng)絡產(chǎn)生的瓶頸問題變得更為突出，這個以往可能并不存在的問題一下子成了必須要考慮并需要解決的問題。到底虛擬化會對物理網(wǎng)絡產(chǎn)生怎樣的影響？影響有多大？我們可以通過幾個并不復雜的實驗來說明它。

　　我們搭建了一個虛擬化的實驗場景，邏輯拓撲圖如下圖所示。交換機的19#端口與存儲相連，我們將17#端口認置為鏡像端口，鏡像19#端口上的所有流量并與監(jiān)控電腦相連接。我們在虛似機(VM)上運行不同的應用，在監(jiān)控電腦上使用流量監(jiān)控軟件跟蹤其數(shù)據(jù)流量變化。

　　在這一測試環(huán)境中，各虛擬機(VM)的實體文件是存放在存儲設備上的，就是說，無論物理交換機左側的邏輯結構如何，在其右側與存儲設備相連的那根網(wǎng)線中，基本上只存在兩種數(shù)據(jù)流量，一是業(yè)務應用流量，二是虛擬機本身的系統(tǒng)流量。這種環(huán)境下在交換機與存儲之間的鏈路上就不可避免的會產(chǎn)生傳輸瓶頸。以上都是我們進行的邏輯推論，但問題到底有多嚴重？我們將用測試截圖來一步步說明。

　　場景一：ERP流量

　　在一個VM上發(fā)起ERP查詢請求，ERP服務器為另一個同在當前物理服務器上的VM，雖然在這種情況下有一部分網(wǎng)絡流量被“消化”在了當前物理服務器內(nèi)部，不過沒關系，要關心的并不是這部分內(nèi)容，而是在物理鏈路上產(chǎn)生的流量變化。

　　ERP基礎流量

　　此處的ERP基礎流量其實是大量的數(shù)據(jù)庫查詢操作，X軸為時間軸(180秒)，Y軸為數(shù)據(jù)流量(單位是Byte)。由于ERP查詢腳本比較“單純”，可以看到，流量曲線也比較有規(guī)則，其非峰值流量并不大，基本在1MBps以下。

　　隨著ERP并發(fā)數(shù)的增加網(wǎng)絡流量產(chǎn)生的變化

　　我們測試的第二個ERP腳本，可看到，隨著并發(fā)數(shù)的增加，峰值流量曲線基本上是一路走高，瞬間最高達到了50MBps。但非峰值曲線并沒有大的變化，總體來說，網(wǎng)絡流量依然不高。

　　測試完ERP的兩個腳本后，重起了兩次虛擬機(VM)，VM的重起速度是非�？斓�，從截圖中也可以看到，兩次峰值流量的持續(xù)時間都只有不到10秒。由于VM的實體文件其實是存放在存儲設備中的，VM在重起時必定會從存儲中讀取大量數(shù)據(jù)，不過從測試截圖來看，重起VM所產(chǎn)生的流量對網(wǎng)絡造成的沖擊并不高。

　　場景二：各種流量疊加

　　在本場景中，將ERP流量作為基礎流量(必要流量)，一、對當前VM進行快照，二、在另一個VM中(不同物理服務器上)對存儲設備使用IOMETER進行吞吐測試。

　　所謂快照就是將VM當前的狀態(tài)進行“拍照”，主要包括當前VM的內(nèi)存數(shù)據(jù)、CPU狀態(tài)等信息。上圖中55MBps處的峰值是快照啟動時的流量，在快照進行中，流量基本維持在10MBps左右，雖然10MBps的流量并不高，但要知道，這一流量在非虛擬化環(huán)境中是不存在的。并且這僅是對一個VM進行快照，如果多臺VM同時進行快照，這一流量將不容小視，因為這一流量是疊加在業(yè)務應用流量之上的。

　　IOMETER吞吐測試起動后網(wǎng)絡流量達到了45MBps左右，此時的ERP流量被徹底淹沒了，最左端的VM快照流量也顯得有些微不足道。

　　從上面這些截圖中我們可以看到，服務器虛擬化以后，流量疊加所產(chǎn)生的問題不容小視，搭建的測試環(huán)境其實很簡單，所產(chǎn)生的網(wǎng)絡流量也相對“單純”，但這已經(jīng)可以說明問題。

　　首先，也是最重要的，在設計全局虛擬化拓撲結構時，要比以往發(fā)費更多精力關注由于網(wǎng)絡結構變化帶來的新性能瓶頸點，如何能讓整個網(wǎng)絡運行得高效且穩(wěn)定，初期設計變得尤為重要，一個大的方向就是將應用網(wǎng)絡與系統(tǒng)網(wǎng)絡相分離。另外，對于一些大流量的應用，例如對VM進行快照，雖然技術上支持任何時間進行，但為了避免對業(yè)務應用造成沖擊，這類操作應當盡量選擇在網(wǎng)絡空閑時進行。

標簽： 服務器 服務器管理 服務器虛擬化 服務器硬件 購買服務器 腳本 買服務器 數(shù)據(jù)庫 通信 網(wǎng)絡 問題 虛擬服務器 選擇

版權申明：本站文章部分自網(wǎng)絡，如有侵權，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權歸原作者所有，如需使用，請與原作者聯(lián)系。