解耦SDS架构：加速云存储的未来

数据存储前沿技术

发布于 2025-03-10 11:26:05

680

全文概览

随着云计算和大数据技术的快速发展，云存储已成为现代数据管理的核心。然而，传统的云存储架构在处理大规模数据访问时，面临着性能瓶颈和延迟问题。本文探讨了一种通过解耦软件定义存储（SDS）架构来加速云存储性能的创新方法。通过引入硬件卸载模块和优化数据路径，本文展示了如何在不牺牲存储可靠性和可用性的前提下，显著提升存储系统的IOPS吞吐量和降低延迟。文章详细介绍了Ceph存储系统的概念验证（PoC）实验，展示了在随机读取操作中实现10倍性能提升的潜力。对于从事云计算、大数据分析和存储系统设计的专业人士，本文提供了宝贵的见解和实践指导。

阅读收获

理解云存储架构的瓶颈与优化方法：通过解耦SDS架构，读者可以了解如何在不牺牲存储可靠性的前提下提升性能。
掌握Ceph存储系统的优化技术：通过Ceph的PoC实验，读者可以学习到如何在实际应用中优化存储性能。
了解硬件卸载模块的应用：读者可以了解到如何通过硬件卸载模块来绕过传统软件路径的瓶颈，提升存储系统的效率。

经典云存储架构

图表明当前云存储架构通过分布式存储集群和软件定义存储（SDS）中间件，实现了高扩展性和高可用性。尽管存储性能存在一定的延迟，但通过微秒级的底层驱动性能，仍能达到较高的IOPS吞吐量。

===

客户端应用程序：客户端节点连接到逻辑卷。
- 逻辑卷被透明地切分，每个逻辑卷分割为多个分片。
- 这些分片作为数据块存储在分布式存储集群中。

架构描述：

云存储服务提供扩展性、高可用性、持久性和可靠性。
内部使用服务器集群，每个服务器提供其驱动器以实现特定服务。
中间件（也称为软件定义存储SDS）在每台服务器上运行，协作提供存储服务。

云存储特点：

云存储速度较慢（毫秒级延迟，10K-100K IOPS吞吐量）。
底层驱动性能：微秒级延迟，吞吐量达到百万级IOPS。

快速云存储的重要性

图展示了在需要大规模数据访问的计算密集型任务中，快速云存储的重要性。为了提高性能，云存储架构中引入了分布式缓存层，以减少从慢速存储中加载数据的时间。尽管有几种不同的处理选项，但每种选择都增加了额外的成本和复杂性。

===

许多重要的使用场景具有读写重的IO模式，涉及大规模数据集：
- 深度学习训练
- 大数据分析
- 网络搜索
这些使用场景计算密集型，因此它们的任务会扩展到许多节点上。
巨大的数据足迹（多GB/TB）+ 多节点访问 → 将数据持久化到云存储中。
需要快速的云存储I/O，以避免计算资源因数据加载缓慢而被“饿死”！

架构描述：

从分布式应用程序到分布式缓存层的数据流。
- 选项1：将数据子集预加载到本地SSD中。
- 选项2/3：从快速存储层读取数据。
- 从慢速存储层加载数据。

当前实践增加了显著的成本和复杂性：

选项1：为实例配置本地SSD，预取并管理数据子集。
选项2：支付缓存产品/服务费用。
选项3：创建/管理定制的分布式缓存层。

解决方案：解耦数据路径

图片提出了一种通过使用硬件卸载模块绕过SDS（软件定义存储）数据路径瓶颈的解决方案。

思路是，尽管SDS管理集群级别的功能，但实际的数据读/写操作可以绕过SDS软件路径。系统使用硬件卸载模块缓存必要的逻辑到物理映射，并在SDS控制下，允许直接访问存储介质。这样可以提高IO请求的速度和效率，减少传统软件路径所带来的延迟。

===

问题：我们能否绕过数据的SDS软件路径瓶颈？
- SDS软件必须处理集群级别的功能。
- 但实际的数据读/写是否需要经过相同的IO路径？

基本思路：完全跳过SDS堆栈处理IO请求！一个辅助模块处理IO请求。

在后端存储目标服务器上：
- SDS软件“共享”数据的磁盘位置，通过卸载模块。
- 数据路径卸载缓存SDS控制下的逻辑到物理映射。
- 在接收到IO请求时，卸载直接访问磁盘上的数据。

软件PoC设计目标

