讓單一虛擬機器的可用頻寬再度提高 2.2 Open vswitch Open vswitch[4][5] 是一個 Apache 2.0 授權下的開放原始碼軟體, 透過軟體模擬出一個多層虛擬交換器功能, 借由對

Size: px

Start display at page:

Download "讓單一虛擬機器的可用頻寬再度提高 2.2 Open vswitch Open vswitch[4][5] 是一個 Apache 2.0 授權下的開放原始碼軟體, 透過軟體模擬出一個多層虛擬交換器功能, 借由對"

宋斋牧
7 years ago
Views:

1 以 OpenFlow 實作區域網路管理模組陳昶禎 * 高勝助國立中興大學資訊科學與工程學系 g @mail.nchu.edu.tw, sjkao@cs.nchu.edu.tw 摘要隨著雲端運算的概念普及, 終端使用者得以透過網際網路連接高效能伺服器達到隨時隨地的服務需求為了有效地提升服務品質及增加系統設備的使用率, 除了使用虛擬化技術外, 資料中心的為了及時處理動態的網路需求, 網路架構也由傳統的分散式管理架構演變為將控制層集中管理的新型架構, 本論文基於 OpenFlow 協定, 分析傳統區域網路服務模組, 並透過 OpenFlow 控制器, 探討將傳統網路功能模組以 OpenFlow 協定描述時會產生的問題, 並以 Python 語言提供系統管理者的網路管理平台本管理平台主要為提供系統管理者一有效率且方便的網路管理方式, 在考量以 traffic flow 交換的網路環境下, 達到如流量監控負載平衡及 IP 共享等動態網路管理功能的應用關鍵詞 : 虛擬化 Open vswitch SDN OpenFlow Abstract With the popularity in cloud computing, end users can ubiquitously request services to high -performance servers through Internet. In order to provide better quality of service and usage, the virtualization technique is widely adopted. A centralized approach for network operations in the data center adds a new management complexity. This paper introduces a method to resolve the challenges by translating common network management functions into flows based implementation using OpenFlow protocol. Our implementation also provides an efficient and easy way for the administrator. Through the adoption of traffic flow, our implementation is able to provide traffic monitoring, load balancing and IP sharing function. Keywords: Virtualization, Open vswitch, SDN, OpenFlow. 1. 前言在資訊產業快速的發展下, 伺服器朝著多核心的架構發展, 為了最佳化伺服器的使用率並保持各種服務間的隔離性 (isolation), 利用虛擬化技術已是服務提供者常用的策略為了降低建置高效能虛擬機的成本, 由 Intel 與 AMD 兩家 CPU 大廠所提出的硬體輔助虛擬化設計 (hardware-assisted virtualization) Intel-VT 與 AMD-V, 使服務提供者取得高效能的虛擬機器成本大幅降低, KVM(kernel-based virtual machine) 即是全虛擬化技術加上硬體輔助虛擬化的虛擬機器管理界面 (Virtual Machine Monitor) 另外, 為提供虛擬機器交換網路封包之能力, 需要在實體伺服器中建置虛擬交換器來提供虛擬機器與實體網路的封包交換路徑, 並透過虛擬交換器的管理工具進行 VLAN QoS(Quality of Service) 及流量的監測與控管有別於傳統網路, 虛擬交換器的數量往往十分龐大, 管理上也較為複雜由美國史丹佛大學提出的新型網路架構 : 軟體定義網路 (Software-Defined Networking, SDN), 基於 OpenFlow 協定, 將網路分為資料層 (Data Plane) 與控制層 (Control Plane), 將虛擬交換器的行為管理統一交由控制層的控制器 (Controller) 軟體負責這個架構可以讓網路管理者借由單一的控制器, 用程式規劃虛擬交換器之間的網路拓撲, 進而簡化管理的複雜度 1.1 問題描述與動機本論文基於 OpenFlow 協定, 探討將傳統網路管理技術轉換成 flow-based 的規則時, 形成 flow 優先權序列性 flow 和平行性 flow 問題提出以多個 Flow Table 為基礎架構的解決方案, 並實作出不同的 flow set 組合, 進行網路管理技術及網路區塊 [1][2] (network slice) 之管理 2. 相關研究為了建構以 SDN 架構為基礎之環境架構, 我們需先了解如何使用 Open vswitch 來管理以 KVM 建立的虛擬化叢集, 以及實現 SDN 架構的 OpenFlow 協定, 以軟體的方式管理網路, 並以探討管理者在以 OpenFlow 協定為基礎的網路管理議題相關的技術如下 : 2.1 KVM virtio vhost Kernel-based Virtual Machine (KVM)[3] 是結合硬體輔助虛擬化技術的 Linux 全虛擬化解決方案, 主要是透過動態載入模組 (loadable kernel module), 將 Linux 核心轉換為一個系統程序 (process),kvm 讓虛擬機器的位址空間獨立於核心, 虛擬機的運算請求得以在核心空間 (kernel-space) 使用, 而其他的影裝置模擬, 則是透過執行於使用者空間 (user-space) 的模擬軟體 QEMU 執行由於 I/O 指令皆是透過 QEMU 模擬, 容易造成效能瓶頸, 以網路卡效能為例, 透過 QEMU 模擬之網路卡頻寬約為 100 Mb/s, 但在 KVM-60 與 Linux kernel 以上的版本提供了 virtio 的核心模組, 使得 KVM 的虛擬網卡可以提供 1Gb/s 的頻寬而在 Linux kernel 3.0 提供了 vhost_net 模組, 173

