專訪UCloud徐亮：UCloud虛擬網絡的演進之路

服務器虛擬化改變了IT運營方式，隨之而來的是愈來愈多的網絡被虛擬化。

當今，幾乎全部的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虛擬網絡團隊帶來了不少挑戰。

轉發面的挑戰與解決方案

1、網卡性能大幅從1G提高到10G、25G、100G帶來的性能挑戰

網絡性能的提高速度，已經超過了CPU性能提高的速度，這是一大挑戰。UCloud目前主要採用硬件卸載的方式來解決，包括可編程交換機和智能網卡。

可編程P4交換機方案

2017年第四季度，UCloud開始預研Barefoot的支持P4的可編程交換機（Tofino芯片），發現P4 and Barefoot Tofino可以很好地知足需求。P4 and Barefoot Tofino的優勢主要有：

與DPDK相比，有更高的轉發性能。DPDK基本上用網卡的方式，單機10G或者25G的性能。對於可編程交換機來講，起步就是8T到6.5T的性能，相對於DPDK在性能上是幾十倍甚至接近一百倍的提高。並且交換機的時延更低，它的單根網線支持100G，基本上能夠避免單線被擁塞的效果。

交換機的轉發性能是很穩定的，而且是能夠預期的，而DPDK的轉發性能隨業務模型可能會發生變化。

與其餘硬件交換機相比，可編程P4交換機更開放。可編程能力強，能夠定製轉發面整個處理包的p4lang。可編程P4交換機能夠完美解決Ethernet Over GRE和Flow Based Tunneling的問題。用P4語言寫程序，比用DPDK的C語言寫程序更簡單，開發效率更高。可編程P4交換機基本上採用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智能網卡正在內測階段，即將上線。

2、有狀態服務（如：安全組）引入帶來的性能挑戰

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用戶的發展，爲客戶提供穩定的服務，提供符合客戶需求的、易用和低成本的產品。」徐亮總結道。

閱讀這篇文章的你，對徐亮大牛有什麼問題要問嗎？歡迎留言，大U幫你找答案！你也能夠微信添加「雲計算總動員」公衆號，在那裏，大U帶你一塊兒飛！