Spine-Leaf 架構
3 秒看懂
Spine-Leaf 是一種為東西向流量最佳化的兩級資料中心網路拓撲。它用“全互聯”取代傳統核心層——每臺 Leaf(接入)交換器都上聯到所有 Spine(骨幹)交換器,任何伺服器間通訊只需經過至多一個 Spine,延遲可預測、無收斂的阻塞風險。這種扁平化設計是雲端原生、AI 訓練叢集和高效能運算網路的基礎。
3 分鐘產業解釋
傳統三層架構(接入-匯聚-核心)是為“南北向”流量(客戶端到伺服器)設計的,匯聚層成為瓶頸與故障域。虛擬化、分散式儲存、容器編排和 AI 分散式訓練產生大量伺服器橫向通訊(東西向流量),要求網路具有確定低延遲、高對分頻寬和彈性擴充套件能力。Spine-Leaf 通過 規則化的 Full‑Mesh 拓撲 滿足了這些需求:
- 拓撲結構:Leaf 交換器下聯伺服器或儲存,上聯所有 Spine;Spine 之間不互連,Leaf 之間也不互連。整個交換在兩級內完成。
- 流量均衡:利用等價多路徑(ECMP)將流量分散到所有 Spine,避免單點擁塞;Spine 的數量決定了上行總頻寬和無阻塞程度。
- 擴充套件模式:橫向增加 Leaf 可容納更多伺服器,橫向增加 Spine 可線性提升上聯總頻寬和故障容忍度。
- 產業落腳點:該架構已從超大規模雲端廠商(Meta、微軟、Google等)的定製網路擴散到企業資料中心;主流交換器廠商(如 Arista、Cisco、Juniper、華為)均已推出針對 Spine‑Leaf 的固定形態交換器與網路作業系統。AI 訓練叢集普遍使用基於此拓撲的 RoCEv2 或 InfiniBand 組網。
15 分鐘專家深入
Spine-Leaf 不僅是拓撲簡化,更是一種橫向擴充套件的架構哲學,它與 Clos 網路1一脈相承,將電交換網路的阻塞效能推到接近理想境界。
- Clos 理論基礎:多級無阻塞交換網路由 Charles Clos 於 1953 年提出。在分組交換領域,Spine‑Leaf 相當於 3 級 Clos 的摺疊變體(摺疊 Clos),其中 Spine 對應中間級交換單元,Leaf 對應輸入/輸出級。Spine 數量由 Leaf 的上行埠數決定,該數量通常根據所需的超額訂閱比確定(例如 Leaf 提供 48 個 25G 下行、6 個 100G 上行,則 Spine 數量為 6),從而實現無阻塞或僅輕度阻塞。
- 等成本多路徑(ECMP)與路由設計:所有 Leaf 到任意目標 Leaf 有 n 條等價路徑(n = Spine 數量)。控制平面通常採用 BGP(大規模)或 OSPF,配合對稱的雜湊策略將流雜湊到不同 Spine。但 ECMP 對流量微突發與極化敏感,因此現代部署常引入 動態負載均衡(如由集中控制器根據鏈路利用率調整,或交換器本地基於流/流片的路徑選擇)。
- Overlay 與 SDN 整合:物理 Spine‑Leaf 提供 Underlay 高頻寬無阻塞矩陣;Overlay 網路(VXLAN、EVPN)在 Leaf 上封裝/解封裝,實現多租戶隔離與虛擬機器任意位置遷移。控制器(如雲端廠商的 SDN 控制器或開源 ONOS/ODL)統一管理策略分發。
- 容錯與運維:單臺 Spine 故障只會導致上行總頻寬降低 1/S(S=Spine 數量),不會中斷任何連線,系統仍可通過剩餘 Spine 保持通訊,延遲僅因雜湊重分佈可能有輕微抖動。運維可對 Spine 輪流升級而不影響業務。
- AI/ML 訓練的特殊需求:分散式訓練通訊模式(All‑Reduce、All‑to‑All 等)會產生大量對分頻寬需求與嚴格尾部延遲要求。Spine‑Leaf 配合無損網路技術(PFC、ECN)和基於信用的流控,建置 RDMA over Converged Ethernet (RoCEv2) 或 IB 閘道器。此時 Spine 埠往往向高基數(64×400G/800G)演進,以減少級數並保持線速無阻塞。
技術原理
Spine‑Leaf 網路本質上是一種 多根樹(Fat‑tree)的摺疊實現,其資料面的核心行為由拓撲連線規則、路由雜湊和緩衝管理共同決定。
拓撲連線與對分頻寬
假設每臺 Leaf 有 p 個下聯伺服器埠(速率 R_serv),s 個上聯 Spine 埠(速率 R_uplink);每個 Spine 有 L 個下聯 Leaf 埠。完整互連下,Spine 數量 = S,Leaf 數量 = L。每臺 Leaf 的 s 個埠分別連線 S 個 Spine(要求 s = S),或通過多根電纜達到總頻寬。網路的對分頻寬總和為:
總對分頻寬 = min( 所有 Leaf 的下行總頻寬, 所有 Spine 的上行總頻寬)
在對稱設計中,通常使 Spine 的上行總容量 ≥ Leaf 下行總容量,從而實現 1:1 對分無阻塞(即任何伺服器間通訊不會因內部鏈路容量不足而丟包)。
[Spine1] [Spine2] ... [SpineS]
| | | | | / \ |
+--+--+--+--+--+--+--+--+
| | | | | | | | | <- s × 上行至每個Spine
[Leaf1] [Leaf2] ... [LeafL]
| \ | \
Server Racks...
簡化連線示意
路由與 ECMP 機制
控制平面在每臺 Leaf 上,為遠端 Leaf 的 IP 字首學習到 S 條等代價下一跳(每個 Spine 一個)。資料平面用資料包五元組雜湊選擇其中一條路徑。雜湊函式設計偏好:
- 對稱性:確保同一流(TCP/UDP 五元組)始終走同一路徑,避免亂序。
- 均衡性:流/流片(flowlet)被均勻分佈,實踐中採用 加權 ECMP(基於鏈路頻寬)或 一致性雜湊 來減少增刪 Spine 時的大規模流遷移。
- 避免極化:若 Spine 之間或 Spine‑Leaf 間存在多級 ECMP,兩級雜湊可能碰撞導致某些鏈路過載。現代晶片引入 隨機化 或 基於 table 的顯式路徑(如動態負載均衡 DLB)。
擁塞控制與無損網路(面向 AI 訓練)
在 RoCEv2 場景,Spine 通常配置為 優先順序流控 (PFC) 可信邊界,Leaf 作為 PFC 生成的起點。同時啟用 明確擁塞通知 (ECN) 標記,伺服器端驅動擁塞控制演算法(DCQCN)降低傳送速率。Spine 的緩衝器大小、水線設定是影響尾部延遲的關鍵引數,但這些引數的精準數值屬於裝置實現細節 [未充分揭露]。
技術演進史
- 2000 年前:資料中心主流為 Layer 2/3 三層樹狀架構,匯聚層通常成對冗餘,STP 阻塞一半鏈路,頻寬浪費嚴重。
- 2000‑2010:Web 2.0 興起,Google、Amazon 等超大規模商開始研發基於 Clos 的扁平架構。2008 年,Google 開始採用基於 Clos 的扁平架構,其後續演進為 Jupiter 網路(2015 年公開),採用多級 Clos 拓撲。
- 2010‑2015:商用晶片(如 Broadcom Trident/Tomahawk)支援高基數 10G/25G,使得兩層 Spine‑Leaf 即可建置萬級伺服器叢集。Arista 推出市場首款用於大規模 Leaf‑Spine 的 40G/100G 交換器。Facebook 釋出 Wedge 40 和 100G backbone 設計2。
- 2015‑2020:VXLAN/EVPN 成為 Overlay 標準,Spine‑Leaf 成為資料中心事實架構。SONiC 等開源 NOS 興起,解耦硬體與軟體。
- 2020‑至今:面向 AI 的 400G/800G 乙太網路和 IB 的 NDR/XDR 速率落地。Spine 向 64×800G 高基數發展,同時出現 Tiered‑Spine(超級 Spine)結構以連線多個 Pod,進入大規模 AI 超級計算機(如 NVIDIA DGX SuperPOD 網路)時代。
技術路線對比
| 維度 | 傳統三層架構 (Access-Agg-Core) | Spine‑Leaf 架構 |
|---|---|---|
| 層級 | 3 層(接入、匯聚、核心) | 2 層(Leaf, Spine) |
| 擴充套件模式 | 垂直(更大機箱) + 有限水平 | 水平擴充套件(新增 Leaf/Spine) |
| 東西向延遲 | 多跳,L3 核心/匯聚之間不確定 | 2 跳(源 Leaf → Spine → 目的 Leaf) |
| 對分頻寬 | 匯聚層利用率有限,STP 阻塞鏈路 | 全互聯,可設計為 1:1 無阻塞 |
| 冗餘與故障域 | 匯聚對故障影響大,收斂慢 | 單 Spine 故障只降頻寬,不中斷服務 |
| 路由協議 | 傳統 STP/MSTP + HSRP/VRRP | ECMP + BGP/OSPF,可集中式控制器 |
| 典型應用場景 | 客戶端‑伺服器,南北向為主 | 雲端原生、虛擬化、分散式儲存、AI 訓練 |
| 技術複雜度 | 成熟,但運維僵化 | 控制平面簡單,物理連線多,運維需自動化 |
上下游
- 上游核心元件:
- 交換晶片:Broadcom (Tomahawk/Trident/Jericho 系列)、Marvell (Teralynx)、NVIDIA (Spectrum)、Intel (Tofino)、Cisco (Silicon One)、華為 (Solar)。高基數、大快取的晶片直接影響 Spine‑Leaf 的埠容量與緩衝特性。
- 光模組與互連:QSFP‑DD、OSFP 等 400G/800G 光模組 (SR/DR/FR/LR),有源光纜 (AOC) 和直連銅纜 (DAC);MPO 光纖矩陣。
- 網路作業系統 (NOS):商用 (Cisco NX‑OS、Juniper JunOS、Arista EOS),開源 (SONiC, Stratum)。SONiC 在超大規模雲端廠商的 Leaf‑Spine 部署中廣泛採用,支援 SAI 抽象硬體。
- 下游應用場景:
- 雲端資料中心與託管:AWS、Azure、Google Cloud、阿里雲端、騰訊雲端等。
- 企業私有雲端/混合雲端:金融、電信、大型製造的高密度虛擬化叢集。
- AI/HPC 叢集:基於 InfiniBand 的胖樹或基於 RoCEv2 的乙太網路 Spine‑Leaf,NVIDIA DGX SuperPOD 網路架構即採用多級 Spine‑Leaf。
- 邊緣計算與 CDN:規模縮小但扁平化需求類似。
關鍵指標
- 埠速率與基數:當前主流 Leaf 埠為 25G/100G 下行,100G/400G 上行;Spine 埠為 100G/400G/800G,單晶片可支援 32‑64 埠 [行業報告]。每臺 Leaf 的上行埠數與 Spine 數量匹配,決定總上行頻寬。
- 對分頻寬比 (Oversubscription ratio):Leaf 下行總頻寬 / Leaf 上行總頻寬。1:1 無阻塞,典型雲端環境可能配置 3:1 或更低,AI 訓練叢集多采用 1:1。
- 等價路徑數 (ECMP 路徑):等於 Spine 數量,通常為 4‑32,取決於規模。路徑數影響流量均衡粒度和故障降級比例。
- 延遲:單跳交換延遲(包括交換器轉發延遲)通常在數百納秒至數微秒 [交換器規格],整個 Leaf‑Spine 內部 RTT 極低,適合高效能運算。
- 功耗與成本:單級 Spine‑Leaf 比三級架構可節省光纖和交換器埠,但佈線複雜度上升;具體 TCO 需要依據規模與功率密度計算 [未揭露具體模型]。
供需與市場資料
由於網路搜尋失敗,無法提供精確市場額數字。根據定性趨勢:
- 需求側:全球超大規模雲端廠商資本支出持續增長,大部分用於資料中心內部網路擴容與升級,AI/ML 工作負載推動高頻寬 Spine‑Leaf 部署。 2023‑2024 年,AI 訓練叢集的交換器市場份額高速增長,400G/800G 埠需求激增。[供應鏈估算]
- 供給側:交換晶片產能一度受限,但廠商擴產;光模組在向 800G 切換,成本過高仍是制約小規模企業採用滿配 Spine‑Leaf 的因素。白盒交換器和 SONiC 的滲透提升,使供應商市場更分散。
- 區域:北美超大規模雲端商為最大采購方,中國市場在政策推動和國產替代下,華為、中興、浪潮等加大自研交換器與晶片推廣。AI 大型模型帶動的訓練網路建設將成為未來 2‑3 年的主要增量。
代表公司與產業對映
- 交換硬體與晶片:Broadcom(AVGO)是商用交換晶片龍頭,其 Tomahawk/Trident 系列是大多數白盒和品牌交換器核心。Arista Networks(ANET)以 EOS 和固定形態交換器主導雲端資料中心市場,市值顯著受益於 Spine‑Leaf 架構普及。Cisco(CSCO)通過 Nexus 9000 系列和 Silicon One 晶片參與競爭。NVIDIA(NVDA)以 Spectrum 乙太網路交換器和 InfiniBand 交換器建置 AI SuperPOD,是 GPU 和網路垂直整合的標杆。華為(未上市)也有資料中心交換器 CloudEngine 系列及自研晶片。
- 光模組:中際旭創(300308)、新易盛(300502)、Coherent(COHR)、Lumentum(LITE)等是高速光模組主要供應商,800G 週期會改變訂單節奏、產品組合和交付壓力。
- 白盒與軟體:雲端杉網路、盛科網路(SDN 控制器),以及提供整體 SDN 解決方案的廠商(如 VMware/Broadcom 的 NSX),在資本市場與資料中心現代化主題相關。
- 雲端運算巨頭:亞馬遜(AMZN)、微軟(MSFT)、Google(GOOGL)、Meta(META)等,其內部網路設計深刻影響供應鏈,並可能自研交換器(如 Google 的 Pluto, Apollo)。
產業觀察
- 高速率升級週期:資料中心從 100G→200G→400G→800G 的切換帶動交換器、晶片、光模組迭代需求,相關硬體的訂單節奏與產品代際同步變化。每一代際,Spine 埠速率率先提升,Leaf 緊隨其後。
- AI 對頻寬的不可壓縮需求:大型模型訓練叢集通訊要求 1:1 無阻塞、超低延遲,推動滿配 Spine‑Leaf 及更高倍數 Fat‑tree,交換器埠數、速率與 GPU 比例通常同步提高。這是主要技術需求來源。
- 白盒化與 SONiC 生態:解耦趨勢使軟體能力更受需求方重視,硬體趨向同質化;傳統品牌交換器份額受到侵蝕,但 Cisco 等以晶片自研和訂閱制應對。
- 網路裝置商的結構性差異:從傳統企業網轉向雲端運算和 AI 資料中心市場後,能否拿下超大規模客戶訂單會影響廠商的競爭位置。Arista 是此類典型,其與 Meta、微軟深度繫結。
- 技術迭代風險:LPO(線性驅動可插拔光學)、CPO(共封裝光學)等新技術可能顛覆傳統光模組和交換器內部互連,影響供應鏈獲利池。同時,下一代拓撲(如直接連線記憶體、機架級交換)可能部分弱化傳統 Leaf 層。
常見誤讀糾偏
- 誤讀 1:“Spine‑Leaf 就是兩層交換器級聯。”
糾偏:Spine‑Leaf 絕非級聯,而是嚴格的 Clos 摺疊全互聯,要求 Leaf 到每個 Spine 都有獨立鏈路。它不是簡單的“上聯下聯”,而是利用 ECMP 建置了無阻塞交換矩陣。級聯可能帶來瓶頸和生成樹阻塞,Spine‑Leaf 則消除了這些。 - 誤讀 2:“Spine‑Leaf 只適用於超大規模資料中心。”
糾偏:雖然超大規模雲端商最先大規模部署,但該架構也可用於中等規模的企業資料中心,甚至小型 AI 叢集。根據需要的伺服器埠數和預算,可用少量 Spine(如 2‑4 臺)和對應的 Leaf 建置。管理平面也可簡化,如使用 BGP 未編號介面,並非只有雲端廠才能駕馭。 - 誤讀 3:“Spine‑Leaf 必須使用昂貴的專用交換器。”
糾偏:基於商用晶片(如 Broadcom Tomahawk)的固定形態交換器即可勝任,且成本低於模組化機箱。開源 SONiC 系統可執行在多款白盒硬體上,大幅降低了每埠價格。整套架構的價效比往往優於同等規模的傳統三層組網。 - 誤讀 4:“I/O 頻寬靠增加 Spine 數量就能線性增長。”
糾偏:增加 Spine 確實增加總上行頻寬和 ECMP 路徑數,但 Leaf 的上行埠數有限,當 Spine 超過 Leaf 埠數後,無法形成全互聯。同時 ECMP 路徑數過多會導致雜湊粒度更粗、控制平面收斂變慢。實際部署中,Spine 數量由所需的對分頻寬和 Leaf 埠數共同決定,並非越多越好。
學習路徑
- 基礎網路:理解乙太網路交換原理、生成樹、VLAN、IP 轉發、路由協議(OSPF/BGP)。
- 資料中心網路演進:閱讀《Cloud Data Center Networking》或相關教材,瞭解從三層架構到 Clos 網路的演變。
- 典型設計案例:學習 Meta 的 FBOSS 網路架構白皮書、微軟的 SONiC 架構,阿里/騰訊的下一代資料中心網路釋出。
- 實踐:搭建虛擬模擬環境(如 GNS3、EVE-NG 配商用或開源映象),配置一個簡單的 BGP‑based Leaf‑Spine 非結構網路;理解 VXLAN/EVPN 的整合。
- AI 網路專題:研究 NVIDIA DGX SuperPOD 網路白皮書、RoCEv2 與 InfiniBand 對比,DCQCN 擁塞控制。
- 持續跟進:關注 OCP(開放計算專案)網路組會議、廠商釋出、市場分析報告(如 Dell’Oro, Crehan)。
一句話總結
Spine‑Leaf 是雲端和 AI 時代的資料中心“龍骨”,它用全互聯的扁平拓撲將東西向流量從擁堵的三層樹狀結構中解放出來,實現可預測的低延遲和橫向擴充套件彈性,是現代高效能網路事實標準。
延伸閱讀與來源
- 論文 / 報告:
- “Jupiter Evolving: Transforming Google’s Datacenter Network via Optical Circuit Switches and Software-Defined Networking” (Google, SIGCOMM 2022, historical series)
- “Introducing data center fabric, the next-generation Facebook data center network” (Meta 2014)
- “A Scalable, Commodity Data Center Network Architecture” (Al-Fares et al., 2008, 介紹 Fat‑tree)
- 開源與標準:
- SONiC - Software for Open Networking in the Cloud
- IETF RFC 7348 (VXLAN), RFC 8365 (EVPN)
- 廠商技術文件:
- Arista “Designing Cloud‑Scale Data Center Networks”
- Cisco “Nexus 9000 Cloud Scale Architecture”
- NVIDIA “NVLink Network and DGX SuperPOD”