1 数据中心网络架构要回答什么
机房里新增了备份进程，服务器网卡显示 25 Gbit/s，文件系统也有足够空间，可备份窗口仍然从 40 分钟延长到 90 分钟。与此同时，另 1 台主机向附近服务器复制文件却很快。值班人员首先需要解释的，是这些主机之间究竟共享了哪些网络资源。网卡速率描述服务器连接交换机的能力，不能单独说明文件从源主机到目标主机时，每段链路是否都有同样的余量。
数据中心网络架构研究服务器怎样接入、交换机怎样互联，以及业务流量与故障怎样穿过这些连接。它要回答几个可以落在图纸上的问题：任意 2 台服务器之间经过哪些设备；同机架和跨机架通信是否使用不同资源；多个进程同时传输时在哪里争用；某条链路或某台设备失效后，还剩多少可用容量。只画设备数量，没有链路速率、流量方向和故障边界，不能支持这些判断。
先把 1 次真实通信放到架构图上。源服务器上的备份进程读取文件，通过套接字把数据交给操作系统网络栈，数据从网络接口发出，经过交换机到达目标服务器，再由接收进程写入文件系统。文件读写、进程处理和网络传输都可能限制速度。本课只建立网络织物的空间关系与容量直觉；遇到慢传输时，仍要保留磁盘繁忙、进程限速、CPU 忙等备选解释。
这里的网络织物，是交换设备及其互连组成的转发网络。它不是 1 条具有统一速率的虚拟电缆。不同流量走不同路径，共享不同链路；同样大小的文件，跨机架复制可能比同机架复制多经过若干设备。理解架构的意义，是把“网络很慢”改写成可查证的描述，例如“机架 A 到机架 B 的多个复制任务同时使用 A 的上行，而 A 内部的复制未明显变慢”。
画图时先给服务器、交换机和接口起稳定的名字。后文使用 H-A、H-B、H-C 表示主机，L1、L2 表示叶交换机，S1、S2 表示脊交换机；这些 S1、S2 是设备标签，与课程编号无关。记录主机接口名，例如 ens5，并把它对应到叶交换机的具体接入口。操作系统中的接口名称不能直接推出机架位置，这个对应关系来自布线记录和资产信息。
2 CLOS、Spine-Leaf 与东西向
传统层次图容易让人把所有通信都想成逐级向上汇聚。数据中心里却有大量服务器互访：计算节点读取存储、备份节点接收数据、集群成员交换状态。这类数据中心内部的横向通信通常叫东西向流量；数据中心内部与外部网络之间的通信通常叫南北向流量。它们是位置和用途的描述，不是交换机端口上的固定方向，也不表示东西向流量永远不经过上行。
Clos 是通过多个较小交换单元构造多级互连网络的思路。Spine-Leaf，也就是叶脊结构，是数据中心中常见的组织方式。服务器连接叶交换机，叶交换机再连接多台脊交换机。在本课采用的简化结构里，每台叶交换机连接每台脊交换机，叶之间没有直接连线，脊之间也没有直接连线。真实部署可能增加边界设备或采用更多级结构，阅读现场图时应以实际连线为准。
假设 H-A 和 H-B 都接在 L1，H-C 接在 L2。H-A 向 H-B 传输时，通常可以在 L1 内完成转发，不使用叶到脊的链路。H-A 向 H-C 传输时，则可能走 H-A → L1 → S1 → L2 → H-C，也可能经过 S2。这样，跨机架通信在拓扑上具有相近的路径层数，扩容时也有相对清晰的连接规则。路径层数接近，并不保证所有通信的实际延迟相同。
多个可选路径如何被使用，需要区分“存在路径”和“流量分布”。网络可能使用等价多路径，把不同连接分配到不同的可用路径。入门时可以把它理解成：多条连接有机会分散走，多条上行可以共同承担总流量。但不能因此断言 1 条文件传输连接会平均使用所有上行。具体分配依赖设备能力和配置，本课不展开路由协议与分配算法。
这也解释了为什么测试要同时包含单连接和多连接。某条连接的速度可能受选中路径限制；多条连接的总吞吐可以帮助观察共享上行的利用情况。反过来，多连接总吞吐较高，也不能证明任意 1 条连接都能获得同样速率。测量报告应写明连接数、通信双方、测试方向和持续时间，否则“带宽达到要求”缺少明确含义。
阅读叶脊图时，可以先用手指沿数据方向走完整条路径，再圈出每段共享资源。不要只沿叶到脊的箭头走到一半：目标叶的下行、目标主机的接口及接收能力同样会限制传输。架构图中的箭头用于展示这次传输的方向，物理链路通常仍能双向通信；讨论容量时，应明确比较的是哪个方向。
3 超订阅与故障域边界
假设 L1 有 8 台服务器，每台以 25 Gbit/s 接入，接入侧标称速率合计为 200 Gbit/s。L1 向脊层提供 2 条 50 Gbit/s 上行，上行合计为 100 Gbit/s。若这 8 台服务器都要向其他机架发送数据，接入侧的潜在需求就是上行容量的 2 倍。我们把这个容量关系写成 2:1 超订阅，也常称过订阅。这里的比值是接入侧标称容量除以上行容量。
计算前必须说明口径：统计哪些接入口、哪些上行、哪个方向，以及设备是否存在其他转发限制。200 ÷ 100 = 2 只描述这组链路的标称关系，实际业务可能远未达到 200 Gbit/s。若大部分数据在 L1 内交换，它们就不消耗 L1 的跨机架上行。因此，超订阅比不等于当前拥塞程度，也不意味着所有服务器的速率会始终按固定比例下降。
容量还有时间维度。8 台主机平时各发送 2 Gbit/s，合计 16 Gbit/s，100 Gbit/s 上行可能很宽裕；定时任务同时启动后，各自尝试发送 15 Gbit/s，合计 120 Gbit/s，就超过了该方向的上行总容量。持续需求超过供给时，数据可能排队，排队空间耗尽时可能丢弃，发送端也可能降低发送速度。短时突发即使未明显改变分钟平均值，也可能影响延迟。
故障域表示某个故障可能影响的范围。L1 的 1 条上行失效，剩余 50 Gbit/s 的连接也许仍能到达所有目标，但容量关系变成 4:1。若 L1 整台设备失效，在本课的单叶接入结构中，接在 L1 上的服务器都会受到影响。若 S1 失效，多台叶交换机可能同时损失部分上行能力。设备层级相似，影响对象和范围却不同，不能统一写成“有冗余，所以无影响”。
故障域还与共同依赖有关。图上画着 2 条链路，如果它们共用同一块接口板、同一供电路径或同一段易受损线缆通道，实际独立性可能比图上看起来弱。入门方案不必穷举设备内部结构，但应标注已经确认的共同依赖，以及尚未确认的部分。逻辑上有 2 个选择，不自动等于物理上有 2 个独立保障。
这里要分别提出连通性目标和性能目标。连通性目标可以是“任意 1 条上行故障后，跨机架通信仍可达”；性能目标可以是“该状态下，备份汇总流量仍不超过预留的容量预算”。前者成立并不推出后者成立。维护时主动关闭链路，也会进入类似的降容状态，因此故障容量预算同样适用于日常检修窗口。
4 动手：画一张叶脊转发路径
先在纸上或绘图工具中放置 H-A、H-B、H-C、L1、L2、S1、S2。把 H-A 和 H-B 接到 L1，把 H-C 接到 L2，然后让 L1、L2 分别连接 S1、S2。在服务器接入线上标注 25 Gbit/s，在叶脊线上标注 50 Gbit/s。旁边留出“正常状态”和“S1 相关路径不可用”这 2 个状态，分别画出 H-A 到 H-C 的候选路径。
接着把图纸与主机证据关联。在 Linux 上执行以下只读命令，记录接口、地址、路由选择和链路计数。示例中的目标地址用于文档说明，现场应替换为获得授权的目标主机地址；接口名也应替换为实际名称。
ip -br addr
ip route get 192.0.2.30
ip -s link show dev ens5ip -br addr 帮助确认地址属于哪个接口；ip route get 显示本机对该目标选择的出口、源地址及可能的下一跳；ip -s link 提供接口收发与错误等计数。这里的“下一跳”只是主机视角的路由结果，不能据此把交换机内部的全部物理路径画出来。网络采用不同的主机接入方式时，结果可能不同，应记录输出事实，再解释它对应图上的哪个位置。
如果需要观察中间响应，可在环境允许时使用 tracepath -n 192.0.2.30。部分节点可能不响应，交换网络也可能隐藏部分物理设备，缺少某跳响应不能直接判定那里发生故障。路径探测提供的是有限线索；叶脊连线及实际承载路径，仍需结合布线资料、设备端口计数和网络侧提供的信息确认。不要把探测输出强行补成想象中的完整拓扑。
若已安装吞吐工具，并有受控测试窗口，可以在目标主机启动 iperf3 -s，在源主机执行 iperf3 -c 192.0.2.30 -t 10，再使用 -P 4 比较多连接总吞吐。服务端需要对应端口可达，测试流量会占用真实容量，应限制范围并在结束后停止测试进程。这里给出的命令用于说明测量方式，无需在繁忙生产网络上照搬执行。
把同叶与跨叶测试结果分别标到图上，并写下时间。主机端能看见出口和端到端结果，交换机端口能帮助确定共享链路是否接近容量。若只能获得主机数据，结论应保留边界，例如“跨叶传输更慢，怀疑共享上行，尚缺设备计数”。这比直接写“脊交换机故障”更有助于后续协作，也避免把架构推测当成现场事实。
5 成本与无阻塞取舍
降低超订阅通常需要更多上行容量。对于 200 Gbit/s 的接入总量，100 Gbit/s 上行对应 2:1，200 Gbit/s 上行对应 1:1。增加容量会占用叶交换机和脊交换机的端口，还可能增加光模块、线缆、供电与维护成本。如果脊侧没有空余端口，仅给叶侧购买模块也无法完成连接。成本要沿完整链路核算，不能只比较某个端口的单价。
“无阻塞”需要明确讨论的范围与条件。某台叶交换机的接入总量与上行总量相等，只能说明这一处标称容量达到 1:1。目标侧汇聚、设备转发能力、路径分配和主机收发能力仍可能构成限制。若许多发送端同时把数据发给 1 台 25 Gbit/s 主机，目标接入口依然只有 25 Gbit/s；不能因为织物上行充足，就承诺所有发送端都保持接入线速。
用同一个例子比较方案：8 台服务器各有 25 Gbit/s 接入，每条叶脊链路为 50 Gbit/s。配置 2 条上行时，正常总容量是 100 Gbit/s，失去 1 条后剩 50 Gbit/s；配置 4 条上行时，正常是 200 Gbit/s，失去 1 条后剩 150 Gbit/s。即使正常状态为 1:1，故障状态也不再是 1:1。容量冗余和路径冗余相关，却必须分别计算。
合理的选择取决于工作负载。多数数据在同叶内交换、跨机架任务可错峰时，适度超订阅可能满足目标。大量服务器需要长期跨机架交换数据时，上行容量的重要性就更高。把存储进程迁到其他机架，还可能让原本留在叶内的数据开始经过脊层。因此，服务器数量没有增长，也不代表网络需求没有变化；进程部署位置和文件分布会改变流量矩阵。
流量矩阵可以先做得简单：按源机架、目标机架、峰值需求、持续时间和并发时段记录。无需为每个数据包建立模型，只要找出哪些任务共享同一出口、是否会同时启动，就已经能支持入门容量讨论。还应给观测误差和未来增长留出余量，避免把“测得最高需求”当作永远不会超过的上限。
方案讨论应把硬件扩容与运行安排放在同张表里。增加上行能够提升可用容量，错开批量任务可以降低同时需求，调整数据放置可能减少跨机架流量。这些措施解决的问题和代价不同。错峰依赖调度纪律，数据迁移可能引入新的集中热点，扩容则受端口和布线条件约束；应根据业务窗口与运维能力选择，并写清成立条件。
6 常见坑：把接入带宽当织物能力
最常见的误读，是看到服务器接口标称 25 Gbit/s，就在机房方案里写“每台服务器随时拥有 25 Gbit/s 跨机架能力”。接入速率只是路径上的 1 个上限，多台主机共享的上行才可能决定并发总量。即便某台主机独占时测得很快，也不能说明 8 台主机同时发送时仍各自拥有同等带宽。承诺应对应明确的通信范围和并发条件。
另一个误读是只看双向合计数字。全双工链路可以同时收发，但某个方向尚有空闲，并不能抵消另一个方向的拥塞。备份汇聚常表现为许多源向少数目标发送，反向只有较少控制流量。检查端口时要分别看发送和接收，并确认从哪台设备的视角命名；叶交换机上行口的发送，对脊端对应口来说就是接收。
平均值也容易隐藏问题。监控面板显示 5 分钟平均利用率 40%，不表示其中任何 1 秒都只有 40%。短时并发可能造成排队和丢弃，随后流量下降，平均值仍显得温和。开始排查时可以提高采样频率并对齐任务启动时间，但不要因此断言所有短时延迟都是网络突发。主机磁盘排队和进程暂停同样需要检查。
读计数器还要区分累计值和区间变化。ip -s link 中出现历史丢弃，不能证明刚才的传输发生了同样的问题。应在测试前后取样，比较增量，同时保留采样间隔、接口重置及主机重启信息。交换机端口的丢弃计数也要确认含义，不同位置的计数对应不同事件；主机接口没有丢弃，不能推出中间交换机没有丢弃。
文件复制速度同样不能直接换算成织物能力。复制过程可能受到源文件读取、目标文件写入、加密处理、进程配置等限制。ss -tin 可以提供 TCP 连接状态及部分连接指标，iostat -xz 1 5 在已安装相关工具时可以帮助观察磁盘活动；它们用于排除或支持具体假设，不能单凭某个字段给网络定责。真实判断要让路径、时间和多处证据互相对应。
最后，不要把“有 2 台脊”当成性能保证。2 台设备可能只有部分链路可用，也可能有流量集中在某条路径。架构提供可用选择，配置和运行状态决定当前能使用哪些选择。现场记录应同时包含设计图和当前链路状态，尤其是在维护、扩容或故障恢复期间；拿正常设计容量解释降容时段，会系统性低估拥塞风险。
7 案例：上行过订阅导致东向拥塞
某机架有 8 台 Linux 主机，每台以 25 Gbit/s 接入 L1。L1 通过 2 条 50 Gbit/s 链路连接脊层。每天夜间，8 个备份进程把本地文件发送到其他机架的多个接收节点。备份目标分散，目标机架和接收主机均有足够余量。平时任务开始时间错开；脚本调整后，它们在 02:00 同时启动，跨机架传输速度明显下降，而机架内的小规模文件复制仍接近平时水平。
值班人员先确认故障时间和影响范围，再检查任务日志、主机出口与磁盘活动。各备份进程同时进入发送阶段，源文件读取能够持续供给，接收端也没有明显写入瓶颈。ip route get 显示源主机仍使用预期出口，接口未发生重置。这些结果尚不足以证明上行拥塞，但已经把问题集中到共同时间窗口内的跨机架路径上。
网络侧在同一时段观察 L1 的 2 个上行发送计数，发现总发送接近可用的 100 Gbit/s，并且相关端口出现新增队列丢弃。多台源主机的 TCP 连接出现重传迹象，端到端有效吞吐下降。备份任务尝试提供的总需求约为 120 Gbit/s，超过这组上行容量。主机证据、设备计数与拓扑中的共享出口相互吻合，才形成“上行过订阅在该时段导致拥塞”的判断。
这里不能把主机上报的发送字节简单相加当作有效文件量，因为其中可能包含重传和其他业务流量。也不能把端口达到高利用率单独当作故障：链路被充分使用，本身可能是预期行为。真正需要解释的是，在既定完成时限下，排队、丢弃和传输耗时是否超出目标，以及它们是否与同一组共享资源相关。
短期处理是恢复错峰，让同一时段启动的任务数量受控，并观察备份能否在窗口内完成。长期可以增加上行容量，或重新安排备份目标与数据位置。变更前应确认脊端口余量和目标侧容量，变更后按相同源、目标、连接数与持续时间复测。若只更换测试对象，即使结果变快，也难以判断是不是扩容产生了效果。
接着考虑维护状态：若其中 1 条上行因检修不可用，剩余只有 50 Gbit/s，原先可接受的错峰安排也可能再次超限。此时应降低并发或调整窗口，并把降容状态写入值班交接。路径恢复后还应确认链路与流量分布都恢复正常；设备显示端口已开启，只能证明某个状态，不能单独证明完整性能已经回到基线。
这起案例的关键不是背住 2:1，而是识别“谁同时争用什么”。如果只有 1 台目标主机成为瓶颈，扩容 L1 上行可能没有明显帮助；如果源磁盘供给不足，上行甚至无法接近容量。排查时每排除或支持 1 个假设，都应说明证据来自哪里，以及还缺什么，避免被初始架构判断锁住视线。
8 把织物假设写进机房方案
机房方案中的网络章节，应从流量需求与可验证的承诺开始。先写服务器如何分布到机架、哪些进程需要互访、文件主要在哪里读写，以及高峰任务会持续多久。再把这些需求映射到接入端口、叶脊链路和目标侧出口。这样，评审者才能从业务并发推导容量，而不是从设备清单猜测工作负载。
建议用容量表记录正常与降容状态。至少包括接入总量、可用上行、超订阅比、预计跨机架需求和允许的运行安排。比如正常上行 100 Gbit/s，预计同时需求 80 Gbit/s；失去 1 条上行后只有 50 Gbit/s，就必须说明降容期间是否暂停部分任务。80 Gbit/s 是本方案的需求假设，不是网络天然提供的保障，应注明它来自测量还是估算。
故障边界也应写成对象与影响的关系。上行链路故障影响该叶的部分跨机架容量，叶设备故障影响它所接入的主机，脊设备故障可能影响多台叶的可用路径。主机若采用单接口、单叶接入，就应明确其接入故障边界。不能在图中暗示存在尚未部署的双接入，也不应在入门方案中用含糊的“自动切换”替代实际验证。
验收计划需要覆盖不同位置和不同状态。可以选择同叶通信、跨叶通信、受控并发，以及获准维护窗口内的单路径退出。每类测试写明目标、方法、持续时间和通过条件，并同步记录主机与交换机计数。故障演练应由负责网络的人员按既定变更流程执行；应用侧观察人员负责对齐任务与测量时间，不能随意拔线制造现象。
还要给方案留下更新入口。增加服务器、迁移文件存储、调整备份脚本、减少可用上行，都会改变原先假设。可以把机架图、容量表、监控看板和任务配置的版本建立关联，在变更评审时检查受影响的共享出口。文档的价值不在于写过“采用叶脊结构”，而在于现场变化后，值班人员仍能找到当前容量和限制条件。
9 从数据中心网络架构走向网络排障（S50）
学完架构后，看到“连接慢”应先问通信发生在哪里。源和目标同叶还是跨叶，是否集中到同一目标，问题只在某个时间窗口出现，还是所有路径都受影响？这些问题把抽象拓扑变成排查范围。若同叶正常而跨叶普遍变慢，共享上行值得优先检查；但它只是优先级判断，还需要链路状态和计数支持。
接下来的网络排障将继续建立从现象到证据的顺序。先确认是无法连接、间歇失败还是吞吐下降，再确认地址与本机出口，随后检查相关路径与对端状态。本课中的 ip、ss 和端口计数提供了切入点；不需要提前展开内核协议栈、驱动或动态路由协议细节，也能先把时间、位置和影响范围讲清楚。
把记录写到其他人能够接手的程度。例如：“02:00—02:10，L1 下 8 台主机向其他机架备份；同叶复制基线无明显变化；L1 上行合计接近 100 Gbit/s，相关端口丢弃出现增量；目标磁盘未见相应繁忙。”这段记录同时包含现象、对照与证据。若某项尚未检查，就直接标记未检查，不用“应该正常”填补空白。
还应区分观测和解释。“备份耗时增加”是现象，“上行发送接近标称容量”是观测，“共享上行不足”是解释，“错峰后耗时恢复”是干预结果。解释会随着新证据修订，原始观测则应保留。这样的记录方式让后续排障能够复用本课架构图，又不会被架构图中的某个猜想提前限制结论。
可以用 3 个问题检查自己的理解：为什么单台主机的 25 Gbit/s 接口不能保证所有主机同时跨机架达到该速率？为什么链路故障后仍然可达，却可能无法按时完成备份？为什么同叶正常只能帮助缩小范围，不能单独证明脊层存在故障？回答时都应指出共享资源、容量状态及需要补充的证据，再进入 S50 的具体排查方法。
放进方案里
本机房采用叶脊互连，服务器按机架接入叶交换机，叶交换机连接多个脊交换机。设计图标注主机接口、接入口、叶脊链路速率及设备位置，并与布线记录关联。业务侧提供源机架、目标机架、并发任务数、预计峰值和持续时间，作为容量测算依据；存储位置或任务时刻变更时，重新评估跨机架需求。
示例机架配置 8 个 25 Gbit/s 接入口和 2 条 50 Gbit/s 上行，接入标称总量为 200 Gbit/s，正常上行总量为 100 Gbit/s，超订阅比为 2:1。该比值描述单方向的容量关系，不代表每台服务器的持续可得带宽。正常运行时，计划跨机架并发需求控制在 80 Gbit/s 以内，并通过实际测量确认完成窗口。
失去 1 条上行后，可用上行降为 50 Gbit/s，超订阅比变为 4:1。降容期间通过限制备份并发，将计划需求控制在 40 Gbit/s 以内；若无法满足，应调整任务窗口。服务器采用单叶接入时，叶设备故障会影响所接服务器的连通性，方案明确接受该边界，不将上行冗余等同于主机接入冗余。
验收覆盖同叶、跨叶、受控并发和授权维护窗口内的路径退出，记录测试方向、连接数、持续时间及通过条件。同步采集主机接口增量、连接状态、磁盘活动和交换机端口利用率与丢弃增量，以区分织物限制和主机限制。监控按方向展示数据，并对齐任务启动时间，保留能够观察短时变化的采样。
运维交接包含当前拓扑、正常与降容容量表、任务错峰规则、监控入口和责任人员。扩容前核对叶侧与脊侧端口、模块、布线和供电条件，变更后使用相同条件复测。所有性能承诺注明测量范围及成立假设，需求超过预算时先调整运行安排或扩充容量，再更新方案版本。
10 小结：下一步网络排障（S50）
叶脊结构让跨机架路径更容易描述，多条路径提供容量与故障后的替代选择。理解它时，要同时看接入、共享上行、目标侧和正常及降容状态。接口速率、路径存在与端到端性能分别回答不同问题，需要在具体并发条件下建立联系。
进入 S50 前，保留 1 张带速率的拓扑图、1 份正常与降容容量表，以及 1 组对齐时间的主机和设备证据。下一步将用这些材料，把无法连接、偶发失败与传输缓慢转化为有顺序、可复核的网络排障过程。