以Virtual Switch建置雲端虛擬網路交換機制(轉)

虛擬交換（Virtual Switch）顧名思義就是建立於虛擬平台上，透過軟體模擬出網路交換器的功能，其提供管理員能夠不依賴於實體網路和硬體，動態地重新配置虛擬環境中的網路架構。也由於其變動性較小，因此可減少網路和虛擬平台管理人員的負擔。
本文中將介紹一套以開放原始碼（Open Source）技術為基礎的虛擬交換器OpenvSwitch，透過實際部署安裝於Xen虛擬平台上的方式，針對虛擬交換機制作深入的分析與探討。
運作流程說明
在Xen的虛擬平台中，傳統上其內部網路主要由虛擬網卡與虛擬橋接器（Linux Bridge）所組成，兩者皆是由Hypervisor所模擬出來的軟體物件，提供虛擬機器橋接實體網路及虛擬機器之間彼此互相連線溝通機制。
而虛擬交換器（Virtual Switch）的介入，則帶給Hypervisor更多彈性化的功能來管控整體的虛擬網路架構。由於連接實體網路的硬體介面是由Hypervisor中的實體網路卡負責，其便可以直接成為虛擬交換器的uplink埠。虛擬交換器和Hypervisor間的互動架構則如下圖所示。
▲虛擬交換器與Hypervisor間的互動架構。 

首先，Xen會啟用一個Domain0負責做為後端驅動（netback），接收從各個虛擬機器（DomainU）中的前端驅動（netfront）所傳送的封包，其傳送的機制是透過共享記憶體的方式，將記憶體存取權限授與（grant）後端驅動，因此DomainU之間無法讀取未經授權的記憶體空間，也不會干擾到本身之外的封包儲存空間。


而Domain0的後端驅動在收到封包之後，則會交由虛擬交換器判別封包應轉發至何處，要往外透過實體網路卡發送，抑或往內送予其他虛擬機器，如此就完成整個虛擬網路的封包流向


優點與用途簡介 


OpenvSwitch這款虛擬交換器具備很強的靈活性，可以在管理程序中作為軟體Switch運行，也可以直接部署到硬體設備上作為控制層


在Linux環境中可透過編譯成核心模組（Kernel Module）的形式運行於系統核心層內（kernel-based）以提供較佳的運行效能，或是以軟體的方式執行於系統應用層（userspace-based）讓使用者可靈活地操控。此外，OpenvSwitch還支援多種標準的管理接口，如Netlow、sFlow、RSPAN、ERSPAN、CLI。


OpenvSwitch和LinuxBridge的差別


目前Linux預設已在核心中提供L2封包交換模組Bridge，Linux Bridge可提供不同虛擬器間的網路數據封包交換，然而OpenvSwitch與LinuxBridge仍有些許的差異，比較如下表所示。








可移動性設定組態


傳統的Bridge在做IP位址轉移時，必須在相同的L2網路環境，然而OpenvSwitch支援GRE tunnel技術，可在任意網路環境中轉移，而且OpenvSwitch易於佈建，每一個佈建案例都可以透過管理介面獨立區分管理，同時在跨虛擬器溝通（inter-VM communication）間具有通透性，其功能多層次的特性可以使轉送封包的狀態跨多台虛擬器，且可運用不同的交換器功能。例如policy routing state、ACLs、QoS policy、monitoring configuration (e.g. NetFlow, sFlow)。

此特性可以有效地與實體網路拓樸做區分，例如一個遠端程式若運行在虛擬控制平台上，可移植其網路設定在多台虛擬機器間。

即時反映網路狀態

虛擬環境常常會因需求不同而有所改變，同時也須改變邏輯網路環境，而OpenvSwitch提供一個狀態資料庫（State Database），支援遠端控制，因此可以隨時反映出網路環境的改變。

自動維護邏輯標籤 

分散式虛擬交換器常常添加標籤（Tag）在網路封包，以維護整體網路的邏輯內容，因此如何有效率且正確地維護邏輯標籤，會是分散式虛擬交換器所需面臨的問題。

OpenvSwitch的標籤規則可被遠端程式存取與編排，同時它們以最佳的形式儲存，以減少網路設備的負擔。OpenvSwitch所提供的VPN GRE tunnel，可以遠端操控tunnel，因此能夠被用於建立私有的虛擬網路環境。

提升封包處理效能

OpenvSwitch由於精簡其位於kernel中的程式碼，封包轉送可運行於kernel中，因此可以減輕處理封包的負擔，在執行效能上較傳統之Bridge有明顯的改進。同時，它也可以兼容其他網路應用服務，如QoS。

安裝部署

關於OpenvSwitch的設定，在此將分為編譯，安裝，控制三部分說明，本篇文章以kernel-based的佈建為示範。

編譯程式碼

在編譯的過程中依系統不同，可能需要額外安裝必須套件，如autoconf、automake、python等，「--with-l26」參數將OpenvSwitch編譯為kernel-based交換器，此處須確定系統的kernel source路徑正確。






