效能透明提升 50%!SMC + ERDMA 雲上超大規模高效能網路協議棧

語言: CN / TW / HK
編者按: 當前核心網路協議棧有什麼問題?新的協議棧是不是重新發明輪子?一個協議棧能否解決所有問題?適配所有場景? 本文整理自   2022 年阿里巴巴開源開放周技術演講 這裡我們將自己的思考分享出來,和大家一起交流。視訊回放已上線至龍蜥官網(首頁-動態-視訊),歡迎大家觀看

本文主要分為三部分:第一部分是我們為什麼需要一個新的核心網路協議棧,我們是不是在重複發明輪子?第二部分是 SMC + ERDMA 的原理、優劣等等,快速為大家瞭解 SMC 技術。第三部分是 SMC-R 在網易 Curve 分散式系統的實踐。

一、我們為什麼需要一個新的核心網路協議棧?

當前核心網路協議棧有什麼問題?新的協議棧是不是重新發明輪子?一個協議棧能否解決所有問題?適配所有場景?這裡我們將自己的思考分享出來,和大家一起交流。

首先我想要丟擲一個觀點,沒有一個網路棧是萬能的,之於此沒有銀彈。 要談現狀,離不開背景:
  • 第一是 100G/400G 網路的普及,此時 CPU 是瓶頸。
  • 第二是雲、規模,當前越來越多的業務遷移到雲上,雲上支援傳統 RDMA 網絡卡成本很高。
  • 第三是 DPU,硬體解除安裝,承接第一點,CPU 成為瓶頸後,是否可以讓網路棧將越來越多的邏輯解除安裝到網絡卡和 DPU 上,讓 CPU 做更多更重要的事情。

我們如何平衡吞吐和時延 或者說如何用最少的 CPU 達到相同的吞吐,如何儘可能地降低時延。首先 Linux 核心的網路棧傾向於吞吐,而不是時延。提升吞吐很重的一點是,降低拷貝的開銷。在大包吞吐的場景,我們很容易看到拷貝佔據了  CPU 的絕大部分時間。而且核心網路棧的 context switch 開銷,拷貝開銷也會增加額外的時延。

那麼這個問題變成了選擇在核心態還是使用者態實現一個網路棧? 我想很多應用,或者說雲上 99% 以上的應用使用的是 socket 介面,如果侵入性改造,對於使用者態方案最大的壁壘。比如 DPDK 等,此時不僅僅是改造成本,也包括了運維成本、部署成本等等。當然使用者態也可以劫持 socket 實現使用者態協議棧,但此時 zero copy 等優勢不在。並且同樣需要改造,此處的改造是運維改造,排程改造和環境改造,這也是額外的成本。此時使用者態的優勢也不再顯著。

軟體 vs 硬體解除安裝? 一開始 Linux 網路棧,例如 TCP 協議是從純軟體實現到越來越多的將功能解除安裝到網絡卡,甚至 TOE 完全解除安裝到網絡卡。如果提到解除安裝到網絡卡,是不是可以用一種更加成熟的硬體解除安裝方案?也就是 RDMA,也就是傳統乙太網卡 vs RDMA 網絡卡,部分解除安裝到成熟的完全解除安裝。RDMA 網路本身有規模的限制,我們可以在小規模把 RDMA 網路玩得很好。那是否有一種大規模 RDMA 的能力。我們現在看到的是阿里雲釋出的 ERDMA 網路,一種普惠、高效能、完全相容 RDMA 的生態。我們藉助 SMC + ERDMA 可以實現硬體解除安裝 RDMA 、大規模部署,二者相輔相成。

開箱即用 vs 應用改造? 上面已經提到一部分,雲上 99% 的應用使用的是 socket 介面程式設計,TCP 進行通訊。絕大部分應用不可能投入大量成本改造適配新的網路棧,其中包括開發成本,測試成本 (新的協議棧可能會有各種問題) ,部署和運維成本 (例如 DPDK 環境,額外軟體包的維護) 等。此時還會讓應用牢牢繫結在某個網路棧之上,後續遷移,或者遇到環境不支援的情況下,成本更高。 所以我們分析後,得出的結論是,當前需要一個相容 socket 介面,可以透明替換傳統 TCP 應用的,硬體解除安裝的網路棧。利用雲上大規模部署、DPU 硬體解除安裝、達成 100G/400G 網路的全新網路棧。
二、共享記憶體通訊 SMC

