ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

RoCEv2无损网络关键配置:PFC与DCQCN实战解析

RoCEv2无损网络关键配置:PFC与DCQCN实战解析 RDMA 网络这件事多数人栽的坑不在硬件选型而在流控和拥塞控制配置。前两天刚帮一个客户在 NVIDIA CX6 网卡和华为 CE 交换机上把 RoCEv2 的 DCQCN 和 PFC 完整使能了一遍整个过程踩了不少雷今天把配置思路和实操命令整理出来。不管你是搞存储网络、HPC 集群还是 AI 训练集群只要涉及 RDMA这篇文章应该都能帮你少走弯路。先说清楚为什么这两样东西这么重要。RDMA 最大的特点是绕过内核、直接网卡间搬数据延迟做到微秒级。但以太网本身是“尽力而为”的拥塞了就丢包一丢包就要等重传RDMA 的性能优势瞬间归零。为了在以太网上跑无损传输就需要 PFC 在链路层提供有损补偿。而 PFC 只管“近处”的暂停DCQCN 负责“远方”的端到端流量整形两者配合才能既不出错又高效。下面我按环境介绍、交换机配置、网卡配置、验证和排障的顺序来写全是实操经验。1. 拆解整体方案RoCEv2 无损网络里的 PFC 和 DCQCN 到底各管哪一段1.1 三个角色的分工发送端、交换机、接收端如果只看协议名会觉得 DCQCN 和 PFC 是一对同时启用的开关但其实它们的协作方式和作用位置完全不同。我习惯用一条链路从 A 网卡到 B 网卡中间过两台交换机来理解PFCPriority-based Flow ControlIEEE 802.1Qbb工作在数据链路层作用在交换机的每个物理端口上粒度是 802.1p 优先级队列。当某个优先级队列的缓冲区快满时交换机会给对端发一个暂停帧让对方在这个优先级上停止发送一段时间。它不是全局禁止而是只暂停队列其他优先级流量不受影响。DCQCNData Center Quantized Congestion Notification则是端到端的拥塞控制。它的组成是改进版 QCN 加上 ECNExplicit Congestion Notification标记配合接收端回发的 CNPCongestion Notification Packet让发送端动态调整发送速率。交换机在检测到队列拥塞时对数据包打 ECN 标记接收端收到后回复 CNP发送端收到 CNP 就将速率降档之后再周期性恢复。用一句生活化的话说如果把数据比作车流PFC 是“前方路口拥堵后面的车先别往前开了”DCQCN 是“走这条高速的总流量太多从源头收费站开始控制车流”。这两者缺一不可。如果只开 PFC 不开 DCQCN拥塞会沿链路逐跳传导甚至形成 PFC 风暴如果只开 DCQCN 不开 PFC偶尔的突发流量仍可能直接把缓冲区塞爆数据包一丢RDMA 就会触发重传。所以无损 RDMA 网络的黄金组合是“PFC 兜底 DCQCN 控速”。1.2 为什么偏偏选 RoCEv2而不是 InfiniBand现在很多场景已经不排斥 InfiniBand 了但在大多数数据中心用现有以太网改造成 RDMA 网络成本最低。RoCEv2 把 RDMA 封装到 UDP/IP 里使用目标端口 4791三层可路由配合 PFC 和 DCQCN 后能获得接近 IB 的端到端性能。NVIDIA CX6 网卡是支持 RoCEv2 的典型代表华为 CE 交换机也原生支持无损以太网相关特性两者互联并不需要特殊兼容层。不过要注意一个细节RoCEv2 默认使用普通 UDP 端口如果中间经过防火墙或开启了某些安全策略UDP 4791 的包可能被拦截。实际部署时我至少碰到过两次这种低级问题一台存储集群的吞吐死活上不去最后查路由器和安全策略才发现是端口没放通。建议在项目初期就把 UDP 4791 以及 PFC 相关的控制报文所在二层域一起规划进去。1.3 核心参数选型的统一思路一台交换机上可能同时跑 TCP、iSCSI、RoCE 等多种流量PFC 和 DCQCN 必须精确控制到具体的 802.1p 优先级和 DSCP 值。我的习惯是把 RoCE 流量固定到一个优先级比如优先级 3DSCP 固定为 26也就是 0x1A网卡和交换机默认值之一。这样做的好处是配置时不用来回猜排障时抓个包就能一眼认出来。在华为例子里RoCEv2 通常建议使用队列 3 或队列 4并且要在所有涉及的无损端口上保持一致的映射关系。这句话说起来简单但实际排查时我发现绝大多数问题是映射不一致交换机的 DSCP→本地优先级映射和网卡的 DSCP→队列映射不同步。下面我详细展开交换机侧的配置。2. 华为 CE 交换机侧无损队列、PFC、ECN 一步步配置2.1 配置前的关键确认版本、端口和拓扑边界开始敲命令前我建议你先做三件事确认交换机软件版本。华为 CE 系列有很多型号比如 CE6881、CE8850、CE6863还有老的 CE12800。同样是 V200R005 和 V200R019命令行可能存在差异无损特性的默认值也不同。先执行display version记录版本号再对照对应版本的命令手册能省掉一半纠结。确认拓扑中所有端口都需要无损。PFC 和 ECN 不是越多越好的如果某条链路上没有 RoCE 流量却启用了 PFC反而可能因为缓冲区被无谓保留而降低 TCP 吞吐。正确做法是只在 RoCE 流量的必经链路上使能 PFC。确认 DSCP 规划和 802.1p 优先级的对应关系。这一步最好在规划阶段就定死后面所有设备统一遵循。在华为 CE 设备上DSCP 到本地优先级local precedence的映射是在 diffserv domain 下配置的。默认域里 DSCP 26 通常映射到某个优先级但这个值不一定适配你的无损队列所以最好显式配置避免依赖默认值后出现问题。2.2 命令行实操CE 交换机的完整无损配置片段以下配置以华为 CE 系列交换机 V200R005 版本为基础采用队列 3 作为无损队列、PFC 优先级 3、DSCP 26 作为 RoCEv2 流量标记为例。命令实际名称可能因型号版本有所调整请以你的设备的命令参考为准。system-view # # 1. 配置 DSCP 优先级映射使 DSCP 26 映射到本地优先级 3 # 注意不同版本命令略有差异CE 高版本常用 diffserv domain diffserv domain ds_roce dscp 26 inbound 0x03 dscp 0 to 63 inbound 0 // 其他流量保持默认映射防止误伤 # # 2. 绑定域到端口并启用接口的 PFC interface 10GE1/0/1 trust dscp diffserv domain ds_roce priority-flow-control enable priority-flow-control priority 3 # # 3. 配置该优先级的缓冲区管理防止拥塞丢包 # 此处保留默认缓冲区即可如需精细调整可参考 buffer 配置 # # 4. 开启 ECN 标记在无损队列 3 上应用 WREDECN qos queue 3 wred ecn enable qos queue 3 wred ecn low-limit 60 high-limit 80 discard-percentage 30上面这段配置里有几个容易被忽略的关键点trust dscp之后交换机才会根据 DSCP 值映射到对应的本地优先级如果忘了这条DSCP 26 的报文就进不了队列 3PFC 也就不会对它生效。priority-flow-control priority 3的含义是端口上开启优先级 3 的无损能力。交换机收到优先级 3 的流量在缓冲区快满时会对端发 PFC 暂停帧也愿意响应对端发来的 PFC 暂停帧。ECN 的low-limit和high-limit是阈值。实际报文在队列中的平均队列长度超过 low-limit 时开始按概率标记超过 high-limit 时开始丢包但丢包率由 discard-percentage 控制。这几个值不是随便拍的需要结合你的端口速率、时延、流量模型来调。对 25G 端口和 100G 端口来说缓冲区大小差异很大直接用一套参数很容易出问题。除了单个端口华为 CE 还支持批量配置用port-group把一组接口放到组里统一下发这样在几十个 RoCE 端口上配置就不会漏port-group pg_roce group-member 10GE1/0/1 to 10GE1/0/10 trust dscp diffserv domain ds_roce priority-flow-control enable priority-flow-control priority 32.3 缓冲区调优不要一上来就猛改 buffer很多刚接触无损网络的人喜欢一上来就把所有缓冲区调到最大觉得“缓冲区越大越不会丢包”。这个想法在 PFC 场景下有问题。缓冲区越大PFC 暂停帧传播得越深端到端时延就越难控制缓冲区太小则根本撑不住突发流量ECN 还没来得及生效包已经丢了。华为 CE 交换机的默认缓冲区对大多数场景是够用的。你先跑一个正常的 RoCE 流量测试如果发现丢包或 PFC 暂停帧频繁触发再去微调。要做变更时我建议只调整无损队列的 buffer不要动全局 buffer。有些型号支持qos buffer或dcb相关的命令来精细分配每个队列的 buffer 比例但这类配置对硬件资源理解要求高改错了影响面非常大务必先在测试环境验证。2.4 两侧 ECN 参数匹配的重要性交换机的 ECN 阈值和网卡的 ECN 阈值是两条独立的配置线。交换机负责在网络拥塞时把 IP 报文头里的 ECN 字段改成 CECongestion Experienced网卡负责看 RTT、判定延迟并调整速率。如果交换机的 ECN 阈值设得太激进网卡会频繁收到 CNP吞吐被压得太低设得太宽拥塞积累到 PFC 都顶不住时又会出现暂停风暴。一个相对稳妥的起点是交换机 WRED ECN 的 low-limit 设在 60% 左右high-limit 设在 80% 左右然后根据display qos ecn和display qos pfc的统计微调。具体的数值还需要配合网卡侧mlnx_qos的配置来定没有一套万能参数。3. NVIDIA CX6 网卡侧驱动、RoCE 使能、QoS 配置3.1 环境准备OFED 驱动与工具链NVIDIA ConnectX-6 网卡要跑 RoCEv2首先要装对驱动。官方推荐使用 MLNX_OFED安装包可以到 NVIDIA 官网下载。注意选择与你的内核版本匹配的版本号我用的是 OFED 5.x 系列具体小版本根据发行版选最接近的。安装完成之后确认下面几个命令存在ibv_devinfo mlnx_qos cma_roce rdma link如果mlnx_qos不存在通常是 tools 包没装全补装即可。在继续之前先用ibv_devinfo -v查看网卡是否已处于 Active 状态。有些服务器在 BIOS 里禁用了 SR-IOV 或网卡相关特性导致 IB 设备不显示需要先到 BIOS 和系统层修好。3.2 使能 RoCE 模式与 PFC 优先级映射CX6 默认支持 RoCE但要确认当前模式是 v1 还是 v2cma_roce mode -d mlx5_0 -p 1如果返回的结果是 RoCEv1需要改到 v2。RoCEv2 使用 UDP/IP 封装可路由几乎没理由用 v1。修改后建议重启网卡驱动或重启机器确保模式彻底生效。然后设置 QoS 信任模式。CX6 默认信任 802.1p 优先级但也支持信任 DSCP。如果交换机端用的是 DSCP 26 映射网卡这边也必须保持一致否则流量进错队列PFC 就不生效。用mlnx_qos查看当前的映射mlnx_qos -i eth0如果显示 trust 模式为 pcp而我们希望按 DSCP 分类可以这样切换mlnx_qos -i eth0 --trustdscp之后还需要确保 DSCP 26 映射到优先级 3。mlnx_qos -i eth0 -p 3其实设置了默认优先级但 DSCP 到用户优先级UP的映射需要检查。更直接的方式是写一个新的 qos 策略或者用mlnx_qos -i eth0 -r 0,1,2,3,4,5,6,7 --dscp0,1,2,3,4,5,6,7这类参数做批量映射。不同 OFED 版本命令选项略有出入建议先用mlnx_qos --help确认。3.3 网卡侧的 DCQCN 参数调整CX6 上的 DCQCN 参数暴露在rdma工具或 sysfs 中。传统方式是在 OFED 的/sys/class/infiniband/mlx5_0/下调整但更现代的方式是用rdma命令查看和修改。你可以用下面的方式看当前时延参数rdma statistic qp show link mlx5_0实际的 DCQCN 参数主要包含以下几组一般在/sys/class/infiniband/mlx5_0/ports/1/dcqcn/或通过mlnx_qos的-d参数查看rp_timer/rate_reduce_period速率恢复周期影响吞吐恢复速度cnp_p_dscp或cnp_802p_prioCNP 报文用的 DSCP 或优先级min_rate最低速率百分比防止流量被压制到零alpha、beta速率调节算法里的因子关键点在于CNP 报文本身也必须走无损队列。CNP 是接收端发给发送端的拥塞通知如果它自己都被 PFC 暂停或丢弃整套 DCQCN 就失效了。在华为 CE 交换机上确定 CNP 使用的 DSCP 值后要把这个值也映射到无损队列 3。我就遇到过 CNP 走了默认 best-effort 队列结果拥塞越调越乱的情况。通常建议把 CNP 固定为 DSCP 48优先级 5 或与数据流量同一个队列。把你的网卡和交换机统一设置即可不需要和别的厂商完全一致。3.4 用持久化配置避免重启后丢失CX6 的配置如果只用命令行改重启或驱动 reload 后会丢。推荐用mlnx_qos -i eth0生成的配置文件保存或者用 OFED 自带的cma_roce配置脚本。更稳妥的方式是把关键配置写入/etc/mellanox/mlnx_qos.conf并让开机脚本自动执行。这是很多运维人员会漏掉的一环特别是在批量装机时如果没做持久化重启后整个集群的 RDMA 性能会瞬间退化到有损网络水平。4. 验证环节数据不会骗人计数器会告诉你真相4.1 检查交换机侧 PFC 与 ECN 计数器配置完成不等于生效。我一般按下面的顺序做验证# 查看端口 PFC 收发帧计数 display qos pfc brief display qos pfc interface 10GE1/0/1 # 查看 ECN 标记统计 display qos ecn interface 10GE1/0/1 # 查看缓冲区和丢包统计 display drop profile interface 10GE1/0/1正常的无损链路上PFC 帧是可以有的但不能疯狂增加。如果rx pause或者tx pause的数量在正常业务下每秒几千上万地跳说明流量整形没做好DCQCN 没有发挥应有的作用PFC 被频繁触发。出现这种情况时优先检查 ECN 阈值和网卡 DCQCN 参数而不是继续加 buffer。4.2 检查网卡侧 PFC、ECN、CNP 计数在 CX6 上用ethtool -S eth0看关键计数器rx_prioX_pause/tx_prioX_pause表示网卡收到的和发送的 PFC 暂停帧rx_pause/tx_pause传统 802.3x pause 帧RoCEv2 环境下应该为 0rx_cnp_*/tx_cnp_*CNP 报文计数rx_ecn_marked收到的被 ECN 标记的报文数tx_ecn_marked发出的被 ECN 标记的报文数一般网卡自己不做 ECN 标记看前者即可评估的关键经验值是rx_ecn_marked和rx_cnp的数量应该随着负载增加而增加但 PFC 暂停帧不应该随之暴涨。如果 PFC 帧和 ECN 标记同时在涨问题不大说明 DCQCN 正在工作如果 PFC 帧涨、ECN 标记几乎为 0说明交换机的 ECN 没开或阈值太高拥塞全靠 PFC 扛后期必然出事。4.3 用工具实测带宽和延迟配置和计数器都正常后还要做实际性能测试。常用工具是 OFED 自带的ib_write_bw或者用perftest包中的命令。测试方法很简单在接收端启动服务在发送端跑# 接收端 ib_write_bw -d mlx5_0 -x 3 -F # 发送端对端 IP ib_write_bw -d mlx5_0 -x 3 -F 192.168.1.100 --report_gbits其中-x 3表示用优先级 3。可以将-x 3换成-x 0做对比观察 PFC/无损队列带来的差异。更真实的场景是多对一通信也就是多个发送端同时打一个接收端人为制造拥塞看 DCQCN 是否能把吞吐稳定在合理水平而不是大幅振荡。如果测试时发现带宽始终只能到线速的 60% 以下先按照“交换机 ECN 计数 → 网卡 CNP 计数 → PFC 暂停帧”的顺序排查配好这套链路问题十有八九就在其中的某一个环节。5. 常见问题与排查技巧实录5.1 问题一RoCE 流量丢包但 PFC 和 ECN 都没怎么动表现业务有重传但看 PFC 帧和 ECN 标记都不多RDMA 性能也上不去。排查思路先用ethtool -S eth0 | grep -i prio确认 RoCE 流量是否真的从优先级 3 走。如果网卡 DSCP 映射或交换机 trust 没配对RoCE 报文可能混进了默认优先级队列 0该队列既没开 PFC 也没开 ECN拥塞了就正常丢包。用 tcpdump 抓包确认 DSCP 值是最快的判定方法。tcpdump -i eth0 -c 1000 -nn udp port 4791 -w roce.pcap然后用 Wireshark 查看 DSCP 字段。服务器侧网卡发的包如果不是 DSCP 26就要去查应用或网卡 QoS 配置。5.2 问题二PFC 暂停帧风暴网络时不时“假死”表现PFC 计数暴涨端口吞吐掉到 0整个网络像死掉几秒后又恢复。这是无损网络最危险的问题之一通常是某条链路上出现了环路或者交换机上同时配了 STP 和 PFC导致暂定帧没完没了。也可能是某个端口的 PFC 配置和交换机内其他端口不一致对端按优先级 3 发暂停本端却把它当成普通优先级。处理办法是用display loop-detection或 STP 状态确认没有环路暂停该端口 PFC 功能观察风暴是否消失检查所有无损端口的 PFC 优先级是否一致检查是否有多个厂商设备混用某些交换机默认不响应 PFC会出现单边暂停的问题5.3 问题三CNP 包丢失DCQCN 形同虚设表现ECN 标记有但网卡 CNP 计数很少发送端速率降不下来。原因大概率是 CNP 报文走了无优先级的普通队列交换机或网卡没有为 CNP 保留资源。CNP 的发送频率很高如果它本身和 TCP 等其他流量抢 buffer很容易被丢弃。解决方案是给 CNP 指定一个明确的高优先级 DSCP/802.1p并把它纳入无损队列。5.4 快速自检清单我把自己在多个项目中反复用到的排查顺序整理成一张表建议你在配置变更前打印出来贴机房检查项命令/位置正常参考网卡 RoCEv2 模式cma_roce mode -d mlx5_0RoCEv2网卡 QoS trustmlnx_qos -i eth0dscp且 DSCP26→优先级3网卡 CNP 计数ethtool -S eth0ECN 标记后应出现 CNP交换机 PFC 配置display qos pfc brief仅 RoCE 端口开启优先级一致交换机 ECN 计数display qos ecn interface拥塞时有标记丢包位置display drop interface应只在拥塞高端口出现且配合 ECN性能测试ib_write_bw -x 3接近线速这张表不只是给我自己用的交接给客户运维团队也非常有效。6. 一些实际操作中的体会几次项目做下来我最深的感触是不要迷信“只要启用 PFC DCQCN 就万事大吉”。这两项技术能跑得好前提是映射关系统一、缓冲区分配合理、监控到位。网卡上开了 RoCEv2交换机全部端口都开了 PFC看着配置没毛病但 DSCP 映射不一致就足以让整个集群性能塌方。很多事故源于这种“看似都配了实际没对上”。再有一点华为 CE 交换机不同型号和软件版本之间的命令并不是完全一致的。我给出的命令可以作为通用思路参考但在生产环境动手前务必在测试交换机上验证并参考你的版本的命令手册。配置变更最好走变更评审流程尤其是涉及缓冲区分配和 PFC 启停的操作风险等级不低。最后分享一个非常实用的小技巧在上线前把交换机和网卡两侧的配置文件完整保存下来然后写一个简单的脚本定期抓取display qos pfc brief、display qos ecn和网卡的ethtool -S关键计数写入日志。这样如果哪天 RDMA 性能莫名其妙下滑你有历史数据可以回溯而不至于在问题发生后靠猜。RDMA 网络优化是个持续打磨的过程参数调优不是一次做完就结束的还是要根据业务流量的变化不断修正。
返回列表