When Cloud Storage Meets RDMA

When Cloud Storage Meets RDMA

1、Introduction

阿里巴巴在内的众多公司已经将其核心业务系统转移到云上。作为信息技术（IT）基础设施的基本组成部分，云存储向云提供商内外的租户提供存储服务。2009年，阿里巴巴推出了云存储系统Pangu（盘古），随后在阿里巴巴的许多核心业务中发挥了至关重要的作用。截至2020年，盘古已经部署在数百个集群中，并管理着数十万个存储节点。此外，它还支持在许多生产环境中对EB级数据的实时访问。（1 EB = 1,024 PB = 1,048,576 TB = 1,152,921,504,606,846,976 Bytes）

为了确保与本地物理存储集群的可比性，云存储系统必须满足以下要求：

（i） 高性能：低延迟和高吞吐量–在许多场景中提供了竞争优势。

（ii）**高可用性：**系统中断会给租户及其云提供商带来重大的财务/声誉损失。

（iii）SLA:service-level agreement：云存储系统必须具有弹性，因此，当各种软硬件故障发生时，其性能应适度下降。

存储介质的快速发展使网络技术落后，这给新一代云存储带来了严重的性能瓶颈。对于使用硬盘驱动器（hdd）构建的传统存储系统来说，联网不是一个问题。但是，当前非易失性内存快速存储（NVMe）磁盘的访问延迟在微秒级，存储节点的总吞吐量可以超过100Gbps。相比之下，传统的网络栈（如TCP/IP）的延迟可达毫秒，而每个内核TCP线程的带宽最多只有几十Gbps。

运行在无损结构上的远程直接内存访问（RDMA）为解决云存储中的网络瓶颈提供了一个很有前途的解决方案。通过在主机NIC上实现其整个协议栈，RDMA能够提供微秒级的访问延迟和大约100Gbps的每个连接吞吐量，CPU消耗几乎为零。

**本文主要介绍了在盘古存储网络（即存储节点之间的网络）中引入RDMA的经验。**我们的经验跨越了4年，并将继续随着RDMA的发展而发展。我们面临许多与云存储相关的挑战，还有与RDMA相关的其他问题。我们已经开发了许多解决方案来允许RDMA在生产级云存储中运行，其中一些是工程级的解决方案。然而，克服上述RDMA问题被证明是一项复杂的任务。在这里，我们揭露了生产系统的实际局限性，以促进这一领域的创新研究和应用。

除了性能、可用性和SLA要求外，盘古在生产规模的部署规划还应考虑存储容量和硬件成本。遵循可用性优先原则，RDMA通信仅在每个podset内部启用。这样一个podset包含一组leaf交换机，以及所有连接到这些leaf交换机的Top-of-Rack（ToR）交换机。Podsets之间通过spine交换机连接。此设置当前是应用程序需求、性能和可用性/SLA控制之间的最佳平衡。存储节点配置经过仔细规划，以使磁盘吞吐量与网络带宽相匹配。在盘古中采用RDMA/TCP混合部署，将TCP作为系统的最后手段。

​

性能优化的目标是在最大化吞吐量的同时最小化延迟。我们利用软硬件协同设计来最小化性能开销。我们在盘古构建了一个软件框架，该框架将RDMA与盘古的private user space storge platform（盘古为新存储介质设计）集成在一起。通过消除数据复制操作，一个典型的块服务请求的延迟减少到几十微秒。我们观察到，当盘古升级到100Gbps网络时，内存带宽成为一个瓶颈。通过利用RDMA特性和卸载关键计算，盘古能够使底层网络饱和。此外，我们在盘古中利用了一种新的线程通信模式，以减少由于每个节点有大量队列对（QPs，RDMA连接抽象）而导致的性能缺陷。

以前的研究报告了大规模RDMA部署的风险。支持RDMA的盘古集群确实会遇到这样的问题，包括PFC死锁、PFC暂停帧风暴和head-of-line阻塞。我们确定了几次PFC风暴都是由于先前未探测到的源造成的，这使得先前的解决方案失效。为了保证系统的可用性，我们采用了escape-as-far-as-possible设计原则来处理PFC风暴。提出了RDMA/TCP流量的细粒度交换机制（fine-grained switching mechanism），该机制可以处理PFC风暴，而不考虑其原因.

为了满足SLA标准，在盘古系统中，我们只要**有用就利用存储语义(exploiting storage semantics whenever useful)**的设计原理。盘古利用其控制应用层的能力，对大量存储服务和网络指标进行了实时检查和警报。 借助双归属(dual-home)拓扑功能，我们通过减少连接恢复时间来优化盘古的故障转移性能。 我们还通过利用应用程序控制来解决网络问题，例如，将有问题的连接节点列入黑名单。

在过去的四年中，该系统已成功为阿里巴巴范围内的众多在线关键任务服务提供服务，其中包括几个重要的购物节（例如Double-11）。

2、Background

Pangu的框架：盘古是阿里云于2009年发布的分布式的文件系统。本文主要研究的是盘古的网络特征。

