数据中心拓扑 —— Spine-Leaf、Fat-Tree、Dragonfly

数据中心几万台服务器怎么连？拓扑选错就是性能瓶颈。本文按演进讲拓扑——从经典三层到现代 Spine-Leaf，再到 AI 时代的 Rail-Optimized 和 Dragonfly。

演进概览

graph LR
  T1[1990s<br/>三层<br/>接入-汇聚-核心] --> T2[2010s<br/>Spine-Leaf<br/>两层 Clos]
  T2 --> T3[2015+<br/>Fat-Tree<br/>无收敛]
  T3 --> T4[2020+<br/>Rail-Optimized<br/>AI 集群]
  T3 --> T5[HPC<br/>Dragonfly<br/>大跨度低跳数]

驱动力是东西向流量增长——传统三层适合”南北向”（用户→服务器），现代数据中心 80%+ 是东西向（服务器↔服务器）。

经典三层（已过时）

graph TB
  CORE[Core 核心层<br/>2-4 台]
  AGG1[Agg 汇聚]
  AGG2[Agg 汇聚]
  ACC1[Access 接入<br/>ToR]
  ACC2[Access 接入<br/>ToR]
  ACC3[Access]
  ACC4[Access]
  
  CORE --- AGG1
  CORE --- AGG2
  AGG1 --- ACC1 & ACC2
  AGG2 --- ACC3 & ACC4
  
  ACC1 --- S1[Server × N]
  ACC2 --- S2[Server × N]

特征：

- 核心层：Cisco Catalyst 6500 等高端框式
- 汇聚层：聚合多个接入交换机
- 接入层：ToR（Top of Rack）

问题：
  - 上行带宽收敛比 1:4 ~ 1:10
  - 跨 ACC 流量要走两跳到 CORE
  - STP 防环 → 一半端口 idle
  - 东西向流量受限

这种拓扑 2010 年后大型互联网就开始抛弃——已经不适合云数据中心。

Clos 网络的回归

Clos 网络是1953 年 Charles Clos 在电话交换机里的发明——多层交换机互联，理论上可以无阻塞连接任意输入输出对。

graph TB
  subgraph Stage3["Stage 3"]
    M1[Switch] & M2[Switch] & M3[Switch]
  end
  subgraph Stage2["Stage 2"]
    N1[Switch] & N2[Switch] & N3[Switch]
  end
  subgraph Stage1["Stage 1"]
    O1[Switch] & O2[Switch] & O3[Switch]
  end
  
  M1 --- N1 & N2 & N3
  M2 --- N1 & N2 & N3
  M3 --- N1 & N2 & N3
  N1 --- O1 & O2 & O3
  N2 --- O1 & O2 & O3
  N3 --- O1 & O2 & O3

每层每台交换机连接下一层每台——任意两个端点 N 跳到达，且无阻塞。

数据中心实际部署的 Spine-Leaf 就是 Clos 的简化版（2 层）。

Spine-Leaf 拓扑

现代数据中心的事实标准：

graph TB
  S1[Spine 1] --- L1[Leaf 1]
  S1 --- L2[Leaf 2]
  S1 --- L3[Leaf 3]
  S1 --- L4[Leaf 4]
  S2[Spine 2] --- L1 & L2 & L3 & L4
  S3[Spine 3] --- L1 & L2 & L3 & L4
  S4[Spine 4] --- L1 & L2 & L3 & L4
  
  L1 --- S1A[Server × 32]
  L2 --- S2A[Server × 32]

特征：

- 只有两层（Spine + Leaf）
- 每 Leaf 连所有 Spine（全互联）
- 任意两个服务器 3 跳到达（Server-Leaf-Spine-Leaf-Server）
- ECMP 多路径负载分担
- 没有 STP——每条链路都用
- 故障收敛快（ECMP 自动重分布）

一个具体例子

Leaf 交换机：
  - 48 个 25/100G 下行口（接服务器）
  - 8 个 100/400G 上行口（接 Spine）
  - 收敛比：48×25 : 8×100 = 1200 : 800 = 1.5:1

