可程式設計網路卡晶片在滴滴雲網路的應用實踐

滴滴技術發表於2020-08-27

​桔妹導讀:隨著雲規模不斷擴大以及業務層面對延遲、頻寬的要求越來越高,採用DPDK 加速網路報文處理的方式在橫向縱向擴充套件都出現了局限性。可程式設計晶片成為業界熱點。本文主要講述了可程式設計網路卡晶片在滴滴雲網路中的應用實踐,遇到的問題、帶來的收益以及開源社群貢獻。

1. 資料中心面臨的問題

隨著滴滴雲規模的不斷擴大,業務層面對延遲以及頻寬的要求越來越高。2018年滴滴雲網路團隊上線了基於開源社群的OVS-DPDK方案。DPDK是X86平臺報文快速處理的庫和驅動的集合, 其主要優勢為通過Bypass Linux核心,Hugepage記憶體以及PMD(Poll Mode Driver)模型驅動的方式實現加速。我們為OVS-DPDK提供了線上熱升級功能,該功能保證了在升級過程中虛擬機器業務無感知,並且網路Downtime時間為毫秒級別。同時我們優化了OVS-DPDK資料轉發平面。實現了不同物理主機上的虛擬機器網路延遲<150us,單核效能約~400w pps(雙向)。

滴滴內部上雲、高效能運算HPC,以及機器學習,對網路提出了更高的要求。通過CPU DPDK處理報文的方式,雖然在效能以及延遲方面遠優於基於Linux 核心的轉發實現。但CPU DPDK已經不能滿足資料中心流量激增帶來的需求。

2. 技術方案選擇

雲網路環境中,在計算節點DPDK不會佔用過多的CPU,否則會影響CPU售賣,一般會使用1-2 CPU用於資料包文處理。同時DPDK 處理資料包文的效能強依賴CPU算力。因此在計算節點網路的橫向擴充套件以及縱向擴充套件都具有侷限性。

在邊際閘道器節點,我們可以通過擴充套件伺服器的方式,提高網路處理容量進而滿足業務需求。但是大規模的擴充套件伺服器,需要承擔更多的機器、功耗以及運維成本。

軟體定義網路(Software Defined Network,SDN)是一種新型網路創新架構,是網路虛擬化的一種實現方式。其核心思想是將網路裝置的控制面與資料面分離開來。控制層面可以通過集中控制的方式實現不同的業務邏輯:拓撲發現,路由管理,安全策略,網路虛擬化等。資料平面更專注在資料包文轉發。2018年AWS re:Invent,AWS 介紹了Nitro System。該系統通過硬體晶片加速虛擬機器IO處理(網路、儲存、安全等)。

目前工業界,加速網路處理的焦點聚集到了硬體層面:AISC,FPGA,P4,可程式設計網路卡,以及智慧網路卡等。

3. 基於可程式設計晶片的解決方案

3.1 硬體晶片選擇

  1. 傳統AISC卡
    該卡比較成熟,但業務邏輯固定,很難適應雲上覆雜的業務場景。

  2. 可程式設計門佇列FPGA
    FPGA 實現網路加速需要專業FPGA技術人員,以及專業網路RD。同時在成本,和研發週期都需要具有一定的侷限性。

  3. P4
    P4 具有靈活的可程式設計性,較為合適做為閘道器節點資料處理。並不適合在計算節點使用。同時價格也是需要考慮的因素。

  4. 可程式設計網路卡晶片
    通過調研發現,可程式設計網路卡除了具有通用網路卡的功能外,還可以通過下發流表規則的方式,實現報文匹配並對報文執行特定的action如:修改,封裝,以及轉發、上送報文至CPU等。這種具有靈活性、可程式設計性的‍‍硬體晶片,能夠滿足快速迭代的需求。

3.2 轉發模型

