服務器虛擬化使網絡管理變得更復雜
服務器虛擬化在數據中心領域中正得到越來越廣泛的實際應用。經濟因素與這一趨勢密不可分。服務器虛擬化可減少服務器的數量，所需的制冷能力和功率都更小，同時也大幅增加了靈活性，因此可以有效地降低總體擁有成本(TCO)。對于業務和服務器團隊而言，這的確是好消息，但對于網絡的管理來說，它又會產生怎樣的影響呢？事實情況是，它會使網絡管理變得更加復雜。
服務器虛擬化會牽涉到兩項重大的網絡問題。首先是虛擬局域網(VLAN)的配置問題。網絡管理者必須確認當物理服務器運行虛擬機時，同樣的交換機端口也被分配給了虛擬機使用的虛擬局域網。
解決方法之一是，服務器虛擬化團隊將虛擬機可能啟動的每一臺服務器告訴網絡管理團隊，并且對交換機端口進行預先配置。但這并不是理想的解決方案，因為這將導致在很大比例的交換機端口上定義VLAN。由于服務器團隊可能并不清楚鏡像啟動時所用的所有服務器，特別在災難恢復情況下他們要采取緊急措施的時候，情況將變得更加復雜。
第二個問題是指定服務質量(QoS)和執行網絡協議，例如訪問控制列表(ACL)。傳統上，這項工作是在與應用所運行的服務器相連的網絡交換機上完成的。當有了服務器虛擬化后，就出現了運行在物理服務器的Hypervisor下的軟件交換機，而非傳統意義上的連接到物理服務器的物理網絡交換機。
在軟件交換機上執行協議還是很重要。例如，有兩臺虛擬機，我們本意是這兩臺虛擬機相互通信，但如果有人控制了虛擬機1，便可以打開與虛擬機2的連接并盜取數據。而我們如果對服務器上的軟件交換機實施了訪問控制列表，這種入侵活動便可被阻止。
在虛擬化之前，此類行為一般都可阻止，由于虛擬機1和虛擬機2運行在不同的服務器上，因而可以通過在網絡交換機上定義訪問控制列表來阻止這種通信。在軟件交換機上執行這種協議可以保持安全性。但問題在于，如何讓軟件來實施協議。
要想使服務器虛擬化順利開展，克服這些挑戰將至關重要。目前，共有四種方法來解決這些問題。
虛擬化廠商的應對之法
市場上有多家提供虛擬化解決方案的廠商，例如VMware、思杰、微軟、紅帽等。不過，Vmware的解決方案應用最為廣泛，因此我們以它來舉例說明。
在圖1中，VMware的vCenter控制著虛擬流程并指導虛擬機應在哪里啟動。Hypervisor控制著服務器和運行在物理服務器上的虛擬機。vSwitch是VMware提供的一種2層軟件交換機。每臺虛擬機都有一個虛擬網卡(vNIC)。vNIC使用的是來自虛擬化廠商的訪問控制清單地址池，或者是企業建立和分配的訪問控制清單地址。該圖的目的并不是顯示真實環境下所有可能的變化情況，它只是展示整個虛擬化流程是如何運轉的。
步驟1是由服務器團隊定義出虛擬機的所有網絡特性和協議。操作員會告訴vCenter在步驟2中啟動虛擬機2。該過程中，vCenter和服務器上的Hypervisor之間會互相傳遞多條消息，例如，vCenter會將網絡協議信息推送給Hypervisor。在步驟3中，Hypervisor會為vSwitch配置正確的VLAN、QoS和協議信息。當虛擬機2上的應用開始發送包時，該協議會在vSwitch上實施。
這種方法解決了在vSwitch上實施協議的問題，但并沒有解決網絡交換機中的VLAN配置問題。虛擬化團隊需要告訴網絡管理團隊，應在虛擬機開始發送流量之前，為VLAN配置交換機端口，這就要求進行快速協調或者對交換機進行預先配置。當虛擬化團隊需要對虛擬機進行動態遷移時，協調問題會變得更加復雜。在移動服務器時，虛擬化團隊需要與網絡團隊進行協調，而且網絡團隊需要在成功遷移后完全清除老交換機上的配置。
使用該方法最大的問題是，虛擬化和網絡團隊之間進行協調的工作量將很大。虛擬化團隊必須對vCenter中的參數進行配置，例如VLAN編號、QoS和ACL等，而這些參數又是由網絡團隊控制的。這意味著服務器虛擬化團隊和網絡團隊之間需要不間斷的良好協調。VLAN或協議中的任何變化都必須立即反映到虛擬服務器配置中，而這其實意味著一個潛在的故障點。
另外一個值得擔憂的問題是，網絡團隊難以了解vSwitch內部的工作情況。因為vSwitch處在vCenter的控制下，而非傳統的網絡管理軟件。此外，對網絡團隊而言，虛擬機的透明度也極低。一些網絡廠商已經要求vCenter將變化或者對變化的抽樣調查通知給網絡團隊，并將其與傳統的網絡數據一同顯示出來。這些方法在一定程度上解決了可視性的問題。
#p#
四大方案破解VLAN配置問題
第一種方案是實現交換機與虛擬機管理軟件的同步。BladeNetworks目前提供了一種在其交換機上運行的應用，而Force10公司的下一版操作系統也可以解決VLAN的配置問題。這兩家公司的交換機會對vCenter進行查詢，監測各種變化，也可以收到vCenter發出宣告變化的消息。如果交換機發現vCenter配置有變化，它會自動執行配置。虛擬化操作員不必與網絡運營部門進行協調，因此能夠使虛擬機的啟動過程變得非常順利。交換機查詢間隔一定要小于一臺虛擬機啟動的時間，從而確保交換機能夠以足夠快的速度看到變化。在Force10的第一個版本中，它惟一監視的參數就是VLAN的參數。BladeNetwork則更進一步，根據vNIC或VM的UUID(通用唯一識別碼)對網絡交換機實施了全系列的協議。該解決方案仍然需要在vSwitch中實施協議。
第二種解決VLAN配置問題的方法是通過中間件協調控制虛擬機管理軟件和交換機。例如，使用惠普或Juniper等廠商提供的協調軟件，但這些軟件只能在其原廠的交換機上運行。Scalent和CA等管理廠商也提供了自己的解決方案。在這種情況下，協調軟件會與網絡交換機和vCenter對話，并協調兩個環境之間的配置變化。這種方法有一定的潛在優勢，即能夠廣泛適用于眾多交換機和虛擬化廠商。
第三種方案來自于思科。思科提供了一種稱為"1000V"的軟件交換機解決方案，用于替代vSwitch。1000V由兩個組件組成：VSM(VirtualSwitchModule)是虛擬交換機模塊，用于替代運行在Hypervisor內的vSwitch軟件;VEM(VirtualElementManager)則用于配置和存儲VSM網絡協議。
首先根據虛擬機的UUID或vMAC地址，在VEM中對虛擬機的VLAN和協議進行配置。在步驟2中，vCenter啟動一臺新的虛擬機或移動一臺虛擬機。在步驟3中，Hypervisor向VSM發出通知。接下來，VSM在第四個步驟中從VEM中提取協議信息。如果網絡交換機屬于Nexus產品線，它也可以從VEM中提取必要的VLAN和協議信息。至此，Hypervisor中的交換機和Nexus交換機都獲得了處理虛擬機2的正確信息。當虛擬機2開始發送流量時，所有正確的協議都會在Hypervisor中的1000V交換機上開始實施。
思科方案的好處與第一種方法相同。如果將1000V與已經為虛擬化做好準備的Nexus交換機一同使用，那么就可以解決網絡交換機中的VLAN問題。該方案的另一個好處在于，可以移動在網絡管理軟件的控制下的Hypervisor中的交換機，從而能夠清楚地劃分網絡團隊應擔負的責任。當然，它也有不足的一面。目前，思科只能提供適用于VMware的解決方案，對于Xen和HyperV則無能為力。
第四種方法采用了一種以網絡設備為中心的視角來解決問題。如附圖3所示，在步驟1中，按照虛擬網卡在網絡管理軟件中對虛擬機進行了定義。在步驟2中，vCenter指導Hypervisor啟動虛擬機。在第三個步驟中，Hypervisor會發送一個公告包，宣布它正在啟動二號虛擬機。該公告中包含二號虛擬機的vNIC及其UUID。在步驟4中，交換機發現了該公告并發送其VLAN和其它協議信息的請求。接下來，交換機會向進入網絡的任何流量實施這些協議。
該方案的重點是交換機只在網絡交換機中實施協議，以藍點表示，而不會在vSwitch中實施。交換機還會監視來自Hypervisor的消息，這些消息表明虛擬機是否移動。如果發現此類消息，交換機便會清除與該vNIC相關的VLAN和協議信息。使用該解決方案的廠商包括AristaNetworks、BladeandEnterasys，另外惠普和Juniper也在通過其協調方法使用該解決方案。Brocade等其它廠商也在計劃提供該解決方案。ExtremeNetworks將該技術用于QoS和協議，但未用于VLAN。
這種方法努力想讓虛擬化團隊不再被牽連到網絡協議的實施工作中來。然而，還有兩個問題。首先是服務器虛擬化和聯網團隊仍然必須就VLAN的編號進行協調。目前，Enterasys可以向vSwitch自動提供VLAN編號，而Arista也計劃在近期加入該功能。
這種方法最大的問題是，它沒有在vSwitch上實施協議，因而使得同一服務器上的虛機之間的交通流量繞過訪問控制列表和其它安全協議。為解決這一問題，Enterasys和Arista計劃添加在vSwitch上實施協議的能力。
在未來，解決這一問題的辦法之一是允許交換機做"180度急轉彎"。這樣，可對vSwitch進行配置，規定其將所有的流量，甚至包括虛擬機1至虛擬機2的流量，都直接發送給網絡交換機。網絡交換機接下來會實施協議并指定QoS。虛擬機1至虛擬機2的流量可以回傳至vSwitch，由它將其發送至虛擬機2。
#p#
這將使vSwitch變成一個只擔負轉發職責的"啞巴"交換機。問題是，所有2層交換機對應的802.1D標準不允許從一個端口發出的流量沿原路返回到該端口。因此，在現行的規則下，網絡交換機無法將從虛擬機1發往虛擬機2的包沿原路返回，因為這樣是違反規則的。該規則的目的是防止出現回路。IEEE目前正在對802.1D進行修訂，允許交換機執行"180度急轉彎"，并且正在開展其它一些工作，實現"啞"交換機在Hypervisor中的標準化。當這種方式普及后，它將能夠解決這一問題，并且可以免去網絡和服務器團隊之間絕大多數的協調工作。
Enterasys目前還有一種變通辦法，可以指導vSwitch將每臺虛擬機安置在獨立的VLAN中。即選擇目前沒有使用的VLAN編號，來預防任何潛在的問題。由于虛擬機處于不同的VLAN中，它們無法相互通信。當數據包到達網絡交換機時，交換機會使用真正分配給虛擬機的編號來替換VLAN編號，讓網絡及其目的地以為虛擬機一直處于正確的VLAN中。
問題仍未徹底解決
另外，還有一個VLAN配置問題是上述技術仍然沒有解決的。當向某個端口分配一個新的VLAN編號時，需要使用該VLAN編號連接所有其它的端口。這就要求聚集在這條在路徑上的所有交換機都要對VLAN進行定義。
例如，如果VLAN5支持某項應付賬應用。所有支持該應用的虛擬機都位于一臺機架式交換機上，且該交換機已經針對VLAN5進行了配置。由于負載的原因，一臺運行應付賬應用的虛擬機需要被遷移到數據中心另外一個帶有自己交換機的機架服務器上。
保留VLAN意味著所有的中間交換機都需要針對VLAN5進行配置;如果未對其進行配置，則等于破壞了VLAN。目前沒有那個解決方案說清楚如何自動分配交換機中的虛擬局域網。這就意味著如果虛擬機可以在數據中心內部遷移，虛擬局域網數量必須在所有的核心交換機和集合交換機上事先進行配置。。此外，這個問題在近期內不太可能得到解決。
業界已經開發出一系列解決端口VLAN和協議問題的解決方案。但是，短期內，網絡和虛擬化團隊需要進行大量的協調工作，以保障工作的順利運行。"180度急轉"是最好的長期性解決方案，而且業界正在朝這個方向努力。由于目前市場上還沒有出現能夠適用于所有虛擬化解決方案的全系列解決方案，因此網絡管理者們應當充分了解各種解決方案。
【編輯推薦】
