第二章：IB网络拓扑——胖树、DragonFly+、环状与故障的博弈

聊到InfiniBand网络，拓扑结构是绕不开的话题。说白了，拓扑决定了你的数据怎么走，也决定了故障来了你有多疼。我这些年经手过的IB网络项目，从几百节点的小集群到上万节点的大规模HPC，拓扑选型几乎每次都成了争论焦点。

今天我就把三种主流拓扑——Fat-Tree、DragonFly+、Torus——掰开揉碎讲清楚。嗯，顺便聊聊拓扑选择对故障的影响，这部分我踩过的坑不少。

一、Fat-Tree拓扑结构

Fat-Tree，也叫胖树。这是目前数据中心里最常见的拓扑，没有之一。为什么？因为它简单、对称、好理解。

它的核心思想是：越往上走，带宽越宽。你想想看，叶子层的交换机连接计算节点，往上汇聚层、核心层，每一层的链路数逐渐增多，保证无阻塞通信。

我在项目中遇到过一件事。有个客户搭建了256节点的集群，用了标准的Fat-Tree。一开始跑得挺好，直到有一天某个核心交换机端口坏了。你猜怎么着？整个集群性能直接掉了30%。因为Fat-Tree的故障容错依赖于冗余路径，但如果冗余路径不够，或者ECMP哈希不均匀，故障影响会被放大。

二、DragonFly+拓扑结构

DragonFly+，这个名字听起来就很酷。它是Cray（现HPE）搞出来的，专门针对超大规模HPC场景。我最早接触它是在一个5000节点的项目上，当时被它的设计思路惊艳到了。

DragonFly+的核心是“分组+全局链路”。每个组内是全互联，组与组之间通过少量全局链路连接。这样做的好处是：跳数少，延迟低。

举个例子：在Fat-Tree里，两个节点通信可能需要经过3跳甚至更多。但在DragonFly+里，大部分流量在组内就解决了，跨组通信最多2跳。嗯，这对延迟敏感的应用简直是福音。

为什么会这样？因为DragonFly+的设计哲学是“用少量长链路换低延迟”。代价就是，这些长链路成了单点故障的放大器。我建议你在部署DragonFly+时，一定要做全局链路的冗余设计，至少1:1备份。

三、Torus拓扑结构

Torus，环状拓扑。这个在传统HPC里用得很多，比如IBM Blue Gene系列。它的结构像是一个多维网格，每个节点只和邻居相连，首尾相连形成环。

Torus的好处是：布线简单，成本低。坏处是：跳数多，延迟高，而且故障传播很麻烦。

我记得有一次，一个客户用了3D Torus，规模是8x8x8=512节点。某个中间节点的链路断了，结果导致整个环上的流量都要绕路。最远的两个节点通信，跳数从原来的12跳变成了24跳。性能直接腰斩。

Torus适合对成本敏感、对延迟不敏感的场景。但如果你跑的是MPI All-to-All这类通信密集型应用，我劝你慎重。

四、拓扑选择对故障的影响

这部分是我最想说的。拓扑选型直接决定了故障的“杀伤半径”。

拓扑类型	故障影响范围	恢复难度	典型场景
Fat-Tree	局部（单条路径失效）	低（ECMP自动切换）	中小集群、通用计算
DragonFly+	组间（全局链路故障影响大）	中（需冗余设计）	超大规模HPC、AI训练
Torus	全局（环上所有节点受影响）	高（需自适应路由）	低成本集群、特定HPC

我个人习惯是：先看应用场景，再看预算，最后选拓扑。别一上来就追DragonFly+，觉得它高大上。如果你的集群只有200节点，Fat-Tree完全够用，而且故障处理起来简单得多。

另外，我建议你在设计阶段就做好故障演练。我曾经在一个DragonFly+集群上模拟过全局链路故障，结果发现自适应路由的收敛时间长达30秒。30秒啊，对于HPC作业来说，这已经是灾难了。

五、知识体系图

下面这张图是我自己整理的，把三种拓扑的核心逻辑和故障影响串起来了。你一看就明白。

这张图把三种拓扑的核心特征和故障影响范围做了对比。你仔细看，Fat-Tree的故障影响是局部的，DragonFly+是组间的，Torus是全局的。这个差异在选型时一定要想清楚。