盘古提供了大量的存储服务，包括弹性块服务、对象存储服务、存储服务等。这里以块服务为例对系统框架进行说明。图1展示了盘古的I/O工作流程。虚拟块设备包含了可由应用程序随机访问的连续地址空间。计算节点中的盘古客户端将数据组织成固定大小（例如32gb）的数据段，而Blocksever和chunkserver运行在存储节点上。每个段与BlockServer对齐以进行I/O处理。

在Blocksever上，一个段被分成块并复制到chunkserver。

chunkserver负责块的独立后端存储和设备管理。

BlockMasters管理元数据，例如段与它所在的BlockServer之间的映射以及BlockServer的生存状态。

PanguMaster管理chunkserver的状态。这些Master节点使用一致的协议进行同步，比如Raft–一种共识算法。

盘古所有的数据通信都是以远程过程调用（RPCs）的形式进行的。每个ChunkServer启动RPC客户机/服务器，并通过发起预注册的RPC来执行存储操作。根据所需的RPC，RPC客户端可以同时使用不同的RPC通道（例如，通过RDMA、内核TCP、用户空间TCP或共享内存的连接）。

云存储需要RDMA。存储服务的主要性能指标是读/写吞吐量和访问延迟。低延迟和高吞吐量被证明对许多应用场景是有利的。许多客户希望云存储的性能与本地物理存储类似。例如，阿里巴巴电子商务数据库要求极低的延迟，以确保快速响应，因为每秒可能有大量的交易（例如，在高峰时间每秒544000个订单）。此外，增强型SSD服务承诺提供100万IOPS、4GB/s吞吐量和4KB随机写入的200µs延迟。

传统网络栈（如TCP/IP）的延迟一般在几百微秒以内[13]。每个内核线程可实现的最大TCP带宽可以达到几十Gbps[51]。相比之下，当前NVMe固态硬盘的访问延迟仅为微秒级，而单个设备的读/写带宽为GB/s级。每个存储节点的总吞吐量（通常使用8-16个NVMe磁盘）可以超过100Gbps，并且传入的存储类内存（SCM，例如Intel 3DXPoint）甚至可以达到纳秒级的延迟。因此，网络是当前云存储的主要性能瓶颈。

RDMA是云存储的另一种网络选择。通过在主机NIC上实现其整个协议栈，RDMA提供了微秒级的访问延迟和接近100Gbps的每个连接吞吐量，几乎没有CPU消耗。RDMA已经成功地集成到许多网络瓶颈系统中。

2.2挑战

除了性能之外，可用性和SLA对于成功的云存储系统也是至关重要的。

可利用性：系统中断会给租户及其云提供商带来巨大的财务/声誉损失。2018年，Amazon S3经历了持续4小时的系统中断，影响了Amazon Elastic计算云、Amazon Elastic Block Store Volume和AWS Lambda。这一中断也影响了亚马逊存储服务上的成千上万个网站，包括Netflix、Spotify、Pinterest和Buzzfeed。类似的事件也发生在Google云和microsoftazure上。

SLA：软件和硬件故障在分布式系统中极为常见。随着各种故障的发生，云存储系统应该表现出良好的性能下降。分布式存储系统包括成熟的节点监视和故障转移机制。单个存储节点故障对服务质量的影响最小。根据我们的经验，确保稳定性能的最具挑战性的方面在于存储网络。与存储节点故障相比，网络故障通常会导致更大的影响范围。

2.3 State-of-the-art Work Do Not Fit

未知的PFC风暴源。PFC是在逐跳机制下运行的，PFC风暴可能会扩散到整个集群中。PFC风暴会严重影响集群的可用性，这是RDMA最著名的问题。2016年，微软展示了其在RDMA部署方面的经验，他们披露了支持RDMA的NIC（RNIC）接收管道中的缺陷导致PFC风暴。通过在网卡和交换机上建立看门狗，问题得到了解决。然而，我们发现了另一种来源于交换机的PFC风暴，这意味着PFC风暴具有多种来源的复杂性。微软的解决方案]未能解决这个新问题。

**限制设计选择的实际问题。**我们不能简单地把RDMA当作一个黑匣子，等待未来的研究和技术进步来解决当前的问题。尽管最近进行了大量的研究，生产水平的无PFC综合解决方案仍然为时过早。以前的工作探讨了RDMA在有损以太网上的应用，允许绕过PFC机制。然而，这些解决方案依赖于新的硬件特性。

新硬件的部署是一个很长的过程，需要几个月甚至几年的测试，随后才引入业务应用程序。例如，与NIC供应商合作的CX-4 RNIC测试盘古的过程持续了两年多。新RDMA需求的快速增长与新硬件的长更新周期之间存在着紧张关系。到目前为止，这些无PFC的方案还不够成熟，不适合大规模的业务部署，特别是对于云存储系统的可用性和SLA标准要求。

