? 背景

随着物理硬件的不断发展，存储软件所使用的硬件的情况也一直在不断变化。

一方面，内存和 IO 技术一直在快速发展，硬件的性能在极速增加。在最初设计 Ceph 的时候，通常情况下，Ceph 都是被部署到机械硬盘上，能够提供数百 IOPS 的读写和数十 G 的磁盘容量。但是，目前最新的 NVMe 设备可以提供数百万的 IOPS 读写，并支持 TB 级的磁盘容量。DRAM 的容量在大约20年的时间内增加了128倍。对于网络 IO 来说，网卡设备现在能够提供超过 400Gbps 的速度，而几年前只有 10Gbps。

另一方面，在大约十年的时间内，CPU 频率和 CPU 内核的单线程性能一直处于稳定的状态，增长不明显。相比之下逻辑核心的数量随着晶体管规模的增加而迅速增长。

Ceph 的性能要跟上硬件发展的速度一直很有挑战的，因为 Ceph 的架构是十年前的——它对单核 CPU 性能的依赖使它无法充分利用不断增长的 IO。特别是，当 Ceph 对象存储守护程序（OSD）依赖线程池来处理不同的 IO 时，跨 CPU 核心通信会产生了大量的延迟开销。减少或消除这些开销成本是 Crimson 项目的核心目标。

Crimson 项目使用 shared-nothing? 设计和 run-to-completion 模型来重写 Ceph OSD，以满足苛刻的硬件与软件系统的扩展要求，同时也与现有的客户端和组件兼容。

为了理解 Crimson OSD 如何针对 CPU 扩展进行重新设计的，我们比较了 传统 OSD 和 Crimson OSD 之间的架构差异，来解释架构怎么以及为何这样设计。然后我们讨论了 Crimson 为什么建立在 Seastar 框架之上，以及每个核心组件是如何实现扩展的。

最后，我们分享了实现这一目标的最新情况，同时还提供了一个我们最终希望达到的性能结果。

Crimson 与传统 OSD 架构

Ceph OSD 是 Ceph 集群的一部分，主要负责通过网络来提供对象的访问、维护数据冗余和高可用性以及将对象持久化到本地存储设备。作为传统 OSD 的重写版本，Crimson OSD 从客户端和 OSD 的角度来看是与现有的 RADOS 协议兼容的，它提供相同的接口和功能。Messenger、OSD 服务和 ObjectStore 等 Ceph OSD 模块化的功能没有太大改变，但跨组件交互和内部资源管理的形式进行了大幅重构，以使用 shared-nothing 设计和自下而上的用户空间任务调度。

传统 OSD 的架构中，每个组件中都有线程池，针对多 CPU 核心场景下，使用共享队列处理任务效率很低。在一个简单的例子中，一个 PG 操作需要先由一个messenger worker 线程处理，将原始数据流组装或解码成一条消息，然后放入消息队列中进行调度。之后由一个PG worker thread 来获取消息，经过必要的处理后，将请求以事务的形式交给 ObjectStore。

事务提交后，PG 会完成操作，再次通过发送队列和 messenger worker 线程发送回复。尽管可以通过向池中添加更多线程来将工作负载扩展到多个 CPU，但这些线程默认共享资源，因此需要锁，这会引入争用问题。

传统架构的一个主要挑战是锁竞争开销随着任务数和 CPU 核数的增加而迅速扩大，在某些场景下每个锁点都可能成为扩展瓶颈。此外，这些锁和队列即使在没有争用的情况下也会产生延迟开销。多年来，社区在分析和优化更细粒度的资源管理和快速路径实现以跳过队列方面做了大量工作。未来，这类优化的成果会越来越少，可扩展性似乎会在当前的设计架构下达到了某个瓶颈。也还有其他挑战。随着在工作线程之间分配任务，延迟问题将随着线程池和任务队列而恶化。锁可以强制上下文切换，这会使事情变得更糟。

Crimson 项目希望通过 shared-nothing? 设计和 run-to-completion 模型来解决 CPU 可扩展性问题。该设计的重点是强制每个内核或 CPU 运行一个固定线程并在用户空间中分配非阻塞任务。因为请求以及它们的资源可以被分配到各个核心，所以它们可以在同一个核心中被处理，直到处理完成。理想情况下，我们不再需要所有的锁和上下文切换，因为每个正在运行的非阻塞任务都使用到 CPU，一直到它完成任务。没有其他线程可以在同一时间抢占任务。如果不需要与数据路径中的其他分片通信，理想情况下，性能将随着内核数量线性扩展，直到 IO 设备达到其极限。这种设计非常适合 Ceph OSD，因为在 OSD 层面，所有 IO 都已经被 PG 分片了。