有一點很重要,前面我們沒有討論,也就是所謂的資料通訊模型。IPC 程序間通訊,TCP 也是程序間通訊的一種。我們按照第一性原理,拆分成不同的不可拆分的資料通訊模型。對比這幾種模型最佳實踐下可能的效能資料。

常見的是基於包的通訊模型,例如最典型的 TCP,TCP loopback 效能不是特別理想,但是易用性毋庸置疑。我們之前有提到,絕大多數應用使用的是 socket 程式設計, 其次是共享記憶體,這個在本機維度的 IPC 通訊中,也是一種非常常見的方式。共享記憶體實現千差萬別,但是總體來看,效能遠遠超過上面幾種方式,但是易用性堪憂,第一是提到的實現方式不同、庫不同、介面不同,和語言和執行時繫結,導致大部分共享記憶體的實現不具備跨越應用的普適性。

我們快速回顧一下共享記憶體通訊的模型:

左邊的圖中,下面不同顏色的方塊代表不同的記憶體,分別分成 sender 和 reciver 角色 。首先發送方寫入資料到這一塊共享記憶體,之後通過某種方式,通知接收方資料寫到了哪裡、偏移量是多少,其次接收方按照遊標位置讀取或者拷貝走這一塊記憶體上的資料,之後通知傳送方,本地已經讀取完成,下次寫資料可以從某某位置開始。 這樣一次簡單的資料通訊就完成,同時是 zero copy,這裡是單向,如果是雙向,只需要維護兩個記憶體區域即可。那麼是否有一種技術可以幫助我們搬運記憶體,讓下面兩個方框的記憶體保持同步,從單機共享記憶體到遠端共享記憶體?答案也就是之前提到的 RDMA, RDMA 本身就是遠端直接記憶體方案的縮寫。
前面 4 步我們可以完成本地的共享記憶體通訊,基於 RDMA,我們的資料模型只需要一個比較小的改動,也就是在第二步,通過 RDMA write 實現記憶體從本地同步到遠端。這樣本地和遠端維護記憶體上的資料可以保持一致,同時通過 RDMA send 作為訊息通知機制、通知遊標更新。同時也可以實現 zero copy 硬體解除安裝。
基於上面的分析,我們是不是可以基於共享記憶體同時相容 socket,基於RDMA 硬體解除安裝實現這樣一個可能高效能的網路棧呢?答案是肯定的, 通過 SMC + ERDMA 構建雲上高效能網路棧 ,為什麼說 SMC + ERDMA 可以滿足上面我們的結論呢?首先,我們快速瞭解一下 SMC。
SMC 是 IBM 開源到 Linux 程式碼中,同時 IBM 也一同提出了 IETF RFC 7609,作為描述 SMC-R 協議是如何實現的。首先在上游社群中,龍蜥社群為上游貢獻的補丁數排第二, 其次,SMC 本身也是一種協議,Linux 下為 AF_SMC,可以直接在 socket 中制定使用,沒有其他特殊的 hack 或者 tricky 的實現 ,和 TCP 等價。模型採用了共享記憶體技術,結合 RDMA 可以實現一次拷貝,硬體解除安裝的效能。同時最為重要的是,SMC 本身是一種混合協議,SMC 協議本身,需要藉助某種更通用的協議建立 RDMA 連結,同時還需要提供一種 fallback 回退機制,如果沒有 RDMA 支援,可以透明回退到 TCP。最後, SMC 相容 socket ,可以透明替換所有的 TCP 應用,應用無需改造,也無需配置,即可享受 SMC 帶來的效能加速。 通過上述特性,最大化兼顧效能和生態。SMC 可以在雲上高效能和大規模部署,也離不開阿里雲的 ERDMA。ERDMA 完全相容 RDMA 生態,相容 verbs 介面,verbs 應用可以無需改造。 同時雲上的 ERDMA 具備超大規模部署的能力,解決了傳統 RDMA 網路的部署難題。

SMC 使用 verbs 介面,可以在雲上直接使用 ERDMA ,從而實現硬體 載,高效能的網路棧  SMC 是如何使用 RDMA 的?