Spine 交换机：
  - 32 个 100/400G 端口（全部接 Leaf）

总规模：
  - 32 个 Leaf × 48 服务器 = 1536 服务器
  - 4-8 个 Spine

加大规模就是堆 Spine 数量 + Leaf 数量——水平扩展。

Fat-Tree（Charles Leiserson 1985）

Fat-Tree 是胖树——上层链路带宽 ≥ 下层总带宽，严格无收敛。

graph TB
  subgraph Core["Core"]
    C1 & C2 & C3 & C4
  end
  subgraph Agg["Aggregation Pod 1"]
    A1 & A2
  end
  subgraph Edge["Edge Pod 1"]
    E1 & E2
  end
  
  C1 --- A1 & A2
  C2 --- A1 & A2
  C3 --- A1 & A2
  C4 --- A1 & A2
  A1 --- E1 & E2
  A2 --- E1 & E2
  E1 --- H1[Host]
  E2 --- H2[Host]

k 元 Fat-Tree（每交换机 k 端口）：

- (k/2)² 个 Core 交换机
- 每 Pod 有 (k/2) 个 Agg + (k/2) 个 Edge
- 每 Pod 容纳 (k/2)² 个 Host
- 总 Host 数 = k³/4
- 总交换机数 = 5k²/4

例：k=48 → 27648 Host，3120 交换机。这就是早期”超大规模数据中心”的基本设计。

Fat-Tree vs Spine-Leaf

Fat-Tree：     三层（Edge / Agg / Core）
Spine-Leaf：    两层（Leaf / Spine）

为什么 Spine-Leaf 够：
  - 单交换机端口数大（64-128 口 400G）
  - 两层就能覆盖几千服务器
  - 简化运维
  
Fat-Tree 仍用：
  - 超大规模（万台 +）
  - 多 Pod 设计
  - HPC 强制无收敛

Rail-Optimized 拓扑（AI 集群）

第五章 5.8 已经讲过——这里再深入：

graph TB
  subgraph Rail0["Rail 0 平面"]
    L0_1[Leaf-0-1] --- L0_2[Leaf-0-2]
    S0[Spine-0] --- L0_1
    S0 --- L0_2
  end
  subgraph Rail1["Rail 1 平面"]
    L1_1[Leaf-1-1] --- L1_2[Leaf-1-2]
    S1[Spine-1] --- L1_1
    S1 --- L1_2
  end
  
  L0_1 --- N1G0[节点 1 GPU 0]
  L1_1 --- N1G1[节点 1 GPU 1]
  L0_2 --- N2G0[节点 2 GPU 0]
  L1_2 --- N2G1[节点 2 GPU 1]

8 GPU/节点 = 8 个 Rail 平面，每平面独立 Spine-Leaf：

Rail 0：服务于所有节点的 GPU 0
Rail 1：服务于所有节点的 GPU 1
...
Rail 7：服务于所有节点的 GPU 7

为什么 Rail 适合 AI

1. AllReduce 同 Rank：     每 Rail 内独立完成
2. 无跨 Rail 流量：        节省 Spine 带宽
3. 故障隔离：             单 Rail 故障只影响 1 个 GPU
4. 网络规划简单：          每 Rail 独立设计

NVIDIA SuperPOD 设计指南把 Rail-Optimized 作为标准。万卡集群基本都是这个套路。

Spine 之上：跨 Rail / 跨 Pod

单 Pod = N 节点 × 8 GPU
多 Pod 之间：
  - 每 Pod 一个"Aggregation 层"
  - Aggregation 跨 Pod
  - 万卡集群典型 Pod 大小：500-1000 GPU

Dragonfly（HPC）

HPC 超算用得多——跳数少、带宽利用高：

graph TB
  subgraph Group1["Group 1<br/>本地全互联"]
    G1A[R1] --- G1B[R2] --- G1C[R3] --- G1A
  end
  subgraph Group2["Group 2"]
    G2A[R4] --- G2B[R5] --- G2C[R6] --- G2A
  end
  subgraph Group3["Group 3"]
    G3A[R7] --- G3B[R8] --- G3C[R9] --- G3A
  end
  
  G1A --- G2A
  G1B --- G3A
  G2B --- G3B

