加入星計劃,您可以享受以下權益:

  • 創(chuàng)作內(nèi)容快速變現(xiàn)
  • 行業(yè)影響力擴散
  • 作品版權保護
  • 300W+ 專業(yè)用戶
  • 1.5W+ 優(yōu)質(zhì)創(chuàng)作者
  • 5000+ 長期合作伙伴
立即加入
  • 正文
    • 編者按
    • 1、高性能網(wǎng)絡綜述
    • 2、TCP/IP高性能網(wǎng)絡
    • 3、高性能網(wǎng)絡協(xié)議棧綜述,以IB為例
    • 4、RDMA高性能網(wǎng)絡
    • 5、AWS SRD高性能網(wǎng)絡
    • 6、其他高性能網(wǎng)絡技術
    • 7、全球互聯(lián)網(wǎng)絡的高性能
    • 8、高性能網(wǎng)絡總結
  • 推薦器件
  • 相關推薦
  • 電子產(chǎn)業(yè)圖譜
申請入駐 產(chǎn)業(yè)圖譜

軟硬件融合視角:一文看懂高性能網(wǎng)絡

06/05 09:05
3046
閱讀需 44 分鐘
加入交流群
掃碼加入
獲取工程師必備禮包
參與熱點資訊討論

編者按

隨著大模型的廣泛流行,GPU集群計算的規(guī)模越來越大(單芯片算力提升有限,只能通過擴規(guī)模的方式來提升整體算力),千卡、萬卡已經(jīng)成為主流,十萬卡、百萬卡也都在未來3-5年的規(guī)劃中。

集群計算的網(wǎng)絡可以分為兩類:南北向流量,也就是俗稱的外網(wǎng)流量;東西向流量,也就是俗稱的內(nèi)網(wǎng)流量。集群計算的網(wǎng)絡連接數(shù) S = N x (N-1)(N為節(jié)點數(shù))。這也是為什么現(xiàn)在數(shù)據(jù)中心中東西向流量占比超過90%的原因所在。再加上系統(tǒng)規(guī)模擴大導致的南北向網(wǎng)絡流量的增加,這使得數(shù)據(jù)中心所需的網(wǎng)絡帶寬呈指數(shù)級增長趨勢。

2019年,NVIDIA收購Mellanox,憑借著在InfiniBand和ROCEv2領域的領先優(yōu)勢,NVIDIA成為了高性能網(wǎng)絡的霸主。各大競爭對手不甘示弱,特別是AWS、阿里云等云計算廠家,都陸續(xù)推出了自己的高性能網(wǎng)絡協(xié)議和對應的產(chǎn)品,行業(yè)呈現(xiàn)百家爭鳴之象。高性能網(wǎng)絡,兵家必爭之地;未來誰主沉浮,我們拭目以待。

本篇文章,從軟硬件融合視角,對高性能網(wǎng)絡相關技術進行介紹并進行分析,讓大家一文看透高性能網(wǎng)絡。

1、高性能網(wǎng)絡綜述

1.1 網(wǎng)絡性能參數(shù)

網(wǎng)絡性能主要關心三個參數(shù),帶寬、吞吐量和延遲:

    • 帶寬:指特定時間段內(nèi)可以傳輸?shù)臄?shù)據(jù)量。高帶寬并不一定保證最佳的網(wǎng)絡性能。例如,網(wǎng)絡吞吐量受到數(shù)據(jù)包丟失、抖動或延遲的影響,可能會遇到延遲問題。吞吐量:指在特定時間段內(nèi)能夠發(fā)送和接收的數(shù)據(jù)量。網(wǎng)絡上數(shù)據(jù)的平均吞吐量使用戶能夠深入了解成功到達正確目的地的數(shù)據(jù)包數(shù)量。為了高性能,數(shù)據(jù)包必須能夠到達正確目的地。如果在傳輸過程中丟失了太多數(shù)據(jù)包,則網(wǎng)絡性能可能不足。

延遲:數(shù)據(jù)包在發(fā)送后到達目的地所用的時間。我們將網(wǎng)絡延遲測量為往返行程。延遲的結果通常是不穩(wěn)定和滯后的服務。例如視頻會議等,對延遲非常敏感。

除此之外,還有一個非常重要的指標,PPS(Packet Per Second,每秒傳輸數(shù)據(jù)包數(shù))。許多網(wǎng)絡設備,在大包的時候,可以做到線速,但在小包(64字節(jié))的情況下,其性能降低的非常嚴重,主要就是PPS能力不足引起的。所以,理想的情況是,在最小包的情況下,仍然能夠達到線速。

高性能網(wǎng)絡,就是要在低延遲(越低越好)、低抖動的情況下,(不管大包小包,任意網(wǎng)絡節(jié)點,都要)實現(xiàn)最高的吞吐量(無限接近于網(wǎng)絡帶寬)。當然了,這些參數(shù)是相互影響的,實際的系統(tǒng)是在這些參數(shù)之間取得的平衡。

1.2 復雜的網(wǎng)絡分層

OSI定義了七層網(wǎng)絡協(xié)議,實際工程應用的TCP/IP網(wǎng)絡協(xié)議一般為五層:

數(shù)據(jù)中心網(wǎng)絡要更加復雜,會分為Overlay網(wǎng)絡和Underlay網(wǎng)絡。如果按照功能邏輯把網(wǎng)絡分層,云計算數(shù)據(jù)中心網(wǎng)絡可以分成三層:

    第一層,物理的基礎網(wǎng)絡連接,也就是我們通常所理解的Underlay底層承載網(wǎng);第二層,基于基礎的物理網(wǎng)絡構建的虛擬網(wǎng)絡,也就是我們通常理解的基于隧道的Overlay網(wǎng)絡;第三層,各種用戶可見的應用級的網(wǎng)絡服務,比如接入網(wǎng)關、負載均衡等。也可以是其他需要用到網(wǎng)絡的普通應用。

