NVMe SSD 开发工具：NVMeVirt

全文概述

文档介绍NVMeVirt，一个基于软件的虚拟NVMe设备模拟器，及其在加速存储系统研发中的应用。

NVMeVirt通过实现对新型存储设备（如NVM SSD、KV-SSD和ZNS SSD等）的高级命令支持，促进了先进存储技术的发展。该模拟器不仅允许开发者在无需物理硬件的情况下测试和优化新功能，还能精确复制真实设备的性能，为用户提供了一个理想的开发平台。此外，NVMeVirt还被用于快速原型设计新的NVMe接口扩展、识别并改进存储栈中的软件瓶颈以及评估未来高性能存储设备的可扩展性等方面。

文中详细讨论了NVMeVirt的工作原理、它如何与操作系统和应用程序交互，以及其提供的多种核心功能，包括检查点性能恢复、深度学习推理性能以及针对特定工作负载的基准测试等。最后，文中提到了相关的研究论文和代码仓库链接，鼓励读者深入了解NVMeVirt及其在存储系统研究与开发中的潜力。

模拟器现况

• Emulators 的优点
  • 如 NVM SSD、KV-SSD、ZNS SSD、FDP、计算存储等。
  • 支持高级指令（例如，批量读写、事务性指令）。
  • 可以在软件中实现这些概念。
  • Emulators 可以通过实现新的设备概念来促进高级存储开发
• Emulators 的局限性
  • 无法支持某些 I/O 模型和现代存储配置。

图中表格比较不同模拟器技术在NVMe 多个特性上的支持情况。

• Trace-driven（基于轨迹驱动的模拟器） 无法部署到真实环境中，执行速度快，但缺乏现代存储功能支持（例如 NVMe 多队列）。
• Full-system（基于完整系统的模拟器） 非常慢，无法部署到真实环境，但提供易于修改的 NVMe 接口。
• VM-based（基于虚拟机的仿真器） 支持 NVMe 多队列，但在支持低延迟设备时有困难，无法实现高效的内核绕过。
• Block-driver level（基于块驱动的仿真器） 执行速度快，支持基本功能，但对接口修改支持较差。
• NVMe-driver level（基于 NVMe 驱动的仿真器） 支持大部分功能，但接口修改和低延迟支持仍有一定限制。
• HW platforms（硬件平台） 支持所有高级功能，但对接口修改较困难。
• NVMVirt（NVM 仿真虚拟化） 提供实时性能，全面支持现代存储功能，包括 PCI 点对点 DMA 和 NVMe-oF 目标卸载。

当前 NVMe 设备的访问方式

Real System（真实系统）

• 结构描述
  • 应用程序通过 I/O 请求与操作系统交互。
  • 操作系统通过 I/O 堆栈处理这些请求，并将其转化为 NVMe 指令。
  • NVMe 指令通过 PCIe（外围组件互连高速通道）直接与 NVMe SSD 通信。
• 特点
  • 直接硬件访问。
  • 高性能和低延迟。

Device driver-level（设备驱动层，例如 David、FlexDrive）

• 结构描述
  • 应用程序通过 I/O 请求与操作系统交互。
  • 操作系统调用设备驱动程序。
  • 一些场景下可能使用用户驱动的 I/O（例如通过 SPDK）。
  • 无法直接访问硬件资源（例如 GPU/NIC），与设备驱动 I/O 的整合存在障碍。
• 限制
  • 阻断路径（用红叉表示） GPU/NIC 和设备驱动之间的交互不被支持。
  • 受限的硬件直接访问能力。

VM-based（基于虚拟机，例如 VSSIM、FEMU）

• 结构描述
  • 应用程序通过 I/O 请求与虚拟化操作系统交互。
  • 操作系统通过 I/O 堆栈生成 NVMe 指令。
  • NVMe 指令由 Hypervisor（虚拟机管理程序）处理，并转发到虚拟 NVMe SSD。
• 特点
  • 提供对硬件抽象的访问。
  • 适用于虚拟化环境。
• 限制
  • 阻断路径（用红叉表示） 无法直接支持 GPU/NIC 等硬件资源的访问。
  • 存在额外的虚拟化开销（用时钟图标标示）。

总结

