📚 课程目录第4章 RDMA环境搭建

4. RDMA环境搭建：硬件选型、驱动安装、固件升级、网络配置与验证

RDMA（Remote Direct Memory Access）环境的搭建质量直接决定了后续所有诊断与调优工作的可行性与可信度。一个“带病上岗”的RDMA环境，往往会在高负载下暴露出令人困惑的间歇性故障——例如偶发的重传、链路降速或连接超时。本章从硬件选型、驱动与固件、网络配置到最终验证，梳理一套可复用的搭建流程，并指出常见误区。

4.1 硬件选型：从网卡到交换机的完整链路

RDMA并非仅靠一张网卡就能工作，它依赖端到端的硬件能力匹配。选型时需关注以下核心组件：

网卡（HCA/NIC）：优先选择支持RDMA的专用网卡，如NVIDIA（Mellanox）ConnectX系列、Intel E810等。需确认其支持的具体协议（RoCE v1/v2、InfiniBand或iWARP）。对于RoCE，务必选择支持DCQCN或类似拥塞控制算法的网卡。
交换机：RoCE v2要求无损以太网（Lossless Ethernet）支持，即交换机需启用PFC（优先级流控）和ECN（显式拥塞通知）。普通商用交换机若未正确配置，会导致RoCE流量因丢包而性能骤降。
服务器平台：PCIe通道数、CPU与内存带宽需匹配网卡速率。例如，100Gbps网卡至少需要PCIe 3.0 x16或PCIe 4.0 x8通道。
线缆与光模块：使用与网卡和交换机兼容的DAC/AOC或光模块，并检查线缆长度与信号完整性。

选型清单建议：在采购前，向厂商索取《RoCE互操作认证列表》，确保网卡、交换机、线缆三者在同一认证组合中。避免“单点验证通过，组合后异常”的尴尬局面。

4.2 驱动安装与固件升级：版本一致性是隐形基石

驱动和固件版本不一致是RDMA环境中最常见的“隐形杀手”。不同版本的驱动可能对RoCE拥塞控制算法、错误处理逻辑存在差异，导致同一套配置在不同节点上表现迥异。

4.2.1 驱动安装流程

确认当前系统与内核版本：uname -r 与 cat /etc/os-release。
从厂商官网下载对应版本的驱动包（如MLNX_OFED或NVIDIA Driver）。
安装依赖包并执行安装脚本。
使用 ibv_devinfo 验证驱动加载状态。

# 以Mellanox OFED为例
wget https://www.mellanox.com/downloads/ofed/MLNX_OFED-5.8-1.0.1.1/MLNX_OFED_LINUX-5.8-1.0.1.1-rhel8.8-x86_64.tgz
tar xzf MLNX_OFED_LINUX-*.tgz
cd MLNX_OFED_LINUX-*
sudo ./mlnxofedinstall --add-kernel-support --skip-repo
# 安装完成后重启或重新加载驱动
sudo /etc/init.d/openibd restart
ibv_devinfo | grep -E "hca_id|state|port"

4.2.2 固件升级的必要性

固件（Firmware）控制着网卡底层行为，包括RoCE的拥塞控制参数、错误检测机制等。厂商通常会针对特定交换机或拓扑发布固件修复。升级固件前，务必阅读Release Notes，确认是否影响现有配置。

固件升级风险提示：固件升级过程中不可断电或重启服务器，否则可能导致网卡变砖。建议在业务低峰期操作，并提前备份当前固件版本（mlxup --query 可查看当前版本）。

4.3 网络配置：RoCE v2的关键参数

RoCE v2将RDMA流量封装在UDP/IP中，因此IP配置、MTU、PFC优先级映射等均需协同设置。以下为推荐配置流程：

4.3.1 IP与路由配置

为RDMA接口分配独立IP，并确保路由可达。建议使用专用VLAN隔离存储/计算流量。

# 配置IP（以Ubuntu netplan为例）
network:
  version: 2
  ethernets:
    enp3s0f0:
      addresses: [192.168.10.1/24]
      mtu: 9000
    enp3s0f1:
      addresses: [192.168.10.2/24]
      mtu: 9000