物理的數(shù)據(jù)中心是一個局域網(wǎng),通過Overlay網(wǎng)絡分割成數(shù)以萬計的虛擬私有網(wǎng);域間隔離后,再需要一定的網(wǎng)絡安全機制實現(xiàn)高性能的跨域訪問。

依據(jù)網(wǎng)絡處理邏輯,網(wǎng)絡可以分為三部分:

    第一階段,業(yè)務數(shù)據(jù)的封包/解包。Tx向的時候,把業(yè)務的數(shù)據(jù)按照既定的網(wǎng)絡格式進行封包;Rx向,則是把收到的數(shù)據(jù)包進行解包。第二階段,網(wǎng)絡包的處理。比如Overlay網(wǎng)絡,需要將數(shù)據(jù)包再次進行封裝;比如防火墻,要對網(wǎng)絡包進行鑒別,是否允許傳輸(輸入輸出雙向);比如網(wǎng)絡包加解密。第三階段,網(wǎng)絡包的傳輸(Tx/Rx)。也即是高性能網(wǎng)絡關注的部分。

1.3 為什么需要高性能網(wǎng)絡

為什么需要高性能網(wǎng)絡?

    原因一,網(wǎng)絡的極端重要性。
    1. 網(wǎng)絡連接的重要性:網(wǎng)絡連接所有節(jié)點,各類服務都通過網(wǎng)絡鏈接,用戶通過網(wǎng)絡遠程操作。沒有網(wǎng)絡,一切都是空的。網(wǎng)絡的復雜性:業(yè)務系統(tǒng),要么是單服務器級別的或者集群級別;網(wǎng)絡系統(tǒng)基本上都是數(shù)據(jù)中心級別,在整個數(shù)據(jù)中心的規(guī)模上,構建各種復雜的網(wǎng)絡業(yè)務邏輯,整個系統(tǒng)復雜度非常高,影響面也大。網(wǎng)絡故障的嚴重性:計算服務器故障、存儲服務器故障都是局部的故障,而網(wǎng)絡故障則牽一發(fā)而動全身。任何一個微小的網(wǎng)絡故障,都可能會引起整個數(shù)據(jù)中心不可用。網(wǎng)絡故障一旦發(fā)生,必然是重大故障。
    • 原因二,超大規(guī)模集群計算,東西向流量激增。數(shù)據(jù)中心復雜計算場景,系統(tǒng)持續(xù)解構,東西向流量激增,網(wǎng)絡帶寬要求迅速的從10G、25G升級到100G,甚至200G。原因三,短距離傳輸,系統(tǒng)堆棧延遲凸顯。相比城域網(wǎng)或者全球互聯(lián)網(wǎng)絡,數(shù)據(jù)中心網(wǎng)絡傳輸距離很短,服務器系統(tǒng)堆棧的延遲凸顯。原因四,CPU性能瓶頸,網(wǎng)絡處理延遲進一步加大。網(wǎng)絡帶寬快速增加,而CPU的性能已經(jīng)瓶頸。網(wǎng)絡堆棧處理的CPU資源消耗快速增加,并且延遲還進一步增大。

原因五,跨服務器調(diào)用延遲敏感。而軟件服務之間的調(diào)用,要求跨服務器的遠程調(diào)用能夠低延遲,接近于本地調(diào)用的延遲。

1.4 網(wǎng)絡擁塞控制

網(wǎng)絡中如果存在太多的數(shù)據(jù)包,會導致包延遲,并且會因為超時而丟棄,從而降低傳輸性能,這稱為擁塞。高性能網(wǎng)絡,就是要充分利用網(wǎng)絡容量,提供低延遲網(wǎng)絡傳輸?shù)耐瑫r,盡可能的避免網(wǎng)絡擁塞。

當主機發(fā)送的數(shù)據(jù)包數(shù)量在網(wǎng)絡的承載范圍之內(nèi)時,送達與發(fā)送的數(shù)據(jù)包成正比例增長。但隨著負載接近網(wǎng)絡承載極限,偶爾突發(fā)的網(wǎng)絡流量會導致?lián)砣罎ⅲ划敿虞d的數(shù)據(jù)包接近承載上限的時候,延遲會急劇上升,這就是網(wǎng)絡擁塞。

擁塞控制(Congestion Control,CC)和流量控制有什么區(qū)別?擁塞控制,確保網(wǎng)絡能夠承載所有到達的流量,是一個全局問題;流量控制,則是確??焖俚陌l(fā)送方不會持續(xù)地以超過接收方接收能力的速率傳輸,是端到端傳輸?shù)膯栴}。

根據(jù)效果從慢到快,處理擁塞的辦法可以分為:

    更高帶寬的網(wǎng)絡;根據(jù)流量模式定制流量感知路由;降低負載,如準入控制;給源端傳遞反饋信息,要求源端抑制流量;一切努力失敗,網(wǎng)絡丟棄無法傳遞的數(shù)據(jù)包。

擁塞控制算法的基本原則如下:

    優(yōu)化的帶寬分配方法,既能充分利用所有的可用帶寬卻能避免擁塞;帶寬分配算法對所有傳輸是公平的,既保證大象流,也保證老鼠流;擁塞控制算法能夠快速收斂。

1.5 等價多路徑路由ECMP

CLOS架構是一種用于構建高性能、高可靠性數(shù)據(jù)中心網(wǎng)絡的拓撲結構。受東西向流量激增等原因影響,數(shù)據(jù)中心為滿足大通量網(wǎng)絡流量的需求,網(wǎng)絡拓撲通常采用CLOS結構。CLOS架構會使得主機和主機之間就存在多條網(wǎng)絡路徑,而“多路徑”是實現(xiàn)高性能和高可靠網(wǎng)絡的基礎。

如何利用數(shù)據(jù)中心網(wǎng)絡拓撲、路徑資源、帶寬資源等,更好的實現(xiàn)網(wǎng)絡流量的負載均衡,將數(shù)據(jù)流分布到不同路徑上進行數(shù)據(jù)傳輸,避免擁塞,提高數(shù)據(jù)中心內(nèi)的資源利用率,就變得越來越重要。