1. 实时系统具有最佳性能，但硬件依赖性较强。
2. 设备驱动层方法支持用户驱动 I/O，但对硬件资源的直接访问有限。
3. 基于虚拟机的方法更灵活，支持虚拟化，但存在性能开销和硬件访问限制。

FEMU 简介

FEMU (Flash EMUlator) 是一种轻量级的存储设备仿真工具，专注于对闪存存储设备（如 SSD）进行功能和性能仿真。它能够在不需要真实硬件的情况下，通过软件模拟存储设备的行为，提供研究与开发环境，主要用于测试存储系统的性能与可靠性。

FEMU 的特点

1. 轻量级设计
   • 作为一种基于软件的模拟器，FEMU 具有低资源需求和易于部署的特点。
   • 无需物理存储设备即可进行存储系统的功能测试。
2. 灵活性
   • 支持各种类型的存储模型（如 NAND 闪存、SSD、NVMe 协议）。
   • 可以在虚拟化环境（如 KVM/QEMU）中运行，模拟存储设备的行为。
3. 应用场景
   • 测试存储系统中的新算法（如垃圾回收、磨损均衡）。
   • 验证文件系统或数据库在不同存储条件下的性能表现。
   • 模拟硬件错误或极端条件下的系统行为（如延迟、坏块）。
4. 开发环境支持
   • FEMU 集成于 QEMU 虚拟化平台，方便开发者在常用的 Linux 环境中使用。

文章 后面将比较 FEMU 与 NVMeVirt 的模拟器性能，姑且先理解下FEMU。

Virtual NVMe Device（虚拟 NVMe 设备）

1. PCIe Device Emulator（PCIe 设备仿真器）
   • PCI 配置头（PCI Configuration Header）。
   • BARs（基址寄存器）。
   • Capabilities（设备能力）。
   • MSI-X 表（中断表）。
   • 提供以下功能
2. NVMe Controller Emulator（NVMe 控制器仿真器）
   • 管理队列对（Administration Queue Pair） 处理控制和管理命令。
   • I/O 队列对（I/O Queue Pairs） 处理实际的数据读写。
   • DMA 引擎（直接内存访问引擎） 负责高效的数据传输。
   • 主要功能
3. Storage Backend（存储后端）
   • 常规 SSD（Conventional SSD） 支持 FTL（Flash Translation Layer）。
   • NVM SSD 支持非易失性存储。
   • Zoned Namespace SSD（分区命名空间 SSD） 支持 Zone 信息。
   • Key-Value SSD（键值 SSD） 支持索引结构。
   • 模拟多种存储模型

NVMVirt 是一种基于软件的虚拟化 NVMe 设备，使用轻量级内核模块实现

1. 提供完整的 NVMe 控制器功能（例如队列管理、DMA 引擎）。
2. 支持多种存储后端（传统 SSD、NVM SSD、分区 SSD、键值 SSD）。
3. 与硬件设备（如 CPU、RAM 和 PCIe 交换机）高效交互，支持轻量级 MSI-X 模拟。

设计过程存在的问题

如何在软件中创建虚拟 PCI 设备实例？

• 解决方法
  1. 通过虚拟 PCI 总线间接创建 PCI 设备实例。
  2. 虚拟 PCI 总线将 PCI 配置头（PCI configuration header）呈现给 PCI 子系统。
  3. 无需对 Linux 内核进行修改

如何模拟设备寄存器的内存映射访问？

• 解决方法
  1. 主机（Host）更新 PCI BAR（基址寄存器）内存映射区域。
  2. 这些更新用于配置设备并触发“doorbells”（门铃机制）。
  3. 一个专用的分发线程（Dispatcher thread）会轮询 NVMe 控制块和门铃。

模拟器中的IO操作

模型 一个调度器（Dispatcher）+ 多个 I/O 线程（每个线程绑定到一个核心）。

流程细节

1. 从提交队列到调度器
   • I/O 请求从 Submission Queue（提交队列） 被调度器提取出来。
   • 提交队列与完成队列形成 I/O 队列对（I/O Queue Pair）。
2. 调度器设置完成时间
   • 调度器通过建模 I/O 延迟，设置目标完成时间（Target Completion Time）。
3. 分配给 I/O 线程
   • I/O 请求被分配到多个 I/O 线程中（如 I/O Thread #0, I/O Thread ）
   • 每个线程绑定到一个独立的 CPU 核心。
