工研院資通所 許名宏、顏至寬、李育緯

Peregrine在不同服務情境中（IaaS/HaaS）實現流量監控及網路虛擬化等功能

基礎架構即服務（IaaS）與硬體即服務（HaaS）

雲端運算（Cloud Computing）已成為當前電腦網路世界中許多應用服務的重要基礎。各大雲端服務供應商（Cloud Service Provider）如Amazon、Microsoft、VMware等等，對一般使用者或企業提供「公有雲」（Public Cloud）的服務，讓使用者可動態地依需求而選購在雲端資料中心（Data Center）的虛擬運算資源、系統平台甚至是應用軟體；另一方面，許多大型甚至中型企業也積極地布建專屬於企業內部使用的「私有雲」（Private Cloud），以便彈性地實現、管理企業專屬的網路服務或使用情境（例如身份認證、監控視訊等等），或是提供其他一般公有雲也具備的服務項目。由此可知，雲端運算最重要的服務項目之一，在於讓用戶（Tenant）可透過網路存取在雲端資料中心彈性實現的虛擬化計算、儲存、網路資源，因而無須用戶採購對應的大規模實體設備。這種「讓不同用戶可使用滿足其需求的計算／儲存／網路資源」的服務，即為一般所稱的「基礎架構即服務」—Infrastructure as a Service（IaaS）。

1.IaaS的運作模式

提供IaaS的服務供應商，需布署大規模的實體計算／儲存／網路設備，並以雲端管理系統（Cloud Management System，CMS）集中式地控管設備資源，例如OpenStack就是著名的開放原始碼（Open Source）CMS[1]；而在提供計算資源的伺服器上，裝有可虛擬化計算資源的系統軟體—Hypervisor，Hypervisor受CMS控制而提供虛擬機器（Virtual Machine，VM）給用戶使用。對用戶來說，遠端操作虛擬機器就如同操作實體機器一般，有獨立的作業系統、網路介面及儲存空間等資源，只是在虛擬機中可使用到的計算資源以滿足用戶最低需求為主，通常只占一部分的實體計算核心（CPU Core）。著名的Hypervisor有VMware的vSphere[2]、Microsoft的 Hyper-V[3]、Linux的KVM等等[4]。不難理解，Hypervisor是實現實體資源虛擬化的關鍵角色，所以其本身也需要占用一部分的計算資源；另一方面，虛擬機器在進行資料的輸入、輸出時，Hypervisor也會介入而造成資料讀寫的回應延遲增加，這些都是為了虛擬化實體資源，在效能面必須付出的額外成本（Overhead）。此外，當一個用戶租用多台虛擬機器，且其中某些虛擬機器有互相連線溝通的需求時，CMS必須控制伺服器上的代理軟體（Software Agent）或是設定實體的網路交換機，來實現網路虛擬化（Network Virtualization，NV）的功能，使位於同一虛擬網路的虛擬機器可彼此溝通，而各個虛擬網路之間無法直接溝通。隨著SDN（Software Defined Network，軟體定義網路）的發展[5]，目前一般IaaS的網路虛擬化功能都以搭配特定的SDN controller來實現。

2HaaS的需求來源？

隨著數年的發展下來，目前市場上已有相當多成熟的IaaS解決方案，本所基於OpenStack而延伸、強化的ITRI OpenStack Distribution（IOD，涵蓋 Peregrine 技術）亦屬其中之一[6]；然而，隨著新興應用的出現，例如大數據分析（Big Data Analytics）、深度類神經網路訓練（DNN Training）等等，以及網路設備效能的提升，資源虛擬化造成的效能損失變得更加明顯而不可忽略，如何改善此狀況也成為部分雲端服務供應商（例如日本的KDDI）的目標，「硬體即服務」（Hardware as a Service，HaaS）便是因應此需求而成為新興的服務模式，如圖 1 所示（其中藍色與紅色線條分別代表用戶A與用戶B的虛擬網路）。對服務供應商或是技術開發者而言，HaaS與IaaS最大的差異，在於HaaS管理的實體伺服器上沒有Hypervisor，因而實體資源不會被虛擬化，用戶租用的不是虛擬機器而是實體的伺服器，且用戶通常會期望租用的實體機上不存在任何非用戶自己要求安裝的軟體，此要求會使得HaaS的實現難度要高於IaaS：例如HaaS的虛擬網路便無法透過伺服器上代理軟體來實現。此外，伺服器的供給（Server Provisioning）以及各類資源的狀態監控也都是HaaS的主要技術挑戰。