此外，大规模的行业部署通常与多代遗留RDMA nic相关。例如，我们已经部署了几代Mellanox NIC（例如CX-4、CX-5），每一代的数量都达到了数万个。在运行的节点中替换所有旧的NIC在操作上是不可行的，而且成本高昂，而升级数以万计正在运行的服务器的固件既耗时又容易出错。因此，对新硬件特性或固件的需求应该最小化。

应充分利用分布式存储的领域知识。现有的工作很大程度上忽略了来自应用层的潜在帮助。**存储服务指标（而不是网络指标）是云服务应用程序的关键关注点。**在盘古的设计中，我们考虑了这种存储语义，以改善工程权衡和各种网络问题的决策过程。

3、RDMA 部署

3.1部署规划中考虑的因素

存储集群的部署规划管理着网络拓扑、RDMA通信范围、存储节点配置等，必须考虑多个因素，包括使存储容量与需求匹配、控制硬件成本、优化性能、最小化可用性和SLA风险。最终的结果是在所有这些因素之间进行权衡。

例如，Microsoft在整个Clos网络的规模上部署RDMA。因此，如果不加以预防，PFC风暴可能会蔓延到整个网络，并导致整个集群瘫痪。这种风险在生产级存储系统中是不可接受的。

3.2盘古的部署–可用性优先原则

网络和节点配置：如图2是盘古基于Clos的网络拓扑结构。与常见的dual-home做法相一致，我们部署了Mellanox CX系列双端口RNIC，用两个不同的ToR交换机连接主机。特别是，两个物理端口绑定到一个IP地址。网络连接（例如，RDMA中的QPs）在两个端口上以循环方式进行平衡。当一个端口down时，此端口上的连接可以迁移到另一个端口。

表1报告了25Gbps和100Gbps RNIC存储节点的典型硬件配置。每个节点的SSD数量由RNIC总带宽与单个SSD的吞吐量确定使得I/O吞吐量与网络带宽匹配。请注意，25Gbps和100Gbps配置中的SSD类型是不同的，这会导致数量不均衡。计算和存储节点部署在单个Podset内的不同racks中。然后根据计算需求计算出计算和存储节点的数量。

**RDMA范围。**为了最小化故障域，我们只在每个podset内部和存储节点之间启用RDMA通信。计算节点和存储节点之间的通信通过专用用户空间TCP协议执行。这是由于计算节点的硬件配置复杂，更新速度快。因此，TCP可以有效地作为一种独立于硬件的传输协议来应用。与内核TCP相比，用户空间TCP更便于升级和管理，而内核TCP由于其通用性而被选择用于跨podset通信。

生产部署是podset级RDMA的另一个关注点。在许多数据中心，podset位于不同的建筑物中。对于交叉构建的RDMA链路，基本链路延迟要大得多，而PFC机制需要更大的headroom缓冲。为了启用RDMA，必须仔细调整和测试spine交换机上的PFC/ECN阈值。这是一项艰巨的任务，目前还没有取得足够的成果。

**RDMA/TCP 混合服务。**据我们所知，以前关于RDMA部署的研究并没有探索RDMA和TCP混合服务。我们遵循可用性优先原则，将TCP作为盘古的最后手段。 尽管目前取得了进步，但RDMA设备远非完美无缺。 因此，当可用性或SLA受到威胁时，将受影响的链路从RDMA切换到TCP可以保持可用带宽。 此escape计划不会影响其余正常的RDMA链接。

然而，在混合部署过程中，我们确定共存的TCP流量会引发大量的TX暂停（即NICs发送的PFC暂停帧），即使RDMA/TCP流量被隔离在两个优先级队列中。

表2给出了盘古在不同负载下，约50%TCP流量下的TX暂停生成率。测试在Mellanox CX-4 25Gbps双端口RNIC上执行。如此大量的TX暂停对性能不利，并可能导致PFC风暴。我们与Mellanox一起研究了这个问题，并确定Linux内核中TCP的处理是高度I/o密集型的。内核TCP在NIC的PCIe总线上启动过多的partical writes。随着PCIe带宽的消耗，NIC的接收管道速度减慢。缓冲区溢出，网卡随后开始传输PFC暂停帧。

为了优化TCP的内存访问，我们对数据访问过程做了一些调整。首先，**禁用Large Receive Offest（LRO）**可以减少内存带宽的使用。这是由于启用LRO时,会造成多条cache line的访问。此外，启用NUMA还可以提高内存访问的效率，从而有助于缓解PCIe的压力。我们还在RNICs上为RDMA流量分配一个更大的缓冲区，以防止TX暂停帧。最后，使应用程序数据cacheline-aligned是提高内存效率的常见优化实践。

3.3 evaluation

我们测试了几种RDMA/TCP流量比率，以研究RDMA/TCP混合部署的效果。每个计算节点都以8个depths（运行中的I / O请求），8个jobs（工作线程）和16 KB块大小运行FIO，以便写入虚拟磁盘。 请注意，在BlockServer上的一个写请求会生成三个数据副本。 我们为TCP内核启用了第3.2节中详述的所有优化方法。（禁用LRO,启用NUMA，使cacheline-aligned）

