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

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

演进概览

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

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

经典三层（已过时）

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

特征：

1
2
3
4
5
6
7
8
9
- 核心层：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]

特征：

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

一个具体例子

1
2
3
4
5
6
7
8
9
10
11
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 端口）：

1
2
3
4
5
- (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

1
2
3
4
5
6
7
8
9
10
11
12
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：

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

为什么 Rail 适合 AI

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

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

Spine 之上：跨 Rail / 跨 Pod

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

Dragonfly（HPC）

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

graph TB
  subgraph Group1["Group 1
本地全互联"]
    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 跳。

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

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

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

数据中心物理布线

1
2
3
4
5
6
7
8
9
10
11
12
13
14
机柜内（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
STP 时代
最大几千台]
  L3[三层 BGP
Spine-Leaf 标配
每 ToR 一个 BGP AS]
  VXLAN[VXLAN Overlay
跨 L3 做虚拟 L2
多租户]
  
  L2 --> L3 --> VXLAN

为什么用 L3 而不是 L2

1
2
3
4
5
6
7
8
9
10
11
12
L2 二层网络（VLAN/STP）：
  - 一个广播域
  - STP 防环 → 50% 端口 idle
  - VLAN 4096 上限
  - 故障收敛慢
  - 难扩展

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

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

VXLAN：跨 L3 做虚拟 L2

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

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

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

流量工程：ECMP 与 hashing

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

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

问题：

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

解决：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
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（数百到几千台服务器）

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

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

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

Hyperscale 数据中心（10万+）

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

AI 训练集群

1
2
3
4
5
6
7
8
9
xAI Colossus 10 万 H100：
  - Rail-Optimized + IB
  - 8 Rail × Pod
  - 多个 Pod 用 Aggregation 互联
  - 总规模 10万 GPU = 12500 节点

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

网络收敛比（oversubscription）

1
2
3
4
5
6
7
8
9
10
11
12
Leaf 上行带宽 / Leaf 下行带宽 = 收敛比

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

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

一些查询命令

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# 看路由表
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
2
3
4
5
6
1. 收敛比：     性能 vs 成本
2. 跳数：       延迟 vs 规模
3. 端口密度：    交换机数量 vs 容量
4. 可扩展性：    增量扩 vs 重新设计
5. 故障域：     大故障域 vs 复杂控制面
6. 布线：       单模 vs 多模 vs DAC，距离

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

实战清单

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
1. 规划阶段：     
   - 确定服务器数量和增长曲线
   - 算 East-West 流量峰值
   - 选拓扑（Spine-Leaf / Fat-Tree / Rail-Optimized）
   - 定收敛比
   - 选交换机芯片（Tomahawk / Tofino / Spectrum）

2. 实施阶段：
   - 布线工程量大（万级线缆）
   - 光模块采购周期长（半年起）
   - 调通 BGP / EVPN / VXLAN
   - PFC/ECN 调优（RoCE 集群）

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

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