ECMP(Equal-Cost Multi-Path routing,等價多路徑路由)是一個逐跳的基于流的負載均衡策略,當路由器發(fā)現(xiàn)同一目的地址出現(xiàn)多個最優(yōu)路徑時,會更新路由表,為此目的地址添加多條規(guī)則,對應于多個下一跳??赏瑫r利用這些路徑轉發(fā)數(shù)據(jù),增加帶寬。

ECMP常見的路徑選擇策略有多種方法:

    • 哈希,例如根據(jù)源IP地址的哈希為流選擇路徑。輪詢,各個流在多條路徑之間輪詢傳輸。

基于路徑權重,根據(jù)路徑的權重分配流,權重大的路徑分配的流數(shù)量更多。

需要注意的是,在數(shù)據(jù)中心這種突發(fā)性流量多,大象流與老鼠流并存的環(huán)境中,需要慎重考慮選擇的負載均衡策略,ECMP雖然簡單易部署,但也存在較多問題需要注意。

2、TCP/IP高性能網(wǎng)絡

TCP/IP協(xié)議棧主要指Ethernet+TCP/IP+Socket的整個系統(tǒng)棧。

2.1 TCP/IP協(xié)議棧硬件卸載

第一類,TCP的部分特征卸載

    TSO,TCP Segmentation Offload,利用網(wǎng)卡硬件能力對TCP數(shù)據(jù)包分段。UFO,UDP Fragmentation Offload ,支持UDP發(fā)大包,硬件會進行分片。LRO,Large Receive Offload,網(wǎng)卡硬件將接收到的多個TCP數(shù)據(jù)聚合成一個大的數(shù)據(jù)包。RSS,Receive Side Scaling,將網(wǎng)絡流分成不同的隊列,再分別將這些隊列分配到多個CPU核處理。CRC 卸載,由硬件完成CRC計算和封包。

第二類,TCP/IP協(xié)議棧卸載(TCP/IP Offload Engine,TOE)

傳統(tǒng)軟件網(wǎng)絡棧的處理開銷很大,把整個TCP/IP協(xié)議棧卸載到硬件,可以提升網(wǎng)絡處理的性能,顯著降低CPU代價。

Linux 標準內(nèi)核不支持 TOE網(wǎng)卡,原因主要是:

    安全性。TOE硬件實現(xiàn),與OS中的經(jīng)過良好測試的軟件TCP/IP棧相比,硬件的安全風險很大。硬件約束。因為網(wǎng)絡連接在TOE芯片上進行緩沖和處理,與軟件可用的大量CPU和內(nèi)存相比,資源匱乏更容易發(fā)生。復雜性。TOE打破了kernel始終可以訪問所有資源的假設,還需要對網(wǎng)絡堆棧進行非常大的更改,即便如此,QoS和包過濾等功能也可能無法工作。定制性。每個Vendor都是定制的TOE,這意味著必須重寫更多代碼來處理各種TOE實現(xiàn),代價是方案的復雜性和可能的安全風險。此外,TOE固件閉源,軟件人員無法修改。過時。TOE NIC使用壽命有限:CPU性能會迅速趕上并超過TOE性能;軟件系統(tǒng)棧的迭代會顯著快于硬件協(xié)議棧。

因此,受上述原因影響,TOE并沒有大規(guī)模使用起來。

2.2 應用層TCP/IP協(xié)議棧Onload

Onload是Solarflare(Solarflare已被Xilinx收購,Xilinx又被AMD收購)加速網(wǎng)絡中間件。主要特征包括:

基于IP的TCP/UDP實現(xiàn),動態(tài)鏈接到用戶模式應用程序的地址空間,應用程序可以直接從網(wǎng)絡收發(fā)數(shù)據(jù),而無需OS參與。

Onload實現(xiàn)的內(nèi)核繞過(Kernel Bypass)可避免系統(tǒng)調(diào)用、上下文切換和中斷等破壞性事件,從而提高處理器執(zhí)行應用程序代碼的效率。

Onload庫在運行時使用標準Socket API與應用程序動態(tài)鏈接,這意味著不需要對應用程序進行任何修改。

Onload通過減少CPU開銷、改善延遲和帶寬,以及提高應用的可擴展性,來顯著降低網(wǎng)絡成本。

Onload核心技術可以總結為:硬件虛擬化SR-IOV,內(nèi)核bypass,以及應用SocketAPI。

2.3 傳輸協(xié)議優(yōu)化:從TCP到QUIC

QUIC(Quick UDP Internet Connections,快速UDP互聯(lián)網(wǎng)連接)是一種新的互聯(lián)網(wǎng)傳輸協(xié)議,對L4、L5(安全)、L7進行部分或全部的優(yōu)化和替代。

QUIC是一個應用自包含的協(xié)議,允許創(chuàng)新。這在現(xiàn)有協(xié)議中不可能實現(xiàn),受遺留的客戶端和系統(tǒng)中間件的阻礙。

與TCP+TLS+HTTP2相比,QUIC的主要優(yōu)點包括:

    連接建立的延遲。簡單地說,QUIC握手在發(fā)送有效載荷之前需要0次往返,而TCP+TLS則需要1-3次往返。改進的擁塞控制。QUIC主要實現(xiàn)并優(yōu)化了TCP的慢啟動、擁塞避免、快重傳、快恢復,可以根據(jù)情況選擇不同的擁塞控制算法;避免TCP重傳歧義問題;允許精確的往返時間計算;等等。無前端阻塞的多路復用。TCP存在行首阻塞問題,QUIC為多路復用操作設計,沒有損失的流可以繼續(xù)推進。前向糾錯。為了在不等待重傳的情況下恢復丟失的數(shù)據(jù)包,QUIC可以用一個FEC數(shù)據(jù)包補充一組數(shù)據(jù)包。連接遷移。TCP連接由四元組標識,QUIC連接由64位連接ID標識。如果客戶端更改了IP地址或端口,則TCP連接不再有效;而QUIC可以使用舊的連接ID,而不會中斷任何正在進行的請求。

