以太网存储网络的拥塞管理连载案例（五）

本文节选自《DetectingTroubleshooting, and PreventingCongestion in Storage Networks 存储网络中拥塞处理》

Troubleshooting Congestion in Lossless Ethernet Networks

解决无损以太网网络拥塞问题的方法与光纤通道结构相同。两者都使用逐跳流量控制机制，只是实现方式不同而已。当交换端口显示出口拥塞时，拥塞的根源在于下游流量路径。当交换端口显示入口拥塞时，一定是因为该交换机上的一个或多个端口在出口方向拥塞。

Goals

正如第 4 章详细介绍的那样，故障排除的目标有两个：

1. 确定拥塞的来源（元凶）和原因： 调查和故障排除的主要目标是确定是否存在拥塞、拥塞源和拥塞原因，拥塞原因可能是慢耗尽（通过高 TxWait（如果可用）或快速递增的暂停计数检测到）或过度利用（通过高出口利用率或微爆发事件检测到）。一旦知道了拥塞的来源和原因，就可以对造成拥塞的终端设备进行详细调查。

2. 确定受影响的设备（受害者）： 次要目标是识别受到罪魁祸首设备不利影响的设备。这些就是受害者。在调查完成之前，您可能不知道设备是罪魁祸首还是受害者。请记住，有时识别不同的受害者类型（直接受害者、间接受害者和同路径受害者）会有所帮助。有关详细信息，请参阅第 4 章 "识别受影响设备（受害者）"一节。

重要的是要明白，受害设备可能会将性能下降报告为罪魁祸首设备。但问题只能通过调查罪魁祸首而不是受害者来解决。

Congestion Severities and Levels

第 4 章定义了光纤通道结构的拥塞严重程度和级别。但它们不能直接用于无损以太网网络，因为与光纤通道不同，无损以太网没有链路（信用）重置的概念，而链路（信用）重置是光纤通道中严重（3 级）拥塞的症状。另一个原因是，如果环境中的设备没有检测这些情况的度量标准，将它们分为不同等级的实际意义就很有限。值得注意的例子是 TxWait 和 RxWait 指标，在撰写本文时，大多数以太网端口都没有这些指标。因此，与光纤通道不同，使用 TxWait 无法检测到 1 级拥塞。

总之，对于无损以太网，不同严重程度的拥塞症状可略作如下调整：

1.  轻度拥塞（1 级）： 延迟增加，但不丢帧。

a. 检测暂停帧数或 TxWait/RxWait （如果有）是否过多以及链路利用率是否过高。

2. 中度拥塞（2 级）： 延迟和丢帧增加。

a. 检测无损级中的丢包情况

3.  严重拥塞（3 级）： 延迟增加、丢帧和流量持续停顿。

a. 使用暂停超时或 PFC 看门狗进行检测，稍后解释

Methodology

我们建议按严重程度递减的方式排除拥塞故障。请注意，这些拥塞严重程度并不是标准化的。它们的唯一目的是帮助用户制定实用的工作流程，从而有助于快速准确地检测和排除拥塞故障。您可以根据自己的环境进行定制。例如，如果没有检测 3 级拥塞的简便方法，可先调查 2 级拥塞（数据包丢弃），然后再调查 1 级拥塞（暂停帧计数或 TxWait（如果有））。

有关详细信息，请参阅第 4 章 "故障排除方法 - 降低电平 "部分。在将第 4 章中的信息应用于无损以太网时，请记住 Rx 信用不可用与光纤通道中的入口拥塞相同，后者在以太网网络中由 Tx Pause 检测到。同样，Tx 信用不可用等同于光纤通道中的出口拥塞，而以太网网络中的 Rx 暂停可检测到出口拥塞。

建议同时学习第 4 章的案例研究。虽然这些案例是针对光纤通道描述的，但从中可以了解到无损以太网网络的故障排除方法是如何类似的。

Troubleshooting Congestion in Spine-Leaf Topology

请参阅图 7-14，它是图 7-8 脊叶网络网络的一个子集。正如前面 "无损脊叶网络中的拥塞 "一节所解释的，一个罪魁祸首可能会使许多设备受害，而这些受害设备的用户也可能会报告性能下降。因此，自然要从最先报告问题的地方开始排除故障，即受害设备或其连接的交换端口。无论从哪里开始，重要的是要追踪拥塞的源头，同时寻找严重性较高的事件，然后是严重性较低的事件（3 级 2 级 1 级）。

