專訪UCloud徐亮：UCloud虛擬網路的演進之路
【51CTO.com原創稿件】當今，幾乎所有的IT基礎架構都在朝雲的方向發展。在基礎架構中，伺服器和儲存虛擬化已經發展的比較成熟，作為基礎架構中的虛擬網路，為了迎合雲端計算和網際網路發展的需求，迎來了新的挑戰，UCloud虛擬網路平臺負責人徐亮對此進行了梳理。
徐亮，UCloud虛擬網路平臺負責人，公司首位5級技術專家。先後任職於上海貝爾、騰訊，有超過18年電信與網際網路行業研發管理經驗。加入UCloud後主要負責雲平臺網路架構，包括UXR網路解耦、網路產品架構升級、虛擬網路架構升級等。
網路虛擬化與SDN
網路虛擬化是一個歷史比較悠久的概念，普遍認為最初的網路虛擬化是起源於VLAN。網路虛擬化讓一個物理網路能夠支援多個邏輯網路。虛擬化保留了網路
設計中原有的層次結構、資料通道和所能提供的服務，使得終端使用者的體驗和獨享物理網路一樣。因此帶來了三大優勢：幫助更好的利用網路資源，平攤被過度使用的資源上的通訊量;無需部署專用物理架構就可以實現一些隔離操作， 提高網路安全性;合併埠，以提高網路的利用率和效能。
SDN(Software-defined Networking)是將網路裝置的控制平面(control plane)從資料平面(data plane)中分離，改用軟體的方式實現，即軟體定義網路。SDN可使網路管理員在不變更硬體裝置的前提下，以中央控制的方式用程式重新規劃網路，為控制網路流量提供了新方案，也為核心網路和應用創新提供了良好平臺，成為網路虛擬化發展的有力推動者。
雲端計算給網路虛擬化帶來新挑戰
首先，雲端計算，特別是公有云，需要網路虛擬化提供多租戶和VPC的能力。VPC(Virtual Private Cloud)允許不同租戶甚至同一租戶的網路地址重疊，廣播域獨立，必然導致對網路虛擬化的需求。最早的網路虛擬化是VLAN協議，但VLAN協議中的VID只有12個bit，僅支援4094個虛擬網路，在公有云的環境下是遠遠不夠的。這就促使公有云廠商紛紛引入Overlay技術解決這一問題。從早期的NVGRE到現在比較主流的VxLAN，和比較新的GENEVE，都支援24 bits(16M)的租戶ID，滿足了公有云的需求。
其次，雲端計算需要SDN幫助提供靈活、彈性的控制面。傳統網路中大多使用硬體裝置，如果新增了一個租戶，去配置硬體裝置是一件比較困難的事情，因為每家配置都是不同的。但是如果用計算的方式，通過軟體可以在不觸及物理網路裝置的情況下，動態的去修改網路配置，從而使網路虛擬化能夠像計算一樣輕鬆、快速、動態。
舉個例子來說明：當租戶VPC-100下的一臺VM10.10.12.34要訪問同子網下的另一個IP 10.10.56.78時，首先需要通過ARP協議去獲得10.10.56.78的MAC地址。當這個ARP請求報文到達宿主機的vSwitch上時，由於VPC的存在IP地址可能被不同租戶複用，所以首先必須要識別出該ARP請求來自VPC-100，才能識別出這個ARP報文請求的是VPC-100下的IP 10.10.56.78. 由於Overlay網路不支援廣播，所以需要知道該子網下所有VM所在的宿主機在哪裡，才能夠把這個ARP請求加上Overlay封裝送到目的宿主機上。當然如果vSwitch瞭解VPC-100的10.10.56.78的MAC是52:54:12:34:56:78，也可以採用ARP代答技術，直接返回ARP響應。所有的這一切都不是依賴網路裝置自動完成，而是通過SDN用軟體控制實現的。
除此之外，Overlay給物理網路也帶來了非常大的複雜度，硬體的支援非常慢。徐亮在此舉例為據：最流行的萬兆網絡卡晶片Intel 82599不支援任何Overlay協議的解除安裝，直到今年Mellanox的網絡卡才開始逐步支援VxLAN的TSO解除安裝。而交換機晶片用了5年的時間才支援VxLAN協議，其他Overlay協議仍然沒有交換機晶片支援，導致Overlay網路的效能長期低於物理網路。
UCloud虛擬網路發展歷程
在2012年UCloud成立之初，虛擬網路就是IaaS的一個核心元件，當時採用EBTables和IPTables的組合來實現租戶隔離。但是UCloud的團隊很快發現這個技術方案不足以向客戶提供安全、穩定的服務。
於是從2013年開始，UCloud的虛擬網路開始採用SDN技術實現租戶隔離，也就是VPC(Virtual Private Cloud)。同年年底，UCloud意識到客戶在使用雲主機的同時也有使用物理機(bare metal)的需求，所以率先採用盛科的SDN交換機，推出了和公有云網路互通物理雲主機產品。
2015年，隨著客戶業務的快速發展，硬體SDN交換機OpenFlow流表有限的條目已經不足以支撐物理雲主機的需求。UCloud迅速開發了採用DPDK技術的伺服器叢集來替代硬體SDN交換機。隨後更多的DPDK閘道器作為OVS的補充出現在UCloud的虛擬網路中，為客戶提供更快速的虛擬網路。
從2017年開始，隨著25G網路的發展，UCloud開始研發基於硬體解除安裝的虛擬網路方案。最後確認下來的方向是可程式設計交換機和智慧網絡卡兩者同時推進。
在控制面流表管理方面主要有兩種方案，被動觸發方式和主動推送方式。被動觸發方式是傳統的OpenFlow流表管理方式，在收到報文時首先檢查是否本地有流表命中，如果沒有，則通過OpenFlow Packet-in訊息傳送給Controller處理，Controller下發新的流表處理此型別報文。主動推送方式則是在網路拓撲發生變化的時候主動將變化的流表推送到轉發面。
早期，UCloud以被動觸發方式為主。其優勢在於實現簡單，但缺點是首包會有延遲，且控制面受使用者行為影響大，可能會有很多突發情況。針對首包延遲問題，UCloud採用主動模擬使用者對外發送報文的方式觸發流表下發，達到類似主動推送的效果。針對控制面突發較多的問題，採用本地Controller先對Packet-in訊息進行去重、限流後再發給遠端Controller的方式進行規避。
在大量引入DPDK閘道器後，UCloud也在使用主動推送方式。其優勢在於有效消除首包延遲，且控制面壓力更可控，不影響轉發面。但主動推送方式存在的問題是，如果虛擬網路規模很大的時候，推送的範圍就會很大，可能會造成推送時間過長而導致網路變化無法實時生效。
針對以上問題，目前UCloud也在探索兩者結合的一些新方法。
UCloud虛擬網路的挑戰及解決方案
虛擬網路領域經過近10年的演進仍然處於一個快速發展變化、百家爭鳴的階段，同時也給UCloud虛擬網路團隊帶來了很多挑戰。
轉發面的挑戰與解決方案
一、網絡卡效能大幅從1G提升到10G、25G、100G帶來的效能挑戰
網路效能的提升速度，已經超過了CPU效能提升的速度，這是一大挑戰。UCloud目前主要採用硬體解除安裝的方式來解決，包括可程式設計交換機和智慧網絡卡。
可程式設計P4交換機方案
2017年第四季度，UCloud開始預研Barefoot的支援P4的可程式設計交換機(Tofino晶片)，發現P4 and Barefoot Tofino能夠很好地滿足需求。P4 and Barefoot Tofino的優點主要有：
1、 與DPDK相比，有更高的轉發效能。DPDK基本上用網絡卡的方式，單機10G或者25G的效能。對於可程式設計交換機來說，起步就是1.8T到6.5T的效能，相對於DPDK在效能上是幾十倍甚至接近一百倍的提升。而且交換機的時延更低，它的單根網線支援100G，基本上可以避免單線被擁塞的效果。
2、 交換機的轉發效能是很穩定的，並且是可以預期的，而DPDK的轉發效能隨業務模型可能會發生變化。
3、 與其他硬體交換機相比，可程式設計P4交換機更開放。可程式設計能力強，可以定製轉發面整個處理包的p4lang。可程式設計P4交換機可以完美解決Ethernet Over GRE和Flow Based Tunneling的問題。用P4語言寫程式，比用DPDK的C語言寫程式更簡單，開發效率更高。可程式設計P4交換機基本上採用RPC/">gRPC的介面進行遠端的管理，作業系統採用 Open Network Linux(基於Debian)，這使交換機更像一個傳統的伺服器。另外相對於其他交換機，可程式設計P4交換機有一個生態圈，有P4 Runtime、Stratum這樣的開源社群，更好的促進交換機的發展。
目前UCloud採用P4可程式設計交換機完成了一個新增的核心Gateway的開發和測試工作，已經開始部署和灰度上線。
智慧網絡卡方案
同期，在計算節點上，UCloud也在探索如何解決25G網路帶來的效能挑戰。
在VMware主宰虛擬化的早期階段，通過VLAN實現租戶隔離，通過SRIOV的方式將硬體網絡卡虛擬化成多張虛擬網絡卡供虛擬機器使用，是非常成熟而高效的解決方案。採用SRIOV的方式，虛擬機器可以獲得物理網絡卡95%以上的PPS效能。但12位的VLAN只能支援最大4094個租戶，並不能滿足公有云的需求，而二層的組網方式也不適合公有云的大規模資料中心。幾乎所有的公有云都是採用的Overlay的解決方案。而Overlay的方案相對VLAN要複雜很多，大多數新一代非智慧網絡卡的ASIC晶片目前僅可以完成VXLAN的封裝和解封裝工作，但虛擬機器所在的宿主機地址資訊需要控制面提供，使得SRIOV技術在Overlay的網路裡完全無用武之地。
基於DPDK的vSwitch方案對比基於Linux Kernel的vSwitch，在報文轉發效能上提升了幾倍。通過DPDK的Vhost Library，VM的網路報文可以通過Virtio虛擬網絡卡，以Zero Copy的方式到達宿主機上的vSwitch進行處理。宿主機上的vSwitch根據控制面資訊瞭解目的MAC或者IP所在的宿主機資訊，然後加上Overlay封裝高速轉發。但代價是絕大多數網絡卡只能支援Busy Poll的DPDK工作方式，無論虛擬機器當前的PPS是多少，DPDK都會佔用固定的CPU Cores，而這部分計算資源原本在閒時是可以出售的。
而智慧網絡卡(SmartNIC)的目標就是將網路轉發所佔用的宿主機計算資源釋放出來，從而達到降低TCO的目標。目前智慧網絡卡的實現百花齊放，例如：AWS採用基於通用ARM的眾核方案、AZure採用基於FPGA的方案、華為雲採用基於專用網路處理器(NP)的方案、阿里雲採用基於可程式設計ASIC晶片的方案。就目前來看各個方案各有優勢，並沒有特別突出一統天下的方案。
基於通用ARM、MIPS的眾核方案，簡單將原來跑在宿主機上的vSwitch移植到網絡卡上，既可以支援Linux Kernel也可以支援DPDK，從而達到釋放宿主機計算資源的目的。其他基於FPGA、NP和可程式設計ASIC的方案，大多在網絡卡上維護一個快速轉發路徑(FastPath)，當收到報文後，首先檢查是否在FastPath已經快取了該類報文的處理規則，如果找到，則直接按照規則執行動作，否則就轉發到SlowPath去處理。而這個SlowPath可以是DPDK，也可以是Linux Kernel。因此，FastPath最重要的是看是否支援足夠多的Action，以及自定義Action的可擴充套件性。SlowPath和FastPath通訊除了各廠商的私有介面外，也有標準的TC Offload介面和DPDK提供的RTE Flows介面。
智慧網絡卡幾乎都可以採用SRIOV的方式接入虛擬機器。VF支援的佇列個數也非常重要，只有支援多佇列的VF，才能夠通過RSS充分發揮出虛擬機器的多核優勢，從而達到較高的網路處理效能。整合FastPath和SRIOV，智慧網絡卡也能夠使虛擬機器的網路效能接近物理網絡卡。
但阻礙SmartNIC採用SRIOV方式的一大原因就是虛擬機器熱遷移(Live-Migration)，SRIOV方式虛擬機器直接管理VF，這導致無法Live-Migration。Live-Migration的問題較傳統的解決方案是通過VF和Virtio Bind的方式來規避，在正常工作的時候，使用VF進行高效能轉發，在Live-Migration前熱拔出VF網絡卡無縫切換到Virtio網絡卡工作，在Live-Migration完成後再熱插入VF網絡卡。
顯而易見，在Live-Migration過程中使用Virtio網絡卡會造成網路效能下降，使得Live-Migration需要選擇閒時進行。Intel提出vhost data path acceleration(vDPA)技術，在VF上相容Virtio，從而更好地支援Live-Migration。同時Virtio 1.1規範的推出使得網絡卡硬體相容Virtio更加容易。
目前UCloud基於SRIOV支援熱遷移的高效能25G智慧網絡卡正在內測階段，即將上線。
二、有狀態服務(如：安全組)引入帶來的效能挑戰
UCloud希望能夠通過智慧網絡卡來解除安裝有狀態業務，例如：防火牆、NAT和安全組。有狀態業務要求實現連線追蹤(Connection Track)。新建連線需要在
FastPath插入新規則，這要求非常高的規則更新速度。每個連線都需要在FastPath維護一條規則，這對記憶體提出了非常高的要求。連線的狀態變化需要在FastPath和SlowPath間同步，TCP的狀態變化時還需要檢查SEQ。
目前UCloud在測試一些商用的SmartNIC，智慧網絡卡對有狀態業務的支援正在越來越好，有望在不久的將來，能夠提供足夠成熟的有狀態業務解決方案。
控制面挑戰與輕量級ServiceMesh方案
虛擬化的優勢很明顯：可以提高伺服器、計算及網路容量的使用效率，減少資金投入。但同時，虛擬化也給負責管理虛擬網路的資料中心人員帶來了新的挑戰。
SDN的控制面需要在每臺計算節點上部署，本質上就是一個超大規模(x萬節點)的分散式系統。它面臨的問題也和常規分散式系統一樣，需要解決CAP問題、可擴充套件性問題等等。為了降低變更的影響範圍，UCloud也逐步開始進行微服務改造。同時更好地實現按使用者灰度釋出，因此引入了輕量級ServiceMesh架構。
輕量級ServiceMesh是基於Envoy和Istio Pilot的Istio變種方案。Istio是一個非常優秀ServiceMesh方案， UCloud團隊對Istio的流量管理功能非常滿意，同時通過評測也能夠接受Envoy的效能開銷。
但是UCloud目前並沒有採用K8S，事實上，UCloud所開發的IaaS控制面程式，本身就和K8S的功能類似。並且，UCloud有大量的既有服務。K8S的網路方案比較複雜，且效能堪憂，再通過IPTables來透明引流確實是雪上加霜，給未來的運維、Trouble-Shooting帶來了很高的複雜度。目前UCloud主要使用gRPC和HTTP，但仍有資料庫服務等業務不適合跑在K8S中，而K8S的網路方案需要能夠相容現有的資料庫等業務。
經過對Istio程式碼的預研之後，UCloud最終選擇了將Pilot從Istio中剝離出來，脫離K8S執行的輕量級ServiceMesh方案。在Istio中Pilot是作為Envoy的控制面提供集中式流量管理功能的模組，這是實現灰度釋出必不可少的功能，事實上也是ServiceMesh的核心功能。Mixer提供的訪問策略和控制，Istio-Auth提供安全認證功能，相對來說在UCloud的內網環境下，都可以裁剪掉。
而得益於Pilot的良好設計，很容易實現ETCD Platform，從ETCD獲取Service和Service Instance資訊。UCloud重寫了Pilott的main.go，保留了Pilot的model、proxy和proxy/envoy模組，刪除其他的Platform僅保留新增的ETCD Platform。
最後在保留完整的Istio DSL支援的同時，得到了完全脫離K8S執行和編譯的Pilot。同時將Pilot和ETCD gRPC naming and discovery做了深度整合，自動剔除沒有線上的ServiceEntry。
在脫離K8S後，仍然需要採用Sidecar的部署方式。UCloud採用container的方式打包和部署微服務，但採用Host的網路方式，簡化了和現存服務的網路通訊方式。同時利用docker-compose模擬K8S的POD，管理服務間的依賴。通過實現一個簡單的服務管理、版本管理、叢集管理、路由策略管理層，為叢集中的每臺Node(VM或物理伺服器)生成docker-compose配置檔案，實現每臺Node的服務部署和管理。
最後針對HTTP 1.0、HTTP 2.0和gRPC的RPC方式，採用顯式代理而不是IPTables透明引流和Envoy整合。如果服務中配置了Envoy的Proxy Port，則通過Envoy接入ServiceMesh;如果配置是IP地址和埠，則直連這個地址;如果配置的是域名且沒有配置Envoy的Proxy則自動採用ETCD gRPC naming and discovery的方式去發現遠端服務。
最終，UCloud輕鬆利用Pilot和Envoy實現了按使用者灰度釋出，目前該ServiceMesh框架已經在UCloud多個專案中使用。
後記
加入UCloud虛擬網路團隊三年多，徐亮深刻地認識到這個領域百家爭鳴，仍然在快速變化中。但 “Software is eating the network” 這個趨勢始終清晰可見。從最早的SDN、軟體vSwitch到智慧網絡卡、可程式設計交換機，軟體在網路中的作用越來越重要。
“同時密切關注網路和軟體兩個領域的發展，消化吸收符合自身需求的新技術，才能夠跟上UCloud使用者的發展，為客戶提供穩定的服務，提供符合客戶需求的、易用和低成本的產品。”徐亮總結道。
【51CTO原創稿件，合作站點轉載請註明原文作者和出處為51CTO.com】
【責任編輯：趙立京 TEL：（010）68476606】