图片概述了软件PoC（概念验证）设计的目标。讨论了Ceph作为SDS的选择，Ceph是开源的并广泛应用于行业。

SDS架构中的变更解耦了数据路径，并与控制平面同步。硬件卸载的内存占用是一个问题，导致采用一种方法，将映射表缓存存储在卸载内存中。此外，图片强调了理解数据平面操作与集群级别操作之间交互的重要性，重点识别瓶颈并提供接口建议。

===

SDS选择：Ceph是开源的，广泛应用于行业。
- 提供多种模式、接口和部署选项。
- 支持多级间接寻址和转换，基于块的逻辑卷创建于对象之上。
- 使用Ceph的PoC增加设计的可信度。
SDS架构变更：解耦要求数据路径与SDS控制平面同步。
- 设计了协议来共享映射，更新时进行驱逐。
- 模拟基于PCIe-ATS，面向未来硬件IP。
内存占用：硬件离载内存通常是稀缺资源。
- 我们最初采用基于压缩的方法，试图将所有映射都存储在内存中。
- 设计已演变为在离载内存中使用映射表缓存，存储整体映射的子集。
表征和理解数据平面与集群级别操作之间的交互：
- 识别离载与主机CPU之间的瓶颈路径。
- 提供离载和SDS的接口建议。

Ceph 中的 NVMe-oF 路径

图片介绍了Ceph NVMe-oF网关项目的目标，即通过优化NVMe-oF路径来改善裸金属客户端的性能并减少客户端的CPU开销。

图片还讨论了如何扩展NVMe-oF路径，包括启动端和目标端的路径扩展，尤其关注如何通过标准化和定制机制提高性能。重点放在Ceph对象存储守护进程（OSD）和目标服务器的数据路径上。

===

Ceph NVMe-oF网关项目的目标：
- 使裸金属客户端能够连接到Ceph。
- 减少客户端访问Ceph时的CPU开销。
关于性能：
- NVMe驱动的性能在几十微秒的量级。
- 通过NVMe-oF进行远程访问的延迟在10-100微秒之间。

在Ceph架构中分离控制和数据路径以提高性能

扩展NVMe-oF路径到运行Ceph对象存储守护进程（OSD）的目标服务器：
- 启动端：如何定位集群中负责指定逻辑范围的服务器。
  - ADNN（自适应分布式NVMe-oF命名空间）的标准化正在进行中。
  - 少数一些大型云提供商为其存储服务使用的定制带外机制。
- 扩展NVMe-oF路径直到驱动器。
  - 目标端：目标服务器中的数据路径。重点关注软件PoC。

软件PoC详细信息

图展示了通过SPDK（存储性能开发工具包）与Olympia服务合作，实现从驱动器到对象的高效数据读取路径。

通过Ceph OSD的控制，映射信息可以被缓存和共享，在数据请求时可以通过直接访问或请求Olympia服务来快速定位对象，从而提升存储操作的效率。

===

直接读取路径到驱动器 在OSD控制下：

补丁应用于Ceph OSD，以共享逻辑到物理映射。
映射由SPDK应用程序缓存（对象数据不被缓存）。

数据流图解：

应用侧发起块读取请求
SPDK Fastpath bdev：首先检查缓存的映射。
- 如果命中，fastpath bdev直接从驱动器读取。
- 如果未命中，SPDK fastpath bdev请求Olympia服务（OTS）以获取物理映射。
Olympia翻译服务（OTS）：识别支持将客户端的块请求转化为对象请求。
Olympia对Ceph OSD的修改：在驱动器上定位对象并与SPDK应用程序共享物理映射。
OSD：当对象在驱动器上移动时，驱逐映射。

软件PoC实验设置

图展示了一个包含两个Ceph节点的PoC实验设置，每个Ceph节点配备一个730GB的NVMe驱动器，并通过fio工具进行性能测试。

测试内容为1百万次随机读取操作，读写大小为4KB。实验架构包括客户端节点、网关节点和两个存储节点，其中存储节点包含Olympia服务来处理块到对象的映射。

===

两节点Ceph部署
每个Ceph节点有一个730GB的NVMe驱动器
在测试运行之前，fio工具会将驱动器写入大约85%的容量（约600GB）
测试运行 = 1百万次随机读取，每次大小为4KB

实验中测量的IO路径

图展示了不同实验设置下的IO路径：

