服務器虛擬化使網(wǎng)絡管理變得更復雜
服務器虛擬化在數(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)將至關重要。目前，共有四種方法來解決這些問題。
虛擬化廠商的應對之法
市場上有多家提供虛擬化解決方案的廠商，例如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上實施。
這種方法解決了在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)交換機與虛擬機管理軟件的同步。BladeNetworks目前提供了一種在其交換機上運行的應用，而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ù)。BladeNetwork則更進一步，根據(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(VirtualSwitchModule)是虛擬交換機模塊，用于替代運行在Hypervisor內(nèi)的vSwitch軟件;VEM(VirtualElementManager)則用于配置和存儲VSM網(wǎng)絡協(xié)議。
首先根據(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é)議信息。使用該解決方案的廠商包括AristaNetworks、BladeandEnterasys，另外惠普和Juniper也在通過其協(xié)調(diào)方法使用該解決方案。Brocade等其它廠商也在計劃提供該解決方案。ExtremeNetworks將該技術(shù)用于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é)議的能力。
在未來，解決這一問題的辦法之一是允許交換機做"180度急轉(zhuǎn)彎"。這樣，可對vSwitch進行配置，規(guī)定其將所有的流量，甚至包括虛擬機1至虛擬機2的流量，都直接發(fā)送給網(wǎng)絡交換機。網(wǎng)絡交換機接下來會實施協(xié)議并指定QoS。虛擬機1至虛擬機2的流量可以回傳至vSwitch，由它將其發(fā)送至虛擬機2。
#p#
這將使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中。
問題仍未徹底解決
另外，還有一個VLAN配置問題是上述技術(shù)仍然沒有解決的。當向某個端口分配一個新的VLAN編號時，需要使用該VLAN編號連接所有其它的端口。這就要求聚集在這條在路徑上的所有交換機都要對VLAN進行定義。
例如，如果VLAN5支持某項應付賬應用。所有支持該應用的虛擬機都位于一臺機架式交換機上，且該交換機已經(jīng)針對VLAN5進行了配置。由于負載的原因，一臺運行應付賬應用的虛擬機需要被遷移到數(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)絡管理者們應當充分了解各種解決方案。
【編輯推薦】