3、高性能網(wǎng)絡協(xié)議棧綜述,以IB為例

3.1 IB網(wǎng)絡協(xié)議簡介

InfiniBand (IB)是一種用于高性能計算的網(wǎng)絡通信標準,具有極高的吞吐量和極低的延遲。

IB用于計算機之間和計算機內(nèi)部的數(shù)據(jù)互連,還可以用作服務器和存儲系統(tǒng)之間的直接或交換互連,以及存儲系統(tǒng)之間的互連。

IB的設計目標:綜合考慮計算、網(wǎng)絡和存儲技術,設計一個可擴展的、高性能的通信和I/O體系結構。

IB的主要優(yōu)點:

    高性能,超算TOP500中一半左右采用IB;低延遲,IB端到端測量延遲為1μs;? ?高效率,IB原生支持RDMA等協(xié)議,幫助客戶提高工作負載處理效率。

IB也是五層網(wǎng)絡分層:物理層、鏈路層、網(wǎng)絡層、傳輸層和應用層。傳統(tǒng)網(wǎng)絡的L1&L2硬件實現(xiàn),而L3/L4軟件實現(xiàn);而IB則是L1-L4均在硬件實現(xiàn)。IB傳輸層API即HCA網(wǎng)卡和CPU之間的軟硬件接口。Socket API是傳統(tǒng)TCP/IP網(wǎng)絡的應用網(wǎng)絡接口,而Verbs API是IB的應用網(wǎng)絡接口。MPI是一種通過提供并行庫來實現(xiàn)并行化的方法庫,MPI可以基于OFA Verbs API,也可以基于TCP/IP Socket。

3.2 IB為什么能夠高性能?

傳統(tǒng)網(wǎng)絡協(xié)議棧的問題:

長路徑,應用需要通過系統(tǒng)層連接到網(wǎng)卡;

多拷貝,很多拷貝是沒有必要的;

彈性能力不足,協(xié)議棧經(jīng)過內(nèi)核,這樣用戶就很難去優(yōu)化協(xié)議功能。

通過網(wǎng)絡協(xié)議棧性能優(yōu)化的四個方面,來總結IB全棧所采用的主要優(yōu)化技術:

優(yōu)化協(xié)議棧:簡化、輕量、解耦的系統(tǒng)堆棧。

加速協(xié)議處理:協(xié)議硬件加速處理, L2-L4多個協(xié)議層卸載;

減少中間環(huán)節(jié):如RDMA kernel Bypass,IB網(wǎng)絡原生支持RDMA;

優(yōu)化接口交互:如軟硬件交互機制,Send/Rcv Queue Pair、Work/Completion Queues。

3.3 InfiniBand vs Ethernet?

Infiniband和Ethernet從多種方面的比較:

    設計目標。Eth考慮多個系統(tǒng)如何流暢的信息交換,優(yōu)先考慮兼容性與分布式;IB則是為了解決HPC場景數(shù)據(jù)傳輸瓶頸。帶寬。IB的網(wǎng)絡速率通??煊贓th,主要原因是IB應用于HPC場景的服務器互聯(lián),而Eth更多的是面向終端設備互聯(lián)。延遲。Eth交換機處理的任務比較復雜,導致其延遲較大(>200ns)。而IB交換機處理非常簡單,遠快于Eth交換機(<100ns)。采用RDMA+IB的網(wǎng)絡收發(fā)延遲在600ns,而Eth+TCP/IP的收發(fā)延遲高達10us,相差10倍以上??煽啃?。丟包重傳對性能的影響非常大。IB基于端到端的流控,保證報文全程不擁塞,時延抖動控制到最小。Eth沒有基于調(diào)度的流控,極端情況會出現(xiàn)擁塞而導致丟包,使得數(shù)據(jù)轉發(fā)性能大幅波動。組網(wǎng)方式。Eth網(wǎng)絡內(nèi)節(jié)點的增刪都要通知到每一個節(jié)點,當節(jié)點數(shù)量增加到一定數(shù)量時,會產(chǎn)生廣播風暴。IB二層網(wǎng)絡內(nèi)有子網(wǎng)管理器來配置LocalID,然后統(tǒng)一計算轉發(fā)路徑信息,可以輕松部署一個規(guī)模幾萬臺服務器的超大二層網(wǎng)絡。

4、RDMA高性能網(wǎng)絡

4.1 RDMA綜述

RDMA,是一種高帶寬、低延遲、低CPU消耗的網(wǎng)絡互聯(lián)技術,克服了傳統(tǒng)TCP/IP網(wǎng)絡的許多問題。RDMA技術特點:

    • 遠程,數(shù)據(jù)在兩個節(jié)點之間傳輸;直接,不需要內(nèi)核參與,傳輸?shù)奶幚矶夹遁d到NIC硬件完成;內(nèi)存,數(shù)據(jù)在兩個節(jié)點的應用虛擬內(nèi)存間傳輸,不需要額外的復制;

訪問,訪問操作有send/receive、read/write等。

RDMA的其他一些特征:

    RDMA和IB是原生一體;RoCEv1是基于標準Eth的RDMA;RoCEv2基于標準Eth、IP和UDP,支持標準L3路由器。

4.2 RDMA/RoCEv2系統(tǒng)棧分層