虽然跨区通信不能完全消除，但那通常是用于 OSD 全局状态的维护，而不是用于数据路径中。这里的一个主要挑战是，最重要的改变是对 OSD 操作的基本要求——相当一部分现有的锁或线程代码无法重用，需要重新设计，同时保持向后的兼容性。

重新设计需要对代码的整体理解，以及相关的注意事项。使用 shared-nothing? 架构实现底层的one-thread-per-core和用户空间调度是另一个挑战。

Crimson 试图在 Seastar 的基础上重新设计 OSD，Seastar 是一个异步编程框架，具有满足上述目标的所有理想特性。

Seastar Framework

Seastar 是 Crimson 项目的理想选择，因为它不仅在 C++ 中实现了 one-thread-per-core? 的 shared-nothing 架构，而且还提供了一套全面的功能和模型，这些功能和模型已被证明在其它应用程序中对性能和扩展有效。资源默认情况下不在分片之间共享，Seastar 实现了自己的内存分配器以进行无锁分配。该分配器还利用了 NUMA 拓扑结构的优势，将最近的内存分配给分片。对于一些不可避免的跨核资源共享和通信，Seastar 强制要求明确地处理它们。如果一个分片拥有另一个核心的资源，它必须通过外部指针指向这些资源；如果一个分片需要与其他分片通信，它必须提交并转发任务给他们。这就迫使程序限制其跨核的需求，并有助于减少对 CPU 扩展性问题的分析范围。Seastar 还为跨核通信实现了高性能的非阻塞通信。

传统的带有异步事件和回调的程序在实现、理解和调试方面是非常困难的。用户空间的非阻塞任务调度需要实现普遍的异步性。Seastar 将 futures、promises 和 continuations (f/p/c) 作为构建块来组织逻辑。futures 和 promises 通过将逻辑上连接的异步结构组合在一起，而不是将它们分散用于普通的回调中，这使代码更更容易实现以及更好的可读性。Seastar 还为循环、计时器以及基于未来控制生命周期甚至 CPU 份额提供了更高级别的工具。为了进一步简化应用程序，Seastar 将网络和磁盘访问封装到 shared-nothing 和基于 f/p/c 设计的模式中。采用不同 I/O 堆栈（如 epoll、linux-aio、io-uring、DPDK 等）的复杂性和细微控制对应用程序代码是透明的。

Run-to-completion performance

Crimson 团队已经为 RBD 客户端的读写工作负载实现了 OSD 的大部分关键特性。当前完成的任务包括重新实现 messenger V2 (msgr2)， heartbeat， PG peering， backfill， recovery， object-classes， watch-notify， etc等，并不断努力的增加一些 CI 测试组件。Crimson 已经达到了一个里程碑，我们可以在具有足够稳定的单个分片中验证run-to-completion设计。

综合考虑现实条件，在相同的随机 4KB RBD 工作负载下，在没有复制的情况下，通过将传统和 Crimson OSD 与 BlueStore 后端进行比较来验证 single-shard run-to-completion?。两个 OSD 都分配了 2 个 CPU 资源。Crimson OSD 很特别，因为 Seastar 需要一个独占 CPU 核心来运行 single-shard OSD 逻辑。这意味着 BlueStore 线程必须固定到另一个核心，引入 AlienStore 来弥合 Seastar 线程和 BlueStore 线程之间的边界，并在两个边界之间提交 IO 任务。相比之下，传统 OSD 没有限制使用分配的 2 个 CPU。

性能结果显示，使用 BlueStore 时，Crimson OSD 的随机读取性能大约提高了 25%，随机写入情况下的 IOPS 大约比传统 OSD 高 24%。进一步的分析显示，在随机写的情况下，CPU 的利用率很低，因为大约 20% 的 CPU 被消耗在频繁的查询中，这表明 Crimson OSD 应该不是是当前的瓶颈。