Figure 7-14 Congestion troubleshooting direction in a lossless spine-leaf network

假设连接到 Leaf-1 的受害主机上的应用程序报告性能下降。这些是间接受害者，因为它们接收来自目标-1 的流量，而目标-1 是罪魁祸首主机-1 的直接受害者。但在故障排除结束之前，这一点还不得而知。故障排除工作流程如下：

1. 转到受害主机直接连接的交换端口。如果发现出口拥塞症状（Rx 暂停或出口丢包），那么这台主机就是罪魁祸首。

2. 如果没有，请在同一交换机的任何其他边缘端口上查找入口拥塞症状（Tx 暂停）。如果发现这样的设备（Target-1），它一定在向罪魁祸首（Host-1）发送流量（如果只有一个拥塞事件或罪魁祸首）。

3. 然后，在 Leaf-1 的上游端口上查找出口拥塞症状。

4. 转到其中一个上游设备（例如 Spine-1）。Spine-1 发送的 Tx 暂停应与 Leaf-1 上游端口上的 Rx 暂停一致。如果它们的值不一致，请调查位错误或固件错误。

5. 在 Spine-1，查找有出口拥塞症状（Rx 暂停）的端口。这些端口通常会传输从显示入口拥塞的端口接收到的流量。

6. 转到流量路径中的下一个设备（Leaf-6）。Leaf-6 发送的 Tx 暂停应与 Spine-1 上的 Rx 暂停一致。如前所述，如果它们的值不同，则应调查位错误或固件错误。

7. 在 Leaf-6 上，查找有出口拥塞症状（Rx 暂停或出口丢包）的边缘端口。这应该是连接到罪魁祸首主机（Host-1）的交换端口。如果未发现 Rx 暂停或出口丢包，则调查端口是否过度使用。

在任何设备上，如果有更多端口出现出口拥塞症状，应先处理较严重的症状。例如，先处理丢包后处理 Rx 暂停。同样，如果 TxWait 不可用，应先处理快速增加的暂停计数，再处理缓慢增加的暂停计数。

Reality Check

图 7-14 所示的故障排除工作流程需要进行实际检查，原因如下。

1. 此故障排除工作流程只能在拥塞状况持续期间使用，因为与 Cisco MDS 交换机和 Nexus 7000/7700 交换机不同，大多数以太网交换机（包括 Cisco Nexus 9000 交换机）不保留带有时间和日期戳的拥塞事件历史记录。

2. 由于大多数以太网交换机不报告 TxWait 和 RxWait 的百分比，因此即使实时排除故障也很繁琐。在 Cisco Nexus 9000 交换机和 Cisco UCS 服务器上，命令输出中只有累计暂停计数。用户必须多次执行这些命令并手动计算差值，如例 7-7 所示。为数百个端口执行这些步骤既困难又耗时，而且容易出错。试想一下，在图 7-8 中可能有数百个端口的脊柱交换机上手动计算这一结果。

3. 正如前面有关暂停帧数的章节所述，暂停帧数的名义增长并不一定表示拥塞。

4. 请注意，造成拥塞的原因可能不止一个。如果造成拥塞的原因在不同的交换机上，那么可能会有不止一条路径。

5. 最后，在手动解释暂停帧数时，如果拥塞条件停止，由于事件没有时间和日期标记，因此无法知道其计数何时增加。

由于这些原因，使用命令行界面很难排除无损以太网网络拥塞的故障。

Troubleshooting Congestion using a Remote Monitoring Platform

通过使用远程监控平台，可以改变在无损以太网网络中排除拥塞故障时令人不快的现实，该平台可持续轮询暂停帧的数量，以保存带有时间和日期戳的历史记录。

UCS 流量监控 (UTM) 应用程序就是此类应用程序的一个示例。有关详细信息，请参阅第 9 章。UTM 应用程序可以使用比较分析、踩点和季节性等方法近乎实时地检测拥堵情况并排除故障。

Comparative Analysis

