四、网络配置与优化：InfiniBand、RoCE、VPC 网络设计，MTU 与流控
网络，可以说是 HPC 云环境的高速公路。路修得不够宽、不够平，车就跑不起来。这一章，我们聊聊怎么规划这条“高速公路”。
我这些年经手过不少集群，坦白讲，大多数性能瓶颈其实都卡在网络这儿。CPU 算力堆上去了，GPU 也到位了，结果一跑分布式训练，节点间的通信延迟直接把算力“吃掉”一大截。所以，网络配置与优化，是 HPC 质控里绕不开的硬骨头。
4.1 三大网络方案选型：IB 还是 RoCE，抑或 VPC？
目前主流的 HPC 网络方案有三种：InfiniBand (IB)、RoCE (RDMA over Converged Ethernet)、以及云原生 VPC。选哪个，取决于你的业务场景和预算。
我个人习惯把 IB 比喻成 HPC 的“专用超车道”，RoCE 是“升级过的国道”，而 VPC 就是云上的“智能导航路网”。
| 特性 | InfiniBand (IB) | RoCE (RoCEv2) | 云原生 VPC (如 EFA) |
|---|---|---|---|
| 传输层 | 专用 IB 链路层 | 基于 UDP (以太网) | 虚拟化 Overlay 网络 |
| 延迟 | < 1.5μs（节点内） | ~ 3-5μs | ~ 10-20μs（典型值） |
| 带宽 | 200Gbps/400Gbps (HDR/NDR) | 100Gbps/200Gbps | 100Gbps (云提供商限定) |
| 成本 | 高（专用硬件） | 中（兼容标准以太网） | 中低（随用随付） |
| 适用场景 | 高并发 MPI、超大规模 AI 训练 | 中小集群、混合 RDMA 需求 | 云端弹性伸缩、传统 TCP 迁移 |
避坑指南：我曾见过一家公司为了省钱，20 个节点的集群全上了 RoCE。结果跑了两个星期，频繁丢包，性能比 TCP 还差。后来排查发现，他们的交换机根本没开 PFC（优先级流控）。说白了，RoCE 对交换机的要求并不比 IB 低多少。
4.2 VPC 网络设计：Underlay 与 Overlay 的博弈
在云环境里，VPC 设计直接决定了网络拓扑的灵活性和性能。核心在于如何平衡 Underlay（物理网络）和 Overlay（虚拟网络）的关系。
我建议遵循以下原则：
- 弹性 IP 与直通模式：千万别给 HPC 节点配 NAT 实例。直接用弹性 IP + 专有网络，减少 NAT 带来的转发延迟和 CPU 开销。
- 单个 VPC vs. 多个 VPC：如果是百节点以内的集群，一个 VPC 足够。异地多活或跨可用区时，才考虑 VPC Peering 或 Transit Gateway。你想想看，跨 VPC 通信多一次隧道封装，延迟就多一跳。
- RDMA 需要独立子网：云平台通常在 VPC 内部划出一个 RDMA 子网，用于 EFA 或 SR-IOV 直通。这个子网不经过虚拟交换机，直接挂载物理网卡。
技巧：在阿里云或 AWS 上创建 HPC 集群时，记得选择“计算优化型”或“GPU 计算型”实例，并勾选“弹性网卡 RDMA”选项。否则，默认的 VPC 网络连 RDMA 的边都摸不着。
4.3 InfiniBand 配置：从网卡到子网管理器
IB 网络的核心在于“通道适配”和“子网管理器”。
- 硬件层：确保所有节点安装了兼容的 HCA（主机通道适配器），如 Mellanox ConnectX 系列。
- 驱动与固件：同一个集群，必须统一驱动和固件版本。
- 子网管理器：必须有一台节点作为主管理器，负责路径计算和负载均衡。
配置 IB 的基本步骤：
# 1. 安装驱动程序
sudo yum install -y mlnx-ofed-kernel-dkms mlnx-ofed-user
# 2. 启动 OpenSM 子网管理器（在管理节点上）
sudo systemctl enable opensmd
sudo systemctl start opensmd
# 3. 检查 IB 链路状态
ibstatus
# 4. 查看 IB 网络中所有活动的节点
ibnetdiscover | grep -E "Switch|HCA"
# 5. 配置分区键（PKey），用于隔离流量
sudo ibsysstat -p注意事项：IB 环境里最忌讳的是“分区键不一致”。我曾经有一个集群，新加了几台机器后死活连不上，查了半天，原来是新机器的 PKey 和交换机定义的分区不匹配。
4.4 RoCE 调优：PFC、ECN 与 QoS
RoCE 虽然跑在以太网上，但性能全靠“无损”机制保障。没有 PFC 和 ECN，RoCE 就是一张普通的千兆网卡。
- PFC（优先级流控）：在交换机上启用，当接收缓存快满时，通知发送端暂停特定优先级的流量。
- ECN（显式拥塞通知）：交换机在包头上打标记，接收端感知后通知发送端降速。RoCEv2 必须配合 ECN 使用。
- QoS 队列：为 RDMA 流量分配最高优先级队列，防止它与普通 TCP 流量争抢带宽。
警告：如果交换机不支持 PFC/E CN，建议索性不要用 RoCE，直接走 TCP 或 InfiniBand。RoCE 在半损网络下会疯狂重传，产生“吞没效应”，拖垮整个集群。
在 Linux 主机端的配置示例：
# 1. 启用 ECN（需要内核支持）
echo 1 > /proc/sys/net/ipv4/tcp_ecn
# 2. 设置 RDMA 设备优先级
mlxconfig -d /dev/mst/mt4123_pciconf0 set ROCE_MODE=2
mlxconfig -d /dev/mst/mt4123_pciconf0 set ROCE_PRIORITY=3
# 3. 验证 RoCE 是否正常工作
ib_write_bw -d mlx5_0 --report_gbits4.5 MTU 与流控：被忽略的“隐形杀手”
很多人觉得 MTU 设成默认 1500 就行了。但在 HPC 网络里，这往往就是性能瓶颈的源头。
- MTU 九千字节（Jumbo Frame）：IB 和 RoCE 都强烈建议使用 9000 字节 MTU。同样的数据量，大帧能减少包数量、降低 CPU 中断开销。
- 流控模式：TCP 使用滑动窗口，而 RDMA 依赖硬件级的“基于信用的流控”。
- 缓冲区设置：网卡接收缓冲区太小，会导致丢包。
配置 MTU 的常用命令：
# 查看当前 MTU
ip link show eth0
# 修改 MTU 为 9000（需要端到端支持）
sudo ip link set dev eth0 mtu 9000
# 在 IB 设备上查看 MTU 限制
ibstat | grep MTU个人经验：我曾经遇到过一个集群，所有节点都配了 9000 的 MTU，结果跑 MPI 作业时频繁超时。查了一整天，最后发现是交换机的一个端口 MTU 设成了 1500。这就是典型的“木桶效应”——一个端口低，整个集群性能都受影响。
4.6 网络质控检查清单
在交付集群前，我习惯用下面这套流程做一次“网络健康体检”：
| 检查项 | 命令/工具 | 预期结果 |
|---|---|---|
| IB 链路状态 | ibstatus |
所有 HCA 处于 ACTIVE 状态 |
| 端到端延迟 | ib_write_lat |
节点间延迟 < 2μs |
| RoCE 丢包率 | ethtool -S eth0 | grep rx_no_buffer |
丢包为 0 |
| MTU 一致性 | ping -M do -s 8972 target_ip |
不丢包、不分片 |
| 子网管理器健康 | smctest -c |
返回 OK |
小技巧：在写测试脚本时，把每项检查的结果都记录到一个日志文件中。一旦出现问题，对比前后两次的日志，能快速定位到是哪个节点或哪个端口在漂移。我习惯把这个脚本叫做 hpc_net_qc.sh ，每次扩容或升级后都跑一遍。
#!/bin/bash
# 简易网络质控脚本片段
for node in $(cat nodes.txt); do
echo "Checking $node..."
latency=$(ssh $node "ib_write_lat -d mlx5_0 --report_gbits 2>&1 | tail -1 | awk '{print \$NF}'")
echo "Latency on $node: $latency us"
done这套流程走下来，基本上可以把网络层面百分之九十的问题挡在门外。最后说一句：HPC 网络调优，没有银弹。IB、RoCE、VPC 各有各的脾气，关键是理解它们的底层机制，再根据你的场景去微调。别偷懒，每个字段都理解清楚了再动手。