本文剩餘篇幅會針對IaaS／HaaS的網路虛擬化相關技術議題，進行現有狀態的統整說明，並呈現未來的發展潛力所在。

圖 1　Cloud-based Hardware as a Service （HaaS） 示意圖

實現IaaS／HaaS的網路技術

OpenStack-Neutron ML2 Plugin提供一種可擴展的架構[7]，以支援可設定實體網路的不同 Mechanism Drivers。該架構提供可使用多個獨立Driver設定來自不同供應商的多種網路設備。若從OpenStack的觀點來看，Neutron提供了一個一致的應用程式界面，並通過該界面讓 OpenStack可提供用戶所需的網路服務。這也意謂著OpenStack-Neutron可用於設定實體網路，實現HaaS所需的虛擬網路建置。各大廠商針對旗下網路設備，開發Neutron ML2 Driver來介接Neutron API的事件，並在實作時轉換為底層網路設備對應的行為。

1.網路虛擬化技術分類

常見的網路虛擬化（NV）技術可分成Overlay及Underlay兩個類別，分別以VxLAN及VLAN為主要欄位來標示封包所屬的虛擬網路為何[8][9]；VxLAN可視為Layer-3穿隧技術（Tunneling）。目前市占率最高的VMware即屬於Overlay類別，而本文介紹的Peregrine則是屬於Underlay。兩類的基本特色比較如下表：

表 1 網路虛擬化技術分類及特色

2.各廠商支援HaaS網路虛擬化的解決方案

以下簡要介紹目前在OpenStack 計畫下，經由支援Neutron API 來控制實體交換機的各家廠商 Driver：

• ALE Omniswitch Mechanism Driver：ALE Omniswitch Driver透過RESTful API以及CLI兩種方式存取ALE Omniswitch等網路設備，支援基於VLAN網路虛擬化。目前無流量監控功能。
• Arista Mechanism Driver：Arista Neutron ML2 Driver是透過特有的EAPI來控制Arista等設備，最早的版本只支援VLANs Network Type，日後預計會加入支援多網段的網路。目前無流量監控功能。
• Avaya Networking Mechanism Driver：可支援OpenStack傳統Dynamic Virtual Routing（DVR）網路環境以及bare-metal實體環境（即HaaS）。Avaya Driver也可介接Avaya自家的SDN Controller去控制底層的網路設備。在網路監控方面，Avaya SDN Controller可以監控設備的事件，以及Flow流量等資訊，並用儀表板（Dashboard）方式顯示予系統管理者。
• Brocade Mechanism Driver：Brocade Mechanism for ML2使用NETCONF控制自家Brocade Switch，目前只支援VLANs Network Type。目前無流量監控功能。
• Cisco Nexus Mechanism Driver：Cisco Nexus Driver支援VLANs（Cisco Nexus models 3000 – 9000） 以及VxLAN overlay network type（僅Cisco Nexus 3100/9000 系列）等兩種網路種類。Cisco Nexus Driver會透過CLI方式登入Cisco設備進行對應的網路設定。目前無流量監控功能。
• DCFabric Mechanism Driver：DCFabric Mechanism Driver透過RESTful APIs和自家的DCFabric SDN Controller 溝通，SDN Controller 再使用 OpenFlow 1.3 與 OVSDB 等協定控制底層的OpenFlow交換機[10][11]，並提供了traffic engineering、firewall、load balance，DDos protection等功能。在監控方面，提供GUI介面可顯示網路拓樸，以及查詢OpenFlow交換機中的Flow Table。
• Lenovo Networking Mechanism Driver：Lenovo Networking Mechanism Driver以NETCONF協定來設定Lenovo自家的交換機，主要是針對交換機上面的VLANs進行修改與設定。目前無流量監控功能。