比较网络端口（主机端口和交换机端口）的暂停帧速率，检测是否有几个端口的暂停帧数比其他端口高得多。

在图 7-8 中，有数千台主机、

1. 每 60 秒从边缘交换端口或主机轮询一次 Tx 和 Rx 暂停。

2.  计算累计暂停帧数的 delta 值，了解 60 秒内的变化情况。

3.  按 "Tx 暂停 "降序排列主机，或按 "Rx 暂停 "降序排列边缘交换端口。

4. 调查该列表中排名前 10 位的主机。通常情况下，这些主机的慢排空严重程度较高。

应在所有类似实体中使用相同的比较分析。例如，将所有骨干端口相互比较，检测是否有几个端口报告了过多的暂停帧。

Trends and Seasonality

暂停帧对无损以太网网络的运行非常重要，因此其正常活动是没有问题的。但要仔细分析任何峰值和谷值。此外，还要查找暂停帧计数在过去几天或几周内是否一直在上升，尽管可能不会出现任何突然的峰值。此外，还要查找是否存在季节性，即暂停帧数的峰值是否出现在一天中的特定时段或一周中的特定日子，甚至一年中的特定月份。

从图表上看，低计数的直线就可以了。注意峰值，尤其是持续时间较长的大峰值。

Monitoring a Slow-drain Suspect

可疑设备是发送暂停帧的终端设备。但它不一定是罪魁祸首。可以肯定的是，我们需要更多的信息，因为如前所述，仅仅计算暂停帧的数量并不能说明传输到底停止了多长时间。

根据我们的经验，以下几种方法有助于判断嫌疑人是否也是罪魁祸首。

1. 不发送暂停帧的终端设备不是慢排空的来源。可以将这些设备排除在可疑设备列表之外，从而只关注那些发送暂停帧的设备。

2. 终端设备每秒最多只有几百个暂停帧（如少于 300 个）并不会使其成为可疑设备。但是，当暂停帧速率增加到每秒数百或数千的大倍数时，终端设备就会成为可疑设备。每秒数百万个暂停帧无疑会使终端设备非常接近于罪魁祸首，因此应积极监控。

3. 检查上游端口的拥塞扩散症状。例如，在脊叶拓扑结构中，主机暂停帧速率的峰值是否与位于主机流量路径上的骨干交换机端口的暂停帧速率峰值一致？如果是，则表明拥塞正在蔓延，因此主机是罪魁祸首。如果不是，则表明主机只是瞬间暂停了流量，因此不会成为罪魁祸首。

4.  比较终端设备在两个（或多个）端口上发送暂停帧的速率。通常情况下，它们的速率应该是一致的。但如果一个端口每秒发送数百个暂停帧，而另一个端口每秒发送数百万个暂停帧，或出现类似的非均匀暂停帧速率，则需要进行调查。

5. 高暂停帧速率或暂停帧速率的增加必须与终端设备上层的事件相关联。例如，终端设备上的 I/O 错误、应用性能下降、I/O 完成时间增加和 IOPS 减少。这种关联必须在网络中的可疑终端设备（发送暂停帧）和其他终端设备（不发送暂停帧）上进行。这是因为，如果可疑设备真的是罪魁祸首，那么由其造成的拥塞就会扩散，使许多其他终端设备受害。

6. 网络端口的过多 Tx 暂停帧应导致该链路的 Rx 流量降低。如果结果与此不同，则可能表明暂停帧没有到达流量发送方，或者没有被正确处理，或者是在没有 TxWait/RxWait 的情况下，仅使用暂停帧数量检测拥塞的局限性，这在前面有关 PFC 风暴的章节中已有解释。需要记住的要点是比较暂停帧和相反方向的流量。

Monitoring an Over-utilization Suspect

正如第 1 章 "定义完全使用率 vs 高使用率 vs 过度使用率 "和 "监控完全使用率 vs 高使 用率 vs 过度使用率 "两节所述，我们建议将任何高使用率（如超过 80%）情况与过度使 用率同等对待。这是因为，根据我们的经验，大多数高使用率情况也有一定的过度使用时间。要确定高使用率是否导致拥塞，可监控上游端口的暂停帧。但在开始调查时，除非另有证明，否则应将高使用率情况与过度使用情况同等对待。这种方法节省了检测拥塞和寻找解决方案的时间。

