1. 为什么数据中心网络离不开PFC从一次存储抖动说起前一阵子我们数据中心做存储集群扩容业务反馈存储复制任务延迟突然从几百微秒跳到了几十毫秒吞吐量直接掉了近一半。刚开始怀疑是光纤链路或磁盘阵列的问题查了一圈才发现问题出在网络交换机上某条100G链路的RoCE流量在微突发时出现丢包RDMA遭遇重传后性能断崖式下跌。这个场景最终靠PFCPriority Flow Control优先级流控解决了大半。PFC最近几年在数据中心网络里几乎成了“无损”的代名词尤其是要跑RoCE、FCoE或高性能存储时PFC配没配好直接影响业务时延和吞吐。本文想做的就是把PFC的背景、工作原理以及DCB、ETS、DCBX这三个经常绑在一起出现的协议整体捋一遍。很多人知道PFC但说不清DCB和ETS、DCBX的关系更说不清部署时要对齐哪些参数。这篇文章会按我自己的理解从原理讲到实操再讲几个真实踩过的坑。1.1 传统以太网流控的前世今生传统以太网从设计之初是“尽力而为”的发送方把数据丢到链路上网络设备尽力转发但一旦拥塞报文就可能被丢弃。对于TCP业务来说丢包不是什么大问题发送端靠ACK超时或重复ACK触发重传就行代价不过是慢一点。但在转发拥塞时交换机内部的缓冲区是有限的。如果一个端口流量超过出端口速率入方向的报文堆积在缓冲区缓冲区满了以后交换机只能选择丢弃新到的帧。为了减少这种“被动丢弃”IEEE 802.3x定义了基于链路的PAUSE流控机制接收端检测到入方向缓冲区快满了就向对端发送一个PAUSE帧请求对端暂停整条链路上一段时间。这个机制在早期的半双工、低速率网络中还能用但在数据中心里很快就暴露出问题——它一暂停就是整条物理链路不管流量优先级导致所有业务一起被卡住。真正让情况复杂化的是数据中心希望用一张以太网承载LAN、SAN和IPC多种流量。普通TCP、高性能计算、存储流量对丢包的容忍度完全不同。如果继续用统一的“尽力而为”方式存储和RDMA流量会被传统拥塞拖死。于是IEEE 802.1Qbb标准应运而生也就是我们今天说的PFCPriority-based Flow Control。1.2 当“丢包重传”遇上RDMA性能悬崖RDMARemote Direct Memory Access和传统TCP/IP栈最大的区别是数据拷贝和协议处理全部由网卡硬件卸载CPU几乎不参与。硬件卸载的好处是极低的时延和极高的吞吐但前提是网络不能丢包。一旦发生丢包RDMA网卡需要触发重传严重时甚至要暂停发送队列并等待ACK性能可能从100Gbps瞬间跌到几个Gbps引发所谓的“RDMA性能悬崖”。FCoE和部分存储协议也有类似问题。FCoE希望把存储流量跑到以太网上同时又希望保持FC存储网络的无损特性。没有PFC之前FCoE和TCP数据混跑时一个突发拥塞就可能把存储帧丢掉存储控制器被迫重试业务延迟和IOPS都受影响。PFC解决的问题就是让网络为特定优先级流量提供“不丢包”通道当接收端缓冲区到达危险水位时只暂停对应优先级的发送而不是暂停整条链路。1.3 PFC不是雪中送炭而是止血带PFC并不能提高链路带宽也不能消除拥塞它做的只是利用缓冲区吸收瞬时突发并在拥塞无法吸收时让上游设备暂停发送以损失局部吞吐为代价避免丢包。我常跟同事打比方PFC像水管上的止水阀水管变细了它没法处理只能在下游快要溢出的时先让上游关一下龙头防止水漫金山。问题是如果管道本身持续地供大于求关阀门只能把水流憋在上游形成新的拥塞点。所以PFC从来不是用来替代容量规划的。真正合理的无损网络设计必须同时考虑缓存、队列调度、流量限速和监控。理解了这一点再往下看PFC的原理和DCB框架就不会把它神话了。2. PFC工作原理拆解基于优先级的逐跳暂停机制PFC的机制可以理解为“按优先级粒度化的PAUSE”。它把以太网流量分为最多8个优先级每个优先级独立进行流控。在数据中心和设备上我们通常会把无损流量打到一个专用优先级比如优先级3然后只对这个优先级启用PFC其他优先级仍然走传统的有损转发。2.1 PFC报文和优先级队列从PAUSE到per-priority PAUSEPFC控制帧本质上还是MAC控制帧EtherType为0x8808和802.3x的PAUSE帧属于同一类。区别在于PAUSE帧只需要一个全局暂停时间而PFC帧在格式上增加了“使能向量”和8个优先级的独立暂停时间值。收到PFC帧的交换机会检查使能向量里哪些优先级需要暂停然后只暂停对应优先级的发送队列不影响其他优先级。举个例子端口上有两个队列队列3承载RoCE流量队列0承载普通TCP流量。当对端发送一个PFC帧使能向量中只有bit3置为1且附带一个时间值本端就会暂停队列3的调度但队列0依然可以继续发送。这就是PFC和传统PAUSE的核心差异精细度从端口级别下钻到了优先级队列级别。配置PFC之前还得把业务流量映射到正确的优先级队列。一般在交换机上通过QoS配置把DSCP、VLAN priority或者准入控制组映射到本地优先级再映射到对应的硬件队列。很多人以为开了PFC就完事了实际上优先级映射错了PFC控制的是别的队列无损流量依然会丢包。2.2 触发阈值与缓冲区分配为什么有XOFF/XON门限PFC的触发是基于缓冲区的水位阈值而不是简单的时间调度。每个启用了PFC的优先级队列都会分配一定数量的专用缓冲区。队列占用超过高水位通常叫XOFF阈值设备就向对端发送PFC XOFF帧请求对端暂停发送队列水位降到低水位XON阈值之后再发送XON帧或暂停时间为零的帧让对端恢复发送。这里有个关键点XOFF阈值不能设得太高否则在PFC帧到达对端之前本地缓冲区可能已经被后续到达的报文填满依然会丢包。这就要计算“headroom buffer”也就是从发送XOFF到对端真正停止发送这段时间内流量还能继续填进来的数据量。headroom至少得覆盖链路往返时间RTT内到达的帧再加上可能的最大帧等。简单计算100G链路、RTT为1微秒时headroom约为12.5KB但实际交换机为了吸收突发通常会预留更大的缓冲而且还要考虑多个队列、多端口间共享缓冲区的策略。配置缓冲区时很多交换机允许调整XOFF、XON和headroom的大小。把XOFF调低可以更早触发暂停减少丢包风险但也会让PFC帧发送更频繁可能引发性能抖动调得太高则容易在突发时丢包。这个平衡点需要结合业务流量模型去调没有一劳永逸的值。2.3 PFC的死锁风险与缓解策略为什么说它是“无脑暂停”PFC最大的问题不是机制复杂而是它太“一根筋”。如果网络中存在环路或者两个方向的PFC流量都在等待对方释放缓冲区就可能形成循环等待最终导致死锁。我见过一次比较典型的故障两个leaf交换机之间的RoCE流量形成环路A端口持续向B端口发PFC暂停B端口又因为另一个方向的拥塞向A发暂停结果两边都卡住整个无损优先级吞吐归零业务几乎瘫痪。现代交换机通常有死锁检测deadlock detection和恢复机制如果发现某个优先级长时间处于暂停状态会强制退出PFC状态并记录日志甚至重新初始化队列。但依赖交换机自动检测终究是事后补救。实际部署中更推荐的做法是尽量不把PFC优先级跑成环只在端到端路径较短的场景使用同时为PFC优先级配置合理的报警阈值让运维人员在死锁即将发生前就能介入。3. 兄弟机制一起看DCB PFC ETSDCBX到底扩展了什么很多人第一次看到“DCBPFCETSDCBXDCB扩展”这句话时容易理解成DCB就是一个更高级的PFC。实际上DCBData Center Bridging不是一个单一协议而是一组协议族。它提供了一套让以太网同时承载多类服务、并且保证无损传输的机制。PFC解决“丢包”问题ETS解决“带宽怎么分”的问题DCBX解决“两端配置怎么对齐”的问题。3.1 DCB协议族的定位把队列调度和流控绑在一起早期的数据中心桥接尝试叫CEEConverged Enhanced Ethernet后来逐步演进成IEEE 802.1Qbb、802.1Qaz、802.1Qau等标准。802.1Qbb就是PFC802.1Qaz包括ETS和DCBX802.1Qau是QCN拥塞通知但在实际的数据中心部署中QCN用得很少大家提到DCB时基本聚焦在PFC和ETS以及用来交换参数的DCBX。从功能看PFC管的是“某个优先级队列在拥塞时的行为”ETS管的是“不同优先级组之间怎么分配带宽”。两者是互补的PFC保证不丢包ETS保证在有限带宽下关键流量不被普通流量挤死。如果只有PFC而没有ETS一个突发的高优先级流量可能占满整个端口带宽其他优先级即使有PFC机制也可能长期得不到发送机会。所以把DCB看作一个完整的QoS框架更合适它要求网络工程师同时配置流控参数和调度参数才能构建出真正可预期的无损以太网。3.2 ETS用ETS把带宽切给关键流量ETS全称Enhanced Transmission Selection增强传输选择。它允许把一个端口上的优先级划分成多个优先级组Priority Group并为每个组分配带宽比例。调度方式可以同时支持严格优先级Strict Priority和基于加权带宽的分配。举个例子我们计划在100G端口上承载三类流量普通TCP业务、RoCE存储流量、管理流量。可以把优先级0-1映射为普通业务组优先级3映射为无损存储组优先级7映射为管理组。然后给普通业务组分配40%带宽存储组60%带宽管理组使用剩余带宽或设为严格优先级。ETS的另一个好处是“带宽借用”如果存储组当前只有少量流量未使用的带宽可以动态让给其他组使用等存储流量上来后再回收。配置ETS时我总是提醒自己ETS只是调度策略不会替PFC兜底。如果把带宽比例搞得太极端比如一个突发流量组只分配了10%带宽那么它在拥塞时依然可能因为排队积压触发PFC暂停。ETS和PFC要一起规划不能各自为战。3.3 DCBX让交换机和对端自动对齐参数DCBXData Center Bridging eXchange是DCB的扩展协议本质上是一个基于LLDP链路层发现协议的协商机制。它让相邻设备自动交换和发现DCB能力参数也就是在链路的两个端点上同步PFC、ETS等配置。DCBX的TLVType-Length-Value可以携带PFC使能优先级、ETS优先级组和带宽配置、应用优先级映射等信息。交换机开启DCBX后可以通过LLDP帧把自己的配置通告给服务器网卡服务器网卡也能把自己的能力通告给交换机。这样两端配置不一致的问题就能在链路层暴露出来。但DCBX不是万能的。它有willing和不willing两种角色配置稍有不匹配可能导致协商结果不符合预期。我记得有一次同事给服务器网卡开启了DCBX但交换机的DCBX管理角色和网卡期望的角色不一致结果PFC参数没能成功下发网卡端显示PFC disabled而交换机端显示已启用。排查了半天最后发现是网卡驱动配置里DCBX角色选错了。所以DCBX可以辅助部署却不能替代人工核对关键参数。3.4 从网卡视角把DCB参数装进RoCEv2传输链路在实际部署里服务器网卡和交换机配合时我习惯把整条链路拆成几段看。首先RoCEv2消息从网卡发出前会被标记到一个指定用户优先级通常建议用优先级3。其次网卡内部的队列调度需要设置ETS参数保证这个优先级具有足够的带宽额度。再次交换机入方向收到报文后会把该优先级的流量放入对应的PFC启用队列如果拥塞交换机向服务器发送PFC暂停帧网卡必须能响应并暂停发送。如果服务器网卡没有开启PFC交换机发给它的PFC帧就只是被静默丢弃无损链路就成了伪无损。所以配置DCB时千万不要只顾交换机而忽略主机。最终PFC、ETS、DCBX这三个组件要形成一个闭环DCBX负责对齐参数ETS负责分配带宽PFC作为最后一道防线防止队列溢出导致丢包。4. 配置DCB时绕不开的细节从交换机到网卡的参数对齐我见过太多网络工程师在交换机上把PFC开起来然后服务器网卡没配或者配了但优先级不一样最后业务还是时延高。这里我把从交换机到网卡的配置要点按顺序整理一下虽然命令因厂商而异但思路是通用的。4.1 交换机上的PFC配置步骤优先级、队列与缓冲区联动第一步是定义流量分类通常可以把无损伤流量的DSCP值或VLAN优先级映射到交换机上的QoS队列。比如把RoCE标记为DSCP 26映射到本地队列3。第二步是启用PFC命令一般是“priority-flow-control mode on”和“priority-flow-control priority 3 on”这类形式不同厂商可能有差异。第三步是调整缓冲区设置XOFF阈值和headroom。第四步是开启DCBX让配置能被对端发现。以常见的厂商风格为例配置逻辑大致如下# QoS分类将DSCP 26映射到队列3 class-map type qos match-any rocetraffic match dscp 26 policy-map type qos dcbtest class rocetraffic set qos-group 3 set priority-code-point 3 # 接口下发 interface Ethernet1/1 service-policy type qos input dcbtest priority-flow-control mode on priority-flow-control priority 3 on dcbx enable这里提醒一个容易忽略的点PFC优先级和ETS优先级组必须一致。如果你在PFC里启用了优先级3在ETS里却把优先级3和普通流量分在同一组那么PFC暂停时可能连累同组的普通流量或者普通流量的拥塞触发PFC暂停影响无损业务。所以建议在纸上先画好“优先级→队列→优先级组→带宽比例”的映射表再动手配置。4.2 网卡侧的DCB设置Linux下的dcb命令和mstconfig服务器端的配置往往是整个无损链路最容易被忽略的一环。在Linux下通常可以用dcb命令配置网卡的DCB参数。这个命令在iproute2工具包中已经很完善了。比如# 启用优先级3的PFC dcb pfc set dev eth0 priority 3:on # 配置ETS优先级组0使用strict优先级3使用ETS带宽分配50% dcb ets set dev eth0 tc-tsa 0:strict 3:ets dcb ets set dev eth0 tc-bw 0:0 3:50 4:50 # 查看配置 dcb pfc show dev eth0 dcb ets show dev eth0对于Mellanox网卡还可能需要用mstconfig设置DCBX模式或RoCE模式mstconfig -d dev set DCBX_MODE1 mstconfig -d dev set ROCE_MODE2网卡端配置完之后建议立刻检查ethtool -S输出看有没有PFC暂停帧计数。如果交换机上已经启用了PFC但网卡侧完全没有收到PFC帧的计数很可能是DCBX协商没生效或者网卡的PFC功能没有打开。4.3 排查PFC生效与否计数器、debug命令和抓包技巧排查PFC最直接的方式是看计数器。交换机上的典型命令有# Cisco Nexus show interface priority-flow-control show queueing statistics # Arista show queueing pfc show hardware counter dropLinux主机上可以用ethtool -S查看MAC层暂停帧计数。比如关注rx_priority_pause_ctrl_frames和tx_priority_pause_ctrl_frames这两类字段。如果你给网卡发起了大流量却始终看不到这类计数那基本可以断定PFC没有真正生效。更暴力但也更有效的手段是抓包。PFC帧属于MAC控制帧EtherType为0x8808用tcpdump可以过滤tcpdump -i eth0 ether proto 0x8808 -nn -e抓包时注意看帧里的使能向量。如果抓到的PFC帧中bit3是1说明该帧在暂停优先级3如果bit0是1就是暂停优先级0。如果交换机发出的PFC帧和网卡接收到的帧使能向量不一致说明两端优先级映射没对齐。有一次我排查时发现交换机持续向网卡发送优先级4的PFC帧但网卡把RoCE流量放在优先级3两边完全错位。原因是我们之前在设计文档里定义了优先级3后来某次配置迁移时有人把交换机端的映射改成了4主机端没动。所以DCBX和人工核对都很重要who knows? 这两个机制要配合使用不能互相替代。5. PFC/DCB的隐性成本与性能调优我不想只配置完就不管PFC和DCB配置上线后并不代表网络就稳了。相反PFC一旦被触发说明网络已经出现了拥塞风险。运维阶段需要关注的是PFC风暴、死锁、缓冲区规划以及和ECN等拥塞控制机制的配合。5.1 PFC风暴与PFC死锁最常见的两种故障模式PFC风暴通常表现为某个优先级的PFC暂停帧在链路上持续、高频地发送。比如网卡或交换机的缓冲区长期处于XOFF门限之上造成对端和本端之间来回暂停整个优先级的吞吐量趋近于零。PFC死锁则更像操作系统里的死锁——多个设备之间由于缓冲区占用形成了循环等待条件谁也无法继续发送。这两种故障有一个共性它们不会像丢包那样直接体现在CRC错误或接口updown状态上而是“看起来链路是通的流量却上不去”。所以监控PFC帧频率至关重要。我在生产环境里会针对每个端口设置PFC帧速率告警一旦速率超过基线值就触发通知避免长时间无人发现。5.2 如何正确规划优先级组和缓冲区谈到Buffer规划我先说一个常见误区不能把所有优先级都开PFC。历史上有些项目图省事所有队列全部启用PFC结果一个优先级拥塞其他优先级跟着被暂停整个网络时不时“卡壳”。正确做法通常只选择少量、真正的无损流量优先级开启PFC其他流量保持普通转发。缓冲区分配的核心参数是XOFF门限和headroom。上文提到headroom要覆盖PFC往返延迟产生的数据量实际配置时还得考虑多队列共享缓冲区的模式。有些交换机支持为PFC优先级单独预留一段“无限头”缓冲不让它占用普通流量缓冲池避免某个优先级突发时抢占所有共享内存。比如在100G端口上典型情况可能需要预留几十KB到几百KB的headroom具体值还要看设备buffer大小和业务模型。我个人的建议是先在低负载或仿真环境里压测观察PFC帧的出现频率再逐步调优XOFF找到一个既不会丢包、又不会过早触发暂停的门限。没有统一最优值必须结合自己的网络拓扑和流量模型。5.3 优先用ECN和拥塞控制让PFC退居二线PFC毕竟是链路级机制它只解决“缓冲区不够别丢包”并没有告诉发送端“你得降速”。所以业界更推荐的方案是在无损优先级上同时启用ECNExplicit Congestion Notification和PFC用ECN作为端到端的拥塞反馈让发送端主动降低发送速率PFC则作为网络过载时避免丢包的兜底。RoCEv2支持ECN标记。交换机通过WRED或类似算法在队列深度超过阈值时给报文打上ECN标记接收端网卡收到ECN标记后通过CNPCongestion Notification Packet反馈给发送端发送端按DCQCN等算法降速。这样可以把拥堵“说”给源头而不是让上游设备盲目暂停。我在实际调优中会把ECN标记阈值设置得比PFC的XOFF阈值更低让ECN先起作用PFC作为最后一道防线。只有当ECN反馈机制失效或者瞬时突发太猛时PFC才会被触发。5.4 监控指标哪些计数器能提前暴露问题运维监控不要只盯着端口up/down和带宽利用率以下几个指标更值得关注PFC帧收发计数数量级突然上涨往往是拥塞在积累。每个优先级的队列丢弃计数如果PFC启用的队列仍有丢弃说明headroom或XOFF配置有问题。ECN标记报文数数值过高说明拥塞控制阈值设置不合理需要调整WRED参数。RDMA网卡的重传计数rdma stat或ethtool -S看到的retransmit数量直接反映无损链路质量。队列深度和暂停时间交换机上可以查看每个队列的平均/最大深度以及PFC暂停持续时长。暂停时间过长可能就是死锁前兆。建议在网络监控系统里把这些指标做成dashboard并设置连续多次超过阈值的告警而不是等PFC帧数量暴涨之后再排查。这个习惯帮我避免过好几次故障。6. 上线半年后我对PFC的认知修正最后聊聊我从第一次配PFC到现在的一些心态变化。刚开始接触PFC时我觉得它就是打开一个开关交换机上配置“priority-flow-control mode on”就完了。真正在业务网络上跑了小半年踩过几次坑之后我对PFC的认知已经从“功能开关”变成了“系统设计”。6.1 我曾以为PFC配置是“两头都一样就行”但不是有一次维护窗口里我在leaf交换机上调整了PFC优先级映射把RoCE流量从优先级3挪到优先级4当时没仔细核对服务器网卡配置。结果刚上线就出现RTT抖动抓包发现交换机在发优先级4的PFC暂停帧服务器端依然用优先级3发送RoCE流量完全不受影响。最终还是有丢包因为流量并没有被真正保护。DCBX本可以纠正这个错误但当时服务器端dcbx没有启用等于丢失了最后一道保险。6.2 调优方向把“怎么减少丢包”变成“怎么减少PFC触发”PFC不丢包只是底线真正的目标应该是让PFC尽量少被触发。后来我们通过ECN标记、ETS带宽限制以及多路径负载均衡把PFC帧从峰值时每秒数万个降到了每秒几百个。这期间最重要的一个动作是给无损优先级设置了合理的ETS带宽上限避免单条大流把整个端口的无损队列占满。限速并不是坏事它比让PFC把上游全部憋住要平滑得多。6.3 回归清单PFC/DCB上线前我会逐项确认这五件事上线前我会按下面的清单过一遍这些也是从故障里总结出来的两端启用的PFC优先级是否完全一致包括交换机和服务器网卡。所有启用了PFC的流量是否都映射到了正确的本地队列ETS优先级组的带宽比例是否和业务模型匹配DCBX是否启用角色配置是否一致协商结果是否符合预期监控系统是否已经采集PFC帧计数、队列丢弃和ECN标记指标如果这五条都能确定我才会放心地把无损流量切到新链路上。PFC和DCB这套体系本身设计得并不复杂真正复杂的是如何在一个多厂商混合、多业务并存的数据中心里把它们配置成一套自洽的系统。希望这篇长文能帮你少踩几个我当年踩过的坑。