4.3.2 PFC与优先级映射

在交换机和网卡上启用PFC，并将RoCE流量映射到高优先级队列。Linux下可使用 tc 或 mlnx_qos 工具配置。

# 使用mlnx_qos设置RoCE优先级（以优先级3为例）
sudo mlnx_qos -i enp3s0f0 --pfc=3,0,0,0,0,0,0,0
sudo mlnx_qos -i enp3s0f0 --trust=dscp
# 验证PFC配置
sudo mlnx_qos -i enp3s0f0 --show

4.3.3 MTU一致性检查

端到端MTU必须一致，否则可能导致分片或丢包。建议设置MTU=9000（巨型帧），并检查交换机端口MTU。

配置项	推荐值	检查命令
网卡MTU	9000	`ip link show`
交换机端口MTU	9216（含L2头）	交换机CLI
PFC优先级	3或4（与交换机一致）	`mlnx_qos --show`
ECN标记	启用（若支持）	`sysctl net.ipoib.ecn_enable`

4.4 验证方法：从连通性到性能基准

搭建完成后，必须通过分层验证确认环境健康。仅用 ping 验证IP连通性远远不够，还需验证RDMA语义是否正常。

4.4.1 基础连通性验证

# 验证IP层连通
ping -c 3 192.168.10.2

# 验证RDMA连通性（使用ibping或rping）
ibping -S -C mlx5_0 -P 1   # 服务端
ibping -G -C mlx5_0 -P 1 192.168.10.2  # 客户端

# 验证RoCE v2数据路径
rping -s -a 192.168.10.1 -v  # 服务端
rping -c -a 192.168.10.1 -v  # 客户端

4.4.2 性能基准测试

使用 perftest 工具集（ib_write_bw、ib_read_lat等）测量带宽与延迟。重点关注以下指标：

带宽：接近线速（如100Gbps网卡实测≥95Gbps）。
延迟：ping延迟应<1ms，RDMA写延迟应<2μs。
重传计数：通过 ethtool -S 检查 tx_packets 与 rx_dropped。

# 带宽测试（双向）
ib_write_bw -d mlx5_0 -a -F --report_gbits

# 延迟测试
ib_write_lat -d mlx5_0 -a -F

# 检查是否有重传或丢包
ethtool -S enp3s0f0 | grep -E "tx_packets|rx_dropped|tx_dropped"

4.5 案例复盘：一次“通而不达”的故障排查

现象：某集群RoCE网络ping通，但运行 ib_write_bw 时带宽仅为预期值的30%，且伴随大量重传。

排查过程：

检查MTU：发现服务器MTU=9000，但交换机端口MTU为1500，导致大包被丢弃。
检查PFC：交换机上PFC未启用，RoCE流量在拥塞时直接丢包。
检查驱动版本：客户端与服务器驱动版本不一致（一个为5.4，一个为5.8），导致ECN协商失败。

解决方案：统一交换机端口MTU为9216，启用PFC并映射优先级，升级驱动至一致版本。修复后带宽恢复至98Gbps。

  复盘要点：RDMA环境验证必须覆盖“IP层→RDMA语义层→性能层”三个层次。任何一层异常都可能导致上层应用表现诡异。建议将上述验证命令固化为脚本，在每次变更后自动执行。

4.6 常见误区与避坑指南

误区一：认为RoCE与普通TCP/IP共用网络无需特殊配置。实际上，RoCE对丢包极度敏感，必须启用无损网络特性。
误区二：忽略固件版本一致性。同一型号网卡，不同固件版本对RoCE的支持细节可能不同。
误区三：仅用 ping 验证连通性。ping只验证IP层，无法发现RDMA数据路径问题。
误区四：在虚拟化环境中未透传RDMA设备。部分虚拟化平台默认不支持RDMA直通，需配置PCIe Passthrough或SR-IOV。

搭建一个稳定、可诊断的RDMA环境，是后续所有调优工作的前提。建议在完成本章步骤后，将当前配置（驱动版本、固件版本、PFC设置、MTU等）记录为基线文档，便于后续变更时对比排查。