图3（a）描绘了当改变RDMA / TCP比率时BlockServer的吞吐量。工作负载从10分钟开始，RDMA流量为100％。之后，每5分钟，工作负载中包含的TCP流量增加10%，RDMA流量减少10%。在60分钟、65分钟和70分钟时，我们分别将TCP流量比改为0%、100%和0%，以探索盘古在RDMA和TCP之间快速切换的性能。随着RDMA流量比率的降低，平均BlockServer吞吐量表现出非常小幅度的降低。

图3（b）显示了与图3（a）中相同工作负载的BlockServer的平均请求延迟。在100%RDMA流量下的平均延迟大约是100%TCP流量下延迟的一半，而在100%TCP流量下的平均延迟比100%RDMA流量下的延迟大10倍以上。与TCP相比，RDMA具有很大的延迟优势。

图3（c）展示了该工作负载每秒的平均TX pause持续时间。只观察到有限数量的TX pause。在30分钟时，当TCP带宽比为50%左右时，pause持续达到峰值。

总的来说，这些结果证明了我们的RDMA/TCP混合机制的稳定性能。

4.性能优化

4.1性能障碍

盘古的性能优化目标是在最大化吞吐量的同时最小化延迟。

**1）RDMA存储协同设计。**将RDMA协议栈与存储后端集成是一项挑战。它必须涵盖关键的性能点，如线程建模、内存管理和数据序列化。由于线程之间的通信开销，线程模型直接影响延迟。设计良好的内存管理和数据序列化是实现数据访问过程中零拷贝的关键。这里我们将简要介绍这些用于存储的组件的设计。

用户空间存储操作系统（USSOS）是一个统一的用户空间存储软件平台，旨在支持新的存储介质，如NVMe SSD和持久内存。它的设计原则（如内存管理、共享内存机制和用户空间驱动程序）基于著名的用户空间技术（如DPDK和SPDK）。相关测试表明，在盘古上启用USSOS，CPU效率平均提高5倍以上。

作为USSOS的核心部分，用户空间存储文件系统（USSFS）是为ssd设计的高性能本地文件系统。通过在用户空间中运行，USSFS能够绕过内核，以避免用户/内核跨空间开销。USSOS将磁盘划分为“chunks”，它是ChunkServer在其APIs中使用（例如，创建、密封和删除) 。USSOS直接将数据和元数据写入磁盘，并使用轮询来感知完成事件。对于不同的块大小，USSFS能够比Ext4文件系统提高4-10倍的IOPS。

run-to-completion模型被认为是RDMA网络堆栈与存储堆栈集成的最佳方法。这个模型以前在讨论分类存储的研究中被探讨过（例如，Reflection，i10）。然而，这些研究是在2017年将RDMA引入盘古之后发表的。Reflex和i10侧重于远程直接I/O，而盘古的ChunkServer则作为本地存储引擎用于分布式存储。

**2）100Gbps网络的内存瓶颈。**部署100Gbps网络可以实现更低的延迟和更高的吞吐量。随着网络速度的提高，内存吞吐量成为系统的瓶颈。

为了获得内存访问吞吐量的上限，我们使用Intel memory Latency Checker（MLC）工具测试内存吞吐量。表3详细列出了测得的硬件资源使用情况。在我们的测试中，最大可实现内存带宽为61GB/s，读写比为1:1。但是，盘古的平均内存吞吐量已经是29GB/s + 28GB/s = 57GB/s。这表明内存是瓶颈，而不是网络。

通过监控盘古的内存使用情况，我们确定验证和数据复制过程都需要优化。数据完整性是分布式存储最重要的特性之一。盘古应用层数据验证采用循环冗余校验（CRC）。如图4所示，将接收到的数据分成4KB的块，每个块上增加4B CRC值和44B间隔。这个操作是内存和计算密集型操作。在将数据写入磁盘时，还会复制数据，以包括CRC页脚。由于RDMA的远程内存访问语义，因此无法在其他组件中执行复制。

3）大量的QPs

我们曾经在盘古中的运行线程之间采用全网状链接模式，以最大化吞吐量并最小化延迟（图6（a））。假设每个ChunkServer有14个线程，每个BlockServer有8个线程，并且每个节点都包含ChunkServer和BlockServer。对于由100个存储节点组成的集群中的全网格模式，每个节点中可能有14×8×2×99 = 2,2176个QP。由于高速缓存未命中，对于大量QP，RNIC的性能急剧下降。尤其是RX pause（即接收到的PFC暂停帧）的数量非常多。
为了解决这个问题，FaSST 在线程之间共享QP，由于线程之间QP的锁争用，随后降低了CPU效率和性能。另一种启发式方法是包括专用的代理线程，该线程管理所有的接收和发送请求。但是，切换到专用代理线程或从专用代理线程切换会增加延迟。此外，很难用单个线程饱和整个网络带宽。此外，代理解决方案对基础RDMA库不透明。

4.2design

在盘古中：以软硬件共同设计最小化性能开销为设计原则。