4. 线程处理 I/O 请求
   • I/O 线程根据后端类型（Backend Type）处理 I/O 操作。
   • 后端模块（Backend）可能包括存储模型（如常规 SSD、键值存储等）。
5. 完成消息与通知
   • 在完成处理后，线程填充完成消息，并通过中断（IPI）通知主机完成操作。

存储后端分析

NVM SSD 与传统SSD的比较

1. NVM SSD
   • 优势：性能高，无垃圾回收，适用于高性能、低延迟需求的场景。
   • 缺点：原地更新的可靠性较低，适用场景较窄。
2. Conventional SSD：
   • 优势：功能更全面，支持复杂的存储管理（如垃圾回收和磨损均衡），适用范围广泛。
   • 缺点：因为垃圾回收等机制导致性能稍低，延迟较高。

选择依据：

• 如果需要极低延迟和高性能（如数据库加速），可选择 NVM SSD。
• 如果需要平衡性能与存储管理功能（如消费级或企业存储应用），Conventional SSD 更合适。

高级模式特性

高级性能模型模拟了复杂的 SSD 内部结构，包括以下特性

1. 全规模的页映射 FTL（Page-mapped FTL）
   • 含有垃圾回收（GC）功能。
   • 精确模拟 SSD 的逻辑到物理地址映射过程。
2. 设备上的写缓冲区（Write Buffer）
   • 模拟写缓冲的行为，优化写入性能。
3. 现代 SSD 的并行架构（Parallel Architectures）
   • 每个通道的带宽为 800 MiB/s。
   • 多个 FTL 实例 每个实例管理独立的存储单元。
   • 独立运行的多个 Dies 和通道（Channels）
   • Superblock 作为操作单元 由多个物理块组成的逻辑管理单元。
   • PCIe 链路和通道的总带宽限制 模拟实际硬件的带宽瓶颈。
4. 预留空间（Reserved Space as OP Area）
   • 预留 N% 的存储空间作为超额分区（Over-provisioning, OP），用于提高性能和延长设备寿命。

右侧图示 SSD 写IO的模块交互，从 PCIe物理线路--写缓冲--FTL地址映射--Flash DIE 模块--Block--Page。

测试组物理参数

测试方法 & 基准测试

• 展示 10 次运行的百分位分布。
• 每次运行使用 fio 工具进行 4 KiB 的随机写操作。
• 图中误差线（Error bar）表示对应百分位的标准差。

Optane 由于介质层优势，整体时延较SSD要明显低，性能更好。

模拟器对照测试

• FEMU 的不足
  • 高百分位的长尾延迟（Long tail latency）显著。
  • 高运行间波动使其无法稳定仿真高性能存储设备（如 NVM SSD）。
• NVMVirt 的优势
  • 仿真延迟低且性能稳定，与高性能存储设备（如 Optane）更接近。
  • 能够提供准确且稳定的性能仿真，是 FEMU 的明显改进。
• Optane 与 SSD 对比
  • Optane 的延迟和波动明显小于传统 SSD，证明其硬件性能的优势。
• 结论
  • NVMVirt 是更适合高性能存储仿真的工具，能够有效模拟实际硬件的性能表现。
  • FEMU 适用于低性能需求的场景，但在高性能仿真中表现不佳。

不同SSD的模拟性能比较

• NVMVirt 是一款高精度存储设备仿真工具，能够几乎完美地复制真实设备的性能。
• 适用于高性能存储设备的开发、测试与研究，提供了一个可靠的模拟环境。

Note

鹏弟看到这张图，最兴奋的不是Get到模拟器与真实设备的性能差距小，而是以下几点：

1. 同一存储介质，不同块大小读写名义性能，这对于具体业务场景/解决方案的概念性评估非常有帮助，能构建起相对合理的业务模型，而且一次性给出了4种先进SSD载体。
2. 不同介质的读写性能比较，这里鹏弟有几点疑惑：
   • 之前没接触过 ZNS 和 KV SSD的基准测试结果，故对图中的名义性能无法评估，KVSSD的性能这么低吗？而且对文件块大小似乎并不敏感。
   • 传统SSD和Optane的性能也有疑点，正常来说非易失的Optane 应该有更高的随机读写性能，但从数据来看：读性能要比SSD差不少。 了解具体情况的朋友，欢迎留言指导下，最好带点具体场景数据，先谢过！

OLTP 事务型场景案例

实验内容

1. 目标
   • 通过 Sysbench OLTP 测试工具评估两个数据库系统（MariaDB 和 PostgreSQL）的 I/O 性能。
   • 测试包括 I/O 带宽和队列中请求数量的动态变化。
2. 测试指标
   • 测量数据库在 I/O 请求队列中排队的请求数量，反映 I/O 压力和延迟。
   • 测量数据库的 I/O 吞吐量，观察不同负载条件下的波动。
   • I/O 带宽（MB/s）
   • 队列中的请求数（requests in queues）
3. 测试负载
   • 测试运行在 4 种负载下（单位 查询数/秒） 250、500、1000、2000，以及最大负载（Max）。

观察与分析

1. MariaDB 的表现
   • 在低负载下性能稳定，高负载时前100s存在波动，之后保持稳定。
   • 高负载下的最终带宽收敛到500MB/s。
2. PostgreSQL 的表现
   • 在中低负载条件下，性能稳定。
   • 最大负载时的 I/O 带宽明显高于 MariaDB，队列积压的请求数量也更少，表明其 I/O 管理效率更高。
3. 对比
   • PostgreSQL 在高负载下具有更高的吞吐量，但 I/O 行为的不稳定性也明显增加。
   • MariaDB 在高负载时波动较大，可能受限于其 I/O 管理机制。

pgSQL 与 MariaDB 带宽性能差异分析

1. PostgreSQL 的 I/O 管理机制更高效

• 异步 I/O 机制：
  • PostgreSQL 广泛使用异步 I/O（Asynchronous I/O），可以在发起 I/O 操作的同时处理其他任务，从而提高整体吞吐量。
  • MariaDB 更依赖于同步 I/O，I/O 操作完成之前可能会阻塞其他操作，因此在高负载时吞吐量受到限制。
• Buffer Pool 的高效设计：
  • PostgreSQL 使用共享缓冲池（Shared Buffers）来减少对存储设备的直接访问。缓冲池能有效减少高负载时的 I/O 请求，提升带宽峰值。
  • MariaDB 的缓冲池（如 InnoDB Buffer Pool）设计虽然相似，但在高并发情况下可能不如 PostgreSQL 稳定。

2. 查询优化器的差异

• 查询优化器的性能：
  • PostgreSQL 的查询优化器在复杂查询和高并发环境下表现更优，能够更好地将请求分布到多个 I/O 通道上。
  • MariaDB 的查询优化器在高负载条件下可能生成次优的执行计划，从而限制了 I/O 带宽的利用率。
• 索引管理：
  • PostgreSQL 的索引机制（如 B-Tree、GIN、BRIN 等）在高并发查询中具有更高的效率，减少了对底层存储设备的负载。
  • MariaDB 在高负载场景下的索引更新可能带来额外的 I/O 压力，降低整体吞吐量。

3. 并行查询和多线程支持

• PostgreSQL 并行查询：
  • PostgreSQL 在高负载条件下可以利用并行查询功能，将查询任务分解为多个子任务并行执行，从而提高带宽利用率。
  • MariaDB 对并行查询的支持较为有限，因此无法在高负载时充分利用硬件资源。
• 多线程优化：
  • PostgreSQL 的多线程机制在高负载场景下表现出色，可以充分利用 CPU 和 I/O 通道。
  • MariaDB 的多线程设计在高并发场景中可能更容易出现资源竞争和瓶颈。

AI 负载案例

Note

这组数据，没看懂想表达什么。。。

NVMVirt 应用场景

• 为新的 NVMe 接口扩展快速制作原型
• 发现并改善存储堆栈中的软件瓶颈
• 分析应用程序在未来高性能存储设备上的可扩展性
• 调查硬件参数（例如 MDTS）的性能影响
• 开发新的以设备为中心的架构
• 基准测试和性能测试与监控

列举了与 NVMe 存储技术相关的多种应用场景，重点是性能优化、扩展性分析和硬件架构改进。它展示了如何利用这些用例来推动高性能存储设备和相关技术的发展。