FC and FCoE in the Same Network

有些交换机，如 Cisco Nexus 9000 交换机、Nexus 5000/6000 交换机和 Cisco UCS Fabric Interconnect 可以有 FC、FCoE（无损）和以太网（有损）端口。这些交换机以类似于前面解释的方式将拥塞从流量控制出口端口扩散到流量控制入口端口。唯一不同的是流量控制机制，因此检测拥塞的指标也不同。

请注意，FC 端口使用 Rx B2B 信用不可用检测入口拥塞，使用 Tx B2B 信用不可用检测出口拥塞。有关光纤通道指标的详细解释，请参阅第 3 章。

FCoE 端口（无损以太网）使用 "Tx 暂停 "检测入口拥塞，使用 "Rx 暂停 "检测出口拥塞。前面关于拥塞检测指标的章节解释了这些指标。

Consider Figure 7-15 with the following components.

 有损以太网： 没有逐跳流量控制（如 PFC 或 LLFC）的骨干网络。这部分网络的流量依靠其他机制（如 OSI 模型第 4 层的 TCP）进行拥塞控制。

 无损光纤通道： 具有 B2B 流量控制功能的边缘核心光纤通道 Fabric。MDS-1 连接存储阵列（Target-1 和 Target-2）。

  融合（有损+无损）以太网： 有损以太网网络和光纤通道结构共享叶子交换机（L-4 和 L-6）。它们有专用的以太网上行链路（无流量控制）连接到骨干交换机，光纤通道上行链路连接到 MDS-1。下行链路连接到一个或多个 FEX（FEX-4 和 FEX-6），最终连接到主机。叶子到 FEX 链路和 FEX 到主机链路使用 PFC。无损 FC/FCoE 流量保持在无丢包类别中，而有损以太网流量保持在不受流控制的其他类别中。

FEX 代表思科 Fabric Extender。从外形上看，它像一个交换机，但实际上像一个远程模块。它需要一个父交换机来实现控制功能（如路由协议）和管理功能（如配置端口）。父交换机和 FEX 之间的链接使用 SFP 和电缆，并运行逐跳流量控制（如 PFC）。这与 ISL 类似。因此，在处理拥塞时，可将 FEX 视为交换机，尽管从一般意义上讲，FEX 本身可能并不符合交换机的条件。

图 7-15 是思科 UCS 架构的近似表示。叶子交换机代表 Fabric Interconnects，FEX 代表 I/O 模块 (IOM)，主机代表服务器。有关 Cisco UCS 服务器的详细信息，请参阅第 9 章。

让我们分析 Host-1 和 Host-2 造成的拥塞事件，并遵循故障排除方法。

Congestion Spreading due to Slow-Drain

在图 7-15 中，Host-1 是一个慢速排空设备，因为它的无损流量处理速率低于向其传送帧的速率。因此，它会向 FEX-4 发送 PFC 暂停帧，以降低无损类别的流量速率。无损类之外的流量不受流量控制，因此在队列满时可能会被丢弃。

当超过 FEX-4 的暂停阈值时，它会向 L-4 发送 PFC 暂停帧，以降低不丢弃类的流量速率。但 L-4 的上行链路（入口端口）运行光纤通道。当其缓冲区耗尽时，它会降低向上游邻居（MDS-1）发送 R_RDY 的速率。最后，MDS-1 降低向目标发送 R_RDY 的速率，以减少来自目标的流量。

Congestion Spreading due to Over-Utilization

请看图 7-15 中的主机-2。它没有造成慢排空，但在其交换端口的出口方向上造成了 100% 的使用率，这可能会因过度使用而导致拥塞。用前面解释过的类似方法从 MDS-1 追逐拥塞源时，在到达 FEX-6 后，可能找不到任何有 Rx 暂停增量的出口端口。在这种情况下，请查找正在以高出口利用率运行的端口，这是过度利用导致拥塞的迹象。这样就能找到罪魁祸首 Host-2。

Figure 7-15 Congestion troubleshooting workflow with FC and FCoE in the same network

请注意以下几点：

1. FC 和 FCoE 混合网络中拥塞的蔓延情况与仅有 FC 或仅有 FCoE 的网络类似。