**storge-RDMA unified Run-to-Completion stack。**我们对存储和网络都采用了Run-to-Completion的线程模型来实现低延迟。图5显示了用于处理请求的过程。当节点接收到写RPC时，RNIC通过DMA将其发送到用户空间。RPC框架使用轮询获得请求，然后将其交给ChunkServer模块进行处理。然后ChunkServer通知ussf为请求分配一个“chunk”资源。最后，用户空间驱动程序与NVMe ssd交互以存储数据。这些操作通常在单个服务器线程中执行，无需线程切换。这种Run-to-Completion的模型将延迟最小化。为了减少大型作业造成的阻塞时间，当应用程序提交大型I/O请求时，将其拆分为较小的请求。这种优化确保了对I / O信号的快速响应。**针对大型I/O请求的另一个优化策略包括将附属工作（例如格式化和CRC计算）传递给非I/O线程，然后在这些线程中进行处理。**这些优化将典型存储请求（例如4KB大小）的平均延迟降低到30µs以下。

数据格式统一为I/O向量。在网络中，使用scatter-gatherDMA（通过 单个中断 传输 不连续数据）通过单个RDMA动词传输I/O vector。由于RDMA语义，不需要序列化。

**零拷贝和CRC卸载。在盘古，数据必须在I/O路径上复制一次，因为每个4KB数据块都经过验证并附有CRC页脚。这里，我们利用RNICs的用户模式内存注册（UMR）**特性来避免这种数据复制。UMR可以通过定义适当的内存键（memory keys）将RDMA数据分散到远程端。因此，可以根据存储应用程序格式格式化和组织数据。我们使用UMR将来自发送方的连续数据重新映射到接收方的I/O缓冲区，其中每个单元包含4KB数据、4B页脚和44B的间隙。在CRC计算之后，填充的I/O缓冲区可以直接用于磁盘写入。此外，CRC计算能够被卸载到有能力的RNICs（例如Mellanox CX-5），从而降低CPU和内存的使用。将4KB数据发送到RNIC，然后生成4B CRC校验和。

**共享链接。**我们采用共享链路模式，这是减少盘古QP数量的有效解决方案。共享链接模式在应用程序层中实现，并且保持RDMA库不变。 目标节点中的对应线程被分配给源节点中的每个线程（图6（b））。线程对节点的请求被发送到其对应的线程，后者随后将请求分派到正确的目标线程。

考虑一个有N个线程的守护进程，每个线程轮询N个请求/响应队列以获得请求/响应。请注意，每个请求/响应队列只有一个生产者/消费者。因此，我们为每个请求/响应队列使用无锁队列以避免争用。根据我们的测试，这种设计增加了大约0.3µs的延迟。.

在共享链接模式下，当源线程发送太多请求时，在请求调度期间，对应线程会有资源开销。盘古支持共享组，一个节点中的线程可以分成几个组。对应线程只传送其组成员的请求。回到上一示例，全共享模式下的QPs的数量现在减少为（8+8）×99＝1584。如果将线程分成2个共享组，则QPs的数量为（8×2+8×2）×99=3168。

4.3 评价

**零拷贝和CRC卸载。**我们使用具有16个jobs和64个I/O depth的FIO来测试单个ChunkServer上的虚拟I/O块设备。图7（a）显示当使用UMR零拷贝和CRC卸载时的存储器带宽使用（包括读/写任务）。内存带宽使用率降低30%以上，说明这些措施能够缓解内存使用压力。图7（b）描绘了优化后吞吐量的提高。对于128KB的block size，单个ChunkServer线程的吞吐量提高了大约200%。

**共享链接。**在一个由198个计算节点和93个存储节点组成的集群中，我们测试了多个共享QP组的共享链路模式。后台工作负载compromise了具有8个线程和8个I / Odepth的4KB随机写入。图8（a）显示了在所有共享、2个共享组和4个共享组模式下的吞吐量，由此可以观察到性能。全共享模式的吞吐量略低，但产生的PFC暂停次数最少。请注意，在全共享模式下，5分钟和24分钟带宽的减少是由于盘古的garbage collection mechanism造成的。图8（b）显示了分别具有1、2和4个共享组的TXpause持续时间。组的数量越少，由于QP数量的减少，产生的PFC暂停就越少。我们在我们的scale和configuration框架中使用全共享组模式。

5 可用性保证

5.1 PFC风暴

一种新型的PFC风暴。从前的一些研究PFC风暴源于NICs，接收管道中的bug是根本原因。图9（a）描述了这个PFC风暴：（1）bug减慢了NIC接收处理，填满了它的缓冲区；（2）NIC将PFCpause发送到其ToR交换机以防止丢包；（3）ToR交换机暂停传输；（4）ToR交换机的缓冲区已满并开始发送PFC暂停；以及（5）受害者端口暂停，无法传输。

