1. 数据中心网络容量规划导论

数据中心网络容量规划，是在业务需求、网络架构与硬件资源之间建立可量化映射关系的一门工程实践。它的核心问题不是“现在网络够不够快”，而是“在未来一段时间内，当流量规模、业务形态和故障场景发生变化时，网络还能否稳定承载”。因此，容量规划既包含对现有资源的度量，也包含对未来需求的预测，还包含对架构余量和失效冗余的验证。

从定义上看，容量规划是指：以业务流量模型和性能目标为输入，评估网络在链路、端口、交换芯片、缓冲区、路由表项、控制平面等维度的承载能力，并据此制定扩容、优化或架构调整方案的过程。它的目标通常包括四项：满足业务SLA、避免资源瓶颈、控制扩容成本、保证故障场景下的可用性。与性能工程相比，容量规划更关注“资源是否足够且分布合理”，性能工程更关注“在给定资源下系统表现如何”。两者互为输入输出：容量规划给出资源基线，性能工程验证该基线是否达标；性能测试暴露出的时延、丢包、抖动问题，又会反过来修正容量模型。

要理解容量规划，必须先理解典型数据中心网络架构。当前主流架构是 Spine-Leaf 与 CLOS。Spine-Leaf 是一种两层 CLOS 变体：Leaf 交换机连接服务器和存储，Spine 交换机只连接 Leaf，不直接接服务器。任意两台服务器之间的通信路径为“源 Leaf → 任一 Spine → 目的 Leaf”，通常最多两跳。这种架构的关键价值在于：东西向流量不再经过核心层逐级收敛，任意 Leaf 之间都有多条等价路径，带宽可以水平扩展。

CLOS 的本质是“用多级小规模交换单元构建大规模无阻塞网络”。在数据中心里，常见的是两级 CLOS，即 Spine-Leaf。若 Leaf 数量为 L，Spine 数量为 S，每台 Leaf 上行端口数为 U，则网络总收敛比可近似表示为：收敛比 = (Leaf 下行端口总带宽) / (Leaf 上行端口总带宽)。例如，一台 Leaf 有 48 个 25G 下行端口和 8 个 100G 上行端口，下行总带宽为 48×25G=1200G，上行总带宽为 8×100G=800G，收敛比约为 1.5:1。若希望做到无阻塞，则需满足上行总带宽不小于下行总带宽，即 8×100G ≥ 48×25G，此时需要至少 12 个 100G 上行端口，或改用 400G 上行端口。

架构对容量规划的影响非常直接。第一，Spine-Leaf 的等价多路径意味着容量不是单条链路容量，而是“Leaf 到 Spine 的可用路径集合容量”。规划时必须同时考虑单链路带宽、链路数量、哈希分布和故障后剩余带宽。第二，CLOS 的可扩展性由 Spine 端口数和 Leaf 上行端口数共同决定。Spine 数量不足会限制 Leaf 间带宽；Leaf 上行端口不足会限制单台 Leaf 的收敛能力。第三，架构决定了扩容粒度：增加一台 Leaf 通常增加接入容量，增加一台 Spine 通常增加骨干容量，两者不能互相替代。

容量规划在业务连续性中的角色，可以概括为“提前发现不可用风险”。业务连续性要求网络在计划内维护和计划外故障时都能维持可接受的服务水平。容量规划通过三类分析支撑这一目标：一是正常态余量分析，确保峰值流量下链路利用率不超过阈值；二是故障态分析，计算单 Spine、单 Leaf 或单链路失效后剩余容量是否仍能满足业务；三是增长趋势分析，判断当前余量还能支撑多久，从而安排扩容窗口。

以一条常见判断为例：某 Leaf 上行 8×100G，正常运行峰值利用率约 55%。若一台 Spine 故障，流量会重新哈希到剩余 Spine。若剩余 7 条上行链路，则单链路平均利用率约为 55%×8/7≈62.9%，仍在可接受范围；若峰值利用率已达 75%，则故障后约为 85.7%，接近拥塞风险区。这个简单计算说明：容量规划不能只看正常态，还要看故障后的“剩余容量”。

实际开展容量规划时，通常先建立流量基线：采集 Leaf 上行端口、Spine 下行端口和关键业务路径的入出向速率，按 5 分钟或 1 分钟粒度统计峰值与 95 分位值。然后建立容量模型：记录每台 Leaf 的下行端口数、上行端口数、单端口速率、收敛比，以及每台 Spine 的端口数和当前连接关系。接着做场景推演：正常峰值、单链路故障、单 Spine 故障、新增业务上线。最后输出扩容建议：是增加 Leaf 上行端口、增加 Spine 数量，还是调整流量路径与哈希策略。

需要强调的是，容量规划不是一次性任务。业务流量会随版本发布、数据迁移、AI 训练任务和存储复制策略变化而改变。建议至少每季度复核一次基线，在重大业务上线前做专项推演。只有把架构关系、流量数据和故障场景放在同一张图里看，容量规划才能真正服务于业务连续性，而不是停留在“端口还空着”的直觉判断上。