隨著傳統(tǒng)IDC向云數(shù)據(jù)中心轉(zhuǎn)型,數(shù)據(jù)中心網(wǎng)絡架構(gòu)開始不斷演進,三層架構(gòu)正過渡到Spine - Leaf架構(gòu)。為了更好地利用數(shù)據(jù)中心的 CPU 資源,公有云提供商采用了多租戶模式。云平臺需要為每個租戶提供防火墻、IPsec-VPN、微分段、加解密等網(wǎng)絡服務,以隔離和保護其流量免受威脅。
在某些數(shù)據(jù)中心中,專門的中央設備負責執(zhí)行這些網(wǎng)絡服務功能,數(shù)據(jù)包必須多次穿越數(shù)據(jù)中心網(wǎng)絡,造成了一定的流量瓶頸?,F(xiàn)代數(shù)據(jù)中心正在嘗試將安全和網(wǎng)絡功能放置到更靠近工作負載的位置,以獲得更好的性能,這就是SmartNIC/DPU 出現(xiàn)的原因之一。
云數(shù)據(jù)中心架構(gòu)
三層架構(gòu)
許多傳統(tǒng)數(shù)據(jù)中心采用三層架構(gòu),包括核心路由器、匯聚路由器和接入交換機。核心路由器通常是大型模塊化路由器,具有非常高的帶寬和高級路由功能。匯聚路由器是中間層路由器,具有更高的上行鏈路速度。服務器與接入交換機(也稱為 TOR交換機)相連,如下所示。
?
當大部分流量是南北向流量時,三層架構(gòu)的工作效果很好:流量從數(shù)據(jù)中心外部進入,流經(jīng)匯聚、接入交換機到服務器,然后再向北離開數(shù)據(jù)中心。大多數(shù)數(shù)據(jù)包每條路都會經(jīng)過三個網(wǎng)絡設備。
隨著虛擬化技術的發(fā)展,單個服務器上可以承載多個虛擬機,再加上微服務的普及,東西向流量(服務器到服務器的通信)出現(xiàn)爆炸式增長。三層架構(gòu)并不適合東西向流量的模式,服務器到服務器的通信必須經(jīng)過兩次訪問、匯聚和/或核心設備(具體取決于目標服務器的位置),這導致延遲大大增加。此外,由于接入交換機僅與一小部分匯聚交換機通信,因此任何一個交換機的故障都會導致帶寬的顯著減少。
兩層或Spine-Leaf架構(gòu)
Spine-Leaf架構(gòu)只有兩層,每個Leaf設備連接到每個Spine設備。由于任意連接,這些設備需要高端口密度。這種架構(gòu)在現(xiàn)代云數(shù)據(jù)中心中很受歡迎,因為密集的Spine-Leaf連接可以很好地支持東西向的流量模式。
?
Spine通常與Leaf交換機有直接連接 (40Gbps - 400Gbps) 。Leaf交換機充當此拓撲中的傳統(tǒng) TOR 交換機,它們具有 20-50 個端口連接到機架中的服務器,以及多個上行鏈路 (40Gbps-400Gbps) 連接到所有Spine設備。 這種架構(gòu)有以下幾個優(yōu)點:
兩臺服務器之間的東西向流量最多有四個躍點 (host-leaf-spine-leaf-host),這有助于減少總體延遲和功耗。
簡化了中間層,與三層相比,拓撲中的網(wǎng)絡設備更少。
可以獨立添加Leaf和Spine設備,以增加網(wǎng)絡容量,有時被稱為“橫向擴展”架構(gòu)。
服務器虛擬化
為了更好地利用數(shù)據(jù)中心的 CPU 資源,公有云提供商采用了多租戶模式,即服務器中 CPU 的計算能力在多個系統(tǒng)、應用程序和/或企業(yè)用戶(租戶)之間共享。盡管資源是共享的,但租戶彼此之間互不干涉,且租戶數(shù)據(jù)由服務器軟件完全分開保存。多租戶可以降低云計算硬件成本。
云服務提供商需要確保每個租戶的數(shù)據(jù)安全,計算資源在租戶之間公平共享,以及防止"嘈雜鄰居"效應(其中一個或幾個客戶端/應用程序消耗大部分接口和計算帶寬)。
主機服務器中的多租戶通常通過服務器虛擬化來實現(xiàn)。服務器虛擬化是通過軟件應用程序(如VMware Vsphere Hypervisor)將物理服務器劃分為多個獨立的虛擬機的過程。每個虛擬機都包含應用程序、操作系統(tǒng)和內(nèi)核。服務器虛擬化允許每個虛擬機充當唯一的物理設備,但虛擬機依賴其專用的操作系統(tǒng)(OS),每個OS都會占用額外的CPU、RAM和存儲服務器。
在過去幾年中,云提供商和企業(yè)開始轉(zhuǎn)向另一種共享服務器資源的方法——容器。容器是輕量級的操作系統(tǒng)級虛擬化,容器與宿主機共享硬件資源及操作系統(tǒng),可以實現(xiàn)資源的動態(tài)分配。微服務是一種軟件架構(gòu)模型,其中應用程序被分解為多個具有明確定義的接口和操作的單個功能模塊(微服務)。微服務鏈接在一起以創(chuàng)建“可插入”應用程序。在容器中運行微服務是現(xiàn)代數(shù)據(jù)中心使用計算資源的最有效方式之一。
虛擬機和容器化微服務不僅增加了主機之間的流量模式,還增加了主機內(nèi)虛擬機和容器之間的流量模式。所有這些主機間和主機內(nèi)的流量都需要進行交換/路由和保護,這都增加了服務器 CPU 的負擔。
Spine/Leaf通信
在虛擬化之前,一臺服務器只有一個 MAC 和一個 IP 地址。服務器虛擬化后,每個虛擬機或容器至少有一個 MAC 和一個 IP 地址。
如果Spine-Leaf交換機在第 2 層 (L2) 中轉(zhuǎn)發(fā)流量,那么每個交換機都需要學習網(wǎng)絡中的每個 MAC 地址,包括服務器上所有虛擬機的 MAC 地址。一臺典型服務器中通常有 60-80 個虛擬機,每個機架大約有 40 臺物理服務器,大約有 20 個機架,這意味著每個Spine交換機中有 64K個 MAC 表條目。
在 L2 轉(zhuǎn)發(fā)中,當目的地未知或未被獲知時,網(wǎng)絡設備應將數(shù)據(jù)包泛洪到與其相連的所有端口,這可能會導致環(huán)路和數(shù)據(jù)包風暴。為了避免這種情況,可以使用生成樹協(xié)議 (STP) 對VLAN 段內(nèi)的網(wǎng)絡拓撲修剪并創(chuàng)建樹狀拓撲。但STP 會阻塞冗余路徑,減少可用鏈路的數(shù)量。
但是,如果Spine-Leaf通信位于第 3 層 (L3),則Spine交換機只需為每個子網(wǎng)(Leaf交換機和與其關聯(lián)的服務器)使用 IP 轉(zhuǎn)發(fā),而無需學習所有的MAC 地址。
當Leaf交換機到服務器的通信是在二層時,Leaf交換機只需要了解其本地虛擬機的 MAC 地址。此外,ECMP可用于在Spine/Leaf之間通過多個并行鏈路(多路徑)發(fā)送流量,從而更好地利用帶寬,并且具有更好的彈性。
由于以上種種原因,L3 轉(zhuǎn)發(fā)是Spine交換機和Leaf交換機之間的普遍選擇。
云數(shù)據(jù)中心的另一個關鍵需求是能夠在不更改MAC和IP地址的情況下將虛擬機從一臺物理服務器移動到另一臺物理服務器。
如果所有虛擬機都位于一個平面以太網(wǎng)中,那么MAC 移動是可行的。在Spine/Leaf和host之間進行L2轉(zhuǎn)發(fā),可以使用VLAN創(chuàng)建多個網(wǎng)段,并且特定網(wǎng)段內(nèi)的虛擬機可以自由移動。但是,由于只有 4K個VLAN,基于 VLAN 的分段無法很好地擴展,也印證了L2 轉(zhuǎn)發(fā)不是首選。
這就是 VXLAN 發(fā)揮作用的地方。VXLAN隧道協(xié)議將以太網(wǎng)幀封裝在IP/UDP數(shù)據(jù)包中,可以創(chuàng)建跨物理 L3 網(wǎng)絡的虛擬化 L2 子網(wǎng)。每個 L2 子網(wǎng)均由 24 位 的VNI唯一標識。執(zhí)行 VXLAN Encap/Decap 的實體(如主機或網(wǎng)絡設備中的hypervisor等軟件應用程序)稱為 VTEP(VXLAN 隧道端點)。VTEP的服務器端位于二層橋接域,網(wǎng)絡端是IP網(wǎng)絡。
?
VXLAN 報頭中的 24 位 VNI 轉(zhuǎn)換為 1600 萬個 VNI 子網(wǎng),這可以在 IP 底層網(wǎng)絡之上構(gòu)建大規(guī)模虛擬以太網(wǎng)Overlay 網(wǎng)絡。還有其他Overlay 協(xié)議,如 NVGRE,也能實現(xiàn)類似的結(jié)果,但相對而言VXLAN 是一個流行的選擇。
SmartNIC的興起
上文在傳統(tǒng)三層網(wǎng)絡架構(gòu)向二層網(wǎng)絡架構(gòu)的轉(zhuǎn)變中,提到了服務器虛擬化和容器化的種種優(yōu)勢,但虛擬機依賴其專用的操作系統(tǒng)(OS),每個OS都會占用額外的CPU、RAM和存儲服務器。此外,使用分布式服務模型,網(wǎng)絡和安全功能也需要在虛擬機/容器之間的所有流量上運行,這會給服務器 CPU 資源帶來壓力,CPU 可能會使用 30% 的內(nèi)核來實現(xiàn)這些功能。
CPU作為服務器中最昂貴的組件,理想情況下,我們希望CPU的所有能力都用來單獨運行應用程序軟件,而不是用來處理網(wǎng)絡、安全或存儲功能,也就是所謂的基礎設施功能。
這就是SmartNIC出現(xiàn)的原因之一。
NIC 是一種網(wǎng)絡接口卡,通過以太網(wǎng)接口接收來自網(wǎng)絡的數(shù)據(jù)包,并將其發(fā)送到服務器 CPU,反之亦然。NIC通過PCIe接口連接到服務器CPU,以線路速率將數(shù)據(jù)包傳輸?shù)?CPU 或從 CPU 傳輸出來。隨后,NIC開始添加硬件加速(使用 ASIC 或 FPGA),以減輕服務器 CPU 對基本數(shù)據(jù)包處理功能的負擔。
事實證明,把服務器從基礎設施功能處理中剝離出來可以節(jié)省大量成本,因此,越來越多的此類功能開始進入NIC。S
martNIC一詞是指那些使用定制 ASIC/FPGA 或基于 SOC 的硬件加速,將 CPU能力從基礎網(wǎng)絡功能中釋放出來的NIC。
x16 接口的 PCIe 插槽的功率預算約為 75 瓦,這限制了用于加速的硬件設備的功耗。雖然基于FPGA的解決方案開發(fā)時間更快,但很難滿足75W的功耗要求。
另外,在SOC 中使用處理器內(nèi)核進行加速/卸載的方法無法獲得良好的性能,因為處理器內(nèi)核無法以足夠快的速度處理數(shù)據(jù)平面流量,以跟上 >100Gbps 以太網(wǎng)流量。
因此,許多供應商都在提供帶有 ASIC 的混合解決方案,ASIC具有數(shù)據(jù)平面處理器內(nèi)核(用于處理難以在硬件中實現(xiàn)的復雜網(wǎng)絡功能)和可編程硬件加速器以及傳統(tǒng)的數(shù)據(jù)包處理卸載。這些設備通常被稱為 DPU 或數(shù)據(jù)處理單元,DPU 還擁有自己的控制/管理平面。
在某些配置中,DPU 可以集成為Leaf交換機的一部分,或者作為Leaf交換機和傳統(tǒng) NIC 之間的轉(zhuǎn)換器。但最常見的配置是將 DPU 作為 NIC 的一部分集成到服務器組中。
DPU是Smartest NIC?
DPU 中的典型子系統(tǒng)和接口如下圖所示:
以太網(wǎng)接口
通常至少有兩個端口,且每個端口為 25Gbps 至 200Gbps(有些供應商在開發(fā) 400Gbps)。每個以太網(wǎng)接口都連接到 MAC/PCS 子系統(tǒng),以提取數(shù)據(jù)包提取并在第2層檢查數(shù)據(jù)包完整性。
與主機之間的 PCIe 接口
通常是Gen3/4/5接口??赡苡卸鄠€ PCIe 接口,一些接口與 CPU 通信,另一些接口與 SSD/GPU 通信。在設計PCIe 接口到CPU的整體帶寬時,應保證能處理來自以太網(wǎng)接口的全部流量,以在不擁塞的情況下到達 CPU。
在具有許多虛擬機的高度虛擬化服務器中,依賴hypervisor向所有虛擬機提供連接會增加 CPU 的開銷。SR-IOV 標準允許單個NIC在hypervisor軟件中顯示為多個虛擬NIC(每個虛擬機一個)。它允許不同的虛擬機共享單個 PCIe 接口,而無需在hypervisor中使用虛擬交換機。PCIe complex支持 SR-IOV 所需的 PF/VF。
實現(xiàn)此功能的 DPU 負責在數(shù)據(jù)包處理引擎中的虛擬機(Open vSwitch) 之間進行切換。
數(shù)據(jù)包轉(zhuǎn)發(fā)
DPU 通常具有復雜的數(shù)據(jù)包轉(zhuǎn)發(fā)管道,支持所有 L2/L3 轉(zhuǎn)發(fā)功能。因此,非常需要有一個可編程的數(shù)據(jù)平面。P4 是轉(zhuǎn)發(fā)平面編程的首選語言,它可用于定義可編程和固定功能網(wǎng)絡處理單元中的數(shù)據(jù)平面行為。
除了支持基本的L2/L3轉(zhuǎn)發(fā)之外,在卸載引擎和/或處理器內(nèi)核的幫助下,數(shù)據(jù)包轉(zhuǎn)發(fā)邏輯還可以支持多種功能。具體實施情況因供應商而異。
Overlay支持:DPU 可以作為 VXLAN 隧道端點 (VTEP),從服務器hypervisor卸載此功能。它可以支持VXLAN和其他Overlay協(xié)議的Inline封裝/解封裝。該邏輯在數(shù)據(jù)包處理引擎中實現(xiàn)。
TCP 基本功能
TCP 校驗和卸載
CP 報頭有一個校驗和字段,DPU 可以計算校驗和并將錯誤標記給 CPU。
TCP 分段卸載
CPU 可以將大數(shù)據(jù)塊與報頭模板一起發(fā)送給 DPU。DPU 對數(shù)據(jù)包進行分段,并在每個分段中添加以太網(wǎng)/IP 和 TCP 報頭。
TCP Large Receive Offload
DPU 可以收集單個流的多個 TCP 報文,并將它們發(fā)送到 CPU,以便 CPU 不必處理許多小報文。
Receive Side scaling
DPU 可以通過對五元組進行哈希來確定數(shù)據(jù)包的流。屬于不同流的數(shù)據(jù)包可以到達 CPU 的不同內(nèi)核。這減少了單個 CPU 線程上的負載。
流表
在基于流的轉(zhuǎn)發(fā)中,主機 (CPU) 或 DPU 的控制平面處理器對前幾個報文進行報頭檢測。之后,處理器將流記錄到流表中。然后,相同流中的其余報文可以通過流表查找來處理,使用的流標識字段是通過哈希L2/IP報頭和外部封裝報頭形成的。
這可以顯著提高某些應用程序的性能,因為查找流表比全面檢查和評估每個數(shù)據(jù)包要快得多。流表由數(shù)百萬個條目組成,存儲在外部存儲器中。
安全功能
DPU 支持多種功能,以驗證和保護不同應用程序之間的流量。
加密/解密
DPU 支持 VPN 終端,可對加密的VPN流量進行在線加/解密和IPsec認證。
防火墻/ACL
現(xiàn)代數(shù)據(jù)中心依賴于分布式防火墻,防火墻可以通過數(shù)據(jù)平面處理器內(nèi)核或卸載引擎來加速。不同的DPU 具有不同的防火墻功能。通常,廠商提供靜態(tài)數(shù)據(jù)包過濾、訪問控制列表 (ACL) 和 NAT。
TLS 加密/解密
傳輸層安全 (TLS) 對應用層流量進行加密,使黑客無法竊聽/篡改敏感信息。它運行在 TCP 之上,最初用于加密 HTTP 會話——Web 應用程序和服務器之間的流量。最近,許多運行在 TCP 上的應用程序也開始使用 TLS 來實現(xiàn)端到端安全。TLS 也可以運行在 UDP 之上,稱為 DTLS協(xié)議。某些 DPU 提供代理 TCP/TLS 服務,用于終止 TCP 會話、解密 TLS 加密流量,以及在將流量發(fā)送到主機處理器之前對其進行身份驗證。TCP/TLS 卸載通常通過專用硬件和處理器內(nèi)核的組合來完成。
控制平面的處理器內(nèi)核
DPU 具有一組運行 Linux 的 ARM 內(nèi)核,用于運行控制(包括 Open vSwitch 控制平面)和管理協(xié)議。
Cross-Bar或NoC
提供內(nèi)存和緩存的連接,并保持緩存一致。
QoS/流量整形
NIC 接收托管不同在虛擬機/容器中不同應用程序的流量,并且需要支持 QoS。DPU 支持多個隊列和優(yōu)先級,并支持從這些隊列進行調(diào)度的復雜調(diào)度算法,還支持流量整形以減少傳出流量的突發(fā)性。
DMA 引擎
DMA 引擎可以在DPU和主機內(nèi)存之間發(fā)起內(nèi)存?zhèn)鬏敗?
存儲功能
隨著計算資源的解耦,存儲解耦在數(shù)據(jù)中心也得到了大力支持。許多云提供商正在將存儲與計算分離,以降低基礎設施成本、減少需要支持的服務器配置數(shù)量,并能夠為數(shù)據(jù)密集型 AI/ML 應用程序提供靈活的存儲資源。
存儲服務器是一組存儲設備(主要是NVMe SSD),充當邏輯池,可以分配給網(wǎng)絡上的任何服務器。存儲服務器中的遠程 SSD 和 CPU 之間的文件和塊數(shù)據(jù)傳輸發(fā)生在承載數(shù)據(jù)包流量的同一個Spine-Leaf網(wǎng)絡上。
NVMe over Fabric 和 NVMe over TCP 是流行的協(xié)議,可以使用以太網(wǎng)和 TCP/IP Underlay在數(shù)據(jù)中心網(wǎng)絡上使用 NVMe 傳輸數(shù)據(jù)。DPU 通常通過實施硬件加速引擎來支持對遠程存儲服務器的訪問,硬件加速引擎可以啟動這些協(xié)議來讀/寫 SSD。
此外,DPU 還支持 RDMA over IP (RoCE) 卸載、數(shù)據(jù)壓縮/解壓縮(以減少通過網(wǎng)絡傳輸?shù)?SSD 設備的數(shù)據(jù)量)和確保安全的數(shù)據(jù)加密/解密。
負載均衡器
負載均衡器將應用程序流量分配到多個虛擬機/容器(運行應用程序),以支持多個并發(fā)用戶。比如谷歌地圖APP可能托管在谷歌數(shù)據(jù)中心的許多服務器上,當用戶在地圖上查詢路線時,根據(jù)服務器上的負載,每個查詢可能會轉(zhuǎn)到不同的服務器。
負載均衡器對第 4 層(TCP/UDP 報頭)和/或第 5-7 層(應用程序數(shù)據(jù))中的字段進行哈希處理,以查找可用服務器的表,并使用策略分配應用程序流量。實際的實現(xiàn)比這個描述復雜得多,是通過卸載引擎實現(xiàn)的。
DPU 的未來
所有云提供商都在大力投資定制DPU的開發(fā)工作,并過渡到基于 DPU 的智能NIC,以降低基礎設施成本,并提供更好的吞吐量/性能。
目前,這些 DPU 尚未廣泛滲透到企業(yè)客戶中,它們比標準NIC要貴很多,并且在編程NIC 軟件時涉及工程工作。對于公有云提供商來說,由于其數(shù)據(jù)中心規(guī)模龐大,在所有服務器上分攤的工程工作量并不顯著。但對于中小企業(yè)客戶來說,將更多的標準化特性卸載到 DPU 和完全可編程的數(shù)據(jù)平面架構(gòu)可以幫助簡化開發(fā)工作。
隨著云軟件和 DPU 硬件團隊之間更緊密的交互(硬件和軟件的共同設計),會發(fā)現(xiàn)更多從卸載到DPU中受益的功能。此外,DPU未來有可能完全解耦云資源,并將 CPU/GPU/GPGPU 降級為與DPU連接的勞動力。
原文鏈接: https://www.linkedin.com/pulse/evolution-smartnicsdpus-modern-data-centers-sharada-yeluri?trk=public_post-content_share-article
審核編輯:劉清
-
交換機
+關注
關注
20文章
2600瀏覽量
98883 -
路由器
+關注
關注
22文章
3681瀏覽量
113279 -
Mac
+關注
關注
0文章
1085瀏覽量
51275 -
虛擬機
+關注
關注
1文章
897瀏覽量
27965 -
VLAN通信
+關注
關注
0文章
18瀏覽量
5625
原文標題:現(xiàn)代數(shù)據(jù)中心SmartNIC/DPU 的演變
文章出處:【微信號:SDNLAB,微信公眾號:SDNLAB】歡迎添加關注!文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
相關推薦
評論