在盘古操作RDMA时，我们遇到了不同类型的PFC风暴。根本原因是特定供应商的交换机硬件存在bug。该bug将无损优先级队列的切换速率降低到非常低的速率。图9比较了两种类型的PFC风暴。作为一个例子，我们假设bug发生在一个ToR交换机的下行端口：（1）由于传输速率低，交换机的缓冲区已满；（2）交换机将PFCpause发送到连接的端口；（3）附加交换机和NIC停止传输。连接到这个ToR交换机的leaf交换机和NIC接收连续的暂停帧，因此风暴蔓延开来。

最先进的解决方案Guo et al.构建了一个基于NIC的看门狗来持续监控传输的暂停帧，必要时禁用PFC机制。此外，在交换机上还部署了看门狗，当交换机接收到连续的暂停帧且无法排出排队数据包时，可以禁用PFC机制。这些交换机随后可以在特定时间段内没有暂停帧的情况下重新启用PFC。因此，在第（2）阶段，可以通过这两个看门狗来控制PFC风暴。

然而，该方案不能完全解决开关产生的PFC风暴问题。特别是，网卡上的TX pause看门狗将不工作，因为NIC只接收来自交换机的PFC风暴。此外，当前交换机硬件不支持对暂停帧传输的监视。如果ToR交换机发生风暴，即使其他交换机上的看门狗能够阻止风暴蔓延，ToR交换机仍将向机架中的终端主机发送暂停。因此，通过该ToR的RDMA流量被阻塞。

**挑战。**这种新型的PFC风暴使Guo等人的解决方案失效，该方案的重点是隔离PFC暂停源，以防止风暴扩散。当源是ToR交换机时，此方法失败，因为ToR中的所有主机都被风暴暂停。因此，为了实现高可用性，盘古需要一个通用的解决方案来处理所有的PFC风暴类型，特别是那些原因不明的风暴。

确保盘古的服务质量，同时解决PFC风暴是一个挑战。PFC风暴检测必须及时准确，以快速保护网络流量。在可用性方面，PFC风暴的总辐合时间应控制在最多分钟水平。

5.2 设计

我们处理PFC风暴的设计原则是escape as far as possible。

在盘古，每个网卡监控接收到的PFC暂停帧。对于连续暂停帧，NIC确定是否存在PFC风暴。在PFC风暴的情况下，管理员可以使用两种解决方案。

解决方法1：shutdown。关闭受PFC风暴影响的网卡端口数秒。dual-home拓扑为PFC风暴提供了一个紧急逃生通道，从而QP将断开连接并通过另一个端口再次连接。 此方法与优化一起使用，以减少QP超时的时间。 尽管此解决方案简单有效，但由于带宽损失了一半，因此不够理想。

解决方法2：RDMA/TCP切换。在这个解决方案中，PFC风暴中受影响的RDMA链路被切换到TCP链路。与关机解决方案相比，它会折中了一个更复杂的过程，但它能够保持可用带宽。我们检测PFC风暴中受影响的RDMA链路。在每 T ms，每个工作线程选择一个服务器，并通过RDMA和TCP链接分别ping它的所有线程。如果RDMA ping失败并且TCP ping成功超过F次，则此RDMA链路上的流量将切换到TCP链路。一旦RDMA ping成功超过S次，交换的TCP链路上的流量将切换回RDMA链路。对于T=10ms和F=3，在一个包含100个存储节点的podset中，可以在大约10秒钟内检测到错误的RDMA链路。通过将RDMA流量切换到TCP连接，吞吐量可在不到1分钟内恢复到90%以上。

5.3 评价

我们模拟PFC风暴的方法是将上述bug注入到交换机中的几种情况，包括ToR和Leaf交换机上的上行/下行端口。RDMA/TCP切换解决方案在所有情况下都表现出很强的性能。图10示出了来自ToR交换机下行链路端口的PFC风暴的结果。请注意，ToR中的节点与ToR外部的节点行为不同。我们选择两个节点（ToR的内部和外部）来演示差异。在这种情况下，暂停帧被传输到直接连接到给定的ToR交换机的NICs和leaf交换机。

如果由于过多的RXpause而导致出现故障，则shutdown解决方案将通过watchdog关闭NIC。。RDMA链路随后通过另一个NIC端口重新连接，从而恢复通信量。注意，由于系统负载（在第0分钟）大于单个端口的可用带宽（25Gbps），拥塞通知包（CNP）和PFC帧的计数器逐渐增加。然后系统在大约30分钟时达到新的平衡。但是，shutdown解决方案有几个限制。例如，计算节点请求可能在1分钟内没有响应（由于应用程序检测到的I/O挂起）。一个leaf或ToR交换机的下行链路故障可能导致数十到数百个挂起请求。此外，关闭port本身就是一种aggressive行为。数百个端口可能由于意外的pause而关闭。这种风险本身可能会影响大量节点的可用性。

RDMA/TCP交换解决方案将通过故障交换机的RDMA流量切换到TCP。RDMA链路由于超时而断开连接。QPs分别分布在服务器的两个NIC端口上，因此RDMA链路可能需要多次尝试才能成功地重新连接。请注意，虽然ToR中的暂停风暴没有终止，但当相邻的交换机端口通过RX暂停看门狗转换为有损模式时，它不会进一步扩散。在迁移到TCP的过程中，流量吞吐量不受影响，并且不存在I/O挂起。