2. 在 FEX-4 和 FEX-6 的上行链路上，排空缓慢和过度使用也会导致类似的症状。即使在 L-4、L-6 和 MDS-1 上也无法找到拥塞原因。只有 FEX-4 和 FEX-6 上的边缘链路能明确区分拥塞原因，因为它们直接连接到拥塞源（罪魁祸首终端设备）。

3.无损以太网链路（L-4 和 L-6 下行链路）和光纤通道链路（L-4 和 L-6 上行链路）的拥塞故障排除方法与前面解释的相同。不同之处在于，L-4 和 L-6 交换机本身需要追寻拥塞源。在这些交换机上，入口（FC）端口使用光纤通道指标，出口（以太网）端口使用 PFC 指标。它们的命令不同。执行这两种命令，检查交换机上 FC 和 FCoE 流量的出口拥塞情况。

4. 在图 7-15 中，如果 L-4 不在上行 FC 端口（例如 Cisco UCS Fabric Interconnects）上提供入口拥塞检测指标，则可以使用 MDS-1 上的出口拥塞检测指标。同样，如果 Host-1 不监控 Tx 暂停帧（或监控起来不够方便），则可选择监控 FEX-4 上的 Rx 暂停。

Bit Rate Differences between FC and FCoE

交换机在 FC 和 FCoE 端口之间传输流量时，必须仔细考虑比特率的差异。如第 2 章 "光纤通道比特率"、"光纤通道速度与比特率之间的差异 "和表 2-4 所述，某些光纤通道比特率与宣传的速度有很大差异。例如，8GFC 端口的比特率为 8.5 Gbps，但考虑到 8b/10b 编码，只能以 6.8 Gbps 的速度传输数据。这使得 10 GbE 的 "速度 "几乎比 8GFC 快 50%。因此，当 FCoE 流量从 10 Gbps 以太网端口切换到 8GFC 端口时，可能会出现速度不匹配导致的拥塞。当流量从 16GFC 端口（比特率为 14.025 Gbps）切换到工作速率为 10 Gbps 的 FCoE 端口时，会出现另一种常见的拥塞情况。正如本章所述，速度或容量不匹配程度越高，拥塞就越容易发生和蔓延。

虽然无法完全消除以太网和光纤通道在比特率上的差异，但必须尽可能地缩小它们之间的差距，例如 32GFC 和 25 GbE。除了端口速度外，还应考虑共享 FCoE 链路的最低带宽保证，因为 FC/FCoE 流量可能不允许占用链路的全部容量。

对于带有 FC 和 FCoE 端口的交换机，如 Cisco UCS Fabric Interconnect（参见第 9 章），这应该是一个设计层面的决策。初步设计完成后，应持续监控流量模式，并根据需要增加额外容量。

Multiple no-drop Classes on the Same Link

当无损以太网网络中启用了多个无损类时，请按照每次一个类（CoS）的拥塞故障排除方法进行操作。

图 7-15 中的融合拓扑只为 FCoE 流量设置了一个无损类。在同一拓扑中，可为 RoCEv2 流量启用另一个无损类。

请参阅图 7-16。存储阵列连接到叶子交换机 (L-1)，并为 RoCEv2 进行了配置。 主机-1 和主机-2 通过 FEX-4 连接到叶子 L-4。这些主机以分配给 CoS 5 流量的无损类访问 RoCEv2 存储。脊叶拓扑现在可为 CoS 5 流量提供 PFC。RoCEv2 流量使用 IP 标头中的 DSCP 字段进行分类，从而实现前面所述的第 3 层 PFC。不过，为简单起见，本节假定 RoCEv2 是表 7-1 中 CoS 到 DSCP 映射的 CoS 5 流量。 

Figure 7-16 Congestion troubleshooting with multiple no-drop classes

FCoE 主机（Host-3）连接到 FEX-4，并将 FCoE 流量分配到 CoS 3。 FEX-4 和 L-4 将 CoS 3 流量分配到专用的无损类。在 L-4 上，CoS 3 流量通过光纤通道上行链路发送。

总之，在此拓扑中，L-4 和 FEX-4 之间的链路为两个无损类配置了 PFC，分别分配给 CoS 5 和 CoS 3。 因此，交换端口创建了两个独立的无损队列，分别有自己的暂停阈值和恢复阈值。