RoCEv2是當前數(shù)據(jù)中心比較流行的RDMA技術,我們以RoCEv2為例,介紹RoCE的系統(tǒng)分層:

    以太網(wǎng)層:標準以太網(wǎng)層,即網(wǎng)絡五層協(xié)議物理層和數(shù)據(jù)鏈路層。網(wǎng)絡層IP:網(wǎng)絡五層協(xié)議中的網(wǎng)絡層。傳輸層UDP:網(wǎng)絡五層協(xié)議中的傳輸層(UDP而不是TCP)。IB傳輸層:負責數(shù)據(jù)包的分發(fā)、分割、通道復用和傳輸服務。RDMA數(shù)據(jù)引擎層(Data Engine Layer):負責內(nèi)存隊列和RDMA硬件之間工作/完成請求的數(shù)據(jù)傳輸?shù)取DMA接口驅(qū)動層:負責RDMA硬件的配置管理、隊列和內(nèi)存管理,負責工作請求添加到工作隊列中,負責完成請求的處理等。接口驅(qū)動層和數(shù)據(jù)引擎層共同組成RDMA軟硬件接口。Verbs API層:接口驅(qū)動Verbs封裝,管理連接狀態(tài)、管理內(nèi)存和隊列訪問、提交工作給RDMA硬件、從RDMA硬件獲取工作和事件。ULP層:OFED ULP(上層協(xié)議)庫,提供了各種軟件協(xié)議的RDMA verbs支持,讓上層應用可以無縫移植到RDMA平臺。? ?應用層:RDMA原生的應用,基于RDMA verbs API開發(fā);OFA還提供OFED協(xié)議棧,讓已有應用可以無縫使用RDMA功能。

4.3 RDMA工作隊列

RDMA并沒有約束嚴格的軟硬件接口,各家的實現(xiàn)可以有所不同,只需要支持RDMA的隊列機制即可。

軟件驅(qū)動和硬件設備的交互通?;谏a(chǎn)者消費者模型,這樣能夠?qū)崿F(xiàn)軟件和硬件交互的異步解耦。RDMA軟硬件共享的隊列數(shù)據(jù)結構稱為工作隊列(Work Queue)。

驅(qū)動負責把工作請求(Work Request)添加到工作隊列,成為工作隊列中的一項,稱為工作隊列項WQE。RDMA硬件設備會負責WQE在內(nèi)存和硬件之間的傳輸,并且通過RDMA網(wǎng)絡最終把WQE送到接收方的工作隊列中去。

接收方RDMA硬件會反饋確認信息給到發(fā)送方RDMA硬件,發(fā)送方RDMA硬件會根據(jù)確認信息生成完成隊列項CQE發(fā)送到內(nèi)存的完成隊列。

RDMA Queue類型有:發(fā)送隊列、接收隊列、完成隊列以及隊列對。發(fā)送隊列和接收隊列組成一組隊列對。SRQ,共享接收隊列。把一個RQ共享給所有關聯(lián)的QP使用,這個公用的RQ就稱為SRQ。

4.4 RDMA Verbs API

RDMA Verbs是提供給應用使用的RDMA功能和動作抽象。Verbs API則是Verbs具體實現(xiàn),提供標準接口供應用調(diào)用。

RoCEv2中的Verbs操作主要有兩類:

    Send/Recv。類似于Client/Server結構,發(fā)送操作和接收操作協(xié)作完成,在發(fā)送方連接之前,接收方必須處于偵聽狀態(tài);發(fā)送方不知道接收方的虛擬內(nèi)存位置,接收方也不知道發(fā)送方的虛擬內(nèi)存地址。RDMA Send/Recv因為是直接對內(nèi)存操作,需要提前注冊用于傳輸?shù)膬?nèi)存區(qū)域。Write/Read。與Client/Server架構不同,Write/Read是請求方處于主動,響應方處于被動。請求方執(zhí)行Write/Read操作,響應方不需要做任何操作。為了能夠操作響應方的內(nèi)存,請求方需要提前獲得響應方的地址和鍵值。

5、AWS SRD高性能網(wǎng)絡

5.1 AWS SRD和EFA綜述

SRD(Scalable Reliable Datagram,可擴展可靠數(shù)據(jù)報),是AWS設計的可靠的、高性能的、低延遲的網(wǎng)絡傳輸協(xié)議;EFA(Elastic Fabric Adapter,彈性互聯(lián)適配器),是AWS EC2實例提供的一種高性能網(wǎng)絡接口。AWS的SRD和EFA技術主要有如下特征:

    SRD基于標準的以太網(wǎng),用于優(yōu)化傳輸層協(xié)議。SRD受IB可靠數(shù)據(jù)報的啟發(fā),與此同時,考慮到大規(guī)模的云計算場景下的工作負載,利用了云計算的資源和特點(例如AWS的復雜多路徑主干網(wǎng)絡)來支持新的傳輸策略,為其在緊耦合的工作負載中發(fā)揮價值。借助EFA,使用消息傳遞接口MPI的HPC應用,以及使用NVIDIA集體通信庫(NCCL)的ML應用,可以輕松擴展到數(shù)千個CPU或GPU。EFA用戶空間軟件有兩個:基本驅(qū)動,暴露EFA硬件的可靠亂序交付能力;而在其之上的libfabric實現(xiàn)了包的重排序。? ?EFA類似于IB Verbs。所有EFA數(shù)據(jù)通信都通過發(fā)送/接收隊列對完成。依靠共享隊列機制,可顯著降低所需的QPs數(shù)量。由消息傳遞層完成的緩沖區(qū)管理和流控制,與應用程序是緊密耦合的。

5.2 AWS為什么不選擇TCP或RoCE