6 SLA维护

6.1 盘古SLA

众所周知，网络故障很难定位和修复。网络故障的原因包括配置错误、硬件/软件错误和链路错误。例如，交换机访问控制列表（ACL）的错误配置可能只会影响特定流，而其他流的行为正常。作为比较，在存储设备或节点上发生的故障通常可以很容易地找到。

有时网络故障可能并不明显。理想情况下，当一个节点发生故障时，heartbeat机制应该确保将节点上service daemon（BlockServers和chunkserver）的不可用性通知给它们的masters（BlockMasters和PanguMasters）。然而，实际情况可能更为复杂，无法通过heatbeats检测到。连接可能会出现间歇性的数据包丢失或长延迟，而不是简单的故障。我们还发现了一种有趣的故障类型，一些链路在短时间内（例如几秒钟）在up和down状态摆动.。这导致I/O请求的尾部延迟非常高，表示为慢I/O（例如，对于存储客户端，超过1秒）。由于许多原因，每天都会观察到数以百计的慢I/o。链路抖动的根本原因包括光纤端口布满灰尘、物理接口松动、硬件老化等。

以前对网络故障的研究。以前的大多数研究集中在确定网络故障的位置。这些解决方案着眼于系统网络，能够实现网络错误的及时发现。然而，工程师可能仍然需要数小时来手动检查、修复和更换故障的交换机和链路。云存储需要一种集成存储和网络功能模块的方法，以确保在故障情况下稳定的服务质量。

6.2 设计

我们的SLA设计原则旨在exploit storage senabtics whenver useful(利用任何有用的存储语义)。分布式存储采用冗余机制设计，并通过存储语义来衡量其性能。在发生故障时，可以利用这些语义（如数据副本和分布式放置）来提高系统性能。

网络综合监控服务。监控是分布式系统的必要组成部分。全面的监控系统对于RDMA在生产存储系统中的安全部署以及可靠的性能至关重要。

必须同时监视配置和计数器。NIC配置包括系统环境、PFC/ECN/QoS配置和多个链路配置。盘古自动检查、收集和报告可疑条目。检查潜在的mis-configration可以减少配置和环境错误。例如，意外重启和软件升级可能会重置QoS、PFC、DCQCN配置并影响系统性能。监控可以发现此类情况并帮助提前解决。

计数器包括存储系统性能计数器（例如，IOPS/延迟）和网络计数器（例如，CNP sent/handled、TX/RX pause和NICs上的RDMA error）。超过阈值的拥塞控制计数器会导致监视器守护进程向工程师发送警报以进行诊断和修复。同时监视存储和网络索引对于错误诊断和可预测的性能至关重要。诸如尾部延迟、慢I/O和排队时间等存储指标可以直接反映系统的状态。此外，监控系统性能也有助于定位错误。例如，网络功能无法快速反映上面描述的抖动问题。但是，通过监视存储应用程序端点上的慢I/o，可以很容易地找到这个问题。

连接失败时设置更快的超时。网络故障的基本解决方案是通过可选择的路径重新连接。由于我们使用dual-home拓扑，网络的每个单点故障都可以通过不同的路径绕过。因此，QPs的超时持续时间对于提高故障期间的系统性能至关重要。在NIC手册中，QPs的超时持续时间计算为4µs×2^timeout×2retry_cnt，其中timeout和retry_cnt分别表示重传超时时间和重传重试次数。最初，这个值是在硬件中配置的常量（大约16秒），不能更改。在与NIC提供商的共同努力下，我们修复了此错误。通过使用更小的QPs timeout value，网络故障时重新连接所需的操作时间减少4倍。

另一种解决方法包括通过修改QPs的源端口来改变连接路径（而不是直接重新连接）。这可以在故障转移期间加快链路恢复。但是，要想有效地改变QP源端口，需要一个比盘古目前部署的网卡固件（MLNX OFED 4.7或更高版本）更新。我们把这个挑战留给今后的工作。

黑名单：我们在盘古采用黑名单，以进一步提高故障转移情况下的服务质量。BlockMasters从客户端收集有关I/O错误（包括超时）和慢I/O的信息。如果一个BlockServer有来自多个客户端的大量慢/错误I/O，主机会在短时间内将其添加到黑名单中。根据集群规模配置触发黑名单的客户端和慢/错误I/O数量。为了保证可靠性，黑名单中块服务器的最大数量通常很小（如3台主机）。这种黑名单机制暂时隔离了提供较差服务的块服务器。系统性能不受影响，工程师有足够的时间来解决问题。

6.3 盘古日常运营方案