基准路径（Ceph RBD）：客户端节点通过RADOS发起对象请求，通过存储节点处理。
NVMf网关-RBD路径：客户端通过NVMe-oF协议发送块请求，经过网关节点并与存储节点交互，涉及RBD bdev。
Olympia路径（miss）：如果缓存未命中，客户端通过NVMe-oF协议请求块，经过Olympia服务进行块到对象映射，fastpath bdev则负责处理miss的请求。
Olympia路径（hit）：如果缓存命中，客户端请求直接通过fastpath bdev和aio bdev进行处理，数据存储在NVMe驱动器中。

性能评估-1

图展示了在不同设置下的随机读取延迟比较，显示了基准、NVMf网关-RBD、fastpath（miss）、fastpath（hit）和本地驱动器的性能差异。

fastpath（hit）显示出显著减少的平均延迟，证明缓存命中路径能够提供更优的性能。图中列出的各项延迟数据表明，fastpath（hit）路径显著降低了延迟，尤其是在P99.99情况下。

===

测试设置：

两个Ceph节点，每个节点配置一个730GB的NVMe驱动器。
基准：客户端通过Ceph本地协议（RADOS）读取。
性能条形图：本地驱动器的软驱动读取延迟。
fastpath hit列表示所有读取都从缓存映射中读取（注意：数据仍然是从驱动器读取的）。

深入理解 fastpath bdev

具体来说，fastpath bdev是一个优化的数据路径，它可以将块数据的映射信息缓存到内存中，从而加速后续的数据访问。当数据请求发生时，如果请求的块数据已经在缓存中（即缓存命中），则直接从内存中读取，而无需每次都访问驱动器。

但是，尽管数据从缓存中读取，实际上还是会执行对存储驱动器的访问。这是因为即使数据已在缓存中，原始数据仍然存储在硬盘驱动器中，而缓存只是提高访问效率的手段。

缓存映射的实现流程：

映射数据存储：通过Olympia翻译服务，将块（block）与对象（object）之间的映射关系存储在缓存中。
读取请求：当读取请求到达时，系统首先检查缓存中是否有该请求的数据映射。
缓存命中：如果缓存中已有该数据的映射，fastpath bdev会直接使用缓存中的数据进行读取，从而提高了访问速度。
缓存未命中：如果缓存中没有数据映射，系统会通过Olympia翻译服务查找数据的物理位置，并从驱动器中读取数据，再将该数据的映射存入缓存中，供后续请求使用。

#todo Olympia 服务的实现原理，值得深入理解下，fastpath bdev 是高性能的存储介质，提供映射缓存（Mapping Cache）。

性能评估-2

图展示了在不同队列深度下的随机读取吞吐量。通过对比基准Ceph RBD和fastpath hit路径，我们可以看到在增加队列深度时，fastpath hit的吞吐量呈现出4-10倍的增长，特别是在高队列深度时表现突出。此结果表明，使用缓存映射（fastpath hit）可以显著提高系统的吞吐能力。

备注：吞吐量随着队列深度的增加，fastpath hit路径的表现明显优于基准。

如何理解这里的队列深度？

队列深度（Queue Depth）指的是存储系统能够同时处理的I/O请求的数量。每一个I/O请求可以看作是一个单独的工作任务，而队列深度表示系统在同一时间内能够排队等待处理的I/O请求的数量。

具体来说，队列深度等于作业数量 × 每个作业的I/O深度，也就是说它衡量了同时进行的读写操作的并发性。

较低的队列深度（如1或2）意味着系统在任何时刻只能处理少量的I/O请求。这种情况下，系统的吞吐量可能会受到瓶颈限制，因为处理的请求较少。
较高的队列深度（如64或128）意味着系统可以同时处理大量的I/O请求。这通常可以更有效地利用存储硬件的并发处理能力，从而提高吞吐量。

为什么fastpath hit在高队列深度时有显著提升？

缓存命中的优势：当使用fastpath hit时，很多I/O请求会在缓存中找到已经映射好的数据，因此可以直接从缓存中读取，而不需要访问存储驱动器。随着队列深度的增加，系统能处理更多的并发请求，这种缓存命中的效率使得fastpath hit在高并发情况下表现特别好，吞吐量大幅提升。
提高了并发处理能力：高队列深度意味着系统能够处理更多的并发I/O操作，利用存储硬件的并行能力。在这种情况下，如果数据已在缓存中，读取的速度会显著提高，从而进一步提升吞吐量。