安裝核心模組


因為OpenvSwitch是以替換掉系統核心中LinuxBridge的方式運作，因此必須先確定Bridge為模組型式而且可以被移除，若是直接編在核心中，便不適用此方式，移除後便可以載入openvswitch_mod.ko核心模組。







建立OpenvSwitch狀態資料庫，儲存網路邏輯環境設定，執行ovsdb-server，讓管理員可以透過unix domain socket遠端設定資料庫內容，當資料庫第一次建立好後須執行「ovs-vsctl --no-wait init」初始化資料庫。







最後的步驟就是啟動ovs-vswitchd daemon，並將其連線到unix domain socket。






系統控制操作

當上述步驟完成後，便可以用ovs-vsctl作設定bridges或是控制interface ports的動作。







此外，OpenvSwitch同時提供支援相容於Linux Bridge「brctl」指令的模組。







將上述兩個模組與daemon載入後，便可用brctl相關指令進行操作。







實際操作

經過上述佈建流程後，接下來將以兩個例子演練如何使用OpenvSwitch設定網路環境。  

第一個範例是將同一個Bridge的虛擬網卡分配到不同的VLAN，其分布如下：







                  ▲將同一個Bridge的虛擬網卡分配到不同的VLAN。

VLAN1:VM1,VM3
VLAN2:VM2 

STEP 1：首先，建立一個OpenvSwitch的Bridge。







STEP 2：將實體網卡eth0加入br0中。







STEP 3：把VM1的虛擬網卡vif1.0加進VLAN1。







STEP 4：將VM2的虛擬網卡vif2.0加進VLAN2中。

STEP 5：最後把VM3的虛擬網卡vif3.0加進VLAN1。







測試結果是，從VM1中Ping VM3可以連線，因其屬於同一個VLAN1中；從VM1中Ping VM2無法連線，因其分屬於不同的VLANs。







第二個範例是使用QoS策略限制虛擬網卡最大傳輸率（Rate Limiting），其相關設定如下：

Rate limit VM1: 1 Mbps 
Rate limit VM2: 10 Mbps





                   ▲使用QoS策略限制虛擬網卡最大傳輸率。


在此須設定ingress_policing_rate、ingress_policing_burst這兩個虛擬網卡參數：  

ingress_policing_rate：虛擬機器所允許傳送的最大傳輸率（kbps）。 
ingress_policing_burst：虛擬網卡在policing_rate下所允許最大傳輸量（kb）。  

STEP 1：首先，在VM1中設定rate limit為1Mbps。






STEP 2：然後，在VM2中將rate limit設定為10Mbps。






這裡以iperf 2.0.4這套網路效能測試工具來測量VM1與VM2的封包傳送頻寬，測試結果顯示，當VM1為client連到VM2 server的時候，頻寬測得為1Mbps；當VM2為client連到VM1 server的時候，頻寬則測得為10Mbps。






             ▲測量VM1與VM2的封包傳送頻寬。


效能測試

前面提到OpenvSwitch因其精簡程式碼設計，並執行於系統核心層中，所以能有效提高處理效能。  

在此以iperf 2.0.4分別對於OpenvSwitch（version 1.1.0pre2）和LinuxBridge（kernel 2.6.32）作效能測試評比。  

下圖以每10秒統計一次throughput測試時間120秒，可以看出OpenvSwitch整體效能遠優於LinuxBridge。






             ▲效能趨勢圖。

從以下圖表可以看出LinuxBridge的平均throughput為11.21Gbps，而OpenvSwitch則為14.88Gbps，整體效能提升32%。






             ▲平均效能圖。

結語

本文介紹了以開放原始碼開發的虛擬交換器OpenvSwitch，用來建置雲端虛擬網路交換機制，其優異的處理效能與靈活的操作，提供管理人員一個很好的使用經驗。目前最新版的OpenvSwitch已經內建於雲端虛擬平台開發組織Xen.org所推出的Xen Cloud Platform裡，並可部署在多種虛擬平台如Xen、XenServer、KVM、Proxmox VE和VirtualBox等。  

然而，網路虛擬化所帶來的便利性並非完美，仍然有許多待改進的地方，尤其當中的「資安問題」更是極其重要。虛擬平台的網路交換溝通機制安全性是否足夠，直接影響了使用者對於隱私資料存放在雲端環境進行傳送時的信賴度。針對此類問題的解決方法，可透過在虛擬交換器中加上過濾封包的功能或是將封包導向網路行為偵測引擎進行深層過濾，而諸如此類的對策將深遠影響虛擬網路未來的發展。

留言

張貼留言

這個網誌中的熱門文章

Json概述以及python對json的相關操作

