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

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

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

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 等）的复杂性和细微控制对应用程序代码是透明的。

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 并消除软件使用高性能硬件而引起的性能瓶颈。

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

在这篇文章中，我们介绍了为什么以及如何对 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

一些关键核心技术实现突破，战略性新兴产业发展壮大，载人航天、探月探火、深海深地探测、超级计算机、卫星导航、量子信息、核电技术、大飞机制造、生物医药等取得重大成果，进入创新型国家行列。