虚拟化 NFSoRDMA 基础的分离式存储解决方案,用于 AI 工作负载

在高性能计算(HPC)和人工智能(AI)领域,对高效且可扩展的存储解决方案的需求不断增加。传统存储系统常常难以满足现代 AI 工作负载的高吞吐量和低延迟要求。分离式存储,特别是与 NFSoRDMA 结合时,为这些挑战提供了一个有前景的解决方案。本文将探讨实施针对 AI 工作负载的分离式存储的目标、性能要求和解决方案。
NFSoRDMA 将广泛采用的 NFS 协议与高性能的 RDMA 技术结合在一起。通过使用标准协议并避免专有软件,我们可以绕过操作系统兼容性和版本冲突的限制。NFSoRDMA 能够以最低的部署成本实现所需的性能水平,无需为并行文件系统客户端或所有组件的严格版本兼容性提供特定的兼容性列表。我们充分利用 400Gbit 接口,证明了高效实现高性能是可能的。这种集成确保了低延迟和高吞吐量,使其非常适合我们苛刻的存储需求。
目标
AI 工作负载通常需要的不仅仅是块设备。它们需要能够处理高性能和可扩展性需求的复杂文件存储系统。我们开发分离式存储解决方案的主要目标包括:
实现高吞吐量 :目标是从少数几个客户端使用一个或两个存储节点(无论是真实还是虚拟)达到几十 GBps。
最大化 IOPS :获取尽可能多的小型 IOPS 对于支持 AI 任务的高速数据处理需求至关重要。
简化配置 :保持硬件和软件配置尽可能简单,对于易于部署和维护至关重要。
部署灵活性 :该解决方案必须能够在本地或云端部署,提供按需扩展和灵活性。
AI 任务通常需要从多个客户端并行访问数据,速度达到每秒数十到数百 GB。我们的软件解决方案旨在最小化复杂性,同时确保高性能和可扩展性。

性能要求
为了高效的集群操作,快速的数据加载和快速的检查点写入是必不可少的。这些要求对于在 AI 和 HPC 环境中保持高性能至关重要。
上面提供的图表说明了 GPU 利用率和 Lustre 读写速率在一个迭代处理周期中的情况,这在 HPC 工作负载中很常见。最初,有一个短暂的 GPU 利用率上升期,称为启动阶段。随后是计算迭代序列,其中 GPU 利用率保持高位,表示活跃处理。定期会有 GPU 利用率下降的情况,对应于保存数据的检查点阶段。在这些阶段,GPU 大多处于空闲状态,等待检查点完成。
Lustre 读写速率反映了这一工作流程的不同阶段。在开始时,在初始化阶段有一次显著的读活动峰值,因为系统加载初始数据,这仅发生一次。在计算迭代期间,读活动最小,反映工作负载的重点在于计算而非数据移动。每隔几次计算迭代,就会发生检查点操作,导致写活动的峰值。在这些阶段,数据被写入存储,GPU 计算暂停。
尽管这个例子基于 NVIDIA 关于 Lustre 的演示数据,但其基本原理同样适用于 NFS 系统。当前模式揭示了效率改进的机会。例如,实施并行或异步检查点可以显著减少检查点阶段 GPU 的空闲时间。我们的解决方案旨在解决这些低效问题,为 HPC 和 AI 工作负载提供更高效和有效的高吞吐量存储需求处理过程。
高级解决方案描述
我们的解决方案将高性能存储引擎与知名文件系统服务集成起来,重点关注:
软件定义 RAID :可部署在各种环境中,如裸机、虚拟机和 DPU。
调优文件系统(FS)和优化服务器配置 :确保最佳性能和效率。
基于 RDMA 的数据访问接口 :提供 AI 工作负载所需的高速数据访问。
主要思想是在必要的主机上按需部署文件存储系统的不同元素。分离式存储资源使用 xiRAID Opus RAID 引擎组合成虚拟 RAID,只需最少的 CPU 核心。然后创建卷并通过 VHOST 控制器或 NVMe-oF 导出到虚拟机,提供灵活且可扩展的存储解决方案。
我们将探讨 NFSoRDMA 和 xiRAID Opus 的虚拟化,观察 Linux 内核空间中的限制,并解释如何虚拟化我们的解决方案。
为了验证我们的解决方案,我们将利用 FIO(Flexible I/O Tester)进行两种类型的测试:顺序读写以展示数据加载和检查点性能,随机读取以展示小型数据读取性能。FIO 允许我们使用各种引擎并调节负载,确保简单性和可重复性。
引入虚拟化 NFSoRDMA + xiRAID Opus 解决方案
新的虚拟存储系统包含两个关键组件:在用户空间中运行的高性能引擎和按需实例化的虚拟机,作为 NAS 网关。这种架构允许高效分配存储资源,平衡高性能与虚拟化环境所需的可扩展性和灵活性。
我们部署了按需存储控制器,并为租户从分离式存储资源构建虚拟存储卷。部署按需存储控制器并从分离式存储资源构建虚拟存储卷为每个租户提供了专用的虚拟存储。这种方法利用了两个关键组件:xiRAID Opus,一种高性能块卷,以及 NFS 网关。xiRAID Opus 提供专为虚拟化环境定制的 RAID 保护块设备,确保强大的性能和可靠性。