盘古的日常运营都是靠这些模块协同工作的。监控系统收集并反映盘古的状况。如果观察到异常的网络指标或I/O指标，监控系统会尝试查找并向管理员报告。对于诸如链路错误之类的意外故障，小的QPtimeout缩短了故障恢复所需的时间。黑名单机制能够确定和隔离服务质量较差的节点。通过遵循这些设计和运营商框架规范，我们的RDMA支持的盘古系统在过去两年中没有出现任何重大故障。

7 经验和今后的工作

在无损RDMA中监测NACK。由于PFC的风险，RDMA在无损结构上的操作很困难。然而，无损结构提高了NACK事件作为网络错误位置指示器的有效性。

为了检测和定位网络问题，我们在盘古建立了一个基于丢包的子系统。特别是，收集RNIC上的out-of-sequence（OOS）计数器和交换机上的数据包丢弃计数器。根据是否由交换机计数器记录，包丢失分为显式或隐式。前者通过检查交换机计数器很容易找到。而由于RNIC计数器不区分流，因此确定后者的位置很复杂。通过监控网络中的NACK，我们可以提取流的五元组并找到问题的根源。

建立系统级基准。为了评估系统的网络性能和SLA，必须建立一个具有代表性的基准。仅仅基于网络指标构建基准是很简单的。但是，不应忽略诸如复制副本完成时间、慢I/O和故障恢复等存储特性。为了衡量存储系统的性能和SLA，我们在存储服务级别建立了一个基准。系统评估指标包括FIO延迟、IOPS、存在网络错误的SLA等。盘古的每一次升级（针对网络和其他组件）都使用基准进行评估，从而可以衡量系统的整体性能。

故障转移场景的拥塞控制。在§3中，我们介绍了盘古采用的dual-home拓扑结构。Dual-home拓扑对于故障转移来说也是至关重要的，因为它在NICs上提供了备份路径。然而，在实际应用中，我们在部署dual-home拓扑时遇到了一个问题。

根据我们的测试，当一个ToR交换机down时，RX暂停时间会增加到每秒200毫秒。这是由于traffic从中断的ToR交换机转移到另一个交换机。DCQCN在这种非对称拓扑下处理突发流量的能力很差。我们采用几个DCQCN参数作为临时解决方案，并利用流体模型[53]分析可用的选择，包括取消快速恢复阶段和延长速率增加持续时间。当去除DCQCN中的快速恢复阶段时，可以消除停顿，但由于流的速度恢复缓慢，flow的尾延迟增加。相反，延长速率增加的持续时间可以导致暂停的急剧减少，但只会稍微增加流尾延迟。根据我们的经验，延长DCQCN中的速率增加持续时间对于存储流量模式是有效的。带宽略有下降，而接收暂停的次数则大大减少。

DCQCN在故障转移场景（如非对称拓扑和业务突发）中的问题表明了它们在拥塞控制设计中的重要作用。我们采用参数调整来解决这个问题，代价是性能稍有损失。存储网络仍然需要一个灵活、健壮、实现良好的拥塞控制机制，以便在所有场景下都能正常工作。2019年，阿里巴巴为RDMA网络设计了一种新的拥塞控制算法HPCC[30]。将HPCC与存储网络进行调整和集成将留待将来的工作。

RDMA读取处理缓慢。盘古的大部分大型RPC都是通过RDMA-READ进行传输的。我们观察到，当一个网卡在短时间内收到过多的RDMA请求时，它会发出许多PFC帧。这是由于缓存未命中导致的接收过程变慢。当NIC准备RDMA读取时，它访问其缓存中的QP上下文。处理许多RDMA读取会消耗过多的缓存资源。对于慢速接收速率，网卡发送PFC暂停帧以防止数据包丢失。我们目前正在与RNIC提供商合作解决这个问题。存储中有损RDMA。Mellanox CX-5和CX-6 RNIC支持有损RDMA。请注意，CX-6支持选择性重复（SR）重传。SR可能是有效消除PFC所需的最终步骤，而有损RDMA的构建是所有基于RDMA的系统的重点。我们用盘古对有损RDMA进行了长时间的测试，并将其部署到新的集群中。

然而，在硬件资源有限且不支持SR的早期一代rnic（例如CX-4）中启用有损特性是很困难的，许多基于RDMA的生产系统仍然承载着早期的rnic。织物上的NVMe。盘古的ChunkServer数据流由cpu处理。但是，通过结构上的NVMe，NIC可以直接将接收到的数据写入NVMe SSD。这种CPU旁路解决方案可以节省CPU成本并减少延迟。我们目前正在构建基于NVMeover结构的专用存储协议（和相应的硬件）。盘古的定制存储协议可以提供更多的灵活性和控制。

9 结论

作为一个分布式存储系统，盘古已经为阿里巴巴内外的租户提供了十多年的存储服务。为了克服高速存储介质不断增长和业务需求不断增长的挑战，我们将RDMA集成到盘古的存储网络中，为不同类型的PFC风暴提供一个通用的解决方案。这允许RDMA的安全部署。盘古通过解决内存带宽瓶颈、QP爆炸等新问题，成功实现了100Gbps网络的迁移。此外，我们还改进了盘古在故障转移情况下的系统性能。