由上述簡介可知，目前各廠商提出的Neutron ML2 Driver：（I）幾乎都有網路設備廠牌綁定（Vendor Lock-in）的情況；（II）有的Driver僅可控制Open Flow switch來實現網路虛擬化，不支援Ethernet環境；（III）支援網路流量監控功能的ML2 Driver非常少見，且通常僅支援OpenFlow環境。由下一節的介紹可看出本團隊所開發的Peregrine SDN Controller，在這幾個面向的表現優於上述的ML2 Drivers。

Peregrine網路監控技術

本單位研發的Peregrine SDN Controller，是奠基於（由Cisco發起）開源的OpenDaylight計畫[12]，再另外延伸、強化而成，其架構如圖2所示。Peregrine起初的目標是為雲端的IaaS服務提供VLAN-based網路虛擬化功能，並針對所謂「ECOE」（Ethernet Core and OpenFlow Edge）這樣的Ethernet與OpenFlow並存的網路環境[13]，提供動態流量工程（Dynamic Traffic Engineering，DTE）、快速復原（Fast Failover）及流量監控（Traffic Monitoring）等特色功能。為了以通用性較高的SNMP協定來設定Ethernet switch的VLAN組態[13]，本團隊還開發了SNMP4SDN plugin，並貢獻於OpenDaylight計畫且隨著OpenDaylight的版本定期釋出。

Peregrine支援OpenStack Neutron plugin、基於ECOE而實現IaaS的系統架構

1. Peregrine for IaaS

參考圖2，在IaaS的每個伺服器上，每個VM皆須經過軟體的OpenFlow switch—Open vSwitch （OVS）[14]，來與其他VM或是外界溝通。Peregrine controller以OpenFlow及OVSDB協定來控制OVS的封包轉送行為[10][11]，以及貼VLAN標籤、除VLAN標籤等動作。由於OpenFlow協定可直接在OVS上設定規則，用於統計特定流量的資訊，Peregrine controller因此可蒐集到精細的（fine-grained）Flow-level流量統計數據，例如某兩個VM之間的流量所使用的總頻寬輸出（Throughput），或是某個TCP連線的即時流量統計。此外，Peregrine的DTE功能可將多個VLAN的樹狀結構，平均分散在不同的實體鏈路上，使得各鏈路的負載可達到一定程度的平衡。當有實體鏈路發生斷路時，Peregrine controller可迅速根據預先計算好的備用路徑，將經過斷路的那些VLAN，改佈署於其他正常的鏈路上，達到快速復原的目的。

2. Peregrine for HaaS

Peregrine由IaaS開始再發展到HaaS環境，由於伺服器上無法安裝OVS或其他Agent軟體，無法利用 OpenFlow switch 的長處，而一般Ethernet switch以SNMP存取資訊庫又只有記錄實體連接埠的流量數據，使得「Flow-level的流量監控」要實現的難度明顯比在IaaS環境高。在以增加軟體的功能來達成此監控目標的前提下，Peregrine controller進化為整合了sFlow／NetFlow／NetFlow-lite等封包採樣或是分類統計機制[16][17][18]，來實現一定程度的Flow監控。如圖3所示，Sample Analyzer會蒐集各個Ethernet switch即時回報的sFlow採樣封包（或是NetFlow 不定期回報的統整資訊），並以事先決定的採樣機率（例如為四千分之一）回推Flow層次的頻寬輸出，而後在Peregrine controller詢問時回報對應的統計結果。目前市面上的中高階 Ethernet switch幾乎都支援sFlow／NetFlow／NetFlow-lite三者其中之一，因此這樣的整合在不同switch廠牌型號的HaaS環境也可適用。

為了進行更高層次的封包Payload解析（Layer-7），HaaS 版的Peregrine controller還進一步整合了遠端流量映射（Remote Traffic Mirroring）機制，使得系統管理者可在圖形化介面上，決定要被映射的目標流量或實體鏈路，並動態觸發流量映射機制，將映射流量送至Payload Analyzer，經分析後再觀察到結果。目前此功能與交換機的廠牌型號的關聯較大。

圖 3　Peregrine 利用 sFlow 及 traffic mirroring 等機制而實現HaaS流量監控的系統架構