然而,性能在虚拟环境中仍然是一个重大挑战,受硬件和软件限制的影响,例如以下几点:
加速器占用 PCI 插槽 :这个问题在云环境中比在裸机安装中更为严重。
Linux 内核更新和实时补丁 :在虚拟化设置中频繁发生,这些更新可能会破坏依赖特定内核版本的专有软件。
Vhost 协议实现 :在内核中每个卷限制为 250K IOPS,此限制消耗大量资源,影响整体效率。
为克服这些挑战,我们的解决方案高效地运行块设备引擎,仅使用 2-4 个 CPU 核心即可提供对高性能虚拟块设备的访问。
我们的虚拟化解决方案的关键特性
我们的虚拟化存储解决方案包括:
用户空间中的软件 RAID 控制器
带 QoS 支持的卷管理器
用户空间中的多线程 VHOST
SR_IOV 将 NIC 功能传递到 VM

通过将命名空间聚合到虚拟阵列中并创建具有特定大小和性能特性的卷,我们将这些设备传递到虚拟机。这些虚拟机充当虚拟 NVMe over RDMA 服务器,连接到高性能网络卡,无论是在同一主机还是远程主机上,客户端虚拟机可以直接或通过主机使用 virtio-fs 连接。
我们解决方案中的数据路径虽然复杂,但通过减少层级和提高每个层级的效率进行了优化。这种优化在保持与现有解决方案兼容的同时,重新发明或改进了关键组件(用颜色突出显示),以实现更高的效率。

测试配置
仅两个 CPU 核心用于 RAID 和 vhost 控制器
24 个 CPU 核心用于 NFS SERVER VM
RAID 50 (8+1) x2
KIOXIA CM6-R 驱动器
AMD EPYC 7702P
文件系统与 RAID 对齐
我们创建了一个卷,将其传递到单个虚拟机,并从远程主机上的两个虚拟客户端应用负载来评估性能。

测试结果
在顺序操作的性能比较中,mdraid 显示出显著的性能损失,高达 50%,而 xiRAID Opus 最大化了接口读取性能,使用一两个客户端时达到了接口潜力的大约 60%。这突显了 xiRAID Opus 在虚拟化环境中的优越性能。


在随机读取操作中,当使用 2 个客户端时,xiRAID Opus 显示出卓越的可扩展性和显著的性能提升,达到 850k-950k IOPS。相比之下,基于 mdraid 的解决方案未能有效扩展,表现出内核限制,每个虚拟机的小块读取性能上限为 200-250k IOPS。我们的用户空间解决方案在连接 3 个客户端后接近 1 百万 IOPS,进一步突显了 xiRAID Opus 相对于 mdraid 的可扩展性和效率。

在比较 CPU 负载时,mdraid 结合内核 vhost 和虚拟机几乎完全占用了约四分之一的 CPU 核心。相反,xiRAID Opus 仅使用两个完全加载的核心,其余核心大约有 12%在约 25%负载下运行。
MDRAID + NFS 虚拟机:


总结与最终思考
以下结论突显了我们在 NFSoRDMA 和 xiRAID Opus 虚拟化中观察到的重大效率:
单个虚拟 NFS 服务器可以饱和 2x200 Gbit 接口,性能与大型服务器相当。
xiRAID Opus 存储引擎仅需 2 个 CPU 核心,而 mdraid 则消耗更多 CPU。
mdraid 在顺序和随机操作中均有限制。
通过虚拟化我们的解决方案,我们实现了写操作约 60%的效率和读操作 100%的效率。
NFS over RDMA 结合 xiRAID 能够创建快速存储节点,提供 50 GBps 性能并饱和 400 Gbit 网络。这是为大学和大型研究机构提供快速存储给 NVIDIA DGX 系统的理想选择。此类解决方案的主要成分是存储引擎、NFS 服务器和客户端调优。
在虚拟环境中实现高性能被证明是可能的。虽然 Linux 内核存在性能限制,但基于用户空间的 RAID 引擎是解决方案。它减少了资源消耗,同时保持了与裸机安装相当的性能。我们对基于 NFSoRDMA 的分离式存储进行了广泛的测试和实施,展示了 AI 工作负载性能和效率的重大进步。
感谢您的阅读!如果您有任何问题或想法,请在下面的评论中留下。我很乐意听到您的反馈!
原文可以在这里找到。
附录
NFS 设置
服务器端 :
客户端 :
MDRAID 调优
ZFS 设置
Fio 配置
版权声明: 本文为 InfoQ 作者【Sergey Platonov】的原创文章。
原文链接:【http://xie.infoq.cn/article/1b9b010611a864e19cc11ca44】。
本文遵守【CC-BY 4.0】协议,转载请保留原文出处及本版权声明。
评论