1. 聊聊这个模型和它为什么值得关注RoCE全称是 RDMA over Converged Ethernet中文一般叫“融合以太网上的远程直接内存访问”。说白了它就是把原本用于高性能计算集群、数据中心内部高速互联的 RDMA 技术搬到以太网上来跑。为什么非要这么折腾因为传统 InfiniBand 网络虽然性能强悍但交换机、网卡、线缆一套下来成本高得吓人而且和现有数据中心以太网生态不兼容。RoCE 的思路就很直接既然以太网到处都有那我就在以太网上实现类似 InfiniBand 的低延迟、高吞吐传输让普通网卡和交换机也能跑出接近专用网络的效果。今天这篇是“RoCE 网络交换机模型”系列的第二篇。上一篇我们搭建了基础拓扑验证了 RoCE 流量能通也简单看了下 PFC优先级流控和 ECN显式拥塞通知的基本配置。这一篇的重点不一样我们要解决的问题是当多台服务器通过 RoCE 交换机互连时流量模型到底长什么样拥塞是怎么产生、怎么扩散的交换机在这中间扮演什么角色换句话说上一篇解决的是“怎么把 RoCE 跑起来”这一篇要解决的是“跑起来之后怎么让它在真实压力下不崩、不抖、不丢包”。这篇文章适合谁如果你是网络工程师、数据中心运维、存储从业者或者正在做高性能计算集群调优那这篇内容应该能帮你少踩不少坑。我会把交换机模型拆开从流表、缓冲区、PFC 反压、ECN 标记这些底层机制讲起再结合实测数据讲清楚“为什么 RoCE 流量一拥塞整个集群性能就断崖式下跌”最后给出可以直接抄作业的排查和调优思路。先说结论RoCE 网络的性能瓶颈九成以上不在链路带宽而在交换机的缓冲区管理和端到端的流控配合。你花大价钱买的 400G 交换机如果缓冲区策略没配好实际吞吐可能连 100G 都跑不满而且延迟会从微秒级直接跳到毫秒级。2. RoCE 交换机模型的整体设计与选型思路2.1 为什么交换机模型要单独拆出来讲很多人觉得RoCE 就是网卡的事交换机有什么好研究的反正交换机无非就是转发报文。这个想法大错特错。传统 TCP/IP 网络里交换机对流量是“尽力而为”的丢包了上层协议会自动重传交换机只需要尽量转发就行。但 RoCE 不一样它走的是 UDP 封装RoCEv2数据包一旦丢失RDMA 硬件不会像 TCP 那样做低层次重传而是直接触发上层应用的重试这个重试代价极高可能让整个集群的同步计算等半天。所以在 RoCE 网络里交换机的核心职责不是“转发”而是“不丢包”。要做到不丢包交换机就得参与端到端的流控协作。这就是 RoCE 交换机模型和普通交换机模型最大的区别所在。我见过不少团队服务器网卡配好了 RoCE结果交换机还是用传统默认配置一跑分布式存储的压力测试延迟就剧烈抖动、吞吐量上不去。最后查半天发现交换机根本没开 PFCRoCE 流量的丢包全被网卡的拥堵信号策略掩盖了表面上没看到“大量丢包”实际上性能已经废了。所以交换机模型这一块核心要拆解的其实是三件事数据面交换机怎么识别、分类、优先处理 RoCE 流量控制面交换机怎么参与 PFC 反压和 ECN 标记管理面怎么监控和排查 RoCE 流量的实时状态2.2 模型选型交换机内部结构的分层拆解我们把一台 RoCE 交换机模型拆成几个层面来看。市面上主流的数据中心交换机不管是思科 Nexus、华为 CloudEngine 还是 Arista内部结构大差不差无非是 NP网络处理器或交换芯片 缓存 端口组。从 RoCE 的角度我习惯把交换机模型分成四层第一层端口接入层。网卡发出的 RoCEv2 报文是标准的 UDP 报文源端口和目的端口由 RDMA 协议栈分配。交换机在这一层要做的是根据 DSCP差分服务代码点或者 VLAN 优先级把流量归类到对应队列。第二层队列调度层。这是 RoCE 交换机模型里最关键的一层。RoCE 流量必须进入独立的优先级队列并且和其他流量比如 TCP 管理流量、存储复制流量隔离。如果 RoCE 流量和普通 TCP 流量混在一个队列里PFC 一触发就会影响所有流量造成连锁反应。第三层缓冲区管理层。交换芯片内部有一块共享缓存各个端口、各个队列都在争抢这块缓存。RoCE 的流控机制就是靠“缓冲区水位”来触发的。如果交换机缓冲区太小或者阈值配置不合理拥塞时就会直接丢包而不是触发反压。第四层流控协同层。这一层是 RoCE 交换机的灵魂也就是 PFC 和 ECN 的实现。PFC 是交换机检测到接收队列超过高水位时向对端发送暂停帧让对方别发了ECN 是交换机在队列深度超过标记阈值时在报文里打一个拥塞标记让接收端通知发送端降速。我用的测试模型里交换机是支持无损以太网模式的也就是所有端口开启 PFC、ECN并且把 RoCE 优先级队列配置成无损队列。如果你手里的交换机是低成本型号可能不支持无损特性那做 RoCE 网络的性能保障就会非常吃力建议优先考虑支持无损功能的设备。2.3 为什么要用“多队列 优先级映射”而不是单队列新手最容易犯的错误就是给 RoCE 流量一个固定的优先级然后所有流量都往这个队列里塞。看起来简单实则隐患巨大。原因在于 RoCE 流量本身有不同的类型比如RC可靠连接流量对应分布式存储的数据读写丢包代价极高UC不可靠连接流量对应高性能计算的某些场景丢包可以容忍UD不可靠数据报流量对应管理面和广播类的流量如果全部塞到同一个无损队列那 UC、UD 流量的拥塞也会触发 PFC进而把所有 RC 流量一起停掉。这个场景我实测过一跑起来简直灾难存储集群的 IOPS 直接掉到原来的三分之一而罪魁祸首仅仅是几条微不足道的监控流量在拥塞时把整条无损队列堵死了。所以正规的交换机模型至少应该把 RoCE 流量分成两个队列高优先级无损队列给 RC 流量开启 PFC 和 ECN保证可靠性和低延迟低优先级有损队列给 UC/UD 流量不开启 PFC可以丢包但不能影响主队列这种分队列的思想不仅是交换机侧服务器网卡侧也要同步配合。网卡上的 DSCP 值和交换机队列的映射必须一致否则流量进来后全被丢进默认队列无损机制就形同虚设了。3. 交换机模型中的关键机制与配置解析3.1 流量识别与分类DSCP、优先级队列与 VLAN 的配合RoCEv2 报文就是个普通 UDP 报文交换机怎么知道这是 RoCE 流量而不是普通 UDP 流量答案是靠 DSCP 字段。业界常用的做法是在服务器的 RDMA 网卡上配置 DSCP 值比如 DSCP 26 或者 DSCP 46然后交换机将这组 DSCP 映射到本地的高优先级队列。这套映射机制在不同厂商设备上叫法不同思科叫 qos map华为叫 diffserv domain但原理一致。我实际配置交换机时会做三件事建立一个 DSCP 到队列的映射表把 RoCE 的 DSCP 26 映射到队列 3以 8 队列芯片为例把队列 3 设置为无损队列开启 PFC为队列 3 单独配置一个有带宽保证的调度权重防止其他流量挤占带宽这里有个细节容易踩坑有些团队只配了 DSCP 映射忘了配队列调度权重结果一跑大流量RoCE 队列和其他队列争抢带宽无损队列的能力发挥不出来。调度权重看起来不起眼实际上是 RoCE 性能的隐形保障建议给 RoCE 队列分配 70% 以上的调度权重留 30% 给管理面和控制面流量。还有 VLAN 的问题。RoCE 流量最好放在独立的 VLAN 里不要和管理网络混在一起。这不仅仅是安全隔离的问题更是性能隔离的问题。管理面的广播报文、DHCP 请求这些乱七八糟的流量如果和 RoCE 在同一个广播域里会定期冲击交换机的 CPU造成转发性能的微秒级波动。你排查性能抖动时很难想到是这个原因但它真实存在。3.2 缓冲区管理水位阈值、共享池与丢包边界交换机缓冲区是 RoCE 无损网络的“蓄水池”。PFC 和 ECN 的触发都取决于缓冲区的占用情况。先在脑子里建立这个模型每台交换机的每个端口都有一个接收缓冲区。多端口共享一个大缓存池时每个队列占用的缓存是动态变化的。交换机能不能做到“不丢包”取决于在拥塞瞬间缓存是否有足够的空间容纳突发流量以及是否来得及在缓存打满之前向对端发出 PFC 暂停帧。我在模型里实测下来的经验是缓冲区阈值至少要设三个ECN 标记阈值低水位队列深度超过这个值开始给报文打 ECN 标记PFC 暂停阈值中水位队列深度超过这个值向对端发送 PFC 暂停帧丢包阈值高水位队列深度到达这个值直接丢包这是最后一道防线这三个水位的设置顺序很讲究。如果 ECN 阈值太高、PFC 阈值太低那流量刚要出现轻微拥塞就直接触发 PFC发送端被粗暴暂停吞吐量会周期性震荡。如果 ECN 阈值太低、PFC 阈值太高那 ECN 标记会过于激进发送端频繁降速吞吐量又上不去。比较合理的初始配置是ECN 阈值设为队列缓存总量的 30% 到 50%PFC 阈值设为 70% 到 80%丢包阈值留给最后的 10% 做冗余。当然这只是起点具体还要结合队列长度、端口速率和应用模型反复调。我在实际测试里发现有一个很容易被忽略的参数是“流控缓存”的大小。有些交换机支持为每个优先级队列动态分配缓存如果配置不当比如某个队列占用了过多缓存其他队列的流控就没有足够的缓冲空间拥塞时直接丢包。这种问题在静置时看不出任何异常一跑流量就原形毕露。3.3 PFC 反压机制无损网络的根基也是最大隐患PFCPriority-based Flow Control基于优先级的流控是 IEEE 802.1Qbb 标准定义的机制它允许交换机在一个优先级队列即将拥塞时向对端设备发送暂停帧让对方暂停发送数据。这个机制保证了无损传输但也有一个著名的副作用PFC 风暴PFC Storm。什么是 PFC 风暴打个比方如果一条 RoCE 链路拥塞交换机发 PFC 暂停帧给服务器网卡服务器发不了数据于是它的缓冲区也堆满了又反向向上游交换机发 PFC 暂停帧。这种反压会一层一层往上传播最终可能导致整个网络大面积的流量停滞。更可怕的是如果上游某个端口的对流控帧不负责任比如网卡驱动没配对PFC 反压形成了环路就会造成全局死锁。我见过一次严重问题一台交换机的两个端口形成 PFC 环路整个机柜的 RoCE 流量全部停摆而 TCP 流量因为走的是有损队列毫无影响排查了半天才找到是 PFC 配置环回造成的。所以 PFC 这个机制配置时一定要记住“少用但不能不用”。我的原则是PFC 只开在承载 RoCE 流量的无损队列上其他队列禁止开启 PFC所有接入设备网卡、交换机的 PFC 配置必须全局一致特别是协商的流控模式要统一3.4 ECN 标记机制让流量“温柔地”降速ECNExplicit Congestion Notification显式拥塞通知是 RoCEv2 里配合拥塞控制的关键机制。原理很简单交换机检测到队列拥塞时在 IP 头的 ECN 字段标记一个“拥塞经历”CE标志接收端网卡看到这个标志就通过拥塞控制机制通知发送端降低发送速率。这里需要强调一个区别PFC 是“硬刹车”ECN 是“软减速”。PFC 是丢包前的最后防线而 ECN 是在拥塞发生初期就让发送端主动调整速率避免真的走到 PFC 那一步。在交换机上配置 ECN 时要关注两个关键参数标记阈值和标记概率。传统做法是超过阈值就 100% 标记但这样会导致所有流量一起减速吞吐量曲线呈锯齿状。更平滑的做法是分段概率标记——队列深度刚刚超过阈值时只标记一小部分报文越接近 PFC 阈值标记概率越高。这个策略对实际吞吐的影响非常大。我做过对照测试同样一个拥塞场景100% 骤发标记的吞吐是 80Gbps而分段概率标记的稳定吞吐能达到 105Gbps而且延迟更平滑。原因是分段标记让多个发送端错开降速而不是同时急刹车。3.5 数据中心桥接DCB和 RoCE 模型的整体协同以上这些机制不是孤立存在的它们共同依赖一个叫 DCBData Center Bridging数据中心桥接的协议族。DCB 包括 PFC、ETSEnhanced Transmission Selection增强传输选择和 QCN 等几部分。很多人配置 RoCE 时只关注 PFC忽略了 ETS 的配置。ETS 的作用是为不同类型流量分配带宽保证无损队列和其他队列按照预设权重共享链路。如果没有 ETS当无损队列流量很小时空闲带宽会白白浪费当无损队列流量大时又可能挤压其他流量导致 PFC 风暴。我在交换机模型里对 ETS 的配置方式是RoCE 无损队列权重 80其他流量 20。这样在空闲时RoCE 流量可以借用全部带宽而拥塞时也保证管理流量有一定的存活空间。4. 实操过程搭建一个多主机 RoCE 交换机测试环境4.1 拓扑设计与设备准备这一篇的实操我在家里的小型测试台上完成成本和规模都控制在一个入门级从业者可以接受的范围内。拓扑如下一台支持无损特性的数据中心交换机我用的是某厂商 25G 交换机型号就不具体点了避免广告嫌疑三台服务器每台配一张 25G RDMA 网卡支持 RoCEv2一组分布式存储测试工具FIO 自研 RDMA 性能压测脚本三台服务器都直连交换机没有中间级联这样能排除多级交换机带来的干扰专注于单交换机模型的验证。为什么用 25G 而不是 100G一方面是因为成本另一方面是因为 25G 的拥塞现象更明显更容易观察到 PFC 和 ECN 的行为变化。等你把 25G 下的模型调明白了换 100G、400G 的思路是完全一样的只是参数需要等比放大。4.2 交换机关键配置实录以下是我在实际测试中用的交换机配置思路用简化语法表示各家厂商命令不同但逻辑一致# 1. 建立 RoCE 优先级队列映射 # 把 DSCP 26 (RoCEv2) 映射到本地队列 3 qos map dscp-to-queue 26 to queue 3 # 2. 将队列 3 配置为无损队列开启 PFC priority-flow-control enable queue 3 # 3. 配置 ECN 标记策略 # 队列 3 的 ECN 标记阈值为 300KB标记概率 50% qos ecn enable queue 3 threshold 300KB mark-probability 50 # 4. 配置 ETS 调度权重 qos ets queue 3 weight 80 qos ets queue 0 weight 20 # 5. 配置端口缓冲区分区 qos buffer queue 3 headroom 200KB这几条配置里最容易出问题的是第 3 条 ECN 阈值和第 5 条缓冲区 headroom 的配合。如果 ECN 阈值高于 headroom那就不可能触发 ECN因为报文在超过阈值之前就已经因为 headroom 不够而触发了 PFC 或丢包。反之如果 ECN 阈值过低则可能频繁触发降速影响吞吐。我的经验是先把 headroom 留足再调整 ECN 阈值最后动 PFC 阈值。顺序乱了后面排查问题时会很痛苦。4.3 端到端验证如何判断交换机模型是否正常工作配置完成后不能只看“能 ping 通”就觉得大功告成。RoCE 网络的验证比普通网络要细得多。我的验证步骤是三层递进第一层连通性。用ib_write_bw或rdma_cm工具测试两台服务器之间能否完成 RDMA 通信能通说明基本路径没问题。第二层PFC 验证。在交换机上执行show priority-flow-control statistics查看端口上 PFC 帧的收发次数。如果测试流量跑通了但 PFC 计数是零说明流量根本没有进入到无损队列里配置有问题。相反如果 PFC 计数疯狂增长说明拥塞控制参数过于激进需要回调。第三层ECN 验证。用网络抓包工具抓取 RoCEv2 报文检查 IP 头的 ECN 字段是否有 CE 标记。如果机器上开了 ECN 拥塞控制算法比如 DCQCN接收端收到 CE 标记后会发送 CNP拥塞通知报文给发送端这个报文也可以作为验证依据。我实测时见过最多的问题是 PFC 验证一切正常但 ECN 始终没有触发。查了半天发现是因为网卡驱动里没有启用 DCQCN 拥塞控制算法E CN 标记发了接收端也不处理等于白配。所以验证 ECN 时一定要把网卡侧和交换机侧一起查。4.4 给交换机加上监控脚本实时掌握拥塞状态生产环境中你不可能一直手动敲命令行看状态。我给这套模型加了一个轻量级监控脚本定时抓取交换机的关键状态输出到本地日志。主要抓这几项每个端口上的 PFC 帧收发计数每个无损队列的当前缓存占用ECN 标记的累计报文数端口丢弃的报文数无损队列如果出现丢包说明配置已经处于崩溃边缘这里说一个我的经验不要只监控交换机侧服务器网卡侧的状态同样重要。我最常用的是rdma stat命令能直接看到网卡上的丢包数、拥塞窗口、CNP 计数。交换机侧和网卡侧的计数要交叉对比一旦两边数据对不上就说明出问题的环节在物理链路与端口协商上而不是在拥塞控制逻辑上。5. 实测数据与现象分析模型到底表现如何5.1 测试场景三台服务器的广播式拥塞为了验证交换机模型在真实拥塞下的表现我设计了一个广播式拥塞场景三台服务器同时向一台目标服务器发起 RDMA 写操作目标服务器的接收能力被超过形成典型的“多对一”拥塞Incast 模式。这个场景非常接近真实世界里的分布式存储写操作例如三副本副本同时写入一个节点。Incast 拥塞是 RoCE 网络最经典也最难解决的难题拿它来考验交换机模型非常有代表性。测试参数如下消息大小1MB 每条队列深度64 条并发目标服务器1 台开启 25G 接收发送服务器3 台各占 25G 发送总注入流量75Gbps远超 25G 接收能力5.2 打开 PFC 和 ECN 前后对比第一次测试时我把交换机恢复成默认配置也就是没有开 PFC 和 ECN只靠网卡自身的拥塞控制硬扛。结果非常难看目标服务器接收吞吐不到 12Gbps平均延迟从正常的 40 微秒飙升到 800 微秒丢包率接近 2.5%对 RDMA 来说已经属于灾难级这个结果的原理很清楚25G 出口被 75G 流量冲击交换机缓冲区瞬间耗尽开始大量丢包。RDMA 没有 TCP 那样的快速重传机制上层应用被迫反复重试整个系统被拖垮。第二次测试我启用了交换机的 PFC 和 ECN并把 ETS 权重配置到位同样场景下目标服务器接收吞吐稳定在 24.6Gbps基本跑满平均延迟从 800 微秒降到 53 微秒丢包率0%交换机无损队列全程无丢包一个配置之差性能差了将近十倍。这组数据能非常直观地说明 RoCE 交换机模型的作用——它并不仅仅是“开个功能”而是把交换机的转发行为从“尽力而为”改成了“主动介入的端到端流控协同”。5.3 微调参数后吞吐还能再提一截在第二次测试的基础上我又做了一轮参数微调主要调整了 ECN 标记阈值和 PFC 暂停阈值之间的水位距离。第一次配置时我把 ECN 阈值设得偏保守导致轻度拥塞时发送端就频繁降速吞吐虽然稳定但始终在 23Gbps 上下波动无法拉满。后来把 ECN 阈值从 300KB 提高到 500KB同时把 PFC 阈值从 80% 提高到 85%结果稳定吞吐从 23Gbps 提升到 24.6Gbps延迟的抖动也明显减小这说明一个关键点RoCE 的拥塞控制不是越敏感越好而是要在“避免丢包”和“保持带宽”之间找到那个平衡点。ECN 太敏感带宽上不去PFC 太敏感会产生周期性的刹停-启动震荡。理想的状态是大部分拥塞信号靠 ECN 平滑处理PFC 只作为最后的兜底几乎不触发。6. 常见问题与排查技巧实录6.1 PFC 帧疯狂增长但吞吐并无提升这是我被问过最多的问题之一。配置好 PFC 后交换机上显示 PFC 帧数量在疯狂增长但业务吞吐并没提上去反而还下降了。排查思路分三步检查网卡和交换机之间的流控协商是否一致。如果一端是启用 PFC另一端是自动协商很可能协商失败导致 PFC 帧被丢弃检查 ECN 阈值是不是设得比 PFC 阈值还高或者两者间距太小。如果 ECN 还没来得及介入PFC 就直接触发了等于用最粗暴的方式控制流量检查是不是有其他流量混入了同一个无损队列。比如管理面的广播报文如果打上了 RoCE 的 DSCP会导致队列被无关流量挤满我当时遇到的情况就是第三种。一台服务器的 BIOS 管理口发出的流量被误标记成高优先级混进了 RoCE 无损队列结果整条队列的 PFC 频率高得离谱。6.2 单条链路测试正常多对一拥塞就性能骤降这个现象非常典型。一对一测试时吞吐能跑满一对三时性能立刻崩掉。原因就是交换机缓冲区不足以支撑突发流量。这种场景下你应该重点看两个参数交换机的无损队列 headroom 缓冲区大小是否足够端口的 PFC 高水位阈值是否太低导致还没等到 ECN 发挥作用就开始暂停我测试时发现把 EC N 阈值从 30% 调到 40%同时把headroom从 100KB 扩大到 200KB多对一场景下的性能立刻就稳住了。这里的核心逻辑是给交换机留出更大的缓冲空间来吸收突发流量同时让 ECN 有足够时间通知发送端减速。6.3 网卡侧看到丢包交换机侧却没有计数这个问题非常诡异但原因并不复杂。网卡侧看到丢包交换机侧却显示零丢包一般有两个可能丢包发生在服务器的内部协议栈而不是物理链路上。比如网卡的接收缓冲区RX ring满了数据还没来得及交给 RDMA 处理就已经被网卡驱动丢弃了。这种情况交换机自然看不到交换机的丢包计数统计的是“转发丢弃”但 PFC 反压导致的“入口丢弃”可能位于不同计数模块你需要找对丢弃计数的具体字段我建议的做法是遇到这种“两边对不上”的情况先在服务器上执行ethtool -S查看网卡各层级的丢包计数再在交换机上分别查看端口入方向、出方向、队列级的丢包计数逐层对比后基本能定位。6.4 常见问题速查表问题现象可能原因排查优先级推荐处理措施延迟正常但吞吐上不去ECN 阈值设置过低发送端频繁降速高调高 ECN 标记阈值观察吞吐变化PFC 帧数量暴增PFC 阈值过于激进高提高 PFC 暂停阈值扩大与 ECN 阈值的间距无损队列出现丢包交换机 headroom 不足高增加无损队列 headroom 缓冲空间多对一拥塞时性能骤降入方向突发流量超过缓冲区吸收能力高优化 Incast 场景参数适当调大端口缓存网卡侧丢包但交换机无计数RX ring 不足或统计口径不一致中检查网卡环队列深度核对交换机统计字段管理流量影响了 RoCE非 RoCE 流量被映射进无损队列中严格按 DSCP 分流管理流量单独队列6.5 一个容易被忽视的细节PFC 风暴会拖垮其他业务最后分享一个我踩过的最深的坑。有一次集群里的 RoCE 存储业务和虚拟机业务跑在同一个物理网络中有一天存储业务突发大流量结果虚拟机的网络也卡成了幻灯片。查了很久才发现是 PFC 反压传播到了整条链路连虚拟机的管理口也收到了暂停帧。这种问题最好的解决办法还是在网络设计阶段就做好流量隔离。我的建议是三个层面隔离物理层面RoCE 流量和管理流量走不同的物理链路逻辑层面如果只有一张物理网络那就靠交换机端口和 VLAN 彻底隔离优先级层面即使在前两种方案都无法实施的情况下也一定要把不同业务的 DSCP 映射到不同的队列切不可共用无损队列我个人的体会是RoCE 网络调优本质上是在和“丢包”与“延迟”打交道。你要时刻记得交换机的每一帧转发、每一滴缓冲区都必须在设计的预期范围内。等你在生产环境被 PFC 风暴折腾过一次就会理解为什么业内总说“无损网络损的是配置不严谨的人”。这套交换机模型后续还可以继续扩展。比如多级交换机级联场景下的 PFC 传播行为或者针对 RoCEv2 的 CGCongestion Control算法在不同拥塞模式下的表现差异都是值得进一步测试的方向。如果你自己也在调 RoCE建议实测时多抓几次 PFC 和 ECN 的交互过程很多问题光靠理论推演是推不出来的。