認識邊緣網路架構 VEB、VN-link、VEPA技術介紹

基本上，硬體包含中央處理器（CPU）、記憶體、網路頻寬及周邊設備，而虛擬機器則成為運用這些硬體的整合單位，也就是每個虛擬機器都應該被視為一台實體機器般地擁有硬體的獨占性，不受其他的機器運作影響。

假設虛擬機器網路架構也與傳統的網路環境相接近，即可在既有的網路管理方法下達到相同的網路運作機制，但是這樣的想法面臨了以下兩個主要的問題：

1.如何讓虛擬機器共享網路卡資源，就像有獨占網路卡的效果
隨著實體機器的資源增加，可產生的虛擬機器也會增加，實體機器的網路卡共用，引發了相關的資源付出，例如頻繁的使用權交換，增加實體機器內的中斷數量。此外，將封包由網路卡搬移至虛擬機器對應的邏輯記憶體上也消耗很多CPU資源，因此在共用網路卡的情況之下，虛擬機器的網路設計也期待可達到與獨占網路卡的效能接近的效果。

2.網路管理不應該屬於實體機器的責任
在傳統實體機器的網路架構中，網管問題很明確地交由外部網管設備，因此網路管理及硬體資源的運用兩者不互相影響，而雲端運算的虛擬技術，讓虛擬機器產生在實體機器內，外部的網路管理設備不容易掌握虛擬機器間的網路狀態，形成不透明的問題。欲管理虛擬機器的網路狀態，須額外地在實體機器上增加虛擬的網路管理設備，因此付出額外的硬體資源，如CPU或記憶體。除此之外，雲端環境的網路管理也造成定位不明的問題，引發了複雜且耗費人力的網路管理問題。

在雲端產業的發展下，各大網路設備廠商紛紛提出不同的架構，最先提出的概念就是虛擬乙太橋接器（Virtual Ethernet Bridge，VEB），用於解決第一個問題，提出類似虛擬橋接器的概念，執行在單一實體機器內虛擬機器間的封包傳遞。

此外，Cisco和VMware合作提出VN-link的想法。同時，HP也提出VEPA的概念，致力於解決第二個問題，將虛擬機器的連接延伸至實體交換器上，如此一來，網管問題就可以從實體機器內移至鄰接的實體橋接器上。

什麼是 Virtual Ethernet Bridge

以虛擬技術為主的雲端服務日益增加，網路上的各種應用不再單純地來自實體機器所建構而成的環境，而是由虛擬器機及實體機器混合而成的服務環境。

由於虛擬機器是透過Hypervisor產生在實體主機上，它們的網路連接如同圖1所示，每個虛擬網路卡的操作是由Hypervisor管理，共同分享使用實體網路卡。

▲圖1 Hypervisor直接控制實體網路卡。

實際上，連接至實體橋接器的是實體網路卡，所有虛擬機器皆透過Hypervisor的網路資源管理對外傳輸資料，而虛擬機器間的資料傳輸，只經由Hypervisor的內部直接轉傳，它們之間並沒有一個類似橋接器的網路設備橋接，如此一來，網路管理變得困難，也無法保證虛擬機器間的資料傳輸安全性。

例如，同一台實體主機上有很多不同的企業的虛擬機器，如果沒有類似VLAN的機制去阻隔不同企業的虛擬機器間的封包流竄，企業的機密將很可能會外流。

因此，虛擬機器的網路連接採用Virtual Ethernet Bridges（VEB）機制的橋接器，以便有效率地在實體機器上模擬網路連接，達成虛擬機器之間的網路管理。

以軟體的方式實作VEB

圖2是以軟體方式實作在Hypervisor上的VEB機制，也就是虛擬交換器（Virtual Switch，vSwitch）。每一個虛擬器上可能有一個或多個虛擬網路卡，而每張虛擬網路卡皆有一個相對應的介面連接至虛擬交換器上。在實體網路卡上的虛擬交換器可能還連接至外部的實體橋接器，與其他實體主機共用存取外部網路資源。