每个 Group 内全互联，Group 之间稀疏互联——最大跳数 3-5 跳。

应用：
  - Cray Aries / Slingshot 互联（HPE Slingshot）
  - 多个 ExaFLOP 超算（Frontier、El Capitan）
  - Aurora（Intel + HPE，Slingshot 11）

Dragonfly 的优势在于节省线缆——跨 group 链路远少于 Fat-Tree。

待补充：Slingshot 11 实际 ExaFLOP 超算部署细节。

数据中心物理布线

机柜内（Top of Rack）：
  ToR 交换机 + 服务器 用 DAC（铜缆，<3m）
  
机柜间（同 row）：
  ToR ↔ Leaf 用 AOC 或短距光（30m 内）
  
跨 row（同 hall）：
  Leaf ↔ Spine 用 SR4 多模光（100m）
  
跨 hall（同建筑）：
  Spine ↔ Core 用 LR4 / FR4 单模光（500m-2km）
  
跨建筑：
  长距单模光（10km+）

线缆类型选择直接决定光模块成本——AI 集群里光模块占总成本 10-15% 不奇怪。

L2 / L3 / VXLAN

graph TB
  L2[二层 VLAN<br/>STP 时代<br/>最大几千台]
  L3[三层 BGP<br/>Spine-Leaf 标配<br/>每 ToR 一个 BGP AS]
  VXLAN[VXLAN Overlay<br/>跨 L3 做虚拟 L2<br/>多租户]
  
  L2 --> L3 --> VXLAN

为什么用 L3 而不是 L2

L2 二层网络（VLAN/STP）：
  - 一个广播域
  - STP 防环 → 50% 端口 idle
  - VLAN 4096 上限
  - 故障收敛慢
  - 难扩展

L3 三层网络（BGP）：
  - 每 ToR 一个 BGP AS
  - ECMP 多路径
  - 故障亚秒级收敛
  - 几乎无规模上限

现代数据中心默认 L3 + BGP——VLAN 只在 ToR 内部。

VXLAN：跨 L3 做虚拟 L2

VXLAN：UDP 4789 端口承载 L2 帧
租户看到 "L2 网络"，物理底层是 L3
跨数据中心可达

VXLAN 让多租户云成为可能——每租户一个 VNI（24-bit）。

EVPN（Ethernet VPN）：
  - VXLAN 控制面用 BGP
  - 大规模 multi-tenancy 标准
  - Cisco / Arista / 锐捷 / 华为 都支持

流量工程：ECMP 与 hashing

Spine-Leaf 多路径——ECMP（Equal-Cost Multi-Path） 在多个等价路径间做哈希分流：

hash(5-tuple) % path_count
  5-tuple：src_ip, dst_ip, src_port, dst_port, protocol

问题：

单流（single flow）只走一条路径
  → 大流量"独占"一条链路
  → 拥塞集中
  → 其他流被影响

解决：

1. Adaptive Routing（IB / Tomahawk 5 等）：
   - 动态选最空闲路径
   - 端到端 reorder buffer
   
2. Packet Spraying：
   - 每个包独立选路径
   - 接收端 reorder
   
3. Flowlet Switching：
   - 流的"间歇"作为切换点
   - 不会乱序
   
4. RDMA Multi-Path：
   - 同一 QP 跨多路径
   - HCA 协调

NVIDIA Spectrum-X / Quantum-2 都支持 Adaptive Routing。

数据中心规模的几个例子

一般企业 IDC（数百到几千台服务器）

拓扑：     Spine-Leaf
Spine：    4× 100G QSFP28
Leaf：     32× 25G ToR
规模：     ~1000-2000 台服务器
软件：     EVPN / VXLAN

互联网中型数据中心（万台规模）

拓扑：     Spine-Leaf 多 Pod
单 Pod：   4 Spine + 32 Leaf = ~1500 服务器
Pod 间：   8 个 super-spine
总规模：   8-10 个 Pod × 1500 = ~12000 服务器

