如何極度壓榨網路性能：揭秘 UCloud 的物理雲網關

近些年來，雲計算蓬勃發展，上雲成為現在軟體開發落地的首選。但隨著企業業務的不斷增長和擴大，傳統雲計算的劣勢也暴露出來：單體硬體性能不夠，只能堆集群；租戶隔離不夠徹底，時有新聞爆出問題。因此，物理機伺服器又再一次的被提上了檯面。

創立於 2012 年的 UCloud，從 2013 年伊始就面向市場同時提供了基於虛擬化伺服器的公有雲產品和基於裸金屬伺服器的物理雲產品。不過，和絕大多數人想像中的不同，物理雲伺服器並非直接幫你上架一個伺服器就行的，其背後也有不少複雜的技術難點需要 UCloud 及合作夥伴們去攻關。這其中最為艱難的，可能就是虛擬網路相關特性的研發。

物理雲產品和公有雲產品最大的不同就在於客戶可以獨佔並完全控制整台物理伺服器，UCloud 作為服務商並不會在伺服器上運行任何虛擬化的軟體。這使得想要讓物理雲產品和公有雲產品的網路互通、讓物理雲產品享受到公有雲產品所享有的網路優勢變得十分困難。特別是一些有狀態的特性比如安全組等實現起來更加困難。

UCloud 踩過的那些坑

從 2013 年開始，UCloud 開始使用 Open vSwitch 來構建基於 Openflow 技術的公有雲 SDN 虛擬網路。也因此，同年， UCloud 提供物理雲產品的時候，選用了支持 OpenFlow 的 SDN 交換機，以實現物理雲產品和公有雲 VPC 網路的互通。

2014 年，隨著 UCloud 業務的擴大和快速發展，已有的交換機所提供的 OpenFlow 流表有限的條目已經無法支撐實際物理雲產品業務的需求。

2015 年，已經在 DPDK 技術上做了兩年研究儲備的 UCloud 領先在產品環境推出了採用 DPDK 技術的伺服器集群，從而替代硬體 SDN 交換機，滿足業務層面的需求。

但隨著乙太網技術的發展，人工智慧、大數據等應用的落地，網路技術的發展得到了爆發般的發展，25G、100G 的網路迅速得到普及， DPDK 網關集群的轉發性能和成本問題逐漸成為業務發展的瓶頸。

時間來到了 2019 年， UCloud 開始使用智能網卡（Smart NIC）來替代原有的 DPDK 網關集群。UCloud 採用的智能網卡方案採用了 16 核 ARM CPU 運行 OVS 作為 SlowPath，採用 Linux TC Flower 卸載技術將網卡晶元作為 FastPath，通過 SRIOV 技術和用戶系統集成，很好地解決了性能問題，但與此同時，其所帶來的高昂採購成本造成了成本的提升。此外，由於所採用的智能網卡的轉發麵尚不可編程，也使得任何新的特性都需要網卡晶元廠商修改固件來實現。甚至一些比較複雜的特性也不能實現。比較典型的例子就是為了讓智能網卡支撐 UCloud 使用的 Overlay 封裝格式，就花費了半年時間才在和網卡晶元廠商反覆溝通協調下完成，而類似帶寬控制、硬體卸載的特性卻難以實現。

痛定思痛的深度思考

六年的艱辛探索，讓 UCloud 調研試驗了幾乎市面上所有的各種網路網關方案。而這些年來踩的坑，也讓 UCloud 看到了這一代網關產品的問題和不足。作為戰鬥在雲計算網路技術一線的團隊，UCloud 基於實踐經驗，總結出了下一代物理雲網關應該滿足的一些需求：

1. 全功能：能夠提供和公有雲一樣的網路特性，比如有狀態服務安全組等。
2. 高性能：能夠滿足從 25G 網路到 100G 網路的需求。
3. 低成本：比 DPDK 網關和智能網卡網關有更低的擁有成本。
4. 可定製：能夠滿足定製需求，可以基於此進行進一步的演進。