tw 摘要隨著雲端運算的概念普及, 終端使用者得以透過網際網路連接高效能伺服器達到隨時隨地的服務需求為了有效地提升服務品質及增加系統設備的使用率, 除了使用虛擬化技術外, 資料中心的為了及時處理動態的網路需求, 網

2 讓單一虛擬機器的可用頻寬再度提高 2.2 Open vswitch Open vswitch[4][5] 是一個 Apache 2.0 授權下的開放原始碼軟體, 透過軟體模擬出一個多層虛擬交換器功能, 借由對於多種虛擬化技術支援的多樣性, 提供方便管理和配置虛擬機器的網路架構由於其變動性小, 可減少網管人員之負擔目前 Linux 已提供了基於 Layer 2 之封包交換模組 Linux Bridge, 但 Open vswitch 與 Linux Bridge 仍有不少差異以下列舉出 Open vswitch 的主要特性 : 子網路隔離機制 : 借由對於封包進入的路由器埠 (switch port) 進行 VLAN Tag 的標記, 標記方式與 802.1Q VLAN Model 相同且支援 VLAN Trunking 機制支援生成樹協定 (Spanning Tree Protocol,STP): 可防止在虛擬機封包之間產生環路即廣播風暴, 並可提供備用路徑 QoS 管理 : 針對每一個路由器埠進行流量決策支援多種通道協定 : 可利用 GRE IPsec GRE 與 VXLAN over IPsec 與交換器建立路由支援 OpenFlow 協定 : 支援 OpenFlow 1.0, 1.2, 1.3 版 2.3 Software-Defined Networking (SDN) Software-Defined Networking[6] 為近年來興起的網路架構, 具有動態可管理低成本, 並可適應各式各樣環境的網路架構此架構將傳統網路架構切割為控制層 (control plane) 及資料傳輸層 (data plane), 其中控制層可透過控制器程式攥寫達成客製化網路需求, 並有許多開源的控制器專案如 NOX/POX[12], Beacon[13] 及 Ryu SDN Frame work[8] 等 SDN 之主要定義如下 [6]: 可直接程式化 : 由於控制層與傳輸層的分離, 網路控制層可經由程式管理敏捷性 : 對於封包轉送進行抽象控制, 可因應快速變動的網路需求集中式控制 : 所有網路裝置皆可透過一個 SDN 控制器管理, 達到集中化的網路管理機制可程式化設定 : 網路管理者可以透過動態且自動的 SDN 程式對自己的網域進行管理即最佳化網路資源開放標準 : 管理者容易開發 SDN 程式並適用在所有支援 SDN 標準之設備上, 而不用考慮設備的品牌系統等問題 2.4 OpenFlow OpenFlow[7] 是一個由史丹佛大學所開發的開放協定, 可以讓管理人員自行定義與設計 OpenFlow 交換器的網路行為, 藉以測試模擬及管理網域在 OpenFlow 協定下的所有交換器, 其封包傳遞流程皆是以 Flow 呈現並記錄於 Flow Table 中 OpenFlow 交換器主要是透過控制器 (Controller) 來控制網路行為, 並透過 OpenFlow 協定與安全通道 (Secure Channel) 與 OpenFlow 交換器溝通, 如圖 1 所示圖 1 OpenFlow 協定組成架構圖一個 OpenFlow 交換器總共包含 Flow Table Secure Channel 以及 OpenFlow Protocol 三個主要部分 Flow Table 包含 Flow 中個欄位的資訊, 當 OpenFlow 交換器處理封包時, 便會查詢表格中的 Flow 資訊, 並以對應的規則處理封包當交換器無法查到與該封包特徵相符的規則時, 則會透過 Secure Channel 與控制器以 Packet-In Message 傳遞封包進入訊息, 當控制器決定封包處理方式後, 也會透過 Secure Channel 傳送 Flow-Modify Message, 告知交換器加入或修改 Flow 而所有傳輸的訊息 (message) 皆會透過 OpenFlow Protocol 定義的訊息事件及資料內容傳輸, 因訊息內容為唯一的語法, 可避免因網路裝置的廠牌不同而造成不相容的問題在 Flow Table 中, 進行封包比對及行為設定的的欄位主要有三個部分, 如表 1 中,Match Fields 記錄該 Flow 要比對的封包特徵, 若封包的欄位 (header) 與欄位上的值相符, 則代表該封包被分類至該 Flow 中 Counters 用以記錄符合該 Flow 的封包數與資料大小而 Instruction 則定義交換器對於該 Flow 的所有封包所應採取的動作表 1 Flow Table 進行封包比對的主要欄位 Match fields Counters Instructions 目前 OpenFlow 的發展已由單一個 Flow Table 成長至多個 Flow Tables, 如圖 2 中, 封包進入交換器後, 會從 Table 0 開始,Flow Table 的執行次序依其 Table ID, 由小至大, 以管線化 (Pipeline) 的方式執行, 直至封包被送出交換器, 或被交換器丟棄 174

