[SIGCOMM'24] R-Pingmesh: A Service-Aware RoCE Network Monitoring and Diagnostic System
摘要
RoCE服务对网络故障和性能瓶颈很敏感，随着RoCE网络的扩展，这些问题变得越来越普遍。此外，一些非网络问题表现得像网络问题，可能会浪费故障排除时间。然而，现有的机制无法快速检测和定位网络问题，也无法确定服务问题是否与网络有关。本文提出了R-Pingmesh，这是业界第一个基于端到端探测的服务感知RoCE网络监控和诊断系统。R-Pingmesh可以基于商用RDMA 网卡准确测量网络RTT和主机端处理延迟，区分RNIC和网络内丢包，判断问题是否与网络有关，并评估其对服务的影响。一个月的评估结果显示，R-Pingmesh 定位到的问题中有 85% 是准确的，其中所有157个与交换机相关的网络问题都是准确的。在部署过程中，R-Pingmesh 能有效发现并定位 14 种类型的问题。
R-Pingmesh框架
R-Pingmesh框架图
R-Pingmesh是一个端到端的RoCE网络延迟探测系统。R-Pingmesh的覆盖范围是所有RoCE NIC以及可能存在RoCE流量的交换机和链路。由于主机可以有多个RNIC，因此最小探测粒度是RNIC到RNIC。
R-Pingmesh有三个模块：agent、controller和analyzer。
Agent是每个RoCE主机上的服务，负责构造RoCE数据包（通过RDMA Verbs API）以执行探测任务，并跟踪其发送的所有探测的路径。Controller为所有agent提供pinglist，以指导其探测目标。Analyzer负责SLA跟踪、检测和定位异常，并评估问题对服务的影响。因此，R-Pingmesh有两个功能：集群监控和服务跟踪。
注：SLA——服务等级协议，Service Level Agreement，简称SLA，是服务提供商与客户之间签订的一种正式协议，它规定了服务供应商应提供的服务水平和质量标准。SLA通常包括服务标准和范围、服务水平的定义和要求、故障响应时间和解决时间、技术支持和服务支持、SLA的制定和执行程序、补救措施和损失赔偿、维护满意度和服务评估等内容。
Agent在每个RNIC上构建一个UD QP，用于探测和响应。探测包是一个常规的RoCE数据包，并受到所有RoCE网络问题的影响。使用UD QP进行探测可以减少RNIC连接资源的消耗，并可以准确测量网络RTT和端主机处理延迟。Controller为每个Agent提供两个pinglist：ToR交换机内ping列表和ToR间ping列表。ToR交换机内探测监测ToR交换机下所有RNIC的状态，并实时识别由RNIC引起的异常。ToR间探测有效地覆盖了RoCE集群内ToR交换机之间的所有网络链路，以监控交换机和链路问题。
服务跟踪独立于集群监控，有三个目标：监控服务网络SLA、测量网络RTT和评估问题对服务的影响。服务跟踪中的探测目标是通过监视5元组的服务流获得的，而不是从controller获得的。当agent检测到RDMA连接的建立时，它会解析这些连接的5元组，并构造具有相同5元组的数据包来探测服务网络。服务跟踪的执行取决于本地主机上是否存在RDMA连接。通过探测服务流使用的路径，R-Pingmesh可以连续跟踪服务网络SLAs。此外，通过监控服务性能下降并判断问题是否存在于服务网络中，R-Pingmesh可以评估问题对服务的影响。
挑战
1）使用商用RNIC准确测量网络延迟和终端主机处理延迟。为确保可部署性，测量应使用商用RNIC的标准接口，而不依赖于特殊的固件或驱动程序。然而，商用RNIC在发送/接收数据包时不提供时间戳。它们仅在生成完成队列事件（CQE）时提供时间戳。挑战在于使用这些隐式时间戳来确定RNIC的发送和接收时间，并测量网络延迟和端主机处理延迟。
2）以低开销探测服务网络。为了准确测量服务网络RTT，需要探测服务使用的路径。一个直观的想法是使用与服务流相同的5元组构建探测。然后，这些探测流将被ECMP路由到与服务流相同的路径。在TCP网络中，流通过其5元组对应于进程。在RoCE网络中，RDMA数据包通过UDP封装，该过程使用内部4元组来标识流。此外，Verbs API允许应用程序确定外部5元组中使用的源端口。通过这种方式，RoCE数据包可以很容易地路由到与服务流相同的路径。那么，挑战在于实时检测服务连接何时建立和关闭，并以低开销获得服务流5元组。
3）准确分类异常数据。首先，并非所有检测到的异常都可以归因于网络。例如，超时可能是由与网络无关的主机故障引起的。使用这些数据来定位网络问题可能会产生误导。因此，数据分析中的第一个挑战是准确确定异常是否是由网络引起的。此外，网络异常可进一步归因于RNIC或交换机。准确地对网络异常进行分类也是一个挑战。
R-Pingmesh已发现的问题
作者总结了R-Pingmesh在部署过程中检测和定位的问题。基于这些问题引起的现象，作者将其归类为故障和性能瓶颈。故障通常会导致数据包丢失和无法访问主机或RNIC。在这些情况下，agent可以检测到探测数据包超时。另一方面，性能瓶颈会导致网络延迟增加、处理延迟增加和吞吐量下降。在这些情况下，agent将检测到高网络RTT或处理延迟。根据这些问题的根本原因，它们可以进一步分为硬件故障、配置错误、网络拥塞和主机内瓶颈。
故障问题主要由硬件故障导致（交换机、网卡、线缆、主机宕机）和错误配置触发。
性能瓶颈：网络拥塞导致、节点内的瓶颈（CPU过载、PCIe配置不当，链路速率及带宽降级）。
在所有硬件故障中，No1(RNIC or switch port flapping)是最常见的。当RNIC或交换机端口的状态在up/down之间频繁变化，导致数据包丢失。在部署的早期，作者注意到RNIC端口状态频繁发生变化，在与RNIC供应商进行长期分析后，找到根本原因是RNIC和电缆之间的不兼容，更换电缆后，RNIC的抖动频率显著降低。严重的抖动可能会导致服务流超时。在这种情况下，如果RDMA连接重传超过一定次数但无法成功，它将被中断，导致训练任务失败。为了确保稳定运行，将重传计数设置为最大值，并将重传超时设置为更高的值，以避免在频繁抖动过程中消耗所有重传计数。
损坏或老化的光纤和光模块中的灰尘会导致数据包损坏，导致交换机或RNIC上的数据包丢失（No2）。这些问题将降低吞吐量和训练效率。此外，硬件故障可能会导致意外的RNIC或主机停机（No3和No4）。
最常见的配置错误是No6。RoCE NIC需要为RDMA通信进行额外的路由配置，这是在主机启动后由脚本配置的。但是，这些配置可能会因某种原因失败。除了RNIC配置错误外，交换机配置错误偶尔也会发生。在我们的公共云集群中，不同的租户通过交换机ACL相互隔离。由于集群有多个租户，租户可能会频繁增加或减少他们拥有的主机数量，因此需要频繁配置ACL。由于操作员疏忽或配置脚本中的错误，ACL可能会被错误配置，导致同一租户的不同RNIC之间的连接失败。R-Pingemsh可以通过在集群内的所有RNIC之间随机探测来有效地检测ACL异常。此外，网络管理员的疏忽可能会导致交换机上的PFC未配置或PFC配置错误，从而在严重拥塞期间导致数据包丢失。通过分析超时5元组，R-Pingmesh可以准确地定位异常交换机。
网络拥塞。网络拥塞在大型集群中很常见。除了链路负载不均衡引起的拥塞外，作者还发现了不同服务之间的干扰引起的拥塞。尽管ACL将公共云中的不同租户隔离开来，但来自不同租户的流量仍然可以共享一些网络链接并导致拥塞。在部署过程中，R-Pingmesh发现来自两个不同租户的服务跟踪结果表明存在相同的拥塞链路，并迅速诊断出了问题的根本原因。此外，通过检测网络热点并识别通过它们的流，R-Pingmesh可以指导服务流的负载均衡。
主机内瓶颈。在部署过程中，R-Pingmesh检测到三种类型的主机内瓶颈。第一个是CPU过载，R-Pingmesh可以通过精确测量主机处理延迟来轻松检测到这个问题。R-Pingmesh还检测到由PCIe降级和配置错误引起的主机内带宽降级，其中PCIe降级可能是由松动的PCIe接口、PCIe接口上的灰尘或硬件故障引起的。主机内带宽下降会导致RNIC发送PFC暂停帧，并可能导致PFC风暴。
R-Pingmesh未来方向
1）将R-Pingmesh适配到IB集群。IB集群也存在RNIC和交换网络问题，需要有效的网络监控和诊断系统。由于IB集群也支持Verbs API，R-Pingmesh可以直接部署在IB集群中，并且在检测IB网络问题方面仍然有效。然而，IB集群可能会使用自适应路由进行负载均衡，并且数据包可能会随机路由到并行路径，从而难以准确跟踪探测路径以进一步定位交换网络问题。如何准确定位IB集群中R-Pingmesh检测到的交换网络问题是未来的工作。
2）检测异常GPU。R-Pingmesh使用CPU内存进行RDMA探测。作为限制，它无法直接检测一些GPU问题，例如GPU故障导致的GPU停机和GPU读/写高延迟。在训练集群中，如果R-Pingmesh能够实时探测RDMA服务器内训练流量的路径, 它可以进一步有效地检测这些GPU问题。一个直观的解决方案是使用GPU内存执行RDMA探测。然而，一个GPU进程至少使用几百MB的GPU内存（在Nvidia A100 GPU上测量，并因GPU类型而异），其中大部分被进程上下文消耗。由于GPU内存很有价值，服务团队通常无法承受这种开销。如何以低开销监控终端主机中RNIC和GPU之间的路径是未来的工作。
3）自动诊断根本原因。虽然R-Pingmesh可以快速检测和定位异常，但很难仅从探测结果中诊断出根本原因。例如，如果ToRmesh探测检测到RNIC不断丢弃数据包，则异常可能发生在RNIC、电缆或连接到RNIC的交换机端口上。此外，交换机上的数据包丢失可能是由端口状态波动或数据包损坏引起的。目前，推断这些异常的根本原因需要我们的操作员进一步检查异常计数器和日志，并依靠他们的经验。将探测结果与计数器和日志等更多信息集成，并使用决策树等高效方法进行自动根本原因诊断，是未来的工作。
4）尽量减少硬件故障的影响。尽管R-Pingmesh可以有效地检测硬件故障，如RNIC down以及数据包损坏，但如果这些问题发生在服务运行时，它们可能会导致严重的服务性能下降甚至任务失败。解决这些问题以恢复服务性能通常需要管理员干预，甚至需要重新启动任务，这是低效的。为了尽量减少硬件故障对服务性能的影响，作者提出了三个方向。
a) 监测RNIC和交换机端口上的异常指标，如CRC（循环冗余校验）错误，以尽早预测或检测异常的RNIC和端口，并更换或隔离它们。
b) 如果交换机端口异常丢弃数据包，则根据问题的影响自动确定是否隔离异常端口，以尽量减少性能损失。
c) 如果RNIC发生故障或异常丢弃数据包，直接在服务应用程序中隔离异常的RNIC，而无需重新启动训练任务。
总结
论文提出了R-Pingmesh，这是第一个基于端到端主动探测的服务感知RoCE网络监控和诊断系统。它基于端侧主机和商用RNIC，因此可以轻松部署在数据中心RoCE集群中且开销低。R-Pingmesh有助于准确检测和定位网络和终端主机中的故障和性能瓶颈。R-Pingmesh还可以快速确定问题是否与网络有关，并评估其对服务的影响。已在数万个RNIC上部署了R-Pingmesh，它已成为RoCE网络重要的监测和诊断系统。