Hyperscale 数据中心（10万+）

Microsoft Azure / Google Cloud / AWS：
  - 多层 Clos（4 层、5 层）
  - 自研交换机（Wedge / Tofino / Trident）
  - 800G 上行
  - 单数据中心 10-50 万服务器

AI 训练集群

xAI Colossus 10 万 H100：
  - Rail-Optimized + IB
  - 8 Rail × Pod
  - 多个 Pod 用 Aggregation 互联
  - 总规模 10万 GPU = 12500 节点

Meta 24K H100：
  - RoCE 三层无收敛
  - 自研交换机

网络收敛比（oversubscription）

Leaf 上行带宽 / Leaf 下行带宽 = 收敛比

例：48× 25G 下行（1.2 Tbps），8× 100G 上行（800 Gbps）
   → 收敛比 1.5:1
   
AI 训练强求 1:1（无收敛）：
   → 上行带宽 = 下行带宽
   → 成本翻倍

普通业务可以 3:1 或 4:1：
   → 节省 Spine 数量和成本
   → 适合一般企业 / 大部分云业务

AI 工厂的 Clos 网络变种：2-tier vs 3-tier

普通数据中心用 2-tier Spine-Leaf 便已绰绰有余，到了 AI 工厂——动辄数万 XPU，流量全是 AllReduce 这类”人人互通”的全局操作——网络拓扑便要认真重新考量。

两层 Clos（2-tier）适合中等规模

graph TB
  subgraph Tier1["Tier-1 Spine（交换层）"]
    SP1[Spine 1] & SP2[Spine 2] & SP3[Spine N]
  end
  subgraph Tier0["Tier-0 Leaf（ToR 层）"]
    L1[Leaf/ToR 1] & L2[Leaf/ToR 2] & L3[Leaf/ToR M]
  end
  SP1 --- L1 & L2 & L3
  SP2 --- L1 & L2 & L3
  SP3 --- L1 & L2 & L3
  L1 --- GPU1[GPU 节点群]
  L2 --- GPU2[GPU 节点群]
  L3 --- GPU3[GPU 节点群]

规模上限（以 Tomahawk 6 为例）：
  - TH6：128 × 800G 端口
  - 如果一半端口接服务器、一半接 Spine：64 下行 × 64 上行
  - 64 个 Leaf × 64 服务器 = 4096 GPU 节点
  - 单节点 8 GPU → 32768 GPU

优点：跳数少（2 跳），延迟极低，运维简单
缺点：规模上限约 3-5 万 GPU（受单交换机端口密度限制）

2-tier 是当前主流 AI 集群（万卡级）的标准选择。

三层 Clos（3-tier）支撑超大规模

当目标是 10 万、甚至 50 万 XPU 的”AI 超算园区”时，就必须引入第三层：

graph TB
  subgraph Tier2["Tier-2 Super-Spine（园区级互联）"]
    SS1[Super-Spine 1] & SS2[Super-Spine 2]
  end
  subgraph Tier1["Tier-1 Spine（Pod 内骨干）"]
    SP1[Pod-A Spine] & SP2[Pod-B Spine]
  end
  subgraph Tier0["Tier-0 Leaf/ToR"]
    L1[ToR A1] & L2[ToR A2] & L3[ToR B1] & L4[ToR B2]
  end
  SS1 --- SP1 & SP2
  SS2 --- SP1 & SP2
  SP1 --- L1 & L2
  SP2 --- L3 & L4
  L1 --- G1[GPU]
  L2 --- G2[GPU]
  L3 --- G3[GPU]
  L4 --- G4[GPU]

Microsoft Fairwater 就是 3-tier + 多 Plane 设计：
  - 多个独立平面（Plane 1 ... Plane N）
  - 每个 Plane 是一个完整的 3-tier Clos
  - 理论上支持 524,288 GPU（来源：Cisco + Microsoft OCP 2025 幻灯片）
  - SRv6 做端到端路径控制，解决传统 ECMP 低熵问题

AI Scale-Up 与 Scale-Out 的拓扑分层