封包交換模組 Linux Bridge, 但 Open vswitch 與 Linux Bridge 仍有不少差異以下列舉出 Open vswitch 的主要特性 : 子網路隔離機制 : 借由對於封包進入的路由器埠 (switch port) 進行 VLAN Tag 的標記, 標記方式與 802.

3 圖 2 多個 Flow Table 的管線處理 2.5 Ryu SDN Framework Ryu SDN Framework[8] 是一個 Apache 2.0 授權下的開放原始碼軟體利用 Python 實作 OpenFlow 協定中控制器之功能, 並透過 API 的方式, 提供開發者方便開發網路管理及控制之程式 Ryu 完整支援 OpenFlow 1.0, 1.2, 1.3, 1.4 以及 Nicira Extensions 3. 研究方法在每個虛擬路由器執行進階網路管理功能時, Flow Table 會產生相同特徵分類問題本論文探討在進行 OpenFlow 協定 (OpenFlow 1.3.3[9]) 管理區域網路時會遭遇到的問題, 並利用多個的 Flow Tables 的管線機制 (pipeline), 制定對應的策略解析方式, 實作出基於 OpenFlow 之進階網路管理模組, 實踐基於 OpenFlow 協定的流量監控封包修改及轉送流程 3.1 相同特徵分類問題為了對封包進行分類,OpenFlow Switch 會對進入交換器的封包進行特徵比對, 當其特徵符合其 Flow 的 Match 欄位描述時, 便會執行該 Flow 的行動 (actions) 然而在每個 Flow 中, 若 Match 比對相同封包特徵, 則可能產生, 語意錯誤, 如表 2 中, 管理者希望丟棄所有目標為 B 的封包, 但如果是從 A 至 B 的封包則正常傳遞然而實際上在 OpenFlow 交換器會丟棄所有送至 B 的封包, 包含由 A 送往 B 的封包, 造成管理策略與實際行為不符合的現象 [9] 為避免封包行為錯誤, 本論文在各個 Flow Table 中, 將 Flow 制定固定的優先權, 確保過濾封包的正確性 Ryu 控制器與 OpenFlow 交換器連線成功時, 會先以優先權 (Priority)100 的方式插入 Flow, 而當管理者啟用進階網路管理功能時, 所有 Flow 會以優先權 1000 插入 Flow Table 中, 並將同時進行的 Flow 放入不同的 Flow Table 中, 以避免相同的優先權卻無法執行的問題 3.2 序列性 Flow 執行分析將進階網路功能分析成 Flow Table 的 Flow 時, 會在 Flow 的 actions 欄位上增加許多不同的行動雖然可於一個 Flow 中執行完所有的行動, 但也造成動態規劃的困難如表 3 中, 若 IP 為 C 的機器實體網路卡位址改變, 則控制器必須修改上述所有 Flow 所對應的行動為降低因封包特徵改變, 使得 Flow 必須大量修改的情況, 本論文利用 Flow Table 的管線特性, 將進階網路功能依其必須修改的 OSI model 分層, 以管線方式依序修改, 並加入相對應的 Flow Table 中, 如圖 3 中, 網路模組可能會影響封包路徑, 故先檢查其實體網路位址是否需要被修改, 若有需要則產生一個 flow 負責進行封包轉送, 若還有其他封包特徵需要被修改, 則會將產生對應的 flow 修改封包的特徵欄位, 直到沒有修改封包特徵的需求為止表 3 利用單一 flow 執行多個行動 Match Priority Instructions dst_ip=a and dst_port=22 dst_ip=b and dst_port= Actions=[set(dst_IP=C), set(dst_mac=x), Forward(3)] Actions=[set(dst_IP=C), set(dst_mac=x), Forward(3)] 表 2 重複特徵的 flows Match Priority Instructions src_ip=a 100 Actions=[drop] src_ip=a, dst_ip=b 100 Actions=[Forward(1)] 圖 3 序列性 Flow 分析流程 175

研究方法在每個虛擬路由器執行進階網路管理功能時, Flow Table 會產生相同特徵分類問題本論文探討在進行 OpenFlow 協定 (OpenFlow 1.3.

4 Flow set Index set 表 4 Flow 分類對應到的 OpenFlow 行為 Modification set Route set OpenFlow action Goto-Table Set(Rewrite packet headers) Goto-Table output Goto-Table 3.3 平行性 Flow 執行分析為了增加管理的多樣性, 本論文利用額外的 Flow Table, 對經過 Flow 的封包採樣, 以不干擾原本的 Flow 行為模式為前提下, 進行統計, 達到平行性 Flow 的應用 3.4 Flow Table 規劃由於序列性 Flow 執行分析會將原本的進階網路策略修改為多條具有相依性的 Flow 執行, 為妥善管理切割後的 Flow 及所屬的 Flow Table, 本論文利用 Ryu SDN Framework 的 API 編寫程式, 將 Flow 對於封包的特徵與行動欄位分類為 Index set Modification set 及 Route set 三類 Index set 僅只是封包應被送往哪一個 Flow Table 進行比對, Modification set 則會根據需要修改封包特徵, 而 Route set 則會根據封包上標注的實體網路卡位址或者 IP 位址, 決定封包送出的交換器埠 (switch port), 本論文所規劃的行動分類對應到至 OpenFlow 會使用到的預設行為如表 4 在交換器正常傳送封包的情況下,Ryu 控制器僅會對 Index set 及 Route Function 至 OpenFlow 交換器中, 由 Index set 決策進入交換器的封包所屬的網路區塊 (network slice), 並在該網路區塊所屬的 Flow Table 決定欲送出封包的交換器埠, 即執行 Route set 若管理者需要對特定目標封包特徵進行修改時, 則目標封包會由 Index set 導引至執行封包修改功能 Flow Table, 執行完 Modification set 後, 在送入網路區塊所屬的 Table 中執行 Route set 考量序列性 Flow 的執行次序與平行性 Flow 中皆須比對執行 Flow 的需求, 本論文將所有的 Flow Tables 分類為以下五個類別 :Index Table, Function Table, Slice Table, Route Table, Statistic Table 在設定交換器時,Ryu 控制器讀取管理者所規劃的交換器設定檔後, 會將進入 OpenFlow 交換器的封包分成需進入 Modification set 的待修改封包, 以及只需進行一般路由的 Route set 封包, 將這兩類的封包規則加上欲對應到下一個 Table 的資訊, 以 Flow 的形式寫入 Index Table, 完成初始化的設定當 OpenFlow 交換器接收到封包後, 會先將封包送進 Index Table 進行比對, 比對的特徵欄位會根據管理者所需有所不同, 若是屬於需要修改特徵的封包, 會將封包送入 Function Table 中進行特徵欄位修改, 若在 Function Table 可以找到對應的規則, 則會套用符合 Modification set, 反之則會傳送一個 Packet-In Message 給 Ryu 控制器, 將例外交給 Ryu 控制器處理在修改過欄位後,Modification set 會將封包轉交給交給 Slice Table 進行網路區塊的分類, 並將封包交給屬於該網路區塊的 Route Table, 並根據實體網路位址決定交換器埠, 進行封包轉發封包從進入交換器至送出交換器的流程如圖 4 所示, 當封包進入後, 交換器會先將封包送至 Index Table 比對, 若管理者想統計該封包出現的次數或是大小, 則交換器會先產生一個封包的副本送往 Statistic Table 進行統計, 而 Statistic Table 會將封包副本統計後丟棄, 並等待管理者調閱統計資訊時, 將統計資訊回傳在確認完統計事件後, 若該封包特徵會被修改, 則封包會送入 Function Table, 並根據管理者需求決定是否進行統計, 若封包屬於 Function Table 中的任何一個 Modification set, 則封包欄位會被修改, 再送入 Slice Table 中若在 Function Table 中沒有發現任何 Flow 上的特徵欄位與封包特徵相符, 則會將封包送入 Ryu 控制器, 由控制器讀取管理者設定, 進行封包處理以及增加 Flow 規則最後, 封包會經由 Slice Table 分配至各個網路區塊中, 借由建立實體網路位址與交換器埠的對應關係, 決定封包送出的路徑為了動態管理實體網路位址與交換器埠的對應關係, 當有任何的 ARP 請求封包經過交換器時, 皆會以 Packet-In 訊息方式通知控制器, 在進行 ARP 封包的廣播前, 控制器會記錄來源端實體網路位址對應到的交換器埠關係 [10] 後, 將該次的關係加入該 Route Table 的 Route set 中, 完成對應關係的記錄 3.5 Ryu 控制器之設計規劃為符合管理者所提出來的策略以及因應快速變化的網路架構, 本論文在控制器之設計規劃分為靜態及動態兩種策略靜態策略負責規劃基本或變動性低的 Flow 借由與管理者的互動界面, 進行靜態路由規劃, 以及進階功能隻基本策略規劃, 並將其策略儲存, 已對應動態的策略規劃而動態策略則處理由 OpenFlow 交換器送至控制器的策略, 並經由靜態策略加入新的 Flow 或修改原有的 Flow 當控制器開始執行時, 會產生兩個執行緒 (Thread):S-Thread 與 D-Thread S-Thread 負責與管理者進行靜態策略管理, 並將讀取到的策略轉換為 Flow 並傳送加入 Flow 至 Flow Table 的訊息給 OpenFlow 交換器, 或轉換為特徵清單, 並將其特徵清單分享給 D-Thread D-Thread 會接收由 OpenFlow 路由器送給控制器的 Packet-In 訊息, 並經由 S-Thread 分享的特徵清單產生 Flow 物件, 並傳送加入 Flow 至 Flow Table 的訊息至 OpenFlow 交換器中 176

4 Flow Table 規劃由於序列性 Flow 執行分析會將原本的進階網路策略修改為多條具有相依性的 Flow 執行, 為妥善管理切割後的 Flow 及所屬的 Flow Table, 本論文利用 Ryu SDN Framework 的 API 編寫程式, 將 Flow 對於封包的特

5 控制器操作交換器中的前 11 個 Table, 並對於其 Flow Table 做與章節 3.4 相同的規劃 Ryu 控制器會將 Host A 與 Host B 的 Open vswitch 的 Flow Table 0 定義為 Index Table, 並寫下 Index set 至 Index Table 中, 並將 Table 1 至 Table 4 的功能記錄為 Function Table, 提供封包特徵修改的 Modification set 皆會寫至 Function Table 上, 如 Table 1 是用來進行 Load Balancing 要修改的封包特徵的 Modification set 會被寫入至 Table 1, 若有其他需求如 NAT, Firewall 等功能則會依其功能模組寫入相對應的 Function Table 中無論是否會進行封包特徵的修改, 封包皆會被送入 Slice Table 中, 即 Table 5, 並透過 Slice Table 上的 Index set 進行分群, 將封包送入對應網路區塊的 Route Table(Table 6 ~ Table 9), 此時封包經由本身實體網路位址對應到交換器埠號碼, 完成封包轉送程序若管理者有統計需求, 則會透過控制器在備份一份原始封包至 Statistic Table 中統計圖 4 交換器利用 Flow Table 處理封包之流程圖 5 實作環境之架構圖 4. 方法實作與分析為驗證將高階網路功能模組轉換為基於 OpenFlow 協定的 Flow 其正確性, 測試之網路模組以流量監控功能負載平衡功能及常見網路位址轉換功能 (Network Address Translation, NAT) 的進行功能檢測與分析 4.1 實驗環境本論文利用 KVM 虛擬化技術部署一虛擬伺服器叢集, 並將所有的虛擬交換器定位為多網域之閘道器, 如圖 5 中,Ryu 控制器會控制兩個扮演閘道器角色的 Open vswitch 由於虛擬機器傳輸封包仍需透過虛擬交換器, 故虛擬交換器可以透過控制器進行 QoS 管理 NAT(Network Address Translation) 負載平衡 (Load balanc) 等功能由於 Open vswitich 可用的 Flow Table 最大數量為 254 個 (Table 0 ~ Table 253), 本論文利用 Ryu 圖 6 虛擬交換器上的 Flow Table 配置 177

Modification set 皆會寫至 Function Table 上, 如 Table 1 是用來進行 Load Balancing 要修改的封包特徵的 Modification set 會被寫入至 Table 1, 若有其他需求如 NAT, Firewall 等功能則會依其功能模組寫入相對應的

6 4.2 流量監控功能在進行流量監控時, 必須先設定欲監控的對象目標, 本次實作為確認負載平衡功能, 將監控目的端 IP 設定為實作負載平衡之兩部機器開始監控時, 可以透過直接觀察特定 Flow Table 之方式進行流量查詢, 如圖 7, 控制器透過搜集 durarion n_bytes 等欄位, 可以計算出區間內送至或的流量圖 7 虛擬交換器上的流量統計情形 4.3 負載平衡功能管理者利用本論文實作所提供的負載平衡模組, 並借由 OpenFlow 協定實作負載平衡之功能, 設定兩部機器提供相同的服務在管理者操作的過程中, 會輸入以下設定至 OpenFlow 控制器 : { "Balance": { "Group": [ { "Datapath": "Switch_ID", "Cond": "tcp_src_port", "Dst": " :5001", "Set": mod_2 } ] } } 從控制器的 S-Thread 開始, 控制器程式分析語法中的 Datapath 欄位, 由此欄位取得 OpenFlow 交換器的 Datapath ID, 並得知此規則的目標對象利用讀取 Cond 欄位分析平衡策略, 由 src_port 得知利用不同的來源 port 進行負載平衡, 並從 Set 欄位中取得平衡規則並加入靜態 flows 至 Index table, 加入的 flows 如下所示 : OFPMatch(oxm_fields= {'eth_type': 2048, 'ip_proto':6, tcp_dst =5001 }), [OFPInstructionGotoTable(len=8,table_id=2,type=1)] ) 其中,OFPInstructionGotoTable 代表將封包送入 Table ID 為 2 的 Flow Table, 即負責 Load balance 功能的 Function Table 由於使用負載平衡功能後, 並無法預知何時會有符合條件之客戶端來訪, 故 S Thread 新增之後的 Flow 至此結束一旦有符合條件的客戶端來訪, 進入 Index Table 後, 會符合上述之 flows 的 Match 條件, 而傳入負責負載平衡的 Function Table, 本例假設來訪客戶端的的來源 port 為 40001, 由於在 Function Table 中沒有任何的 Flow 規則可以處理目前的封包, 故會傳送 Packet-In 訊息至控制器控制器的 D-Thread 接收到 Packet-In 訊息後, 會先檢查該封包是由交換器的哪個 Flow Table 發出, 如本例發出訊息的 Flow Table 之 ID 為 1, 則控制器對於此 Flow Table 的功能實作為負載平衡, 即開始讀取 S-Thread 所提供的特徵清單, 並將產生的 flow 加入至負責 Load balance 功能的 Function Table, 加入的 Flows 如下所示 : OFPMatch( oxm_fields= {'eth_type': 2048, 'ip_proto':6, tcp_src =40001}), [OFPInstructionActions( actions=ofpactionsetfield(eth_dst='11:22:33:44:55: 66'),type=4), OFPInstructionActions( actions=ofpactionsetfield(ipv4_dst=' '),type=4), OFPInstructionGotoTable(len=8,table_id=5,type=1)]) 上述的 flow 規則會將所有由來源 port 送至 :5001 的封包修改為送至 :5001 的封包此外, 由於區域網路內的封包路由為 Layer 2 Learning, 故必須將其封包的目標實體網路位址修改, 亦即將 eth_dst 欄位修改為 '11:22:33:44:55:66', 然後再將修改過的封包送入 Slice Table(table_id=7) 最後交換器在 Slice Table 中, 透過封包的目標實體網路位址送入其所屬的 Route Table, 然後再往目標主機所屬的交換器埠送出由上述流程, 可以成功執行負載平衡之功能由於網路功能與封包傳送路徑的規劃被切割, 即便提供服務的目標主機位址改變, 也不會影響到封包傳送路徑的規劃為檢視其負載平衡的正確性, 本論文利用一部虛擬機器發出多個 request session, 考量 client 端有 10-Gbit 的網路交換能力, 且 server 端上的每部機器皆具有 1-Git 的網路交換能力進行負載平衡測試本次測試由 1 個 request 開始, 逐步測試至同時發出 32 個 request, 並統計 server 端可以提供的最大流量之吞吐量測試結果以圖 8 表示, 在只有 1 個 request 的情況下, 只會利用到一部機器提供服務, 故只會有 1Gbits/s 的流量, 而在 2 個或者是更多個 request 時, 利用 Load Balancing 功能皆可有效利用兩部機器的頻寬, 且不會因為 request 數量的增加而造成效能瓶頸 178