SMC 首先使用 TCP 帶完建連,使整個 RDMA 鏈路可用,此時 TCP 連結可以用於回退,任何 RDMA 的問題都可以順利回退到 TCP,確保 SMC 連結的可用。其次 RDMA 負責整個資料的通訊,在核心態是 zero copy。SMC 有一次使用者態-核心態拷貝。 RDMA 技術的另一個問題是連結的規模,特別是 RC 模式下,連結的規模不是很大。SMC 通過 linkgroup,將 N 個連結對映到 1 個或多個 RDMA QP 之上,充分複用 QP 資源,也加快了控制路徑建立 QP 慢的問題,最重要也具備了 linkgroup 多 QP 的容災高可用的能力。 最後 SMC 支援 RoCE v1/v2, 龍蜥版本還支援 ERDMA ,確保 SMC 既可以使用在雲上,也可以使用在資料中心內部。我們多次提到了 SMC 基於 TCP 連結建連,那麼 SMC 是怎麼做的?

首先 SMC 本身是一種混合協議,協議底層包括 TCP 和 RDMA,充分運用 TCP 通用、相容、可達率高、RDMA 高效能的優勢 。同時這一條 TCP 連結也可以幫助 RDMA 不可用或者建連錯誤後,快速回退到 TCP 模式,對於應用完全透明。SMC 通過 TCP SYN 包中的特定的 TCP options 標註是否支援 SMC 能力。如果支援會接下來交換 RDMA 建連所需的資訊, SMC 相容 socket 之後,是如何透明替換 TCP?

首先 AF_SMC 和 AF_INET 是在同一層級 。對外暴露的介面和效能完全一致,應用可以在建立 socket 的時候直接使用 AF_SMC,與使用 TCP 時完全一致。應用不僅可以顯示的制定 AF_SMC,也可以使用 smc_run 命令,快速將 TCP 替換成 SMC,如左圖所示,任何應用都可以透明改造,無需任何適配,SMC 模組也會自動載入到核心。 其次支援 netns 維度的替換 ,支援容器場景下的加速。也支援 eBPF 的策略替換,通過 eBPF 編寫規則匹配所需的應用特徵,選擇性的替換成 SMC。對於一些不重要,不想要佔用 SMC 資源,或者不適合 SMC 的場景,可以使用這種方式。

SMC 回退機制 ,也是 SMC 為什麼能夠替換 TCP 重要的一個特性。

上圖左邊可以看到,SMC 首先建立 TCP 連結,經過 TCP 的握手後,才會進行 SMC 握手。如之前所提到的是,SMC 是混合協議,在 RDMA 建連失敗後,可以快速透明的切回到 TCP。同時也提供了各種錯誤碼,幫助應用排查問題,例如 RDMA 網絡卡問題,還是資源問題等。 談了這麼多 SMC 自身的特性,那麼 SMC 的效能如何?下面的測試是在阿里雲上 ERDMA 網絡卡和 SMC 對比 TCP 的效能。

例如常見的 netperf microbenchmark 有一倍以上的效能提升。Redis 和 Netty 這種常見的基礎元件有 30% 到 50% 的 QPS 提升,時延也顯著下降。NGINX 也有 40% 左右的效能提升。這些效能提升,都是在應用無需任何改造,透明替換成 SMC 下進行的測試。 接下來我們聊一下我們龍蜥社群在 SMC 上所做的工作。

2021 年 11 月開始在社群密切參與開發和穩定性工作,當前貢獻共計 70 多個補丁,排在 IBM 之後為第二。 首先我們從頭到尾優化了 SMC 的效能 ,包括短連結效能,包括吞吐和一些 syscall,CQ 中斷打散等優化, 最終 microbenchmark 綜合性能提升了 357% ,這裡是對比的 SMC 之前的版本,對比 TCP 可以參考剛才的資料。 其次是更多的場景支援 ,包括雲原生、ERDMA、容器網路等等,拓寬了上游社群 SMC 的使用場景。 最重要的是, 極大地提升了穩定性 ,我們一直在持續看護上有社群,解決了數十個 panic 問題,徹底解決了遺留的 link 和 linkgroup 問題,同時也在持續看護 SMC。龍蜥社群我們有 CI/CD 持續不斷的測試,能夠成為一個產品級別的協議棧。 大家可以訪問 我們的倉庫 (地址見文末) ,使用 HPN 中我們不斷優化的 SMC 版本。

接下來我們談一談 SMC 的未來。回到分享的開始,SMC 同樣也不是銀彈。SMC 基於 RDMA 技術,本身也有 RDMA 引入的各種各樣的問題。 第一是記憶體消耗,SMC 本身需要一致維護一塊比較大的連續記憶體區域,用來實現共享記憶體通訊,記憶體消耗顯著大於 TCP。 其次是 SMC 的建連效能,還是會受制於 RDMA RC 模式的建連效能,這一塊我們會持續不斷的優化,相關優化我們會陸續推送到社群。 其次是穩定性,SMC 不同於 TCP 在業界廣泛使用多年。有很多問題沒有被發現,我們當前也在藉助 SMC CI/CD 幫助我們發現問題。