Crimson OSD 提交和完成 IO 任务，以及在 Seastar 和 BlueStore 线程之间进行同步，也有额外的开销。因此，我们针对 MemStore 后台重复了同一组实验，两个 OSD 都分配了 1 个 CPU。如下图所示，Crimson OSD 在随机读取中提供了大约 70% 的 IOPS，在随机写入中比 传统 OSD 高 25%，这与之前实验中的结论一致，即 Crimson OSD 可以做得更好。

尽管上述场景仅涵盖实验性 single-shard? 案例，但结果表明使用 Seastar 框架具有性能优势——消除锁、通过用户空间任务调度删除上下文切换、分配更靠近 CPU 的内存。此外，重要的是要重申，run-to-completion 模型的目标是更好地扩展 CPU 并消除软件使用高性能硬件而引起的性能瓶颈。

Multi-shard Implementation

实现多分片的路径很明确。由于每个PG中的 IO 已经在逻辑上被分片，所以对IO路径没有太大改变。主要的挑战是确定无法避免的跨核通信，并设计新的解决方案，以尽量减少其对IO路径的影响，这需要根据具体情况进行分析。一般来说，当从 Messenger 接收到一个 IO 操作时，它会根据 PG-core 映射被定向到 OSD 分片，并在同一分片/CPU的上下文中运行，直到完成。请注意，在当前阶段，为了简单起见，设计上选择不修改RADOS协议。

Messenger

Messenger 在确保解决方案可扩展方面发挥着重要作用。有一些限制需要认真考虑。一个限制来自 RADOS 协议，它只为每个客户端或 OSD 定义一个连接。连接必须存在于特定核心上才能根据其状态高效且无锁地解码和编码消息。与 OSD 对等体的共享连接意味着在当前阶段跨核消息传递到多个 PG 分片是不可避免的，除非可以调整协议以允许到每个分片的独占连接。

Seastar 框架的另一个限制是它不允许在 Seastar 套接字被 accept()ed? 或 connect()ed 之后移动到另一个核心。这对无损连接 (msgr2) 来说是一个挑战，因为它会影响 Messenger 和 OSD 服务之间的交互，在这种情况下，由于网络故障重新连接，连接可能会预先跳转到另一个核心。

扩展 Messenger 的大部分工作是在将 IO 操作分派到 PG 分片之前将消息传递工作负载（编码、解码、压缩、加密、缓冲区管理等）优化扩展到多个内核，并最小化跨内核消息沿 IO 路径传递，理想情况下，在上述约束下，对于每个消息发送和接收操作，它最多保持 1 跳。

OSD

OSD 负责维护 PG 分片之间共享的全局状态和活动，包括心跳、身份验证、客户端管理、osdmap、PG 维护、访问 Messenger 和 ObjectStore 等。

多核 Crimson OSD 的一个简单原则是将所有与共享状态相关的处理保持在专用内核上。如果一个 IO 操作要访问共享资源，要么按顺序访问专用核，要么访问保持同步的共享信息的独占副本。

实现这一目标有两个主要步骤。第一步是让 IO 操作根据 PG 分片策略运行在多个 OSD 分片中，包括 PG 状态在内的所有全局信息都维护在第一个分片中。此步骤在 OSD 中启用分片，但需要在第一个分片中做出有关 IO 调度的所有决策。即使这一步 Messenger 可以在多核中运行，消息仍然需要传递到第一个分片进行准备（例如 PG peering）并在提交到该分片之前确定正确的 PG 分片。这会导致额外的开销和不平衡的 CPU 使用（第一个 OSD 分片使用率高，其他分片很低，等等）。因此，下一步是将 PG-core 映射扩展到所有 OSD 分片。

ObjectStore

Crimson 支持三种 ObjectStore 后端：AlienStore、CyanStore 和 SeaStore。AlienStore 提供与 BlueStore 的向后兼容性。CyanStore 是用于测试的虚拟后端，由易失性内存实现。SeaStore 是一种新的对象存储，专为 Crimson OSD 设计，采用 shared-nothing 设计。根据后端的具体目标，实现多分片支持的路径是不同的。

1AlienStore

AlienStore 是 Seastar 线程中的一个瘦代理，用于与使用 POSIX 线程的 BlueStore 进行通信。对于多个 OSD 分片没有特别的工作要做，因为 IO 任务通信同步了。BlueStore 中没有为 Crimson 定制其他内容，因为不可能真正将 BlueStore 扩展到 shared-nothing 设计，因为它依赖于第 三 方 RocksDB 项目，而 RocksDB 仍然是线程的。但是，在 Crimson 能够拿出一个足够优化和足够稳定的原生存储后端解决方案（SeaStore）之前，合理的开销来换取复杂的存储后端解决方案是可以接受的。