▲圖2 以軟體實作VEB。

以軟體實作在Hypervisor上的虛擬交換器，驅使每台虛擬機器以中斷的方式要求Hypervisor執行System Call，操作網路I/O，此外網管功能也是由CPU執行。

隨著能提供的網路管理功能增加，I/O操作次數的頻繁也會增加，將劇烈地消耗系統資源，導致系統的效率變低，因此VEB也可以透過硬體的方式實作，改善提升系統效率。

以硬體的方式實作VEB

硬體式實作的VEB使用SR-IOV（Single Root I/O Virtualization）技術，如圖3所示，實體網路卡上設計了多組Queue及相對應的Virtual Function，在資源足夠的情況下，虛擬機器將獲得一組Queue及Virtual Function。

▲圖3 硬體實作的VEB。

當封包要從外部網路傳送至某一虛擬機器A時，送達至網路卡上的封包先經由分類器（Sorter）放置到虛擬機器A所擁有的Queue上，而相對應虛擬機器A的記憶體上會建立一個空間，對應實體網路卡上獲得配置的Virtual Function，配合直接記憶體存取機制（Direct Memory Access，DMA）。

在Queue上的封包，則可直接被搬移到虛擬機器A所占據的記憶體上，無須請求Hypervisor產生中斷搬移，因此可以節省CPU的運算資源。

反之，虛擬機器欲傳送封包至外部網路，也是透過相同的程序，以反方向進行。因此，SR-IOV技術允許虛擬機器直接存取實體網路卡，這意味著比軟體式的VEB效率更高，而且更節省系統資源。

討論完VEB的實體架構和支援的相關技術之後，接下來詳細介紹VEB可支援的網路環境，以及可允許的封包傳遞的形式。

不論是傳統的實體主機連接至實體鄰近橋接器，或是實體主機內的虛擬機器間的連接，VEB就像是一般的橋接器（Switch）一樣，根據MAC Address或是運用VLAN標籤作為轉傳封包的依據。

因此，透過VEB提供兩種轉傳封包的方式，如圖4所示，一種類似路徑1，虛擬網路卡和鄰接實體交換器之間的封包接收傳送，另一種就是像路徑2，虛擬機器間的封包轉傳，而除此之外的路徑，例如路徑3不被允許。

▲圖4 VEB的封包傳遞路徑。

路徑2引發了網管的界定問題，以VEB架構為主的網路結構允許虛擬機器在實體機器內互傳封包，這意味著網路管理必須交付給該實體機器，以及消耗Hypervisor的管理資源。

如果虛擬機器的網管問題可視同一般實體機器，將網路管理交給外部的網路設備負責，除了可以節省實體機器的系統資源外，現行的網路管理技術將可方便地直接運用。

VMware分散式虛擬交換器

VMware提出分散虛擬交換器（Distributed Virtual Switch）的概念，如圖5所示，由VMware的vSphere提供中央控制介面，以集中式管理的方法自動地調整分散在不同實體主機上的虛擬交換器，虛擬成一個大型的虛擬交換器，具動態變動的雲端網路環境中。

▲圖5 分散式虛擬交換器。

網路管理者在這樣的架構下，無須繁瑣地調整每個交換器的狀態，可以省去非常多的管理麻煩，也因為虛擬成整體的單一大型交換器，所以虛擬機器的動態轉移，就好像是改變交換器上的埠口而已，虛擬機器上原有的網路設定，如VLAN、防火牆或是流量控制都可以很容易地保持在搬移過後的實體主機上。

聚合管路及延伸埠口（Aggregated Ports）的概念

在虛擬技術下的網路架構，網管問題不應該透過其他特殊的方法，這樣的概念已經成為各網路大廠的共識，因此如何讓外部的網管設備掌握虛擬機器的網路狀態，成為關鍵的切入點。