本文簡要地介紹了IaaS與HaaS兩種雲端服務情境，以及Peregrine在不同服務情境中如何實現流量監控及網路虛擬化等功能。近期Peregrine仍在持續整合發展更多特色功能，包括：（I）將實體網路區分為多個Layer-2 domain，同時使用VLAN及VxLAN來支援千萬等級的虛擬網路數量，而絕大多數的虛擬網路仍享有VLAN的好處；（II）可動態限制特定虛擬網路或虛擬機器的流量輸出，以控制網路頻寬的使用量；（III）依據各虛擬網路的不同歷史流量模型來實現動態流量工程，使得網路整體的負載平衡效果更佳等等，期望Peregrine能盡快在IaaS與HaaS市場上占有一席之地。

參考文獻

[1] Sefraoui, O., Aissaoui, M., Eleuldj, M., “Openstack: toward an open-source solution for cloud computing,” International Journal of Computer Applications 55（3）, 38–42, 2012.

[2] Lowe S. Mastering VMware vSphere. Wiley: Indianapolis, 2011

[3] Anthony Velte , Toby Velte, Microsoft Virtualization with Hyper-V, McGraw-Hill, Inc., New York, NY, 2009

[4] A. Kivity, Y. Kamay, D. Laor, U. Lublin, and A. Liguori., “kvm: the Linux virtual machine monitor,” OLS ’07: The 2007 Ottawa Linux Symposium, pages 225–230, July 2007.

[5] B. Nunes, M. Mendonca, X. Nguyen, K. Obraczka and T. Turletti, “A Survey of Software-Defined Networking: Past, Present, and Future of Programmable Networks,” IEEE Communications Surveys and Tutorials, vol. 16, no. 3, pp. 1617–1634, Aug 2014.

[6] Huang, Chun-Chieh, Guo-Hong Lai, Ling-Kang Wu, Ming-Shan Deng, and Jaime Alvarez. “ITRI OpenStack Distribution.” 電腦與通訊 No.166, 2016.

[7] List of Neutron ML2 drivers. Available at https://wiki.openstack.org/wiki/Neutron/ML2

[8] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, “Virtual eXtensible Local Area Network （VXLAN）: A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks”, RFC 7348, August 2014.

[9] IEEE 802.1Q – Virtual LANs. Available at http://www.ieee802.org/1/pages/802.1Q.html

[10] Nick McKeown, Tom Anderson, Hari Balakrishnan, Guru Parulkar, Larry Peterson, Jennifer Rexford, Scott Shenker, and Jonathan Turner, “OpenFlow: enabling innovation in campus networks”, SIGCOMM Comput. Commun. Rev. 38, 2 （March 2008）, 69-74.

[11] B. Pfaff and B. Davie, “The Open vSwitch Database Management Protocol,” RFC 7047. https://www.rfc-editor.org/rfc/rfc7047.txt

[12] J. Medved, R. Varga, A. Tkacik and K. Gray, “OpenDaylight: Towards a Model-Driven SDN Controller architecture,” Proceeding of IEEE International Symposium on a World of Wireless, Mobile and Multimedia Networks 2014, Sydney, NSW, 2014, pp. 1-6.

[13] Yu-Wei Li, “Software Defined Network Based on Ethernet-in-Core OpenFlow-at-Edge Network Architecture,” 電腦與通訊 No.161, 2015.

[14] William Stallings. 1998. Snmp,Snmpv2,Snmpv3, And RMON 1 and 2 （3rd ed.）. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.

[15] B. Pfaff et al., “The design and implementation of Open vSwitch”, Proc. USENIX Symp. NSDI, pp. 117-130, 2015.

[16] Phaal, P., Panchen, S., and Mckee, N., “InMon Corporation’s sFlow: A Method for Monitoring Traffic in Switched and Routed Networks,” RFC 3176, 2001.

[17] B. Claise, “Cisco Systems NetFlow Services Export Version 9,” RFC 3954, Internet Engineering Task Force, 2004.

[18] L. Deri, E. Chou, Z. Cherian, K. Karmarkar and M. Patterson, “Increasing data center network visibility with cisco NetFlow-Lite,” Proceedings of 2011 7th International Conference on Network and Service Management, Paris, 2011