為了滿足網元業務靈活性、多樣性的需求,我們將網元業務和底層平臺功能分離,捨去了傳統的資料面Pipeline轉發模型,採用了類似Open Flow的macth+action的方式。這樣不同的match規則和不同action 匹配能夠實現不同的業務邏輯。這種弱依賴的關係能夠剝離了業務和底層細節,方便業務功能迭代、快速上線,同時底層可程式設計晶片的更新不會對業務邏輯產生影響。

3.3 網路平臺化

隨著‍‍雲上業務場景的複雜化,以及上雲的客戶越來越多,雲上網路的功能也複雜化。為了統一計算節點以及閘道器節點功能,我們實現了統一的程式設計框架。這樣能夠快速開發不同功能的閘道器節點,減少運維負擔。

3.4 落地實踐

我們基於OVS-DPDK Offload 框架實現流表規則offload。OVS 採用首個報文觸發的方式下發硬體流表規則,該方式的優點為在必須的時候下發規則,能夠達到節省流表的目的,但是缺點卻會導致首個報文延遲。經調研我們發現網路卡支援至少百萬級流表量(使用x86記憶體或者其他擴充套件記憶體),最終我們捨去OVS-DPDK ofproto 轉發層,使用dpctl 介面下發流表,這樣就不存在首個報文延遲問題,同時也縮減了使用TC Flower時資料面過多問題(這些轉發平面包括:硬體晶片轉發,TC資料面,OVS Linux 核心模組轉發,以及ofproto層)。我們修改了OVS-DPDK 流表老化方式,保證通過dpctl 下發的規則不會被刪除。最後通過upcall limit 限制了upcall 報文處理。滴滴雲網路資料平面主要分為兩大部分:計算節點和閘道器節點。計算節點主要負責虛擬機器、容器網路的虛擬化,閘道器節點主要負責各種邊際節點業務如:SLB負載均衡、vRouter EIP報文處理,分流器、SNAT、FullNAT、雲企業網等。可程式設計網路卡晶片通過平臺化的方式在兩個主要節點均有應用。

  1. SLB負載均衡
    提供四層負載均衡,根據使用者策略將underlayer網路報文分發到虛擬網路服務節點。

  2. vRouter
    提供彈性EIP服務。使用者可以將一個公網IP地址繫結到虛擬機器、容器、或者裸金屬,從而獲得公網訪問功能。

  3. iRouter
    將滴滴資料中心和滴滴雲虛擬網路打通,滴滴資料中心可以方便快捷的訪問雲上資源。

  4. SNAT
    為虛擬機器、容器以及裸金屬提供訪問公網服務。

  5. 雲企業網互聯
    互聯服務支援將滴滴雲上的多個VPC網路加入雲互聯,任意兩個VPC網路即可實現資源之間的互訪。

  6. 計算節點
    在計算節點主要有兩大應用場景:一種場景為在計算節點為虛擬機器、容器提供VPC服務(網路隧道,限速,轉發,報文修改,公網服務),RDMA網路。另外一個場景使用智慧網路卡為裸金屬提供VPC服務。

3.5 遇到的問題

在調研開發過程中遇到諸多問題,在這裡和大家總結分享下:

  1. OVS-DPDK 支援Offload 程度有限
    首先OVS 社群並對DPDK Offload介面(rte flow)支援有限:實現的action非常有限。需要使用者獨立完成開發:如set action,meter offload,vxlan 隧道報文處理等。

  2. 埠轉發限制
    目前mellanox網路卡晶片並不支援從一個PF埠轉發到該晶片另一個埠, 最終我們通過SRIOV+Hairpin的方式解決該問題。據瞭解後續的網路卡晶片開始支援該功能(功能也受限於韌體)。

  3. Open vSwitch Crash
    在刪除包含meter action 流表規則時,OVS 程式退出。該問題最終確認為DPDK的一個bug,目前該問題已經修復,傳送到社群並接收。http://git.dpdk.org/next/dpdk-next-net/commit/?id=0d7d180a0dda4b97021fc1f580d6bfe3b42a332d