圖6表示虛擬機器、實體機器及實體交換器的連接概念，每張實體網路卡實際上是扮演著多張虛擬網路卡的角色，欲讓外部的實體交換器掌握所有虛擬機器的網路活動，最好的方法就是讓實體交換器可以知道連接到本身埠口的實體網路卡扮演多少張虛擬網路卡，並且這個連接埠口必須扮演成多個埠口，分別被虛擬機器連接。

▲圖6 實際上的網路連接。

如圖7所示，在具有三台虛擬機器的實體機器上，該實體網路卡應該要扮演三張虛擬網路卡，假設連線分別用綠、紅、黃表示，因此在圖6中的該實體機器與實體交換器上的埠口，則應該扮演三個不同的埠口。

▲圖7 實際網路連接代表的接線示意。

此外，所使用的單一實體連接線，則必須代表綠、紅、黃三條不同的連接線，分別連接至三台虛擬機器，如此一來則可達到讓虛擬機器的網路行為透明化的目標。

Cisco和VMware合作所提出的VN-Link

在WMware分散式虛擬交換器的概念下，Cisco提出了VN-Link，不但讓分散在不同實體主機上的Hypervisor容易調整虛擬機器的網路狀態，而且使得虛擬機器好似真的接在其他實體網路設備上。

也就是說，這個概念提供一個虛擬介面，可以被外部的實體網路設備清楚地辨別，所以虛擬機器的狀態配置、監控、搬移或網路診斷，就可以容易地執行在實體網路設備上。實作VN-Link時必須包含以下兩個概念：

虛擬乙太網路介面（Virtual Ethernet Interfaces，VEI）

虛擬乙太網路介面是一個隨著虛擬網路卡自動配置的虛擬介面，如圖8所示，其概念就像是在實體網路卡上建立虛擬網路卡的專屬存取埠口。

▲圖8 VEI的概念圖。

透過VEI，封包的傳送接受會自動地對應至所屬的虛擬機器上，而這個虛擬介面保留了虛擬機器的網路狀態、安全性或相關的統計資料，因此虛擬機器搬移之後，網路環境將隨著VEI的移動維持在新的實體主機上。

埠口狀態描述（Port Profiles）

除上述的VEI為虛擬網路卡的網路配置、屬性、安全性及流量統計的介面外，埠口狀態描述被設計為設定VEI的網路指令集，也就是說，網管人員欲針對某一虛擬機器設定網路管理時，相關的虛擬／實體網路設備必須獲得網管指令的設定，而這些指令的集合就是專屬於VEI的埠口狀態描述，一旦虛擬機器遷移至另外的實體機器上，VEI相對應的埠口狀態描述就會以擴散的方式自動將原有的網管指令集設定在搬移之後的相關虛擬／實體網路設備上。

部署VN-link在已存在的網路上（Cisco Nexus 1000）

Cisco推出了Nexus 1000，宣布將VN-link的概念以軟體的實作方式增加在已存在的網路設備上，如圖9所示，這個概念包含了兩個重要的軟體模組：

▲圖9 部署VN-link在已存在的網路上。

1.Virtual Ethernet Module（VEM）
這是一個在Hypervisor上嵌入的軟體模組，具備類似虛擬交換器的功能，提供虛擬機器的封包傳遞，及安全性維護。

2.Virtual Supervisor Module（VSM）
這是一個獨立被安裝在實體或虛擬機器上的中央控制系統，負責監控、管理、診斷或調整所有的網路狀態，也就是包含VSM本身及所有VEM的控制。

這兩個元件的概念有別於傳統的虛擬交換器，將網路資料傳輸功能及網路狀態控制功能分離，每個VEM在各自的實體機器上就像是一台獨立的虛擬交換器，而透過VSM，可集中式地自動調整所有的VEM以及所連接的實體交換器，因此在動態變化的網路環境下，虛擬機器的可見度可達外部的實體交換器，並且降低Hypervisor的負擔。

部署VN-link在硬體上

在硬體上實作VN-link的切入概念，是希望將虛擬交換器的功能從Hypervisor上去除，並且移至實體交換器上，如圖10所示，實作的部署包含介面虛擬元件（Interface Virtualizer）、中央控制橋接器（Centralized Controlling Bridge）以及傳輸協定。