这是 2026 年 AI 基础设施最重要的架构分层之一：

graph TB
  subgraph ScaleUp["Scale-Up 层（节点内 / 小 Pod 内）"]
    NVL[NVLink / UALink / PCIe Switch]
    NVL --> XPU1[GPU/XPU 0]
    NVL --> XPU2[GPU/XPU 1]
    NVL --> XPU3[GPU/XPU N]
  end
  subgraph ScaleOut["Scale-Out 层（跨 Pod / 跨机柜）"]
    NET[InfiniBand / RoCEv2 网络]
    NET --> NODE1[计算节点 A]
    NET --> NODE2[计算节点 B]
    NET --> NODE3[计算节点 C]
  end
  ScaleUp --> ScaleOut

层次	技术	延迟	带宽	适用规模
Scale-Up	NVLink 5 / UALink / PCIe Switch	ns 级	TB/s 级	8-1024 XPU
Scale-Out	IB NDR / RoCEv2 / UALink（未来）	μs 级	400-800 Gbps/端口	数万 XPU

两层不能合并的原因：

Scale-Up 需要：
  - 共享内存语义（load/store/原子操作）
  - ns 级延迟
  - 极高带宽（单 GPU 间 900 GB/s NVLink 5）
  - 小 pod 内就能搞定

Scale-Out 需要：
  - 消息传递语义（send/recv）
  - 可以容忍 μs 级延迟
  - 需要路由、拥塞控制
  - 扩展到数万 XPU

UALink 联盟（AMD + Google + Intel + Meta + Microsoft，115+ 成员）正在做的，就是用开放标准填补 Scale-Up 这一层——对标 NVIDIA NVLink 的封闭生态。

双层 Scale-Out 方案：Tomahawk 6 支撑 128K XPU

咱要讲的这个方案，来自 2026 年微软的生产实践，数据相当硬核。

解聚合 Spine（Disaggregated Spine）的由来

微软在 OCP 2026 EMEA 峰会公开了一件事：把传统机箱式 Tier-2 交换机拆开，分成 Upper-T2（UT2）和 Lower-T2（LT2）两种不同芯片的固定形态设备。

graph TB
  RNG[区域网络网关 RNG<br/>100km 范围聚合多个 DC]
  RNG --> UT2[Upper-T2<br/>Broadcom DNX 系列<br/>Q3D 25.6T / Q4D 51.2T<br/>支持 ZR 长距光 + MACSec]
  UT2 --> LT2[Lower-T2<br/>Broadcom XGS 系列<br/>TH5-512 51.2T / TH6-P 102.4T<br/>高 Radix + 低延迟 + 低功耗]
  LT2 --> T1[Tier-1 交换机]
  T1 --> T0[ToR / Leaf]
  T0 --> GPU[GPU 节点]

为什么拆？ 微软用 30 天 Sflow 数据分析发现：机箱内 85% 的流量是数据中心内部流量，只有 15% 是跨 DC 的 WAN 流量。把两种功能混在一个机箱里——用同一块 ASIC 既处理 ZR 长距光又处理高密度本地 Fabric——是严重的资源浪费。

量化收益

部署方案	UT2 芯片	LT2 芯片	功耗对比机箱
400G 基准机箱	机箱混用	机箱混用	100%（179.7 kW）
400G 解聚合	Q3D	TH5-512	节省 30%（116.5 kW）
400G 解聚合 + TH6-P	Q3D	TH6-P 102.4T	节省 43%
800G 解聚合	Q4D	TH6-P 102.4T	节省 47.3%

来源：微软 OCP 2026 EMEA 幻灯片《From Modular Chassis to Modular Network Spine》

TH6-P 的角色

在这个方案里，Tomahawk 6（TH6-P）专职 LT2——负责数据中心内部的高密度 Fabric 连接：

TH6-P 规格：
  - 102.4 Tbps 总带宽
  - 128 × 800G 端口（或 64 × 1.6T）
  - 功耗：<500W（XGS 系列，低于 DNX 同等级）
  - 高 Radix，低延迟，无 VoQ / MACSec（不需要）