当 Host-1（RoCEv2 主机）成为慢排空设备时，它会发送 CoS 5 的 PFC 暂停帧。当 FEX-4 的暂停阈值超过 CoS 5 队列时，它只向 L-4 发送 CoS 5 的 PFC 暂停帧。结果，Host-2（另一台使用 CoS 5 的 RoCEv2 主机）因 L-4 和 FEX-4 之间的共享链路拥塞而受害。

L-4 不会接收 CoS 3 的 PFC 暂停帧，因此不会减慢 CoS 3 流量。因此，FCoE 主机（Host-3）不会受到影响。

在 L-4 上，拥塞只扩散到 CoS 5 上行链路（骨干交换机），而不扩散到光纤通道上行链路。

总之，启用多个不丢包类别时，应分别注意每个类别的拥塞症状。分析 L-4 上每个端口的暂停计数器可能会导致错误的方向。只在 CoS 5 中排除故障可以找到拥塞源（Host-1）。

Bandwidth Allocation Between Lossless and Lossy Traffic

回想一下，增强传输选择（ETS，除 PFC 外）是使融合（有损+无损）以太网取得成功的重要功能，因为它为无损类提供带宽保证，同时与其他类别的流量共享链路。

请注意以下有关使用 ETS 分配带宽的要点：

1. 每个无损类别都预留了最少数量的缓冲区。

2. 无损类别会被分配一个最小带宽，例如链路容量的 50%。但这并不是 "无损 "类所能达到的最大带宽。当其他类没有流量时，流量类最多可占用 100% 的链路容量。

3. 但是，当其他类别有流量时，无损类别的带宽分配就会受到限制（假设为 50%）。这可能会因过度使用而造成拥塞。

4. 端口在无损等级中的传输容量为 50%，在其他等级中的传输容量为 50%。

5.当端口已按各流量等级的带宽分配满负荷传输时，例如无损等级的流量为 50%，其他等级的流量为 50%、

a. 如果交换机上的其他端口接收到的有损类流量超过了该端口的发送量，多余的流量就会像有损网络一样被丢弃。

b. 如果交换机上的其他端口接收到更多要从该端口发送出去的无损类流量，则接收到多余流量的端口会在暂停阈值处发送一个暂停帧。每个入口端口都维护有自己的暂停阈值、恢复阈值和净空的无损队列。这种情况就像过度使用造成的拥塞，并导致拥塞扩散。

Effect of Lossy Traffic on no-drop Class

一个常见的误解是，有损类中的流量不会影响无损类。这取决于处理问题的方式。

无损类的流量可以消耗 100% 的容量。但是，当其他类有流量时，它就会被限制在保证带宽内。换句话说，以前不会造成拥塞的链路，在其他（有损耗）类别的流量增加后，可能会开始造成拥塞（由于过度使用）。例如，考虑一条 10 GbE 链路，其中 5 Gbps 分配给无损类，5 Gbps 分配给其他类。如果不存在其他流量，无损类中的无损流量可以消耗掉链路的全部容量。但是，如果其他流量需要 2 Gbps，无损流量将被限制在 8 Gbps。这台交换机现在必须将其他端口的入口速率均衡为 8 Gbps，而之前的速率为 10 Gbps。为实现速率均衡，交换机会调用 PFC，导致拥塞扩散。

如果只监控 I/O 吞吐量，这种情况就不容易理解了。早期，10 Gbps 的 I/O 吞吐量不会造成拥塞。后来，仅 8 Gbps 就会造成拥塞。

由于这些原因，在融合存储网络甚至共享存储网络中确定过度使用情况要比专用存储网络困难得多。再也不能通过出口百分比利用率来确定过度利用。在链路级别上分别监控每类流量和每类拥塞情况，以及将两者结合起来，有助于更好地理解和检测此类问题。

Case Study 1 — An Online Gaming Company

一家在线游戏公司将融合以太网网络用于无损存储 I/O 流量和有损 TCP/IP 流量。他们的服务器以 10 GbE 连接网络，50% 的带宽分配给无损类。他们的链路利用率很少超过 90%。

