利用 RDMA 技术加速 Ceph 存储解决方案
晓兵XB 云原生云 2023-04-29 20:37 发表于四川
首发链接: 利用 RDMA 技术加速 Ceph 存储解决方案
在本文中，我们首先回顾了 Ceph* 4K I/O 工作负载中遇到的性能挑战，并对单个 Ceph OSD 对象存储守护进程 (OSD) 进程的 CPU 分布进行了简要分析。然后，我们讨论了现有 TCP/IP 堆栈中的低效问题，并介绍了英特尔® 以太网连接 X722 支持的 iWARP RDMA 协议，随后描述了 iWARP RDMA 集成到 Ceph 中的设计和实现。最后，我们提供了使用 iWARP RDMA 对 Ceph 的性能评估，与 TCP/IP 堆栈相比，它展示了高达 17% 的性能提升6。
背景
红帽 Ceph* 是当今最流行的分布式存储系统之一，可在单一平台1中提供可扩展且可靠的对象、块和文件存储服务。它在云和大数据环境中得到广泛采用，在过去几年中，Ceph RADOS 块设备 (RDB) 已成为占主导地位的 OpenStack* Cinder 驱动程序。同时，随着Intel ® 3D XPoint ™ memory 2和远程直接内存访问（RDMA）网卡（NIC）等新硬件技术的出现，企业应用开发者对高性能、超低延迟的存储解决方案产生了新的期待用于云上的在线事务处理 (OLTP) 工作负载。
自 Ceph Jewel* 发布以来，Ceph 在改进网络信使方面取得了稳步进展。默认的简单信使已更改为异步信使，以提高 CPU 效率并与不同的网络协议（如 TCP/IP 和 RDMA）兼容。Ceph 社区设计并实施了一种新的固态硬盘 (SSD) 友好对象存储后端，称为 BlueStore*，并利用了其他最先进的软件技术，例如数据平面开发工具包 (DPDK) 和存储性能开发工具包（SPDK）。这些软件堆栈的变化使得进一步提高基于 Ceph 的存储解决方案性能成为可能。
图片
图 1. Ceph* 系统中的软件演变
用于 Red Hat Ceph BlueStore 元数据和 WAL 驱动器的英特尔® 傲腾™ 固态盘填补了 DRAM 和基于 NAND 的固态盘之间的空白，即使在低队列深度工作负载下也能提供无与伦比的性能。英特尔®至强®可扩展处理器提供一系列性能、可扩展性和功能选项以满足各种工作负载，是红帽 Ceph 数据密集型解决方案的理想选择。RDMA 支持在支持 RDMA 的服务器适配器和应用程序内存之间进行直接的零拷贝数据传输，从而消除了以太网网络中将数据多次复制到操作系统数据缓冲区的需要。这是非常高效的，并且消除了内核空间和用户空间之间相关的处理器密集型上下文切换。英特尔至强可扩展处理器平台包括集成的英特尔®带有互联网广域 RDMA 协议 (iWARP) 的以太网连接 X722，并提供多达四个 10 吉比特以太网 (GbE) 端口以实现高数据吞吐量和低延迟工作负载，这使得该平台成为横向扩展存储解决方案的理想选择.
动机
性能挑战
在 2017 年波士顿 OpenStack 峰会3上，英特尔展示了基于英特尔傲腾固态盘和英特尔®固态盘数据Ω中心 P4500 系列的 Ceph 全闪存阵列集群，可提供每秒数百万次输入/输出操作 (IOPS) 以及极低的延迟和具有竞争力的每 GB 美元费用。我们还展示了网络信使强加的大量网络开销。如图 2 所示，CPU 往往是 4K 随机读取工作负载的瓶颈。分析表明，22-24% 的 CPU 用于处理网络流量，突出表明需要优化 Ceph 网络组件以实现超低延迟和低 CPU 开销。传统的 TCP/IP 无法满足这一要求，但 RDMA 可以4。
图片
图 2. Ceph* 系统中的网络组件瓶颈。
RDMA 与传统 TCP/IP 协议
如今，存在三种 RDMA 选项：InfiniBand* 需要在必要的以太网网络之外部署单独的基础设施，iWARP 5和 RoCE（RDMA over Converged Ethernet）是实施 RDMA 以通过 Internet 协议网络进行高效数据传输的计算机网络协议。
之前的研究表明，传统的 TCP/IP 有两个突出的问题：在操作系统内核中处理数据包的高 CPU 开销和高消息传输往返延迟，即使在平均流量负载适中时也是如此。RDMA 执行从一台计算机到另一台计算机的直接内存访问，而不涉及目标计算机的操作系统，与 TCP/IP 相比具有以下优点：
避免发送方和接收方的内存复制，为应用程序提供最小的往返延迟和最低的 CPU 开销。
数据从网络移动到目标计算机中的应用程序内存区域，而不涉及其操作系统和网络输入/输出 (I/O) 堆栈。
RDMA 协议将数据作为消息传输，而 TCP 套接字将数据作为字节流传输。RDMA 避免了 TCP 流中使用的标头消耗额外的网络带宽和处理。
RDMA协议天然是异步的；消息传输期间不需要阻塞。
因此，当将 RDMA 集成到 Ceph 网络组件中时，我们期望更低的 CPU 开销和更低的网络消息延迟。
将 iWARP 集成到 Ceph* 系统中
本节介绍 Ceph 中 RDMA 设计和实现的演变。我们将讨论 Ceph RDMA messenger 的总体架构，然后分享我们如何在当前的 Ceph async messenger 中启用 iWARP。
Ceph RDMA 信使
Ceph 系统依靠信使进行通信。目前，Ceph 系统支持简单、异步和 XIO 信使。从信使的角度来看，所有的 Ceph 服务，如 OSD、监视器和元数据服务器 (MDS)，都可以被视为消息分发者或消费者。Messenger 层扮演着 Ceph 服务和底层网络硬件之间的桥梁角色。
还有几个其他项目专注于将 RDMA 集成到 Ceph 系统中——XIO* messenger 就是其中之一。XIO messenger 建立在 Accelio* 项目之上，该项目是针对硬件加速优化的高性能异步可靠消息传递和远程过程调用 (RPC) 库。它于 2015 年合并到 Ceph master 中，支持不同的网络协议，例如 RDMA 和 TCP/IP。XIO messenger 无缝支持 RDMA*，包括 InfiniBand*、RoCE* 和 iWARP*。在此实现中，RDMA 被视为网络组件，就像 Ceph 系统中的简单信使或异步信使。根据 Ceph 社区的反馈7，存在一些扩展性问题和稳定性问题；目前这个项目没有得到积极维护。
另一个项目旨在将 InfiniBand RDMA 集成到异步信使中。Async messenger 是从 Ceph Jewel 版本开始的默认网络组件。与 Ceph Jewel 之前的默认网络组件 simple messenger 相比，async messenger 的 CPU 效率更高，可以节省更多的 CPU 资源。是为Ceph系统设计的异步网络库，兼容Posix、InfiniBand RDMA、DPDK等不同网络协议。图 3 显示了使用 InfiniBand 协议的 Ceph 异步信使的架构；RoCE 支持类似。
图片
图 3. InfiniBand 与 Ceph* 异步信使的集成
iWARP 与异步信使的集成
随着互联网应用程序之间消息传输的快速增长，需要高性能（高速、高吞吐量和低延迟）网络来连接数据中心的服务器，英特尔以太网仍然是主导网络物理层，并且TCP/IP 堆栈广泛用于网络服务。此前，我们得出的结论是 TCP/IP 堆栈无法满足新一代数据中心工作负载的需求。带有 iWARP RDMA 的 Ceph 是通过 TCP/IP 运行 Ceph 的数据中心迁移到 RDMA 的实用方法，它利用带有 iWARP RDMA 的英特尔®以太网来加速 Ceph 系统。
图片
图 4. 集成在异步信使中的 iWARP
由于异步信使的可扩展框架，我们可以修改 RDMA 连接管理以使用 RDMA 连接管理 (RDMA-CM) 库来支持 iWARP，而不是当前的 InfiniBand RDMA 实现，它使用自实现的基于 TCP/IP 的 RDMA连接管理。我们使用librdmacm库实现 RDMA 连接接口，因此它与包括 InfiniBand 和 RoCE 在内的其他实现兼容。选择 iWARP 或 InfiniBand 作为 RDMA 协议是可配置的。此外，我们支持创建与共享接收队列无关的队列对。接收队列请求的内存是从一个集中式内存池中分配的。内存池在启动和结束异步消息服务时被保留和释放。
性能测试
在本节中，我们将介绍使用 iWARP RDMA 对 Ceph 的性能评估。
测试方法
性能评估是在一个有两个 OSD 节点和两个客户端节点的集群上进行的。详细配置如下：
硬件配置：四个节点均配置了 Intel Xeon Platinum 8180 处理器和 128 GB 内存，集成了带有 iWARP RDMA 的 10-Gigabit Intel Ethernet Connection X722。每个 OSD 节点都有 4 个 Intel SSD Data Center P3520 系列 2TB SSD 作为存储设备。
Ceph 系统和 FIO* 配置：OSD 服务器运行带有 Ceph Luminous* 版本的 Ubuntu* 17.10。每个服务器节点上的每个 OSD 驱动器都托管一个 OSD 进程作为 BlueStore* 数据和数据库驱动器，总共有 8 个 OSD 进程在测试中运行。用于测试的 RBD 池配置了两个复制。FIO 版本为 2.12。
网络配置：OSD 节点和客户端节点之间的网络模块是用户定义的。在这个测试中，我们将网络模块从 TCP/IP 更改为 RDMA。网络拓扑如图 5 所示。对于带有 RDMA 测试的 Ceph，公共网络和集群网络共享一个 NIC。
图片
图 5. Ceph* 基准测试拓扑——两个节点
我们模拟了云中全闪存 Ceph 集群的典型工作负载，并在 Ceph RBD 卷上运行 FIO 4K 随机写入。对于每个测试用例，IOPS 是在不同级别的队列深度缩放（1 到 32）下测量的。每个卷都配置为 30 GB。这些卷是预先分配的，以消除 Ceph 自动精简配置机制对稳定和可重现结果的影响。OSD 页面缓存在每次运行之前被删除，以消除页面缓存的影响。对于每个测试用例，FIO 配置了 300 秒的预热和 300 秒的数据收集。
Ceph 系统与 TCP 和 iWARP RDMA 的性能比较
图片
(a) FIO性能对比
图片
(b) OSD 节点上的 CPU 比较
图 6. Ceph* 系统性能与 RDMA 或 TCP/IP 的比较
图 6 (a) 说明了使用不同网络协议的客户端节点上聚合的 FIO IOPS。它表明，与 TCP/IP 相比，具有 RDMA 的 Ceph 在 4K 随机写入工作负载中提供了更高的性能——队列深度 = 2 时性能提高了 17%。增加 FIO 队列深度也影响了 RDMA 结果。RDMA 的优势在低队列深度工作负载中更为明显，具体取决于 Ceph 调优，例如 Ceph RDMA messenger 中的完整队列深度。
图 6 (b) 显示了在 RBD 卷上运行 FIO 进程时 OSD 节点上的 CPU 利用率。使用 RDMA 的 Ceph 的 CPU 利用率高于使用 TCP/IP，这不是我们的预期（详细的根本原因将在后面说明）。理论上，RDMA 应该会降低 CPU 利用率，因为 RDMA 会绕过内核并限制上下文切换。
图片
图 7. OSD 节点上的 CPU 分析
如图 7 所示，具有 TCP/IP 的 Ceph 消耗了更多的系统级 CPU，而具有 iWARP RDMA 的 Ceph 消耗了更多的用户级 CPU。乍一看这是有道理的，因为RDMA实现了kernel bypass，所以RDMA消耗的系统级CPU更少。但是，RDMA 消耗更多的用户级 CPU 是没有意义的。其根本原因将在后面解释。即使是带有 iWARP 的 Ceph 也会消耗更多的 CPU，并且与 TCP/IP 相比，OSD 节点上每个 CPU 周期的 FIO IOPS 更高。总体而言，采用 iWARP 的 Ceph 提供了更高的 4K 随机写入性能，并且比采用 TCP/IP 的 Ceph 的 CPU 效率更高。
可扩展性测试
为了验证 Ceph 与 iWARP RDMA 的可扩展性，我们将 OSD 节点和客户端节点的数量增加到三个，同时保持其他 Ceph 配置和基准测试方法与之前的测试相同。
图片
图 8. Ceph* 基准测试拓扑——扩展到三个节点
多一个 OSD 节点后，使用 iWARP 的 Ceph 性能提高了 48.7%，使用 TCP/IP 的 Ceph 性能提高了 50%。它们都显示出更大的节点可扩展性。毫不奇怪，带有 iWARP RDMA 的 Ceph 在三个 OSD 节点集群上显示出更高的 4K 随机写入。
图片
图 9. Ceph* 基准测试拓扑——扩展到三个节点
性能分析
为了更好地理解使用 iWARP RDMA 的 Ceph 异步信使内部的开销，我们查看了消息接收流程。
图片
图 10. 使用 RDMA 的异步信使中的数据接收流程
为了更清楚地描述流程，我们简化了消息传输过程，它遵循以下前提条件：它是一个单一的服务器和客户端架构；客户端已经和服务器建立了RDMA连接，服务器发送4K消息给客户端。
一旦客户端的网络驱动程序收到远程发送请求，它就会触发 CQ 轮询事件。该事件接管后端工作线程并处理 CQ 轮询事件。CQ 轮询事件获取 4K 远程 DMA 消息并将其放入异步信使接收缓冲区，然后是另一个请求以触发异步信使读取事件。之后，轮询事件释放后端线程。
read事件从指定的recv buffer中读取4K消息，然后传递给响应的dispatcher处理。最后，读事件释放工作线程，完成读过程。
RDMA 消息传输过程基于 Ceph async messenger。对于一个消息接收流程，触发两个事件并复制一个消息。我们更深入地使用 perf 火焰图来获取一个异步消息工作者的 CPU 使用率的详细信息。
图片
图 11. Ceph* async messenger worker 的 CPU 使用率
图 11 显示，工作线程使用的大部分 CPU 都被 RDMA 轮询线程和异步信使轮询进程消耗。如消息传输流中所述，在异步信使上添加 RDMA 轮询会增加 CPU 开销和上下文切换，因为它使轮询过程加倍，并且一次消息传输会触发两个事件。同时，从 RDMA 接收缓冲区到异步信使未读缓冲区的额外消息复制增加了消息传输往返延迟。两个轮询线程和额外的内存复制问题导致使用 iWARP RDMA 的 Ceph 的用户级 CPU 消耗更高。
下一步
性能优化
使 RDMA 轮询适应异步信使等 I/O 多路复用框架并不是最佳解决方案。RDMA 专注于避免内核级别的 CPU 开销。在异步信使中向描述符发送信号会引入额外的上下文切换，这会增加 CPU 开销。同时，我们提出了一个RDMA messenger库，并将其与分布式缓存存储项目——超融合分布式缓存存储（HDCS）8集成。与 TCP/IP 相比，初始基准显示了 RDMA 网络的巨大性能优势（I/O 和 CPU 消耗）。
根据以往的经验，我们将继续对 Ceph RDMA 代码进行性能优化，包括将 RDMA 轮询与异步消息事件驱动分离，避免内存复制到异步消息接收缓冲区。因为 RDMA 协议提供基于消息而不是基于流的事务，所以我们不需要在消息发送方将流分成不同的消息/事务，然后在接收方将它们拼凑在一起。基于 Messenger 的事务可以避免用于缓冲数据的额外内存复制操作。
使用 NVMe-oF 分解 Ceph 存储节点和 OSD 节点
对于两个问题，我们考虑利用非易失性内存 express over Fabrics (NVMe-oF) 来分解 Ceph 存储节点和 OSD 节点。首先，当前的 Ceph 系统配置无法充分受益于 NVMe 驱动性能；日志驱动器往往是瓶颈。其次，对于每个 NVMe 驱动器配置一个 OSD 进程，40% 的英特尔至强处理器未在 OSD 节点上使用。通过分解 Ceph 存储和 OSD 节点，我们可以将目标节点上的所有 NVMe 设备用作一个 NVMe 池，并为指定的 OSD 节点动态分配合适的 NVMe 驱动器。
我们有初始性能数据6 表明 NVMe-oF 不会降低 Ceph 4K 随机写入性能。通过目标节点上的 NVMe-oF CPU 卸载，目标节点上的 CPU 开销不到 1%。我们没有在 OSD 节点上找到 CPU 开销的证据。但是，我们发现在高 FIO 队列深度工作负载中，使用 NVMe-oF 时，FIO 尾部延迟远高于本地 NVMe 驱动器。我们仍然需要找出根本原因，并利用高密度存储节点作为池来降低 TCO。
概括
我们发现 CPU 仍然倾向于成为 4K 随机读写工作负载的瓶颈，这严重限制了峰值性能和 OSD 扩展能力，即使 Ceph 社区进行了最新的网络层和对象存储后端优化。RDMA 提供远程内存访问，绕过内核释放 CPU 开销，并减少往返消息传输时间。
我们发现 iWARP RDMA 可加速 Ceph 网络层（异步信使）并将 4K 随机写入性能提高高达 17%。此外，带有 iWARP RDMA 的 Ceph 显示出极佳的可扩展性。当将 Ceph OSD 节点从两个扩展到三个时，4K 随机写入性能提高了 48.7%。
根据 OSD 节点上的系统指标，具有 iWARP RDMA 的 Ceph 消耗更多 CPU。但是，通过更深入的分析，我们看到了 CPU 周期分布，并发现了当前 RDMA 实现中的两个轮询线程问题。
后续步骤：我们将专注于异步信使 RDMA 性能优化，包括两个轮询线程问题。此外，我们将探索利用 NVMe-oF 并将高密度存储节点用作存储池的机会，以降低 Ceph 全闪存阵列集群的 TCO。
参考
-
OpenStack 用户调查 (PDF)
-
Intel Optane 技术和 Intel ® 3D NAND SSD
-
Intel Optane 和 Intel Xeon 平台的 Ceph 系统优化
4.大规模商品以太网上的 RDMA (PDF)
- iWARP RDMA 技术简介
6.使用 RDMA 和 NVMe-oF 加速 Ceph
- Ceph 与 XIO Messenger 性能
8.超融合分布式缓存存储（HDCS）
原文链接: https://www.intel.com/content/www/us/en/developer/articles/technical/leveraging-rdma-technologies-to-accelerate-ceph-storage-solutions.html
原文时间: 2018 年 7 月 3 日
晓兵
首发链接: 利用 RDMA 技术加速 Ceph 存储解决方案
博客: https://logread.cn
weixin: ssbandjl
公众号: 云原生云
