為何需要虛擬交換器？

伺服器的虛擬化，使得實體主機原本連接的邊緣交換器（Edge Switch），轉換成為Hypervisor虛擬層模擬出來的虛擬交換器，提供虛擬機器連接網路的服務。而隨著技術的演進，網路設備業者在去年推出了首款第3方的虛擬交換器軟體，安裝在虛擬機器所在的虛擬平臺伺服器後，便能提供原生虛擬交換器所不具備的網路功能。

另外，新的技術標準也在研議當中，未來虛擬交換器的大部分功能，可以改由實體交換器提供，使得IT人員可以更容易地在伺服器的虛擬化環境中，管理進、出虛擬網路的流量，並能降低虛擬平臺伺服器的硬體負載。

提供L2等級的流量管理，並因應虛擬網路的連線方式，精簡不必要的網路功能

在虛擬網路，虛擬交換器所提供的是L2等級的服務，像是VLAN、Port Mirror等企業常用到的功能，都可以內建在虛擬交換器的軟體平臺，和實體交換器相比，它所具備的功能較少，其中的主要原因，和虛擬網路的連線方式不同有關。

在實體的網路環境，為了避免網路斷線，造成伺服器的服務中斷，我們可以將伺服器同時連接到多臺交換器，而交換器之間也會相互連線，形成綿密的備援架構，在此同時，交換器會透過Spanning tree protocol（STP）的功能，演算出伺服器傳送資料的最佳路徑，並且暫時停用其他的備援連線，完成收斂的動作，以防止迴圈現象的產生，致使網路癱瘓。而在虛擬網路的環境，虛擬機器與交換器之間並非透過網路線做連線，所以只要虛擬平臺伺服器沒有發生故障，虛擬機器的對外網路就能正常連通，故虛擬機器多半僅會同時連線到一臺虛擬交換器，而隨著實體設備的虛擬化，像是STP等使用不到的網路功能，也就不復存在。

虛擬交換器的類型

一般而言，虛擬交換器可以分為External及Private等2種類型。

External交換器可以將虛擬平臺伺服器的實體網卡指派為Uplink埠使用，提供虛擬機器連接實體網路，不僅如此，許多的虛擬交換器還支援業界共通的802.3ad標準，當Uplink埠的數量大於1組時，我們可以透過這項功能，將它們集結成為群組，讓虛擬與實體交換器之間的傳輸頻寬得以倍增。

相對於前者，Private交換器則不具備Uplink埠，因此與實體環境隔離，形成全然封閉的網路環境，這種虛擬交換器，一般是提供給企業架設不需要連接實體網路的測試平臺。

比較特別的是，微軟的Hyper-V除了External、Private等2種虛擬交換器外，還提供了一種Internal交換器，它和Private交換器的唯一差別之處，位於Internal交換器上的虛擬機器，可以連接Hyper-V的Host OS，也就是底層的Windows Server 2008，藉此增加虛擬交換器的使用彈性。

交換器在企業內部，屬於隨處可見的網路基礎設施，當需要連線的電腦太多，造成交換器的網路埠數量不敷使用時，通常會以串接其他交換器的方式做為擴充，反觀虛擬交換器，因為本身擁有為數可觀的虛擬網路埠，而沒有此一問題。

像是VMware的vSphere，及它的精簡版本ESXi，一臺虛擬交換器最多可以提供1,016臺虛擬機器連接網路，所以2臺虛擬交換器之間，通常不會相互連線。

除非是基於安全上的需求，而將一臺具備防火牆，或者是IPS等防護功能的虛擬設備（Virtual Appliance），放置在External交換器，及虛擬機器所在的Private交換器中間，提供流量檢測的功能。例如iThome在2008年曾經測試過的Reflex System VSA，就是該類型防護產品當中的其中一種。

而隨著新版伺服器虛擬化產品的推出，業界也提供了更好的方法，從而提升流量的檢測效能，及減少硬體資源的使用量，而這就是我們接下來，將會介紹到的VMsafe。

具備防護虛擬機器的功能

虛擬交換器除了提供網路流量的交換服務外，也和虛擬機器的安全防護息息相關。

最為常見的做法，就是透過交換器，將內部網路切割為多個VLAN，由於每個VLAN都是各自分開的廣播網域，如此一來，當網路型的病毒在內部爆發時，就不能任意透過廣播的方式擴散到所有電腦。

另外，像是VMware虛擬交換器的PortGroup，也可以算是一種類似的應用，我們可以根據虛擬機器的性質，而對應到不同的PortGroup，並各自套用不同的交換器設定，而各個PortGroup，還可以指派不同的VLAN id，便於企業能彈性管理虛擬網路。

透過VMware虛擬交換器的設定介面，我們最多可以在一臺虛擬交換器設定512個PortGroup，而每個PortGroup可以包含1到多個不等的虛擬網路埠。以每臺vSphere（含舊版ESX）/ESXi版本的虛擬平臺伺服器來說，其PortGroup最大值為4,096個，和虛擬網路埠的最大值相等。