2CyanStore

Crimson OSD 中的 CyanStore 与传统 OSD 中的 MemStore 相对应。对多分片支持的唯一改变是为每个分片创建独立的 CyanStore 实例。一个目标是确保虚拟 IO 操作能够在同一个内核中完成，以帮助识别 OSD 级别的可扩展性问题（如果有的话）。另一个目标是在 OSD 层面上与传统 OSD 做直接的性能比较，而不受 ObjectStore 的复杂因数影响。

3SeaStore

SeaStore 是 Crimson OSD 原生的 ObjectStore 解决方案，采用 Seastar 框架开发，采用相同的设计原则。

虽然很有挑战性，但是 Crimson 必须建立一个新的本地存储引擎，这有多种原因。存储后端是主要的 CPU 资源消耗者，如果 Crimson OSD 的存储后端不改变，那么它就不能真正地随核心扩展。我们的实验也证明了 Crimson OSD 不是随机写入场景中的瓶颈。

其次，BlueStore 中具有事务支持的 CPU 密集型元数据管理基本上由 RocksDB 提供，如果不重新实现，它无法在原生的 Seastar 线程中运行。与其为 BlueStore 重新实现通用的键值事务存储，不如在更高的层次上重新思考和定制相应的架构——ObjectStore。问题在原生的解决方案中比在 第三方项目中更容易解决，因为第三方项目必须保证使用与通用的场景。

第三个考虑是为异构存储设备和硬件加速器提供原生支持，让用户可以根据自己的需求平衡成本和性能。如果 Crimson 能够更好地控制整个存储堆栈，那么 Crimson 将更灵活地简化部署硬件组合的解决方案。

SeaStore 在单分片读写方面已经可以正常使用，尽管在稳定性和性能改进方面仍有待努力。目前的努力仍然集中在架构上，而不是极端情况下的优化。它针对多分片 OSD 的设计很明确。与 CyanStore 一样，第一步是为每个 OSD 分片创建独立的 SeaStore 实例，每个实例都在存储设备的静态分区上运行。第二步是实现一个共享磁盘空间平衡器来动态调整分区，它应该可以在后台异步运行，因为 PG 已经以伪随机方式分配了用户 IO。SeaStore 实例可能不需要等于 OSD 分片的数量，根据性能分析，调整这个比例是后期工作的第三步。

摘要和测试配置

在这篇文章中，我们介绍了为什么以及如何对 Ceph OSD 进行重构以跟上硬件的发展。另外我们也给出了我们所做的详细设计、 一个简单的性能测试结果。也提供了 Crimson OSD 真正实现多核可扩展的所要考虑的大部分因素。

测试结果可能会根据不同的 commit 版本、软件和硬件配置而有所变化。为了确保我们的测试是可重复的，可复现的，并可在以后场景中作为参考，我们列出了所有可能产生影响的设置和注意事项。

我们为 Crimson 和 传统 OSD 部署了本地 Ceph 集群，并使用 CBT 执行了 FIO 测试。Crimson 在使用 tcmalloc 时仍然存在问题，因此为了公平起见，我们将两个 OSD 配置为使用 libc*。我们使用 BlueStore。RBD 缓存被禁用。BlueStore 线程数设置为 4 以获得更好的结果。部署 Crimson 时，需要指定*ceph-osd_cmd ( crimson-osd )。CPU 绑定通过 CBT 配置文件中的 crimson_cpusets 指定，BlueStore 线程通过 crimson_alien_thread_cpu_cores 和 crimson_alien_op_num_threads 配置。要部署传统 OSD，numactl 用于控制 CPU 绑定。根据 CBT 存储库，部署过程的其余部分没有变化。

测试场景：

• Client: 4 FIO clients
• IO mode: random write and then random read
• Block size: 4KB
• Time: 300s X 5 times to get the average results
• IO-depth: 32 X 4 clients
• Create 1 pool using 1 replica
• 1 RBD image X 4 clients
• The size of each image is 256GB

测试环境：

• Ceph 版本 (SHA1)：7803eb186d02bb852b95efd1a1f61f32618761d9
• Ubuntu 20.04
• GCC-12
• 1TB NVMe SSD 作为 BlueStore 块设备
• 50GB 内存用于 MemStore 和 CyanStore