呼叫DPDK Meter API 介面導致crash。目前該問題已經修復,傳送到社群並接收。
http://git.dpdk.org/next/dpdk-next-net/commit/?id=4f19f4140e058c92822f228dcdc55c44bd88b613

修改OVS 配置導致刪除offload flow crash,目前該問題已經修復,傳送到社群並接收。https://github.com/openvswitch/ovs/commit/058b80d3de31b2c539d9e6f5f6687bde78ef08e9

  1. Meter offload
    OVS社群沒有實現該功能,我們根據業務特徵抽象出介面並在OVS實現了meter offload。該系 列補丁檔案正在OVS 社群review,不久會進入upstream。

  2. Decap/Encap 流表限制
    下發多條帶有decap/encap的流表規則時報錯。該問題最終確認為DPDK的一個bug,目前該問題已經修復,與社群maintainer 協同修復。http://git.dpdk.org/next/dpdk-next-net/commit/?id=64927f72a72fad39898b084e0cf66cc97b40959f

  3. Decap + Meter action限制
    decap + meter 做為action 下發規則時失敗。該問題最終確認為DPDK的一個bug,目前該問題已經修復,與社群maintainer 協同修復http://git.dpdk.org/next/dpdk-next-net/commit/?id=431f199883e5b7eeea87a2f9f0272daf3354c1da

  4. Hairpin 效能問題
    在高併發情況下,mellanox 網路卡晶片效能會下降約40%,最終確認是網路卡驅動hairpin問題。目前mellanox 確認該問題並給出修復方式。

  5. 流表數目限制
    通過刪除流表上限修復該問題:https://github.com/openvswitch/ovs/commit/df5c293642cc07013e796e588eb7aead917e20a1

  6. MAC 地址對VxLAN的影響
    物理主機源MAC地址變更後vxlan 報文依舊使用原來MAC地址,這樣會導致收不到響應報文:
    https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=6707f74be8621ae067d2cf1c4485900e2742c20f

  7. 多次修改報文不生效問題
    多次使用TC Flower pedit 修改報文,offload 不生效問題, 最終確認是核心驅動問題:
    https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=218d05ce326f9e1b40a56085431fa1068b43d5d9

  8. 配置vf rate、mac不當導致核心crash
    https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=6e77c413e8e73d0f36b5358b601389d75ec4451c

https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/? id=24319258660a84dd77f4be026a55b10a12524919

3.6 效能資料

以實現的vRouter 彈性公網閘道器為例(基礎網路10Gpbs):

pps(64B) Mpbs(64B) pps(1500B) Mpbs(1500B)
9495892 8660.25 811935 10067.98

業務延遲資料如下(使用pktgen-dpdk latency):

背景流量 閘道器延遲
10W條流表以及併發1Gbps 64B流量 3u
10W條流表以及併發5Gbps 64B流量 6u

4. 開源社群貢獻

除了為開源社群提供 bug patch,我們也將新增特性、效能優化patch回饋至開源社群:OVS、DPDK、Linux 核心社群(約80+ patch), 其中Linux 核心補丁列表如下:

團隊介紹

滴滴雲平臺事業群滴滴SDN網路團隊負責雲網路產品的規劃、設計、以及研發等工作。為公有云提供負載均衡SLB、專有網路VPC、彈性公網EIP、SNAT 以及雲互聯等服務。團隊針對雲網路業務需求,在Linux 核心網路虛擬化、DPDK、OVS、可程式設計晶片、RDMA、智慧網路卡以及系統優化等領域均有廣泛深入的研究。團隊具有多名開源社群contributor,涉及OVS、DPDK、Linux 核心等。

作者介紹

專注於高效能網路技術,從事雲網路研發工作。活躍於Linux 核心、OVS、DPDK開源社群。

延伸閱讀

內容編輯 | Charlotte & Teeo
聯絡我們 | DiDiTech@didiglobal.com

本文由部落格群發一文多發等運營工具平臺 OpenWrite 釋出

相關文章