VMsafe也和虛擬交換器有關，它是VMware在vSphere，及ESXi 4.0的新版伺服器虛擬化平臺，所提供的一種防護技術，其做法是透過一臺裝有防護產品的虛擬設備，替代原本安裝在各臺虛擬機器上的主機型防護軟體，達到節省硬體資源使用的目的。

它一共包含vCompute（CPU/Memory）、vNetwork Appliance（DVFilter），及Virtual Disk Development Kit（VDDK）等3種不同功能的API，VMware將它們開放給協力的資安廠商，開發對應的防護產品。其中，vNetwork Appliance在架構上必須搭配虛擬交換器的機制運作，以便透過Fast Path，及Slow Path等2種做法，對於虛擬網路當中的流量，進行深度不等的檢測。

Fast Path的做法，是完全整合虛擬交換器，使之變成一臺具備防護功能的網路設備，由於Fast Path僅允許在流量通過交換器的同時，進行基本的檢測，以免對於網路的效能造成太大影響；而Slow Path則是將流量轉送到防護產品所在的虛擬設備做檢測，確認沒有問題之後，才會放行通過，反之，則是直接丟棄。

不論是Fast Path，或是Slow Path，vNetwork Appliance API需要在虛擬平臺伺服器安裝驅動程式，修改虛擬交換器的設定，使得虛擬設備能夠介接VMsafe，提供服務。

有了該項技術後，企業就不需要架設前、後2層的虛擬交換器，所以網路效能的提升是可以預期的，也因此當VMsafe技術隨著vSphere/ESXi 4.0的推出而實用化之後，像是Reflex System這家公司，便以整合VMsafe技術的新版IPS產品vTrust，替代原本的VSA產品線。

除了Cisco外，尚有其他第3方虛擬交換器軟體，提供非VMware平臺移轉網路設備的能力

上述的虛擬交換器都是在固定的虛擬平臺伺服器上作業，而虛擬機器的線上移轉，是伺服器虛擬化之後，最重要的一項功能應用，當底層的虛擬平臺伺服器需要停機維修，或者負載過高時，我們可以在虛擬機器保持服務的前提下，將其轉移到另外一臺虛擬平臺伺服器繼續運作，除了VMware的VMotion外，像是微軟的Hyper-V，及Citrix的XenServer等伺服器虛擬化套件，都有相同的移轉功能。

對於IT人員來說，這類型的移轉功能，雖能保證虛擬機器和實體網路之間的連線不會中斷，然而，位於原本虛擬交換器上的網路設定，並不會隨之移動，必須在移轉過去的另外一臺虛擬平臺伺服器，以手動方式設定。

為了解決這個管理上的難題，VMware後來決定正式在vSphere，及ESXi 4.0的版本，額外提供了分散式虛擬交換器（vNetwork Distributed Switch，vDS）的新功能，使得網路設定，終於可以隨著虛擬機器的線上移轉而同時移動。

所有版本的vSphere，及ESXi 4.0皆有支援這項功能，而它必須搭配vCenter伺服器，才能讓我們在虛擬網路部署vDS交換器，及操作該種交換器的各項功能。

我們可以將vDS交換器看成是一臺大型的機箱式交換器，而架構下的虛擬平臺伺服器，則可當做是一張張的線卡（Line card），因此線上移轉虛擬機器的動作，僅被視為連接到同一交換器的不同網路埠而己，對應的網路設定也不會有任何改變。

為了達到這個目的，vDS交換器也同樣具備PortGroup的功能，稱之為dvPortGroup，當我們架設vDS交換器的同時，可以選擇是否同時建立預設的第1個dvPortGroup，隨後將標準虛擬交換器上的虛擬機器移轉到此，便大致完成部署。隨後，當虛擬機器線上移轉到其他的虛擬平臺伺服器後，仍然位於同一個dvPortGroup，使得原本的網路設定，可以繼續生效。

另外，VMware也將vDS交換器的API，提供給網路設備的製造商，使他們能夠運用這項技術，開發第3方的虛擬交換器軟體，Cisco的Nexus 1000V，就是業界推出的首款第3方產品，他們將自家的虛擬交換器技術，稱之為「VN-Link」，Nexus 1000V是其中的軟體型式產品，另外也有硬體型式的Nexus實體交換器推出。

就功能而言，Nexus 1000V不僅具備vDS交換器的所有功能，而且也提供了NetFlow及ERSSPAN等Cisco網路設備專屬的功能。

而在其他平臺，也有和Nexus 1000V相同的計畫正在進行，其中，開放原始碼的Open vSwitch，是成果最為具體的一款套件。根據Open vSwitch官網的資料，他們的合作對象是開放原始碼版本的Xen、KVM，及Citrix的XenServer等其他非VMware的伺服器虛擬化平臺。

而在今年5月，Open vSwitch的1.0版本，已能安裝在XenServer的5.5版本運作，當它安裝完成後，XenServer本機的管理介面，會新增Open vSwitch的管理選項；至於虛擬交換器的管理，則可以透過網頁介面，及類似於Cisco IOS的文字指令等2種方式操作。就部署方式來說，除了現行的手動安裝外，未來Open vSwitch將會成為Xen雲端平臺（Xen Cloud Platform，XCP）的預設虛擬交換器，屆時不需要安裝，就能直接使用。

Open vSwitch的目標，是為非VMware的伺服器虛擬化平臺提供類似vDS的功能，而他們的計畫還不僅如此，在後續的版本，還會加入完整的L3路由能力、802.1x等功能，使之更加強大。

新標準成形後，可以整合實體交換器，提供虛擬網路的設定管理

對於網路設備的製造商而言，推出第3方的虛擬交換器軟體，只是他們整合伺服器虛擬化技術的其中一步，未來待IEEE正式通過相關的技術標準後，虛擬交換器的大部分功能，可以透過實體交換器提供，在這樣子的架構下，原生的虛擬交換器，會被同樣是內建在Hypervisor虛擬層的新型物件所替代，同時不再負責網路流量的交換，僅是做為虛擬機器連通實體網路的媒介，因此，虛擬平臺伺服器的硬體負載也會隨之降低。

Cisco是最早提出這項構想的網路設備廠商，並在硬體式的VN-Link方案中得到實現，像是Nexus交換器產品當中的5000、6120，及6140等型號，目前已經具備這樣的能力。在硬體式的VN-Link架構下，企業仍然需要在虛擬平臺伺服器安裝Nexus 1000V，但不負責交換，僅是幫流量貼上VLAN標籤，並在欄位當中寫入專屬的額外資訊，成為所謂的「VN-Tag」，當前端的Nexus交換器接收到流量後，就會根據VN-Tag的內容，套用對應的網路設定。

從格式上來看，VN-Tag並非標準的VLAN標籤，而且其體積已經超過傳統VLAN標籤所規範的4Bytes，僅有支援這項技術的實體網卡才能承載，目前，Cisco自家的刀鋒式Unified Computing System（UCS）伺服器，其網卡已經支援VN-Tag，可連接伺服器機箱上的Nexus 6120，或者6140的交換器模組，建立硬體式的VN-Link架構。

由於這個構想，需要得到其他網路設備廠商的合作才能廣為應用，因此，Cisco後來在IEEE，與其他廠商合作制定出802.1Qbg及802.1Qbh等2項尚在草案階段中的標準，許多項目皆參考到Cisco VN-Link的現行做法，其中802.1Qbg是規範虛擬網路流量，如何透過實體交換器做交換，802.1Qbh則是規範VLAN標籤的內容，最快在2011年上半就有可能在IEEE通過，成為業界共通的標準。

802.1Qbg的合作對象，會是包含VMware、Citrix，及Kernel-based Virtual Machine（KVM）在內的多種伺服器虛擬化平臺，Extreme是最早實做這項技術的網路設備廠商之一，他們先前便已經搭配特製版本的KVM，實做了802.1Qbg，並將這項技術稱之為「Direct Attach」。

而企業在內部網路架設支援802.1Qbg的實體交換器後，虛擬平臺伺服器內的原生虛擬交換器，會改由虛擬乙太網路埠聚合器（Virtual Ethernet Port Aggregator，VEPA）的新型物件做為替代，它的角色，和硬體式VN-Link架構下的Nexus 1000V一樣，僅提供虛擬機器上的虛擬網卡連通到實體網路，同時為流量貼上802.1Qbg的VLAN標籤。

以交換器傳統的工作模式來說，是根據封包內的目的地MAC位址，以便決定要傳送給那一個網路埠，但對於802.1Qbg，它必須要能做到，讓虛擬網路的流量在交換器內的同一個網路埠裡做交換，而遇到不支援這項標準的交換器，則會直接丟棄封包。

未來當802.1Qbg成為標準後，現有的許多交換器將可以透過韌體升級的方式提供支援，因此不一定要更換基礎設施，因此像Extreme就表示，他們現有的交換器產品經過升級後，就可以支援802.1Qbg。

Open vSwitch可架設於多種不同的伺服器虛擬化平臺，以Citrix的XenServer為例，5.5及最新版本的5.6皆能部署該套件，透過網頁介面或文字指令設定功能。（圖片來源：Open vSwitch官網）。

虛擬交換器對於虛擬機器的防護也扮演重要角色，像是網路型的VMsafe產品，就必須搭配虛擬交換器才能運作。

802.1Qbg架構解說

相關報導請參考「思科首款虛擬交換器安裝實測：初探虛擬交換器」