基於 Jericho2 晶元的下一代物理雲網關 —— BCM88690

在使用現有的智能網卡解決方案的同時， UCloud 也在積極的在技術市場上尋找合適的下一代物理雲網關，以替換現有的產品解決方案。

首先進入 UCloud 視線的是某公司的一款高性能交換機。它和智能網卡一樣可以運行 Linux 和 Open vSwitch，更加難得的是，其通過 Switchdev 支持 OVS TC Flower 卸載，並使用交換機晶元作為 OVS 的 FastPath。遺憾的是交換晶元對 TC Flower 卸載的支持仍然不好，造成很多功能無法卸載。並且交換晶元不支持用戶編程，UCloud 無法修改交換晶元的管線來滿足自己實際的業務需求。

而在這時，博通正在研發 Jericho2 可編程交換晶元相關的產品，於是 UCloud 與博通一拍即合，與博通合作利用 Jericho2 可編程交換晶元研究開發物理雲網關，並基於研究的成果，開發出了能夠完美滿足 UCloud 需求的物理雲網關。

在技術層面上，UCloud 通過在 Jericho2 可編程交互晶元上定製了管線來作為 TC Flower 的 FastPath，並在交換機控制面運行 Linux + OVS 作為 SlowPath ，並通過 TC Flower Offload 將兩者集成在一起，從而實現硬體的加速。

當報文進入交換晶元，首包未命中時通過可編程交換機的虛擬網卡進入交換機的 Linux 內核，通過 OVS 的 Datapath 觸發 ovs-vswitchd 下發新的 Openflow 流表。UCloud 通過對 OVS 做了盡量少的改動，將原先通過 Netlink 發送到內核去的 TC Flower 卸載消息通過 UNIX 套接字發送到運行在用戶態的 Jericho2 Agent，它再將消息轉化為對應的可編程交換機的消息下發給交換晶元。後續報文將直接命中交換機管線中的流表，由交換晶元轉發。

Jericho2 提供了業界獨一無二的可編程架構，除了管線節點可編程外，還可以進行管線延展，在增加了處理流程的同時而沒有損失任何轉發性能。其基於 C++ 的編程工具鏈，成熟且直觀，使 UCloud 可以輕鬆的基於現有晶元添加功能、在線升級，並輕鬆的根據實際需求進行定製和實施。得益於 Jericho2 靈活的可編程能力，UCloud 和博通合作在交換晶元上實現了 OVS 的 TC Flower 卸載轉發麵，可以實現和智能網卡同樣的 OVS 卸載功能，但達到了 4.8T 的轉發性能，相當於 48 塊 100G 智能網卡。並且還保留了進一步擴展定製的能力，以實現 UCloud 使用的 Overlay 封裝格式 GRETAP 為例，可以完全自行開發、靈活修改，一周的工作就能完成。

另外 Jericho2 真正的模塊化表項結構，所有表項共享同一塊物理緩存，極大增加了片上資源的使用效率。管線上所有處理節點可以並行訪問，根據不同的應用場景進行邏輯表項的靈活劃分，使得同樣的硬體可以應用在完全不同的使用場景。豐富的表項資源使得新一代的網關能夠完全滿足用戶現有甚至未來可見數年的規格需求。

最終， UCloud 實現了一個完全和公有雲特性兼容，轉發能力高達 4.8T ，並且可以自由定製，成本也非常有競爭力的物理雲網關。這滿足了對於下一代物理雲網關所定義的四大需求：全功能、高性能、低成本、可定製。

總結

UCloud 作為國內公有雲市場的大玩家，更是如今國內的公有雲第一股，在國內風起雲湧、巨頭林立的大環境下，穩穩的佔據了屬於自己的市場， 實屬不易。而 UCloud 能做到這一點，得益於其始終堅持「客戶為先」的價值觀，及時響應客戶需求，快速解決客戶問題，不斷推出超出客戶預期的創新產品和服務。也正是這樣對於客戶為先的價值觀，讓 UCloud 不僅能做好服務，更能打造出卓越的產品。

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive