xiRAID：高性能块存储访问路径优化

全文概览

在人工智能（AI）浪潮席卷各行各业的今天，云环境已成为承载AI工作负载的主流平台。然而，您是否曾困惑，为何强大的云基础设施，在面对AI训练和推理时，存储性能却成了瓶颈？传统的软件定义存储（SDS）解决方案，在满足现代AI应用对极致性能的需求方面显得力不从心，尤其是在需要多个计算实例共享访问数据时，高性能共享卷的支持更是普遍缺乏。

更令人担忧的是，存储系统的速度直接影响着昂贵计算资源（特别是GPU）的利用率。想象一下，当GPU在等待数据写入或读取时，它们并未全力运转，这无疑造成了巨大的资源浪费。特别是在AI训练中频繁发生的Checkpoint写入阶段，缓慢的存储速度会显著延长等待时间，直接拉低GPU的整体利用效率。

那么，如何在云环境和虚拟化场景下，突破存储性能的限制，真正释放AI计算的潜力？本文将深入探讨这一核心问题，并介绍一种旨在解决这些挑战、提供高性能存储解决方案的技术。

阅读收获

• 理解云环境中AI工作负载对存储性能的独特需求和现有挑战。
• 认识到存储速度如何直接影响GPU等计算资源的利用效率。
• 了解一种通过用户空间优化和特定技术手段提升虚拟化存储性能的解决方案（xiRAID Opus）。
• 看到实际测试数据，对比不同存储技术在虚拟化场景下的性能表现。

云环境中AI工作负载下的SDS性能瓶颈

云环境中AI工作负载下的SDS性能瓶颈

图片提出了一个关键问题：在云环境中运行AI工作负载时，软件定义存储（SDS）面临性能挑战。

具体来说，问题主要体现在以下两个方面：

1. 性能瓶颈： SDS通常难以满足现代基于云的AI应用对高性能的需求。
2. 共享卷限制： SDS解决方案普遍缺乏对高性能共享卷（文件存储）的良好支持，这对于需要多个计算实例访问共享数据的AI工作负载是必需的。

慢速存储意味着GPU利用率低下

慢速存储意味着GPU利用率低下

图片的核心观点是：存储系统的速度瓶颈会导致计算资源（特别是GPU）未能得到充分利用。

这一现象尤其体现在 Checkpoint 写入阶段，存储系统若具备更高写入速度，则可明显缩短 Checkpoint 过程耗时，从而提高GPU利用率。

图片清晰地阐述了项目或研究的核心目标，主要聚焦于在云环境和虚拟化场景下提升存储性能，以更好地支持AI工作负载。

• 总体目标： 开发并部署一种高性能的存储解决方案，该方案的核心是一个高效的块设备，能够克服虚拟化带来的性能损耗，特别是在与并行文件系统结合时，并能满足AI工作负载对随机和顺序访问的高性能需求。
• 具体目标 (分解):
  1. 高性能块设备： 创建一个本身就具有优异性能的块设备。
  2. 虚拟化并行文件系统兼容性： 确保这个块设备在由虚拟化环境中的并行文件系统使用时，依然能保持高性能。
  3. 云环境性能无损： 确保该解决方案在云部署中，不会因为虚拟化层而牺牲性能。
  4. 满足AI负载需求： 专门优化存储性能，以适应AI工作负载对随机读写和顺序读写的要求。

图片介绍了 xiRAID Opus 这项技术，它是一个专注于在虚拟化环境中提供高性能存储数据路径的引擎。

• 目的： 在虚拟化环境下实现高性能存储数据路径。
• 核心功能：
  • 支持创建具有RAID保护的存储卷。
  • 能够将这些存储卷分配给虚拟机使用。
• 性能优化手段：
  • Polling (轮询): 通过主动检查I/O完成状态来降低操作延迟。
  • Zero-Copy (零拷贝): 避免数据在不同缓冲区之间进行不必要的复制，从而提升数据传输效率（吞吐量）。
• 性能实测结果 (与理论 RAID5 对比)：
  • 图片提供了一个性能对比表格，展示了 xiRAID 在各种I/O模式下（4K随机读写、顺序读写）接近或达到 2x RAID5 理论性能，并列出了相应的效率百分比（基本都在90%以上）。
  • 特别提到使用 24 块 Kioxia CM7 PCIe 5 NVMe SSD 驱动器实现了世界纪录性能。
• 结论： xiRAID Opus 是一种通过用户空间优化和特定技术手段，旨在解决虚拟化环境下存储性能瓶颈的解决方案，并在实际测试中表现出优异的性能，尤其适用于需要高性能存储的场景。

Cite

更多关于 xiRAID Opus 的技术报道，可参考阅读：

• XINOOR：高效RAID的存储实践

文章主要内容

• xiRAID Opus技术概述：xiRAID Opus是XINOOR公司推出的一款用户空间优化的RAID解决方案，旨在提供高性能和高可扩展性的存储服务。与xiRAID Classic不同，xiRAID Opus运行在用户空间，独立于内核，适用于网络设备或虚拟化环境 。
• 主要特点：
  • 高性能：xiRAID Opus通过优化用户空间性能，实现了更高的I/O吞吐量和更低的延迟 。
  • 灵活性：支持NVMe发起器、基于TCP/RDMA的NVMe、iSCSI目标和Vhost控制器，适用于多种存储场景 。
  • 分布式管理：采用分布式CLI进行管理，支持多个服务器的管理和配置 。
  • 多架构支持：不仅支持x86架构，还支持ARM架构（如DPU），为未来的硬件升级做好准备 。

图片展示了 xiRAID Opus 的内部架构，详细描绘数据流和控制流的各个组成部分及其交互方式。其设计目标是在虚拟化环境中提供高性能存储。

• 架构概览： xiRAID Opus 架构将存储功能实现为一个解决方案，运行在主机上，通过不同的组件处理来自虚拟机的I/O请求，并与底层的NVMe驱动器交互。架构被分为数据平面和控制平面。
• 关键组件与流：
  • 数据平面：
    • 虚拟机 (VMs): 发起存储I/O请求。
    • Multithread Vhost / NVMe-TCP / RDMA host: 接收来自虚拟机的I/O请求，支持不同的前端协议（如用于虚拟机块设备的vhost-blk，以及用于远程连接的NVMe-TCP或RDMA）。
    • Volumes (卷): 代表分配给虚拟机的逻辑存储单元。
    • RAID engine (RAID 引擎): 执行RAID逻辑，将逻辑卷的I/O请求映射到底层物理驱动器，并处理冗余计算。
    • NVMe Initiator (NVMe 发起端): 负责与物理NVMe驱动器进行通信和发送命令。
    • NVMe Drives (NVMe 驱动器): 底层的物理存储介质。
    • Network (网络): 用于远程访问（如通过NVMe-TCP/RDMA）或管理。
  • 控制平面 (Control Plain):
    • xiRAID Opus Calc Library: 可能包含用于RAID计算或优化的库。
    • Device Manager (设备管理器): 管理底层的存储设备（NVMe驱动器）。
    • Config (配置): 处理系统的配置信息。
    • gRPC: 作为控制平面内部或与外部组件通信的接口。
    • Network / localhost: 控制平面与管理客户端通信的网络接口。
    • CLI Mgmt Client (CLI 管理客户端): 外部的管理工具，通过命令行界面配置和监控 xiRAID Opus 解决方案。
• 交互方式： 虚拟机通过 Vhost 或网络协议发送I/O请求到 xiRAID Opus 数据平面；数据平面组件（卷、RAID引擎、NVMe Initiator）处理请求并与物理NVMe驱动器交互。控制平面负责管理驱动器、配置系统，并通过网络/localhost和gRPC接口与管理客户端进行交互。

架构图详细展示了 xiRAID Opus 如何在虚拟化环境中通过优化的数据路径和独立的控制平面来管理和提供高性能的RAID保护存储，以利用底层的NVMe驱动器。

将块设备连接到虚拟机的方法

将块设备连接到虚拟机的方法

图片列出了几种将块设备呈现给虚拟机的方法。这些方法通常涉及虚拟化框架和用户空间驱动程序之间的交互，以实现存储I/O。

• 主要方法： 图片中提到了四种不同的技术或框架：
  1. VIRTIO: 一种标准的半虚拟化框架，支持单 IOT (I/O Thread) 和多 IOT 配置。
  2. vhost-user-blk: 基于 vhost 框架，运行在用户空间的块设备后端实现。
  3. VDUSE (vhost-user-blk Device in Userspace): 允许在用户空间实现块设备，并通过 vhost-user 协议将其暴露给虚拟机。
  4. ublk: 另一种在用户空间实现块设备的方法，图片中特别指出其对虚拟环境的支持是有限的。

图片详细说明了进行技术比较时使用的测试环境和配置。主要是将 xiRAID Opus RAID 5 的性能与标准的 MDRAID RAID 0 进行对比，以展示 xiRAID 的优势。

这些配置细节为后续的性能测试结果提供了背景信息，说明了测试的严格性和复现性。

不同IO路径的IOPS性能

不同IO路径的IOPS性能

图片展示了在将共享块存储卷连接到单个虚拟机时，不同存储技术和配置在随机读取性能方面的比较结果。测试使用了两种不同的工作负载强度（低负载和高负载）。

• 测试目标： 衡量在单虚拟机场景下，各种方法传递共享块卷时的随机读取性能（IOPS 和 99.9% 延迟）。
• 测试配置：
  • 低负载： 1 个作业，IO 深度为 1。
  • 高负载： 32 个作业，IO 深度为 32。
• 比较的技术/配置：
  • xiRAID Opus 通过 vhost-user-blk 接口。
  • xiRAID Opus 通过 NVMe/RDMA 接口。
  • MDRAID 通过 VDUSE 接口。
  • MDRAID 通过 VIRTIO MVQ，使用 aio=native。
• 观察到的性能结果：
  • 低负载 (1 job/1 IO depth): xiRAID Opus (vhost-user-blk) 和 xiRAID Opus (NVMe/RDMA) 提供了最高的 IOPS，且 99.9% 延迟相对较低。MDRAID VDUSE 性能最低，MDRAID VIRTIO 性能居中。
  • 高负载 (32 jobs/32 IO depth): xiRAID Opus (NVMe/RDMA) 表现出最高的 IOPS，其次是 xiRAID Opus (vhost-user-blk)。MDRAID 的两种配置在高负载下的 IOPS 显著低于 xiRAID Opus，尤其是 MDRAID VDUSE 性能仍然很低。同时，xiRAID Opus 的两种配置在高负载下依然保持了相对较低的 99.9% 延迟增长，而 MDRAID 的延迟增长可能更高（虽然图中 MDRAID VIRTIO 的延迟线缺失）。

测试结果表明，在随机读取工作负载下，特别是在高并发场景中，xiRAID Opus 通过其不同的接口（vhost-user-blk 或 NVMe/RDMA）相比传统的 MDRAID 配置（无论是通过 VDUSE 还是 VIRTIO）提供了显著优越的性能（更高的 IOPS 和更好的延迟）。

不同IO路径的传输带宽

不同IO路径的传输带宽

图片展示了在将共享块存储卷连接到单个虚拟机时，不同存储技术和配置在顺序写入性能方面的比较结果。测试使用了两种不同的工作负载强度。

• 测试目标： 衡量在单虚拟机场景下，各种方法传递共享块卷时的顺序写入性能（吞吐量，单位 GBps）。
• 测试配置：
  • 低负载： 1 个作业，IO 深度为 1。
  • 高负载： 8 个作业，IO 深度为 32。
• 比较的技术/配置：
  • xiRAID Opus 通过 vhost-user-blk 接口。
  • MDRAID 通过 VDUSE 接口。
  • MDRAID 通过 VIRTIO MVQ，使用 aio=native。
  • 注意：与随机读取测试不同，此处未包含 xiRAID Opus (NVMe/RDMA) 的数据。
• 观察到的性能结果：
  • 低负载 (1 job/1 IO depth): xiRAID Opus (vhost-user-blk) 的顺序写入吞吐量显著高于 MDRAID VDUSE 和 MDRAID VIRTIO。
  • 高负载 (8 jobs/32 IO depth): xiRAID Opus (vhost-user-blk) 依然保持最高吞吐量，但与 MDRAID VIRTIO 的差距在高负载下有所缩小。MDRAID VDUSE 的性能仍是最低的。

测试结果表明，在顺序写入工作负载下，xiRAID Opus 通过 vhost-user-blk 接口通常能提供优于 MDRAID 通过 VDUSE 或 VIRTIO 的性能，尤其是在低负载情况下优势更明显。在高负载下，xiRAID Opus 保持领先，但 MDRAID VIRTIO 的性能有所提升，差距相对缩小。

选择 vhost-user-blk 的理由及结论

选择 vhost-user-blk 的理由及结论

图片阐述了为什么 xiRAID Opus 项目选择并优化了 vhost-user-blk 作为向虚拟机交付高性能块设备的关键方法，并给出结论认为这是实现此目标的“唯一选择”。

• 主题： 选择 vhost-user-blk 的理由及结论。
• 核心结论： 作者认为，使用他们自己实现的 vhost-user-blk 的 xiRAID Opus 是向虚拟机提供高性能块设备的最佳（甚至是唯一）途径。
• 支持该结论的理由/实现：
  • 多线程接口： 为 VHOST User BLK 开发了多线程接口，这通常有助于提高并行处理能力和性能。
  • 借鉴 SPDK 最佳实践： 吸取了 SPDK (Storage Performance Development Kit) 中的优秀经验和技术，SPDK 是一个专注于高性能存储的用户空间库。
  • CPU 特性优化： 针对 AMD 和 Intel 处理器上的特定 CPU 特性进行了优化，以更好地利用硬件能力。
  • 单实例性能优化： 即使在只有一个虚拟机和单个块设备这样看似简单的场景下，性能也得到了优化，这表明其底层实现的效率。

原文标题：High-Performance Block Volumes in Virtual Cloud Environment

Notice：Human's prompt, Datasets by Gemini-2.5-flash-thinking

延伸思考

这次分享的内容就到这里了，或许以下几个问题，能够启发你更多的思考，欢迎留言，说说你的想法~

1. 除了本文讨论的块存储性能优化，文件存储或对象存储在云端AI工作负载中面临哪些独特的性能挑战，又有哪些潜在的解决方案方向？
2. 用户空间存储解决方案（如xiRAID Opus）相比传统的内核态存储方案，在部署、管理和安全性方面可能带来哪些新的机遇和挑战？
3. 随着AI模型规模持续增长和计算硬件不断演进，未来的云端AI存储技术需要具备哪些新的特性才能满足需求？