AWS認為:

    TCP是可靠數(shù)據(jù)傳輸?shù)闹饕侄?,但不適合對延遲敏感的處理。TCP的最優(yōu)往返延遲大約25us,因擁塞等引起的等待時間可以到50ms,甚至數(shù)秒。主要原因是丟包重傳。IB是用于HPC的高吞吐量、低延遲網(wǎng)絡,但IB不適合可擴展性要求。原因之一是RoCEv2的優(yōu)先級流量控制(PFC),在大型網(wǎng)絡上不可行。會造成隊頭阻塞、擁塞擴散和偶爾的死鎖。即使PFC可用,RoCE在擁塞和次優(yōu)擁塞控制下仍會遭受ECMP(Equal-Cost Multi-Path routing,等價多路徑路由)沖突。SRD針對超大規(guī)模數(shù)據(jù)中心進行了優(yōu)化:跨多個路徑的負載平衡、快速恢復、發(fā)送方控制ECMP、專門的擁塞控制算法、可靠但亂序的交付等。SRD是在AWS Nitro卡中實現(xiàn)。讓SRD盡可能靠近物理網(wǎng)絡層,避免OS和Hypervisor性能噪音注入??煽焖僦貍鞑⒀杆贉p速以響應隊列建立。SRD作為EFA設備公開給主機,EFA是Amazon EC2實例的網(wǎng)絡接口。

5.3 SRD特征之一:多路負載均衡

為了更好的多路負載均衡,AWS的SRD遵循如下原則:

    為了減少丟包的幾率,流量應該在可用路徑上均勻分布。SRD發(fā)送方需要在多個路徑上Spray(噴灑)數(shù)據(jù)包(即使是單個應用程序流),特別是大象流。以最小化熱點出現(xiàn)的可能性,并檢測次優(yōu)路徑。為了與未啟用多路徑的傳統(tǒng)流量共享網(wǎng)絡,因此隨機Spray流量是不合適的,SRD避免使用過載路徑。因為規(guī)模的原因,偶爾的硬件故障不可避免。為了讓網(wǎng)絡從鏈路故障中快速恢復,如果原始傳輸路徑不可用,SRD能夠重新路由重傳的數(shù)據(jù)包,而無需等待路由更新收斂。

5.4 SRD特征之二:亂序交付

在網(wǎng)絡傳輸中,平衡多條可用路徑上的流量有助于減少排隊延遲并防止數(shù)據(jù)包丟失;但不可避免地會導致數(shù)據(jù)包的無序到達。

與此同時,眾所周知,恢復網(wǎng)卡中的數(shù)據(jù)包排序代價昂貴,網(wǎng)卡通常具有有限的資源(內(nèi)存帶寬、重排序緩沖容量或開放排序上下文的數(shù)量)。

如果按順序發(fā)送接收消息,將限制可伸縮性或在出現(xiàn)丟包時增加平均延遲。如果推遲向主機軟件發(fā)送亂序數(shù)據(jù)包,將需要一個非常大的緩沖區(qū),并且將大大增加平均延遲。并且許多數(shù)據(jù)包會因為延遲可能被丟棄,重傳增加了無謂的網(wǎng)絡帶寬消耗。

SRD設計為:將可能亂序的數(shù)據(jù)包,不做處理,直接傳送到主機。

應用程序處理亂序數(shù)據(jù)包,在字節(jié)流協(xié)議,如TCP,是不可行的,但在基于消息的語義時很容易。每個流的排序或其他類型的依賴追蹤由SRD之上的消息傳遞層完成;消息層排序信息與數(shù)據(jù)包一起傳輸?shù)搅硪欢?,SRD是不可見的。

5.5 SRD特征之三:擁塞控制

Incast,是一種流量模式,許多流量匯聚到交換機的同一接口,耗盡該接口的緩沖空間,導致數(shù)據(jù)包丟失。

多路徑Spray減少了中間交換機的負載,但其本身并不能緩解Incast擁塞問題。Spray可能會使Incast問題變得更糟:即使發(fā)送方受自身鏈路帶寬限制,來自發(fā)送方不同時刻的流量,也可能通過不同的路徑同時到達。對于多路徑傳輸來說,擁塞控制將所有路徑上的聚合隊列保持在最小值至關重要。

因此,SRD CC的目標是:用最少的飛行中的數(shù)據(jù)量,獲得最公平的帶寬共享,防止隊列堆積和數(shù)據(jù)包丟失。發(fā)送方需要根據(jù)速率估計調(diào)整其每個連接的傳輸速率,速率估計依據(jù)確認包的時間提示,同時需要考慮最近的傳輸速率和RTT的變化。

6、其他高性能網(wǎng)絡技術

6.1 微軟Fungible的Truefabric

TrueFabric是開放標準的網(wǎng)絡技術,提高數(shù)據(jù)中心的性能、經(jīng)濟性、可靠性和安全性,單集群規(guī)模從幾個到數(shù)千機架。

    橫向擴展數(shù)據(jù)中心,所有服務器節(jié)點都通過可靠的高性能局域網(wǎng)連接。目前,大多數(shù)數(shù)據(jù)中心仍構建在Eth+TCP/IP之上。局域網(wǎng)比廣域網(wǎng)速度快三個數(shù)量級或更多,TCP/IP成為性能的瓶頸。TCP卸載并不成功,很難在CPU和卸載引擎之間清晰拆分TCP。網(wǎng)絡接口和SSD設備的性能比通用CPU提高得更快;系統(tǒng)持續(xù)解構,東西向流量激增。I/O技術和業(yè)務應用的發(fā)展,給網(wǎng)絡棧帶來了巨大的壓力。? ?TrueFabric的所有特性,都是通過基于標準UDP/ IP以太網(wǎng)的新型Fabric控制協(xié)議(FCP)實現(xiàn)。TrueFabric支持:中小規(guī)模,服務器節(jié)點直連Spine交換機;大規(guī)模,兩層拓撲,Spine和Leaf交換機;FCP還可以支持三層或更多層交換機的更大規(guī)模網(wǎng)絡。右圖為TrueFabric網(wǎng)絡部署的抽象視圖,有四種服務器類型:CPU服務器、AI/數(shù)據(jù)分析服務器、SSD服務器和HDD服務器。每個服務器實例包含一個Fungible DPU。

