本文首先簡單介紹網路功能虛擬化(Network Functions Virtualization, NFV)、K8S (Kubernetes)專案與國家5G NFV計畫；接著介紹工業技術研究院所建立的網路功能虛擬化效能實驗室、相關測試技術與測試案例，藉由多年深耕網路功能虛擬化的經驗，該實驗室能為客製化客戶所需環境，以釐清效能瓶頸並產出效能報告。另外，儘管Kubernetes已是為目前主流的虛擬化容器技術，但現有Kubernetes仍略顯不足，工研院團隊亦整合其他專案並加強了效能監控、虛擬化管理與網路方面的性能，本文在最後也給予簡短的結論。
網路虛擬化
早期由於專屬的網路硬體、成本限制與核心網路發展愈趨複雜且客製化程度極高，使得設備汰換或是升級不易，容易產生相容性與互通性不足的情況[1]，為了克服這個難題，以網路功能虛擬化技術逐漸受到注目。意即，將網路功能從專屬設備中取出，將其改運行至伺服器、交換器或儲存設備中，將可有效降設置與維護成本，以增加布建彈性及更有效的利用現有資源，如圖1所示。
圖1 網路功能虛擬化示意圖
為了進一步管理網路功能虛擬化系統，ETSI提出的網路虛擬化架構中也提出網路功能虛擬化基礎設施(NFVI)，其包含協作者(Orchestrator)、虛擬化管理程序(Hypervisor)、作業系統、虛擬機器、容器(Container)、其他硬體所組成。NFVI虛擬化硬體資源後，再將虛擬化的硬體資源分配給虛擬網路功能(Virtual Network Function, VNF)使用，而目前各大廠商亦針對不同網路虛擬化技術或者虛擬網路功能持續進行研發，如Cisco、AT&T與樂天等大廠。
目前國家「5G通訊系統與應用旗艦計畫」亦針對5G技術與應用投入研發，內容包含移動性邊緣計算、電信核心網路虛擬化(Virtual Evolved Packet Core, vEPC)輕核網、NFVI虛擬化系統平台、擴增實境/虛擬實境(Augmented Reality/Virtual Reality, AR/VR)、無人機、物聯網等。其中在NFVI平台應用方面，則可應用在邊緣端、骨幹網路、核心網路等，如圖2所示。其優點為可彈性布建網路服務功能、可依照使用量自動增減服務節點，有效利用現有硬體資源。
圖2 NFVI應用場域示意圖
在面對日新月異、快速發展的網路功能虛擬化技術，各大軟硬體廠商紛紛投入人力，想得知自家產品在NFVI平台或者虛擬網路功能產品上的效能，但苦於技術、人力或是硬體資源不足，無法全面得知自家產品在哪種平台的哪種環境下執行哪種運作會產生哪種效能瓶頸等詳細數據。為解決廠商困境，工研院成立網路虛擬化效能實驗室，能夠根據客戶要求建立客製化NFVI或虛擬網路功能環境，進而幫助客戶分析效能瓶頸以及定期產出效能報告，讓客戶能夠迅速了解問題癥結點，相關客戶測試案例將在本文後續進行介紹。
Kubernetes
此外，隨著網路功能虛擬化的發展，2013年由於Docker正式開源，虛擬化技術逐漸由基於虛擬機器(Virtual Machine, VM)轉變為基於容器的技術為主。藉著容器虛擬化技術的崛起，越來越多的應用服務改以容器運行，因此管理容器運作與部署的工具變得至關重要。Kubernetes正是容器協作者的主流技術，最早由Google內部開發且是目前唯一的開源軟體，主要可管理容器運行與部署並提供多租戶管理面(Multi-tenancy)、平台擴充(Cluster Scalability)、高可用性(High Availability)、滾動式升級(Rolling Update)與自動負載平衡(Load Balancing）等特性，由於其成熟的技術及開放原始碼的特性，目前Kubernetes已廣泛運用於各種雲端場域、大型企業內部。
然而原生Kubernetes僅提供單一虛擬網卡介面，對於5G NFV核心網路而言確實不敷使用，雖然目前有許多開源軟體提供解決方案，但國內廠商缺乏能夠調整、修改與整合Kubernetes與各種開源軟體的能力。此外，國內廠商雖有使用OPNFV或Kubernetes等開源平台，但僅用於內部簡單測試，並無整合5G End-to-End系統的能力與環境，更沒有系統自動化監控、管理、效能優化等功能。除此之外，目前主流的容器平台Kubernetes並非特地為網路虛擬化打造，無法滿足5G NFV的各項需求，為了更符合5G NFV各種應用服務的運作特性，工研院研發一套名為「X-K8S」的效能監控與最佳化軟體，當容器發生異常時便成自動回報與分析效能瓶頸、調整系統參數與自動優化整體效能，有關X-K8S的相關技術將在本文後續進行介紹。
工研院NFV效能測試實驗室
如前文所述，網路虛擬化技術快速崛起使得各大廠紛紛投入人力、物力進行研發，然而如圖3、與框架所示，當各種硬體或應用紛紛虛擬化的同時，如何得知多種參數之間的交互影響；意即，根據框調教優化的參數可能影響框或框中的虛擬化效能，此結果可能導致的效能問題演變成一種複雜且棘手的情況。
圖3 網路虛擬化可能潛在的效能瓶頸示意圖
為此，工研院開發一個NFV實驗平台，以幫助客戶客製化所需實驗場景，如NFVI或VNF等。其測試架構如圖4所示，本實驗室採用英特爾(Intel)提出的OPNFV Yardstick的NSB(Network Service Benchmarking)專案，主要能模擬NVFI與VNF虛擬化場景亦可管理虛擬化環境，可支援不同NFVI平台，如ESXI、KVM、Docker、VMware、OpenStack與Kubernetes等；虛擬機器/容器效能調教則引入基本輸入輸出系統(Basic Input/Output System, BIOS)與非統一記憶體存取架構(Non-uniform Memory Access, NUMA)、處理器的親和性(CPU Pinning/Processor Affinity)、巨大分頁(HugePages)等設定；資料平面(Data Plane)則採用單一根I/O虛擬化(Single Root I/O Virtualization, SRIOV)、資料平面開發工具集(Data Plane Development Kit, DPDK)，如OVS-DPDK、向量封包處理程序(Vector Packet Processing, VPP)、SPP(Soft Patch Panel)等與QAT(Quick Assist Technology)等技術。圖4中，NSB控制節點(NSB Control Node)中的虛擬化網路功能目前則提供幾種組合，分別為：L2-Fwd、L3-Fwd、ACL與多協定標籤交換(Multi-Protocol Label Switching, MPLS)，亦可加入更多商用虛擬化網路功能；Traffic Generator(GEN)端可產生使用者自訂的封包大小，可從64Bytes到1,280Bytes不等或是封包型態與封包流(Flow)數量等，並透過NSB顯示圖型化數據提供客戶測試結果；SUT(System Under Test)端為接受測試的系統，可按照客戶需求客製化測試環境，如特定的軟硬體、商用虛擬化網路功能、作業系統、虛擬化管理程序、Soft Switch等。本實驗室使用NSB PROX進行客製化NFVI測試，在NSB觸發測試事件，由GEN端在自訂拓撲上產生流量並傳送至SUT端後，再傳回GEN端。藉由此過程中所產生的封包差異量或吞吐量(Throughput)則可推算出接受測試的SUT端效能；最後NSB可將上述結果透過GUI介面供使用者閱覽，進一步找出效能瓶頸並決定解決方案。
圖4 工研院NFV效能實驗室之測試架構示意圖
根據上述概念，本文介紹的網路虛擬化效能測試案例為在軟體定義廣域網路(Software-Defined WAN, SDWAN)環境下的效能問題。客戶指定使用Intel Atom Processor C3758系列進行SWDAN環境下的效能測試。為此，本實驗室在SUT端布建了客戶要求的相關客製化硬體環境，網路環境分別為1Gbps與10Gbps，在此以1Gbps環境為例。場景敘述如圖5所示，每個主機端分別配有兩個虛擬機器，一個虛擬機器執行虛擬深度封包檢測(Virtual Deep Packet Inspection, vDPI)而另一個虛擬機器執行虛擬網際網路安全協定(Virtual Internet Protocol Security, vIPSec)，並執行加密或解密演算法，如AES、GEM與QAT。此案例為：封包流從GEN端送出，流入圖中Enterprise Branch Node(DUT)端左側的虛擬機Phys(DPDK)端進入vDPI後再進入vIPSsec(VM)進行加密。最後該封包流流經DUT右端的Phys(DPDK)端再送往Traffic Termination Endpoint端。在此端點，封包流不會經過vDPI，而是直接在vIPSsec進行解密，如與所示；最後此封包流會再送往DUT端與GEN端，如圖5中與所示。
圖5 SDWAN客戶測試案例結果
如果網路環境與參數正常的話，在1Gbps的網路環境下，理想情況的網路吞吐量應該接近1Gbps。然而在圖5中，可以看到DUT端vIPSsec進行加密之後封包大小增加了18%，但因為網路環境僅1Gbps，故在Traffic Termination Endpoint端封包大小變開始有了改變，最後在此端封包解密的時候，吞吐量僅剩804Mbps；故可從此案例推論在1Gbps網路環境下，vDPI與vIPSec並不是造成網路效能瓶頸的主要原因，下一步可在10Gbps網路環境下進一步做測試，以便逐步找到真正造成效能瓶頸的肇因。
以下介紹另一個測試案例，如圖6所示，主要測試在同一個插座(Socket)下使用6個Poll Mode Driver程序(PMD Thread)配置不同對於效能的影響。圖中有4個虛擬機器，分別為VM1~VM4，使用CPU Core 20與21，而CPU Core分配的PMD thread如圖6所標示；圖中雙向箭頭線段為封包流向。在NUMA調整之前，吞吐量僅有2.41Mpps，而在修改VM1的PMD Thread使其使用相同CPU Core之後，吞吐量則可提高至2.48Mpps，由上述結論可知，在同一個插座下僅是調整一個小小的參數便能影響整體網路效能。
圖6 同插座中CPU與PMD分配結果
X-K8S技術/實際案例
隨著容器虛擬化技術的成熟，虛擬化技術逐漸邁向容器網路功能化(Container Network Function, CNF)發展，而5G關鍵核心(如vEPC)亦從以虛擬機為基礎的NFV改以容器化架構實現。除了5G核心元件的架構革命，當前應用服務亦逐漸以雲原生(Cloud Native)概念實作。為了提供雲原生服務所需的虛擬化容器平台及5G核心功能所要求的高頻寬、低延遲，C/U(Control Plane/User Plane)分離等需求，如圖7所示，X-K8S整合了原生Kubernetes、Multus-CNI、Prometheus專案以及SR-IOV插件，使得Pod能同時使用多張高頻寬網卡，直接透過SR-IOV從硬體層面做C/U分離，甚至能使用P4 Smart NIC[2]加速核網元件的封包運算。為了讓核心網路CNF能夠提供穩定可靠的服務，X-K8S在Kubernetes平台上加入了CMK(CPU Management for Kubernetes)插件，CMK允許CNF綁定在指定的CPU上，藉此不受上下文交換(Content Switch)影響。此外，X-K8S亦針對5G CNF和各種應用服務的運作特性，監控其網路、CPU、記憶體、Session等資訊，當發生異常行為時會自動示警且自動分析效能瓶頸、調教系統參數與自動優化整體服務效能。
圖7 X-K8S架構圖
另一方面，工研院的X-K8S同時作為經濟部5G計畫的NFVI平台，亦整合了各種應用服務，如vEPC、iMEC(intelligent Mobile Edge Computing)、VR社群、SON(Self-organizing Network)等，打造一套完整End-to-End專網整合系統。藉此，UE(User Equipment)可透過小型基地台(Small Cell)連線至iMEC，透過iMEC與vEPC進行註冊後，UE便可使用平台內的網路服務。若使用者查訪的應用位於此邊緣範圍內，則iMEC會將使用者的網路封包導引至近端服務，避開傳統連線上雲端帶來的高延遲缺點。如圖8所示，使用者可透過部署於邊緣端的小型基地台連線至工研院X-K8S NFVI內的iMEC，直接訪問位於邊緣端的應用服務，如圖中內原點箭頭線所示。而當使用者訪問的是位於邊緣平台以外的雲端服務時，iMEC則會將流量導引至外部網路，如圖中粗線段箭頭線所示。如此一來，使用者便能在使用高速邊雲運算架構的同時，一如往常地使用原本的雲端服務。
圖8 經濟部5G計畫NFVI X-K8S示意圖
5G NFV潮流勢在必行
目前國外主流電信商也紛紛將網路服務以容器方式虛擬化，如AT&T、樂天、Nokia等。由此可見未來不管是在電信商或是營運商對於虛擬化的需求只會越來越高，5G NFV的潮流已是勢在必行。而目前工研院的虛擬化效能實驗室與X-K8S已與多家國內廠商達成合作計畫，而X-K8S於工研院內部也建置私有5G 邊緣平台，未來也將會與電信商合作，技術轉移或共同建置網虛擬化基礎設施平台。
(本文由台灣資通產業標準協會提供，作者皆任職於工研院資料中心架構與雲端應用軟體組)