他们报告了以下观察结果：

 许多应用程序都报告了性能下降。

 问题只在工作时间出现。

 在同一时间段内，他们发现了一台 CPU 高的服务器，但这台服务器的链接利用率从未超过 70%。在这台服务器上运行的应用程序的所有者怀疑存在存储访问问题。

CPU 高并不是有力的证据，但应用程序所有者怀疑是存储问题。他们没有在主机上看到任何 I/O 错误。为了验证网络拥塞情况，他们检查了该服务器链接上的暂停帧计数。他们发现，在问题持续期间，服务器发送了很多暂停帧。此外，连接该服务器的交换机也在其上行链路上进一步发送暂停帧。这是拥塞的扩散，可能会使许多其他服务器受害。

接下来，他们想找到在链路利用率保持在 70% 以下的情况下，该服务器出现高 Tx Pause 的原因。他们开始监控每个类的流量利用率，并在问题持续期间发现了以下情况：

1.  服务器入口链路利用率从 5 Gbps 提高到 7 Gbps。

2.每级流量监测显示

a. 无损类的流量从 2 Gbps 降至 1.5 Gbps。

b. 其他（有损）类别的流量从 3 Gbps 增加到 5.5 Gbps。

根据这些观察结果，我们怀疑其他（有损）流量的增加可能会导致 CPU 使用率过高，从而没有足够的资源来处理存储 I/O。因此，服务器试图减慢入口 I/O 流量，这一点从暂停帧的数量和整个 I/O 的减少可以看出。

为了验证这一理论，他们将该应用程序移到了一台 CPU 数量更多的强大服务器上。这一改变之后，应用程序不再遇到性能问题。有损类流量保持在 3 Gbps 至 5.5 Gbps 之间。无损类的平均流量为 2 Gbps。暂停帧数保持在最低水平，没有出现任何峰值或骤降。服务器的 CPU 使用率也不高。

除了说明监控每个端口和每个类流量利用率的重要性外，本案例研究还展示了全栈可观测性如何帮助更快、更准确地检测拥塞问题。但全栈可观察性并不是本案例研究的目的。真正的教训是，当有损类的流量增加时，可能也会导致无损类的拥塞。在本案例中，真正的问题出在网络之外，也就是服务器的 CPU 容量，但其影响却体现在网络上，使许多其他服务器也深受其害。

不能一概而论地认为 CPU 高会导致 I/O 性能问题。只有在本案例研究中，CPU 高才会导致问题。影响 I/O 性能的原因还有很多。本案例研究的关键是了解有损耗类流量对无丢包类的影响。

Case Study 2 — Converged Versus Dedicated Storage Network

本案例研究与案例研究 1 相似。不同之处在于服务器的 CPU 利用率不再很高。此外，无损类的平均流量为 6 Gbps（60%），有损类的平均流量为 2 Gbps（20%）。当报告应用性能下降时，持续时间也与会聚链路的 100% 利用率相吻合。对每类流量利用率进行调查后发现，有损类的流量从 2 Gbps 激增到 5 Gbps。同时，无损类的流量从 6 Gbps 下降到 5 Gbps。这是因为在这条 10 GbE 链路上，无损类被分配了 5 Gbps（50%）的带宽保证。但该交换机其他端口上无损流量的总入口速率仍为 6 Gbps。为了将这些流量均衡到 5 Gbps，该交换机调用了 PFC，从而导致拥塞扩散。交换机上接收边缘端口发送流量的其他端口上的 Tx 暂停帧峰值证实了这一点。

在本案例研究中，明显的问题是融合链路的容量不足，以及无损和有损类之间的流量争用。通过增加另一条 10 GbE 链路，这一问题得以解决。

在本案例研究中，两种类型的流量（有损和无损）都使用两条链路，这是共享存储网络的方法。另一种有效的方法是将一条链路专用于有损（普通级）流量，另一条链路专用于无损（无丢包级）流量，这就是专用存储网络的方法。

正确答案在于链路的容量和这些链路的预期吞吐量。专用存储网络是一种不同的架构，需要以不同的方式进行操作。其优点在于结构的独立性、可扩展性、故障隔离和更易于故障排除。相反，专用存储网络的部署成本更高，需要更多资源来管理和运行。

 

审核编辑：刘清