圖片
什麼是json： JSON(JavaScript Object Notation) 是一種輕量級的數據交換格式。易於人閱讀和編寫。同時也易於機器解析和生成。它基於JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999的一個子集。JSON採用完全獨立於語言的文本格式，但是也使用了類似於C語言家族的習慣（包括C, C++, C#, Java, JavaScript, Perl, Python等）。這些特性使JSON成為理想的數據交換語言。 JSON建構於兩種結構： “名稱/值”對的集合（A collection of name/value pairs）。不同的語言中，它被理解為對象（object），紀錄（record），結構（struct），字典（dictionary），哈希表（hash table），有鍵列表（keyed list），或者關聯數組（associative array）。 值的有序列表（An ordered list of values）。在大部分語言中，它被理解為數組（array）。 這些都是常見的數據結構。事實上大部分現代計算機語言都以某種形式支持它們。這使得一種數據格式在同樣基於這些結構的編程語言之間交換成為可能。 jso官方說 ​​明參見：http://json.org/ Python操作json的標準api庫參考：http://docs.python.org/library/json.html 對簡單數據類型的encoding 和decoding： 使用簡單的json.dumps方法對簡單數據類型進行編碼，例如： import json obj = [[ 1 , 2 , 3 ], 123 , 123.123 , 'abc' ,{ 'key1' :( 1 , 2 , 3 ), 'key2' :( 4 , 5 , 6 )}] encodedjson = json.dumps(obj) print repr (obj) print encodedjson 輸出： [[1, 2, 3], 123, 123.123, 'abc', {'ke...
閱讀完整內容

Docker容器日誌查看與清理

1. 問題 docker容器日誌導致主機磁盤空間滿了。 docker logs -f container_name 劈裡啪啦一大堆，很佔用空間，不用的日誌可以清理掉了。  2. 解決方法 2.1 找出Docker容器日誌 在linux上，容器日誌一般存放在 /var/lib/docker/containers/container_id/ 下面，查看各個日誌文件大小的腳本docker_log_size.sh，內容如下： #!/bin/sh echo "======== docker containers logs file size ========" logs=$(find /var/lib/docker/containers/ -name *-json.log) for log in $logs do ls -lh $log done # chmod +x docker_log_size.sh # ./docker_log_size.sh 2.2 清理Docker容器日誌（治標） 如果docker容器正在運行，那麼使用 rm -rf 方式刪除日誌後，通過 df -h 會發現磁盤空間並沒有釋放。 原因是在Linux或者Unix系統中，通過 rm -rf 或者文件管理器刪除文件，將會從文件系統的目錄結構上解除鏈接（unlink）。 如果文件是被打開的（有一個進程正在使用），那麼進程將仍然可以讀取該文件，磁盤空間也一直被佔用。 正確姿勢是 cat /dev/null > *-json.log ，當然你也可以通過 rm -rf 刪除後重啟docker。 接下來，提供一個日誌清理腳本 clean_docker_log.sh ，內容如下： #!/bin/sh echo "======== start clean docker containers logs ========" logs=$(find /var/lib/docker/containers/ -name *-json.log) for log in $logs d...
閱讀完整內容

利用 Keepalived 提供 VIP

Keepalived 是一種基於 VRRP 協定實現的高可靠 Web 服務方案，用於防止單點故障問題。因此一個 Web 服務運作至少會擁有兩台伺服器執行 Keepalived，一台作為 master，一台作為 backup，並提供一個虛擬 IP（VIP），master 會定期發送特定訊息給 backup 伺服器，當 backup 沒收到 master 訊息時，表示 master 已故障，這時候 backup 會接管 VIP，繼續提供服務，來確保服務的高可靠性。 VRRP VRRP（Virtual Router Redundancy Protocol，虛擬路由器備援協定），是一個提供備援路由器來解決單點故障問題的協定，該協定有兩個重要概念： * VRRP 路由器與虛擬路由器：VRRP 路由器是表示運作 VRRP 的路由器，是一個實體裝置，而虛擬路由器是指由 VRRP 建立的邏輯路由器。一組 VRRP 路由器協同運作，並一起構成一台虛擬路由器，該虛擬路由對外提供一個唯一固定的 IP 與 MAC 位址的邏輯路由器。 * 主控制路由器（master）與備援路由器（backup）：主要是在一組 VRRP 中的兩種互斥角色。一個 VRRP 群組中只能擁有一台是 master，但可以有多個 backup 路由器。 VRRP 協定使用選擇策略從路由器群組挑選一台作為 master 來負責 ARP 與轉送 IP 封包，群組中其他路由器則作為 backup 的角色處理等待狀態。當由於某種原因造成 master 故障時，backup 會在幾秒內成為 master 繼續提供服務，該階段不用改變任何 IP 與 MAC 位址。 Keepalived 節點配置 IP ADDRESS ROLE 172.16.1.101 vip 172.16.1.102 master 172.16.1.103 backup 安裝與設定 這 ubuntu 14.04 LTS Server 中已經內建了 Keepalived 可以透過 apt-get 來安裝： $ sudo apt-get install -y keepalived 也可以透過 source code 進行安裝，流程如下： $ sudo apt-get install build-essential libssl-dev $ wge...
閱讀完整內容