无收敛通常表示某层下联总带宽可以由上联和交换结构承接，但真正设计还要考虑流量方向、路径散列和链路或设备故障。不能只比较端口速率之和，应从节点通信矩阵逐层计算正常、维护和故障状态的可用容量。
从节点规模形成端口模型
记录每个节点的网络接口数量、速率、Rail 关系和目标节点数，计算每台 Leaf 的下联端口与总带宽。再根据目标收敛比确定上联数量，并检查 Spine 端口能否覆盖全部 Leaf。扩容节点、备用端口和新机柜应在初始表中单独体现。
总带宽之外还要检查路径
等价多路径依赖流哈希，少量大流可能无法平均分散到所有链路。集合通信模式、Rail 绑定和作业放置也会改变流量分布。应使用代表性消息大小和并发作业测试各上联利用率，识别局部热点而不是只观察全网平均。
故障状态决定是否真正可用
模拟单上联、单 Leaf、单 Spine 和计划维护，计算剩余路径和带宽，并明确受影响的节点范围。若无收敛只在所有设备正常时成立，应在容量表中写出故障后的实际收敛比和业务降级策略。
项目核验要点
- 容量表覆盖当前规模、目标规模和至少三类故障状态。
- 核对 Leaf 与 Spine 两侧端口数量、速率和介质距离。
- 用并发集合通信检查路径分布与局部拥塞。
- 将扩容所需机柜、电力、光纤和管理地址一并预留。
架构评审应能从任意一个计算节点追溯到端口、Leaf、Spine 和故障域。若容量结论不能落到这条路径上，“无收敛”就只是标签，而不是可验收的设计。
WeChat
Profile