TrueFabric/FCP的特性

    可擴展性:可以從使用100GE接口的小規(guī)模部署,擴展到使用200/400GE接口的數(shù)十萬臺服務器的大規(guī)模署。全截面帶寬:支持端到端的全截面帶寬,適用于標準IP的以太網(wǎng)數(shù)據(jù)包大小。TrueFabric支持短的、低延遲消息的高效交換。低延遲和低抖動:提供節(jié)點之間的最小延遲,以及非常嚴格的長尾延遲控制。公平性:在競爭節(jié)點之間以微秒粒度公平分配網(wǎng)絡帶寬。擁塞避免:內(nèi)置的主動擁塞避免,這意味著數(shù)據(jù)包基本上不會因為擁塞而丟失。并且,擁塞避免技術并不依賴于核心網(wǎng)絡交換機的特性。容錯:內(nèi)置的數(shù)據(jù)包丟失檢測和恢復,錯誤恢復比依賴于路由協(xié)議的傳統(tǒng)恢復技術快五個數(shù)量級。軟件定義的安全和策略:支持基于AES的端到端加密??梢酝ㄟ^配置將特定的部署劃分為單獨加密域。開放標準:FCP建立在基于以太網(wǎng)的標準IP之上,可以與以太網(wǎng)上的標準TCP/IP完全互操作。

6.2 阿里云HPCC和eRDMA

阿里云的HPCC(High Precision Congestion Control,高精度擁塞控制),其關鍵方法是利用INT(In-Network Telemetry,網(wǎng)絡內(nèi)遙測)提供的精確的鏈路負載信息來計算準確的流量更新。

    大規(guī)模RDMA網(wǎng)絡在平衡低延遲、高帶寬利用率和高穩(wěn)定性方面面臨挑戰(zhàn)。經(jīng)典的RDMA擁塞機制,例如DCQCN和TIMELY算法,具有一些局限性:收斂緩慢、不可避免的數(shù)據(jù)包排隊、復雜的調(diào)參參數(shù)。? ?HPCC發(fā)送方可以快速提高流量以實現(xiàn)高利用率,或者快速降低流量以避免擁塞;HPCC發(fā)送者可以快速調(diào)整流量,以使每個鏈接的輸入速率略低于鏈接的容量,保持高鏈接利用率;由于發(fā)送速率是根據(jù)交換機直接測量的結果精確計算得出的,HPCC僅需要3個獨立參數(shù)即可調(diào)整公平性和效率。與DCQCN、TIMELY等方案相比,HPCC對可用帶寬和擁塞的反應更快,并保持接近零的隊列。

彈性RDMA(Elastic Remote Direct Memory Access,簡稱eRDMA)是阿里云自研的云上彈性RDMA網(wǎng)絡,底層鏈路復用VPC網(wǎng)絡,采用全棧自研的擁塞控制CC(Congestion Control,HPCC)算法,享有傳統(tǒng)RDMA網(wǎng)絡高吞吐、低延遲特性的同時,可支持秒級的大規(guī)模RDMA組網(wǎng)??杉嫒輦鹘y(tǒng)HPC應用,以及傳統(tǒng)TCP/IP應用。

eRDMA能力主要具有以下產(chǎn)品優(yōu)勢:

    高性能。RDMA繞過內(nèi)核協(xié)議棧,將數(shù)據(jù)直接從用戶態(tài)程序轉移到HCA中進行網(wǎng)絡傳輸,極大地降低了CPU負載和延遲。eRDMA具有傳統(tǒng)RDMA網(wǎng)卡的優(yōu)點,同時將傳統(tǒng)的RDMA技術應用到VPC網(wǎng)絡下。規(guī)模部署。傳統(tǒng)的RDMA依賴于網(wǎng)絡的無損特性,規(guī)模部署成本高、規(guī)模部署困難。而eRDMA在實現(xiàn)中采用了自研的擁塞控制CC算法,容忍VPC網(wǎng)絡中的傳輸質(zhì)量變化(延遲、丟包等),在有損的網(wǎng)絡環(huán)境中依然擁有良好的性能表現(xiàn)。彈性擴展。不同于傳統(tǒng)的RDMA網(wǎng)卡需要單獨一個硬件網(wǎng)卡,eRDMA可以在使用ECS的過程中動態(tài)添加設備,支持熱遷移,部署靈活。共享VPC網(wǎng)絡。eRDMA依附于彈性網(wǎng)卡(ENI),網(wǎng)絡完全復用,可以在不改變業(yè)務組網(wǎng)的情況下,即可在原來的網(wǎng)絡下激活RDMA功能,體驗到RDMA。

6.3 新興的Ultra-Ethernet

2023年7 月,超以太網(wǎng)聯(lián)盟 (Ultra Ethernet Consortium,UEC) 正式成立,它是一個由 Linux 基金會及其聯(lián)合開發(fā)基金會倡議主辦的新組織。UEC 的目標是超越現(xiàn)有的以太網(wǎng)功能,例如遠程直接內(nèi)存訪問 ( RDMA ) 和融合以太網(wǎng)RDMA (RoCE),提供針對高性能計算和人工智能進行優(yōu)化的高性能、分布式和無損傳輸層,直接將矛頭對準競爭對手的傳輸協(xié)議 InfiniBand。

人工智能和高性能計算給網(wǎng)絡帶來了新的挑戰(zhàn),比如需要更大規(guī)模、更高帶寬密度、多路徑、對擁塞的快速反應以及對單個數(shù)據(jù)流執(zhí)行度的相互依賴(其中尾延遲是關鍵考量點)。UEC 規(guī)范的設計將彌補這些差距,并為這些工作任務提供所需的更大規(guī)模組網(wǎng)。UEC 的目標是一個完整的通信棧,解決跨越多個協(xié)議層的技術問題,并提供易于配置和管理的功能。

UEC將提供基于以太網(wǎng)的開放、可互操作、高性能的全通信堆棧架構,以滿足大規(guī)模人工智能和高性能計算不斷增長的網(wǎng)絡需求。從物理層到軟件層,UEC計劃對以太網(wǎng)堆棧的多個層進行更改。