三、SMC-R 在網易 Curve 儲存系統的實踐

首先介紹一下 Curve。Curve 是一個開源分散式儲存系統,可對接 OpenStack 平臺為雲主機提供高效能塊儲存服務,可對接 Kubernetes 為其提供持久化儲存卷,可對接 PolarFS 作為雲原生資料庫的高效能儲存底座。 Curve 在效能、運維、穩定性、工程實踐質量上都優於 Ceph 下面介紹 Curve 的網路通訊:

通訊過程為由 leader 向 follower 發起 RPC 進行資料拷貝。 特點是: 網路通訊頻繁、網路通道穩定、網路傳輸時延小、RPC 時延佔比不低。 因此我們調研了幾種網路加速選型:

其中 SMC-R 可以實現透明替換,無侵入,並且提供較好的效能。

我們使用 SMC-R 改造了 Curve 並使能同時擴充套件了黑名單、資源監控和讀取速度監控等能力。

我們使用 Curve E2E 測試,在 3 Volume  256 depth randwrite case 下,對比 TCP 提升了 18.5% 的效能。
最後,以上為大家介紹了我們為什麼需要 SMC,SMC 的原理和效能以及 SMC 在網易 Curve 的最佳實踐。對於 SMC 而言最重要的是社群和生態,在此歡迎大家使用並參與龍蜥社群和 SMC 社群,一同打造 SMC 高效能網路協議棧。

相關連結地址:

高效能網路 SIG 地址:

https://openanolis.cn/sig/high-perf-network

SMC程式碼倉庫連結:

https://gitee.com/anolis/hpn-cloud-kernel

往期技術文章參考:

1、效能提升 57% ,SMC-R 透明加速 TCP 實戰解析

2、SMC-R讓網路效能提升20%

3、系列解讀SMC-R(一):透明無感提升雲上TCP應用網路效能

4、系列解讀 SMC-R (二):融合 TCP RDMA SMC-R 通訊
—— 完 ——
加入龍蜥社群
加入微信群:新增社群助理-龍蜥社群小龍 (微信:openanolis_assis) ,備註【龍蜥】與你同在;加入釘釘群:掃描下方釘釘群二維碼。歡迎開發者/使用者加入龍蜥社群(OpenAnolis)交流,共同推進龍蜥社群的發展,一起打造一個活躍的、健康的開源作業系統生態!

關於龍蜥社群

龍蜥社群(OpenAnolis)是由企業單位、事業單位、社會團體、個人等在共建、共治、共享的基礎上組成的非營利性開源社群。龍蜥社群成立於 2020 年 9 月,旨在構建一個開放、平等、協作、創新的 Linux 上游發行版社群及創新平臺。

龍蜥社群成立的短期目標是開發龍蜥作業系統(Anolis OS)作為 CentOS 停服後的應對方案,構建一個相容國際 Linux 主流廠商的社群發行版。中長期目標是探索打造一個面向未來的作業系統,建立統一的開源作業系統生態,孵化創新開源專案,繁榮開源生態。
目前, Anolis OS 8.6  已釋出,更多龍蜥自研特性,支援 X86_64 、RISC-V、Arm64、LoongArch 架構,完善適配 Intel、兆芯、鯤鵬、龍芯等晶片,並提供全棧國密和機密計算支援。
歡迎下載:
https://openanolis.cn/download
加入我們,一起打造面向未來的開源作業系統!
https://openanolis.cn

往期精彩推薦

1.只需 6 步,你就可以搭建一個雲原生作業系統原型

2.龍蜥開發者說:海納百川,有容乃大,我在龍蜥社群的升級之旅  | 第 11 期

3.益思芯科技加入龍蜥社群,推動網路和儲存DPU晶片創新落地

4.關於 eBPF 安全可觀測性,你需要知道的那些事兒

5.技術門檻高?來看 Intel 機密計算技術在龍蜥社群的實踐


本文分享自微信公眾號 - OpenAnolis龍蜥(OpenAnolis)。
如有侵權,請聯絡 [email protected] 刪除。
本文參與“OSC源創計劃”,歡迎正在閱讀的你也加入,一起分享。