${ "Datapath": "Switch_ID", "Cond": "tcp_src_port", "Dst": "192.168.20.$

7 頻寬 (Mbits/s) server 提供之最大流量 (Gbits/s) 頻寬 (Mbts/s) 第十三屆離島資訊技術與應用研討會論文集同時發出的 request 數圖 8 request 數與 server 端可提供之最大流量關係圖 4.4 IP 共享 IP 共享為區域網路上常用的功能, 借由一個公開的 IP 位址 (Public IP) 對應到多個私有 IP 位址 (Private IP), 可解決 IP 位址不足及區域網路防護等問題本論文將 IP 共享機制將傳統 NAT(Network Address Translation) 功能轉換為 OpenFlow 協定中的 Multiple Flows 架構, 並與以 VyOS[14] 為基礎的傳統閘道器系統進行 NAT 在 TCP port 轉換以及 UDP port 轉換的執行效率比較, 如圖 9 10 在 TCP 的轉換效率上, 傳統閘道器的轉換效率平均為 942 Mbits/s, 而本論文方法的轉換效率為 941 Mbits/s, 表示在經過多個 Flow Table 之後, 轉換效能的衰退仍在可接受的範圍 UDP 轉換效率的測試中, 傳統閘道器的轉換效率平均為 804 Mbits/s, 而本論文實作之效率為 807 Mbits/s, 其轉換效率略優於傳統閘道器相較於傳統閘道器, 利用 OpenFlow 所實作的網路功能還具備切割子網域, 將一個大型區域網路再切割成數個小的虛擬區域網路, 並在其中提供負載平衡之功能, 提供多功能且高效率的網路管理 5. 結論由於 SDN 架構的提出, 對於網路功能的管理帶來龐大的改變由於控制層與資料層的分離, 管理者可透過單一控制器對所有的交換器下達同步的設定, 也可以針對每個交換器進行個別的最佳化, 借由比對封包特徵, 管理者對於區域網路的管理不再僅限於特定的條件, 而是可以透過開發人員所編寫的軟體, 進行客制化區域網路拓樸監控與管理本論文基於 OpenFlow 網路管理協定, 針對其特性分析, 借由多個 Flow Tables, 將衝突的封包特徵進行排序, 解決 Flow 規劃與管理者預期不符之問題, 並將傳統網路架構中常使用的模組轉換為基於 OpenFlow 協定的 Flow set, 並將 Flow 插入規劃的 Flow Table 中, 除了可以滿足網路模組所需執行的功能, 也可避免因 Flow 的增刪而造成交換器邏輯錯誤或封包轉送失效等問題未來可將路由器 (router) 的網路功能加入探討, 分析其封包特徵, 並以此方法為基礎, 發展屬於路由器的 Flow 分析策略與設定平台圖 9 VyOS 與本論文方法在 TCP port 轉換比較時間 (s) OpenFlow TCP VyOS TCP 時間 (s) OpenFlow UDP VyOS UDP 圖 10 VyOS 與本論文方法在 UDP port 轉換比較參考文獻 [1] R. Sherwood, G. Gibb, K.-k. Yap, M. Casado, N. McKeown, G. Parulkar, Can the production network be the testbed?, Proceedings of the 9th USENIX conference on Operating systems design and implementation, Vancouver, BC, Canada, Oct [2] S. Gutz, A. Story, C. Schlesinger, N. Foster, Splendid isolation: a slice abstraction for software-defined networks. Proceedings of the first workshop on Hot topics in software defined networks, Helsinki, Finland, Aug [3] Y. Goto, Kernel-based Virtual Machine Technology. Fujitsu Scientific & Technical Journal, vol. 47, pp , July [4] B. Pfaff, J. Pettit, et al., Extending networking into the virtualization layer. Proc. HotNets, Oct [5] Open vswitch, Available from: (Date of access: April, 2013). [6] Open Networking Foundation, Software-Defined Networking: The New Norm for Networks. ONF White Paper, April 12,

4 IP 共享 IP 共享為區域網路上常用的功能, 借由一個公開的 IP 位址 (Public IP) 對應到多個私有 IP 位址 (Private IP), 可解決 IP 位址不足及區域網路防護等問題本論文將 IP 共享機制將傳統 NAT(Network Address

8 [7] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenker, and J. Turner, OpenFlow: enabling innovation in campus networks. SIGCOMM Computer Communication Review, vol. 38, no. 2, pp , Apr [8] Ryu SDN Framework, Available from: (Date of access: April, 2014). [9] Open Networking Foundation, OpenFlow Switch Specificstion ONF Specification, Dec 18, [10] Nate Foster, Rob Harrison, Matthew L. Meola, Michael J. Freedman, Jennifer Rexford, and David Walker, Frenetic: A high-level langauge for OpenFlow networks. Proceedings of the Workshop on Programmable Routers for Extensible Services of Tomorrow, Nov [11] J. Matias, B. Tornero, A. Mendiola, E. Jacob, N. Toledo, Implementing Layer 2 Network Virtualization Using OpenFlow: Challenges and Solutions. Software Defined Networking (EWSDN) on 2012 European Workshop, vol., no., pp.30,35, Oct [12] POX, Available from: (Date of access: Oct, 2013). [13] The Beacon Controller, Available from: ome (Date of access: Dec, 2013). [14] VyOS, Available from: (Date of access: Mar, 2014) 180

[9] Open Networking Foundation, OpenFlow Switch Specificstion 1.3.3. ONF Specification, Dec 18, 2013. [10] Nate Foster, Rob Harrison, Matthew L. Meola, Michael J.

Microsoft Word - 10100000191.doc

Microsoft Word - 10100000191.doc 臺灣集中保管結算所股份有限公司辦理認購 ( 售 ) 權證帳簿劃撥作業配合事項部分條文修正條文對照表附件 1 修正條文現行條文說明第五章認購 ( 售 ) 權證之權利行使第一節認購權證採證券給付或以證券給付之認購權證發行人得選

讓 單 一 虛 擬 機 器 的 可 用 頻 寬 再 度 提 高 2.2 Open vswitch Open vswitch[4][5] 是 一 個 Apache 2.0 授 權 下 的 開 放 原 始 碼 軟 體, 透 過 軟 體 模 擬 出 一 個 多 層 虛 擬 交 換 器 功 能, 借 由 對

讓單一虛擬機器的可用頻寬再度提高 2.2 Open vswitch Open vswitch[4][5] 是一個 Apache 2.0 授權下的開放原始碼軟體, 透過軟體模擬出一個多層虛擬交換器功能, 借由對