服務器虛擬化的陰暗面
服務器虛擬化在數(shù)據(jù)中心領域中正得到越來越廣泛的實際應用。經(jīng)濟因素與這一趨勢密不可分。服務器虛擬化可減少服務器的數(shù)量，所需的制冷能力和功率都更小，同時也大幅增加了靈活性，因此可以有效地降低總體擁有成本（TCO）。對于業(yè)務和服務器團隊而言，這的確是好消息，但對于網(wǎng)絡的管理來說，它又會產(chǎn)生怎樣的影響呢？事實情況是，它會使網(wǎng)絡管理變得更加復雜。
服務器虛擬化會牽涉到兩項重大的網(wǎng)絡問題。首先是虛擬局域網(wǎng)（VLAN）的配置問題。網(wǎng)絡管理者必須確認當物理服務器運行虛擬機時，同樣的交換機端口也被分配給了虛擬機使用的虛擬局域網(wǎng)。
解決方法之一是，服務器虛擬化團隊將虛擬機可能啟動的每一臺服務器告訴網(wǎng)絡管理團隊，并且對交換機端口進行預先配置。但這并不是理想的解決方案，因為這將導致在很大比例的交換機端口上定義VLAN。由于服務器團隊可能并不清楚鏡像啟動時所用的所有服務器，特別在災難恢復情況下他們要采取緊急措施的時候，情況將變得更加復雜。
第二個問題是指定服務質(zhì)量（QoS）和執(zhí)行網(wǎng)絡協(xié)議，例如訪問控制列表（ACL）。傳統(tǒng)上，這項工作是在與應用所運行的服務器相連的網(wǎng)絡交換機上完成的。當有了服務器虛擬化后，就出現(xiàn)了運行在物理服務器的Hypervisor下的軟件交換機，而非傳統(tǒng)意義上的連接到物理服務器的物理網(wǎng)絡交換機。
在軟件交換機上執(zhí)行協(xié)議還是很重要。例如，有兩臺虛擬機，我們本意是這兩臺虛擬機相互通信，但如果有人控制了虛擬機1，便可以打開與虛擬機2的連接并盜取數(shù)據(jù)。而我們?nèi)绻麑Ψ掌魃系能浖粨Q機實施了訪問控制列表，這種入侵活動便可被阻止。
在虛擬化之前，此類行為一般都可阻止，由于虛擬機1和虛擬機2運行在不同的服務器上，因而可以通過在網(wǎng)絡交換機上定義訪問控制列表來阻止這種通信。在軟件交換機上執(zhí)行這種協(xié)議可以保持安全性。但問題在于，如何讓軟件來實施協(xié)議。
要想使服務器虛擬化順利開展，克服這些挑戰(zhàn)將至關重要。目前，共有四種方法來解決這些問題。
#p#
虛擬化廠商的應對之法
市場上有多家提供虛擬化解決方案的廠商，例如VMware、思杰、微軟、紅帽等。不過，Vmware的解決方案應用最為廣泛，因此我們以它來舉例說明。
在圖1中，VMware的vCenter控制著虛擬流程并指導虛擬機應在哪里啟動。Hypervisor控制著服務器和運行在物理服務器上的虛擬機。vSwitch是VMware提供的一種2層軟件交換機。每臺虛擬機都有一個虛擬網(wǎng)卡（vNIC）。vNIC使用的是來自虛擬化廠商的訪問控制清單地址池，或者是企業(yè)建立和分配的訪問控制清單地址。該圖的目的并不是顯示真實環(huán)境下所有可能的變化情況，它只是展示整個虛擬化流程是如何運轉(zhuǎn)的。
步驟1是由服務器團隊定義出虛擬機的所有網(wǎng)絡特性和協(xié)議。操作員會告訴vCenter在步驟2中啟動虛擬機2。該過程中，vCenter和服務器上的Hypervisor之間會互相傳遞多條消息，例如，vCenter會將網(wǎng)絡協(xié)議信息推送給Hypervisor。在步驟3中，Hypervisor會為vSwitch配置正確的VLAN、QoS和協(xié)議信息。當虛擬機2上的應用開始發(fā)送包時，該協(xié)議會在vSwitch上實施（圖1中的藍點表示）。
這種方法解決了在vSwitch上實施協(xié)議的問題，但并沒有解決網(wǎng)絡交換機中的VLAN配置問題。虛擬化團隊需要告訴網(wǎng)絡管理團隊，應在虛擬機開始發(fā)送流量之前，為VLAN配置交換機端口，這就要求進行快速協(xié)調(diào)或者對交換機進行預先配置。當虛擬化團隊需要對虛擬機進行動態(tài)遷移時，協(xié)調(diào)問題會變得更加復雜。在移動服務器時，虛擬化團隊需要與網(wǎng)絡團隊進行協(xié)調(diào)，而且網(wǎng)絡團隊需要在成功遷移后完全清除老交換機上的配置。
使用該方法最大的問題是，虛擬化和網(wǎng)絡團隊之間進行協(xié)調(diào)的工作量將很大。虛擬化團隊必須對vCenter中的參數(shù)進行配置，例如VLAN編號、QoS和ACL等，而這些參數(shù)又是由網(wǎng)絡團隊控制的。這意味著服務器虛擬化團隊和網(wǎng)絡團隊之間需要不間斷的良好協(xié)調(diào)。VLAN或協(xié)議中的任何變化都必須立即反映到虛擬服務器配置中，而這其實意味著一個潛在的故障點。
另外一個值得擔憂的問題是，網(wǎng)絡團隊難以了解vSwitch內(nèi)部的工作情況。因為vSwitch處在vCenter的控制下，而非傳統(tǒng)的網(wǎng)絡管理軟件。此外，對網(wǎng)絡團隊而言，虛擬機的透明度也極低。一些網(wǎng)絡廠商已經(jīng)要求vCenter將變化或者對變化的抽樣調(diào)查通知給網(wǎng)絡團隊，并將其與傳統(tǒng)的網(wǎng)絡數(shù)據(jù)一同顯示出來。這些方法在一定程度上解決了可視性的問題。
#p#
四大方案破解VLAN配置問題
第一種方案是實現(xiàn)交換機與虛擬機管理軟件的同步。Blade Networks目前提供了一種在其交換機上運行的應用，而Force10公司的下一版操作系統(tǒng)也可以解決VLAN的配置問題。這兩家公司的交換機會對vCenter進行查詢，監(jiān)測各種變化，也可以收到vCenter發(fā)出宣告變化的消息。如果交換機發(fā)現(xiàn)vCenter配置有變化，它會自動執(zhí)行配置。虛擬化操作員不必與網(wǎng)絡運營部門進行協(xié)調(diào)，因此能夠使虛擬機的啟動過程變得非常順利。交換機查詢間隔一定要小于一臺虛擬機啟動的時間，從而確保交換機能夠以足夠快的速度看到變化。在Force10的第一個版本中，它惟一監(jiān)視的參數(shù)就是VLAN的參數(shù)。Blade Network則更進一步，根據(jù)vNIC或VM的UUID（通用唯一識別碼）對網(wǎng)絡交換機實施了全系列的協(xié)議。該解決方案仍然需要在vSwitch中實施協(xié)議。
第二種解決VLAN配置問題的方法是通過中間件協(xié)調(diào)控制虛擬機管理軟件和交換機。例如，使用惠普或Juniper等廠商提供的協(xié)調(diào)軟件，但這些軟件只能在其原廠的交換機上運行。Scalent和CA等管理廠商也提供了自己的解決方案。在這種情況下，協(xié)調(diào)軟件會與網(wǎng)絡交換機和vCenter對話，并協(xié)調(diào)兩個環(huán)境之間的配置變化。這種方法有一定的潛在優(yōu)勢，即能夠廣泛適用于眾多交換機和虛擬化廠商。
第三種方案來自于思科。思科提供了一種稱為"1000V"的軟件交換機解決方案，用于替代vSwitch。1000V由兩個組件組成：VSM（Virtual Switch Module）是虛擬交換機模塊，用于替代運行在Hypervisor內(nèi)的vSwitch軟件；VEM（Virtual Element Manager）則用于配置和存儲VSM網(wǎng)絡協(xié)議。
圖2顯示的是該過程的工作原理。首先根據(jù)虛擬機的UUID或vMAC地址，在VEM中對虛擬機的VLAN和協(xié)議進行配置。在步驟2中，vCenter啟動一臺新的虛擬機或移動一臺虛擬機。在步驟3中，Hypervisor向VSM發(fā)出通知。接下來，VSM在第四個步驟中從VEM中提取協(xié)議信息。如果網(wǎng)絡交換機屬于Nexus產(chǎn)品線，它也可以從VEM中提取必要的VLAN和協(xié)議信息。至此，Hypervisor中的交換機和Nexus交換機都獲得了處理虛擬機2的正確信息。當虛擬機2開始發(fā)送流量時，所有正確的協(xié)議都會在Hypervisor中的1000V交換機上開始實施（以藍點表示）。
思科方案的好處與第一種方法相同。如果將1000V與已經(jīng)為虛擬化做好準備的Nexus交換機一同使用，那么就可以解決網(wǎng)絡交換機中的VLAN問題。該方案的另一個好處在于，可以移動在網(wǎng)絡管理軟件的控制下的Hypervisor中的交換機，從而能夠清楚地劃分網(wǎng)絡團隊應擔負的責任。當然，它也有不足的一面。目前，思科只能提供適用于VMware的解決方案，對于Xen和HyperV則無能為力。
第四種方法采用了一種以網(wǎng)絡設備為中心的視角來解決問題。如附圖3所示，在步驟1中，按照虛擬網(wǎng)卡在網(wǎng)絡管理軟件中對虛擬機進行了定義。在步驟2中，vCenter指導Hypervisor啟動虛擬機。在第三個步驟中，Hypervisor會發(fā)送一個公告包，宣布它正在啟動二號虛擬機。該公告中包含二號虛擬機的vNIC及其UUID。在步驟4中，交換機發(fā)現(xiàn)了該公告并發(fā)送其VLAN和其它協(xié)議信息的請求。接下來，交換機會向進入網(wǎng)絡的任何流量實施這些協(xié)議。
該方案的重點是交換機只在網(wǎng)絡交換機中實施協(xié)議，以藍點表示，而不會在vSwitch中實施。交換機還會監(jiān)視來自Hypervisor的消息，這些消息表明虛擬機是否移動。如果發(fā)現(xiàn)此類消息，交換機便會清除與該vNIC相關的VLAN和協(xié)議信息。使用該解決方案的廠商包括Arista Networks、Blade and Enterasys，另外惠普和Juniper也在通過其協(xié)調(diào)方法使用該解決方案。Brocade等其它廠商也在計劃提供該解決方案。Extreme Networks將該技術用于QoS和協(xié)議，但未用于VLAN。
這種方法努力想讓虛擬化團隊不再被牽連到網(wǎng)絡協(xié)議的實施工作中來。然而，還有兩個問題。首先是服務器虛擬化和聯(lián)網(wǎng)團隊仍然必須就VLAN的編號進行協(xié)調(diào)。目前，Enterasys可以向vSwitch自動提供VLAN編號，而Arista也計劃在近期加入該功能。
這種方法最大的問題是，它沒有在vSwitch上實施協(xié)議，因而使得同一服務器上的虛機之間的交通流量繞過訪問控制列表和其它安全協(xié)議。為解決這一問題，Enterasys和Arista計劃添加在vSwitch上實施協(xié)議的能力，如圖3中A所示。
在未來，解決這一問題的辦法之一是允許交換機做"180度急轉(zhuǎn)彎"。這樣，可對vSwitch進行配置，規(guī)定其將所有的流量，甚至包括虛擬機1至虛擬機2的流量，都直接發(fā)送給網(wǎng)絡交換機。網(wǎng)絡交換機接下來會實施協(xié)議并指定QoS。虛擬機1至虛擬機2的流量可以回傳至vSwitch，由它將其發(fā)送至虛擬機2。
這將使vSwitch變成一個只擔負轉(zhuǎn)發(fā)職責的"啞巴"交換機。問題是，所有2層交換機對應的802.1D標準不允許從一個端口發(fā)出的流量沿原路返回到該端口。因此，在現(xiàn)行的規(guī)則下，網(wǎng)絡交換機無法將從虛擬機1發(fā)往虛擬機2的包沿原路返回，因為這樣是違反規(guī)則的。該規(guī)則的目的是防止出現(xiàn)回路。IEEE目前正在對802.1D進行修訂，允許交換機執(zhí)行"180度急轉(zhuǎn)彎"，并且正在開展其它一些工作，實現(xiàn)"啞"交換機在Hypervisor中的標準化。當這種方式普及后，它將能夠解決這一問題，并且可以免去網(wǎng)絡和服務器團隊之間絕大多數(shù)的協(xié)調(diào)工作。
Enterasys目前還有一種變通辦法，可以指導vSwitch將每臺虛擬機安置在獨立的VLAN中。即選擇目前沒有使用的VLAN編號，來預防任何潛在的問題。由于虛擬機處于不同的VLAN中，它們無法相互通信。當數(shù)據(jù)包到達網(wǎng)絡交換機時，交換機會使用真正分配給虛擬機的編號來替換VLAN編號，讓網(wǎng)絡及其目的地以為虛擬機一直處于正確的VLAN中。
#p#
問題仍未徹底解決
另外，還有一個VLAN配置問題是上述技術仍然沒有解決的。當向某個端口分配一個新的VLAN編號時，需要使用該VLAN編號連接所有其它的端口。這就要求聚集在這條在路徑上的所有交換機都要對VLAN進行定義。
例如，如果VLAN 5支持某項應付賬應用。所有支持該應用的虛擬機都位于一臺機架式交換機上，且該交換機已經(jīng)針對VLAN 5進行了配置。由于負載的原因，一臺運行應付賬應用的虛擬機需要被遷移到數(shù)據(jù)中心另外一個帶有自己交換機的機架服務器上。
保留VLAN意味著所有的中間交換機都需要針對VLAN5進行配置；如果未對其進行配置，則等于破壞了VLAN。目前沒有那個解決方案說清楚如何自動分配交換機中的虛擬局域網(wǎng)。這就意味著如果虛擬機可以在數(shù)據(jù)中心內(nèi)部遷移，虛擬局域網(wǎng)數(shù)量必須在所有的核心交換機和集合交換機上事先進行配置。。此外，這個問題在近期內(nèi)不太可能得到解決。
業(yè)界已經(jīng)開發(fā)出一系列解決端口VLAN和協(xié)議問題的解決方案。但是，短期內(nèi)，網(wǎng)絡和虛擬化團隊需要進行大量的協(xié)調(diào)工作，以保障工作的順利運行。"180度急轉(zhuǎn)"是最好的長期性解決方案，而且業(yè)界正在朝這個方向努力。由于目前市場上還沒有出現(xiàn)能夠適用于所有虛擬化解決方案的全系列解決方案，因此網(wǎng)絡管理者們應當充分了解各種解決方案。
#p#
【深度點評】
為了更加全面地看待本文所探討的問題，本報特地邀請服務器虛擬化方面的專家，對此文進行深度點評，期冀能給讀者呈現(xiàn)更深更廣的視角。
本文討論的是網(wǎng)絡廠商針對服務器虛擬化所做出的技術反映。文章討論了4種技術方案，VMware的vSwitch（方案1）和思科的1000v（方案3）的基本思路是一致；方案2的orchestration類似于一種中間件，這符合惠普一貫的作風，不過他們擅長做管理軟件嗎？而且我不喜歡這種方式，層次太多更不好管理；方案4是較好的方案，更有可能在虛擬機管理軟件和網(wǎng)絡設備間建立一種標準協(xié)議，從而實現(xiàn)不同虛擬機廠商和網(wǎng)絡廠商的兼容。
對這個問題，我希望的解決方案是這樣的：
應該是以虛擬化管理軟件為中心，這個軟件管理的不僅是虛擬機和物理服務器，而且包括所有的網(wǎng)絡設備；
傳統(tǒng)上網(wǎng)絡系統(tǒng)中鏈接主機的最后一條（last hop）是硬件交換機，而在虛擬化環(huán)境中一定是軟交換機（如vSwitch或v1000）；
不論是軟交換機還是硬交換機，要提供可編程的控制接口或者標準協(xié)議，所有網(wǎng)絡設備由統(tǒng)一的管理軟件（如虛擬化管理軟件，類似vCenter或更上層的管理軟件）進行管理。
總地說來，這篇文章很好，提的問題很實際，有一定深度。不過文章的標題看起來有點夸張，實際上虛擬化是未來的一種趨勢，當一種技術帶來更大的靈活性，使人們能夠完成以前無法完成的任務的同時，必然會帶來更大的復雜性。虛擬化是一種潮流，從處理器到服務器，然后將是網(wǎng)絡，再接著是整個IT基礎設施，再之后呢，無限的空間可以想象……
——中國移動研究院云計算研究員 張志宏
文中提到的由服務器虛擬化所引起的兩個重大的網(wǎng)絡問題，即虛擬局域網(wǎng)（VLAN）的配置問題以及服務質(zhì)量（QoS）和執(zhí)行網(wǎng)絡協(xié)議問題，確實是一直以來困擾服務器虛擬化廠商和網(wǎng)絡管理廠商的難題，也在某種程度上影響了服務器虛擬化的順利開展。
針對這兩個問題，文中提到了四種解決方案，但這四種方案都存在一定的局限性。
VMware通過對內(nèi)置于Hypervisor中的vSwitch進行配置來解決實施協(xié)議的問題，但對VLAN的配置問題依然沒有觸及。
為了解決VLAN的配置問題，虛擬化組件群和網(wǎng)絡組件群之間的協(xié)調(diào)是關鍵所在，F(xiàn)orce10和Blade Networks通過在交換機上安裝監(jiān)控程序來監(jiān)聽vCenter的變化，惠普和Juniper等廠商也提供了協(xié)調(diào)軟件，但這些軟件只能在其自家生產(chǎn)的交換機上運行，Scalent和CA等管理廠商推出了會與網(wǎng)絡交換機和vCenter對話的協(xié)調(diào)軟件。
思科的解決方案與VMware有異曲同工之處，配合為虛擬化做好準備的Nexus交換機一同使用，也可以解決VLAN的配置問題，但該方法主要針對VMware的服務器虛擬化產(chǎn)品提出的，對其它服務器虛擬化產(chǎn)品則束手無策，局限性很明顯。
第四種方法以網(wǎng)絡設備為中心的視角來解決問題，主要體現(xiàn)在Hypervisor直接與網(wǎng)絡交換機進行通信，僅在網(wǎng)絡交換機上實施協(xié)議，支持廠商有Arista Networks, Blade and Enterasys等。該方法旨在讓虛擬化團隊不再參與網(wǎng)絡協(xié)議的實施工作，但同時也產(chǎn)生了兩個問題，其一是服務器虛擬化和網(wǎng)絡團隊仍然必須就VLAN的編號進行協(xié)調(diào)，對該問題，Enterasys目前提供了一種變通辦法；其二是由于沒有在vSwitch上實施協(xié)議，使得同一服務器上的虛機之間的交通流量繞過訪問控制列表和其它安全協(xié)議，該問題是一個非常重要的問題，Enterasys和Arista等都在尋求積極的解，甚至IEEE也參與到這一熱潮中，正在通過對802.1D進行修訂，以及對vSwitch的標準化來對解決這些問題提供支持。
從上面的解決方案及其演進過程中，我們不難看出，這些方法多是互聯(lián)網(wǎng)和虛擬化團隊在短期內(nèi)協(xié)調(diào)各項活動，甚而是特定廠商特定產(chǎn)品之間的協(xié)調(diào)，而非長久之計。
——運軟網(wǎng)絡科技（上海）有限公司研究工程師 熊麗 博士
【編輯推薦】
