服務器虛擬化改變了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虛擬網絡團隊帶來了很多挑戰。
轉發面的挑戰與解決方案
一、網卡性能大幅從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智能網卡正在內測階段，即將上線。
二、有狀態服務（如：安全組）引入帶來的性能挑戰
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帶你一起飛！