支撑规模估算：
  - 单个 TH6-P LT2 可服务 ~128 个 800G 下行口
  - 组成双层 Clos（TH6-P Spine + ToR）可覆盖 128K XPU 级别规模

UT2/LT2 互联用 LPO AOC

两者之间的互联不用昂贵的 ZR，而是用低功耗 LPO AOC（Active Optical Cable with Linear-drive Pluggable Optics）：

400G QSFP-112 LPO AOC：4W（vs ZR 的 18W）
800G OSFP LPO AOC：8W（vs ZR 的 28W）

功耗降低 77%！
风扇冷却功耗是风扇转速的三次方关系，
光模块功耗降低一半 → 整机冷却功耗降低更多

延迟与光成本降低

延迟降低：
  - 去掉 DSP（数字信号处理器）
  - LPO 方案直接驱动激光器，无 DSP 延迟（节省 ~10-20 ns/跳）
  - 多跳累积效应在大规模 AllReduce 中显著

光成本降低：
  - LPO 模块比 ZR 模块便宜 60-70%
  - 不需要相干光技术，制造简单
  - CPO（共封装光学，如 TH6-Davisson）进一步降低光成本

一些查询命令

# 看路由表
ip route
ip -6 route

# BGP 状态
vtysh
show ip bgp summary
show ip bgp neighbor

# ECMP 路径
ip route get <dst>
ip neigh

# 看 NIC 多路径
ethtool -S eth0 | grep -i drop

# 路径追踪（多路径感知）
mtr <dst>
traceroute <dst>
paris-traceroute <dst>

# IB 拓扑发现
ibnetdiscover
ibtracert

拓扑设计的几个权衡

1. 收敛比：     性能 vs 成本
2. 跳数：       延迟 vs 规模
3. 端口密度：    交换机数量 vs 容量
4. 可扩展性：    增量扩 vs 重新设计
5. 故障域：     大故障域 vs 复杂控制面
6. 布线：       单模 vs 多模 vs DAC，距离
7. Scale-Up / Scale-Out 分层：节点内互联 vs 跨节点互联，选不同技术

万卡级集群拓扑设计要 1-2 月——不是简单的”买交换机连起来”。

实战清单

1. 规划阶段：     
   - 确定服务器数量和增长曲线
   - 算 East-West 流量峰值
   - 选拓扑（Spine-Leaf / Fat-Tree / Rail-Optimized）
   - 定收敛比
   - 选交换机芯片（Tomahawk / Tofino / Spectrum）
   - 明确 Scale-Up / Scale-Out 分层设计

2. 实施阶段：
   - 布线工程量大（万级线缆）
   - 光模块采购周期长（半年起）
   - 调通 BGP / EVPN / VXLAN
   - PFC/ECN 调优（RoCE 集群）
   - UT2/LT2 解聚合 Spine 配置（SONiC 2025.11 支持）

3. 运维阶段：
   - 链路 flap 监控
   - ECMP 流量观测
   - 故障切换测试
   - 容量管理

小结

• 经典三层已淘汰，Spine-Leaf 是事实标准
• Fat-Tree 在超大规模仍有价值
• AI 集群推 Rail-Optimized——8 GPU = 8 个独立 Rail
• HPC 用 Dragonfly 节省线缆
• VXLAN + EVPN 是多租户标配
• ECMP 单流瓶颈靠 Adaptive Routing 解决
• 现代数据中心 L3 + BGP，VLAN 只在 ToR
• AI 工厂的关键分层：Scale-Up（NVLink/UALink，ns 级）与 Scale-Out（IB/RoCE，μs 级）必须分开设计
• **解聚合 Spine（UT2 + LT2）**是微软验证的方向：800G 部署节省 47.3% 功耗，TH6-P 支撑 128K XPU 规模
• LPO AOC 替代 ZR 做 DC 内互联，降低光成本和功耗 70%+

下一篇讲交换机本身——商用 vs 白盒、SONiC 生态。

内容深度由贤狼赫萝于 2026-06-15 增补，引用来源：OCP 2025/2026 幻灯片、Broadcom 技术访谈。