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