▲圖10 硬體實作的VN-link。

介面虛擬元件被建立在實體機器上，用於辨識、加入和移除封包的標籤。而中央控制橋接器是支援VN-link的實體交換器，實際上，內部是由虛擬介面交換器，Virtual Interface Switch（VIS）執行封包轉傳的功能。

當虛擬機器產生時，介面虛擬元件隨即產生一個與虛擬網路卡對應的虛擬介面vEth，在虛擬介面交換器上也會產生一個相對應的虛擬埠口（Virtual Interface，VIF），執行內部的封包交換以及實體交換器的埠口和虛擬網路卡的對應。

在這樣的軟硬體架構下，還需要傳輸協定，也就是Cisco所提出的VN_Tag，如圖11所示，原有的封包格式加入了一段新的VN_Tag，不但提供資訊讓虛擬介面交換器決定轉傳封包的路徑，也讓介面虛擬元件（Interface Virtualizer）決定封包的接收。

▲圖11 被加入VN_tag的封包格式。

HP提Virtual Ethernet Port Aggregrator架構

欲達到聚合管路及延伸埠口的概念，HP提出Virtual Ethernet Port Aggregrator （VEPA）的架構，實作的概念較為簡單，封包格式也不需改變。

所謂VEPA是一種在實體機器內的封包傳送機制，如圖12所示，VEPA可以使用SR-IOV技術的硬體實作，也可以是以虛擬交換器為主的軟體實作，規定實體機器內部的封包流向只會有傳送至外部網路或是接收自外部網路兩種情況。

▲圖12 VEPA的封包傳遞路徑。

此外，還需要有支援VEPA的鄰接實體橋接器，重要的特徵就是埠口允許有別傳統交換器的Hairpin Forwarding（或稱為Reflective Relay Forwarding Mode），也就是允許封包進入與該封包流出相同的埠口。

因此，在這樣的特徵下，封包的路徑只會有兩種，也就是傳統的路徑1及支援Hairpin Forwarding的路徑4，而不允許路徑2和路徑3的發生。

如此一來，這樣的概念在不需要修改封包格式的條件下，可以達成延伸埠口的概念，讓虛擬機器彷彿直接連接在鄰接實體交換器上。

在IEEE 802.1Q第8.6.1項提及傳統的虛擬交換器的相關限制，假設有一個封包需要被虛擬交換器的轉傳埠傳送至其他地方，而這個封包又是接收自這些傳輸埠的其中一個埠時，則這個封包會透過這個接受埠以外的轉傳埠傳送出去，也就是不允許封包經過它上次經過的出入埠。

表1 各種架構的比較

結語

整體而言，在雲端基礎建設底下，邊緣虛擬橋接技術所在意的是如何直接透過實體網路卡存取網路，以增加CPU的效能，以及有效的網路管理，讓外部的管理設備可以看見虛擬機器。

VEB的架構討論實體機器內的虛擬機器應該如何橋接，以達到第一個目的，而Cisco的VN-link和HP的VEPA也紛紛地被提出，來達成第二個目的，表1簡單地列出各種架構的比較，提供讀者選擇。目前以Cisco公司為主的802.1Qbh和以HP公司為主的802.1Qbg，在不久將成為IEEE標準，預計也會是市場上的兩個主流。

資料來源：
‧經濟部科技專案
‧VN_Link
http://www.infoclip-vmware-vsphere.com/Sites/vSphere/pdf/vNetwork%20Distributed%20Switch%20Data%20Sheet.pdf
http://www.cisco.com/en/US/solutions/collateral/ns340/ns517/ns224/ns892/ns894/
white_paper_c11-525307_ps9902_Products_White_Paper.html
‧VEB,VEPA
http://www.ieee802.org/1/files/public/docs2010/bg-joint-evb-0310-v0.pdf
‧SRIOV
http://download.intel.com/design/network/desguides/322192.pdf