UEC的技術目標是開發(fā)規(guī)范、API 和源代碼,UEC定義:

    以太網(wǎng)通信的協(xié)議、電信號和光信號特征、應用程序接口/數(shù)據(jù)結構。鏈路級和端到端網(wǎng)絡傳輸協(xié)議,可擴展或替換現(xiàn)有鏈路和傳輸協(xié)議。鏈路級和端到端擁塞、遙測和信令機制,均適用于人工智能、機器學習和高性能計算環(huán)境。支持各種工作負載和操作環(huán)境的軟件、存儲、管理和安全結構。

UEC傳輸協(xié)議:

    從一開始就設計為在IP和以太網(wǎng)上運行的開放協(xié)議規(guī)范。? ?多路徑、包噴灑傳輸,充分利用AI網(wǎng)絡,不會造成擁塞或隊頭阻塞,無需集中式負載均衡算法和路由控制器。Incast管理機制,以最小的丟包控制到目標主機的最終鏈接上的扇入。高效的速率控制算法,允許傳輸快速提升至線速,同時不會導致競爭流的性能損失。用于無序數(shù)據(jù)包傳送的 API,可選擇按順序完成消息,最大限度地提高網(wǎng)絡和應用程序的并發(fā)性,并最大限度地減少消息延遲??蓴U展未來網(wǎng)絡,支持1,000,000個端點。性能和最佳網(wǎng)絡利用率,無需針對網(wǎng)絡和工作負載進行特定的擁塞算法參數(shù)調(diào)優(yōu)。旨在在商用硬件上實現(xiàn) 800G、1.6T 和未來更快以太網(wǎng)的線速性能。

7、全球互聯(lián)網(wǎng)絡的高性能

隨著5G通信基礎設施的大規(guī)模覆蓋,短視頻、視頻會議等多媒體應用的大量使用,自動駕駛智能網(wǎng)聯(lián)汽車的廣泛落地,以及VR/AR元宇宙的快速發(fā)展,對整個全球互聯(lián)網(wǎng)絡的吞吐量、實時性、穩(wěn)定性等各個方面提出了更高的要求。

上圖為聲網(wǎng)通過基于SDN架構的SD-RTN(軟件定義全球?qū)崟r網(wǎng)絡)技術,構建全球?qū)崟r通信網(wǎng)絡,利用廉價的邊緣節(jié)點和獨特的智能路由加速技術,讓全球端到端延遲控制在400ms以內(nèi)。

8、高性能網(wǎng)絡總結

8.1 高性能網(wǎng)絡優(yōu)化總結

高性能網(wǎng)絡優(yōu)化的主要手段:

    • 網(wǎng)絡容量升級:例如網(wǎng)絡帶寬升級,把整個網(wǎng)絡從25Gbps升級到100Gbps;例如更多的網(wǎng)絡端口和連線。輕量協(xié)議棧:數(shù)據(jù)中心網(wǎng)絡跟互聯(lián)網(wǎng)不在一個層級,物理距離短,堆棧延遲敏感,可以不需要復雜的用于全球物理互聯(lián)的TCP/IP協(xié)議棧;網(wǎng)絡協(xié)議硬件加速處理;高性能軟硬件交互:高效交互協(xié)議 + PMD + PF/VF/MQ等,如AWS EFA;

高性能網(wǎng)絡優(yōu)化:通過①多路負載均衡、②亂序交付、③擁塞控制、④多路處理并行等技術(例如AWS SRD技術),實現(xiàn)①低延遲、②高可靠性(低性能抖動)、③高網(wǎng)絡利用率。

8.2 從高性能網(wǎng)絡協(xié)議??聪到y(tǒng)分層

從高性能網(wǎng)絡協(xié)議??聪到y(tǒng)分層:

系統(tǒng)是由多個分層(layer)組成。

每個分層可以當作獨立的組件模塊,根據(jù)需要,選擇不同分層,并對業(yè)務敏感的特定層進行定制設計和優(yōu)化,組合出符合業(yè)務需求的個性化的系統(tǒng)解決方案。

即使分層間有很好的解耦,但每個分層仍不是孤立的;每個分層不宜是一個黑盒,這樣無法從系統(tǒng)層次對其進行優(yōu)化;要想實現(xiàn)極致的性能,需要系統(tǒng)棧不同分層間的通力協(xié)作。

全棧優(yōu)化。系統(tǒng)需要不斷優(yōu)化,每個分層需要不斷優(yōu)化,上下分層間的交互接口也需要不斷優(yōu)化,分層的運行平臺也需要不斷優(yōu)化。

每個分層、交互接口以及整個系統(tǒng),都需要持續(xù)不斷的變化,來適應業(yè)務需求的變化。

推薦器件

更多器件
器件型號 數(shù)量 器件廠商 器件描述 數(shù)據(jù)手冊 ECAD模型 風險等級 參考價格 更多信息
LAN8720AI-CP-TR 1 SMSC Ethernet Transceiver, 1-Trnsvr, CMOS, 4 X 4 MM, 0.85 MM HEIGHT, ROHS COMPLIANT, QFN-24
$1.74 查看
DP83848IVVX/NOPB 1 Texas Instruments Industrial temperature, 10/100-Mbps Ethernet PHY transceiver with SNI &amp; JTAG support 48-LQFP -40 to 85

ECAD模型

下載ECAD模型
$5.13 查看
KSZ9031RNXCA-TR 1 Microchip Technology Inc DATACOM, ETHERNET TRANSCEIVER, QCC48

ECAD模型

下載ECAD模型
$105.81 查看

相關推薦

電子產(chǎn)業(yè)圖譜

公眾號:軟硬件融合;CPU靈活性好但性能較差,ASIC性能極致但靈活性差,魚和熊掌如何兼得,同時兼顧性能和靈活性,我給出的方案是“軟硬件融合”。軟硬件融合不是說要軟硬件緊耦合,相反,是要權衡在不同層次和粒度解耦之后,再更加充分的協(xié)同。