13.2. Crimson 和 Classic Ceph OSD 架构之间的区别

在典型的 ceph-osd 架构中，senger 线程从有线中读取客户端消息，它将消息放在 OP 队列中。然后，osd-op thread-pool 会获取消息，并创建事务并将其队列到 BlueStore （当前默认的 ObjectStore 实施）。然后，BlueStore 的 kv_queue 会获取这个事务以及队列中的任何其他事务，同步等待 rocksdb 提交事务，然后将完成回调放在完成者队列中。然后，完成线程获取完成回调和队列，以替换要发送的 messenger 线程。

每个操作都需要对队列的内容进行线程并发协调。对于 pg state，可能有多个线程会需要访问 PG 的内部元数据来锁定争用。

随着处理器使用量的增加，这种锁定竞争会随着任务和内核的数量迅速扩展，在某些情况下，每个锁定点可能会成为扩展瓶颈。此外，即使不连续，这些锁定和队列会导致延迟成本。由于此延迟，线程池和任务队列会分离，因为图书维护工作在 worker 线程和锁定之间委派任务可能会强制 context-switches。

与 ceph-osd 架构不同，Crimson 允许单个 I/O 操作在没有上下文切换的情况下在单个内核中完成，如果底层存储操作不需要，则阻止它。但是，一些操作仍然需要等待异步进程完成，可能取决于恢复或底层设备等系统状态。

Crimson 使用名为 Seastar 的 C++ 框架，它是一个高度异步引擎，通常预先分配一个线程固定到每个内核。这些内核划分了这些内核的工作，以便避免在内核和锁定之间对状态进行分区。使用 Seastar 时，I/O 操作会根据目标对象在一组线程中分区。在不同线程组中运行 I/O 操作阶段而不是在单个线程中运行所有管道阶段。如果需要阻止某个操作，内核的 Seastar 反应器切换到另一个并发操作和进度。

理想情况下，所有锁定和上下文切换都不再需要，因为每个运行非阻塞的任务都拥有 CPU，直到它完成或合作生成为止。没有其他线程可以同时抢占任务。如果数据路径中的其他分片不需要通信，则理想的性能会与内核数量线性扩展，直到 I/O 设备达到其限制。此设计非常适合 Ceph OSD，因为在 OSD 级别上，PG 分片所有 IO。

与 ceph-osd 不同，crimson-osd 不会自行守护进程，即使启用了 daemonize 选项。由于支持的 Linux 发行版使用 systemd，因此不要对 crimson-osd 进行守护进程化，这能够对应用程序进行守护进程化。使用 sysvinit 时，使用 start-stop-daemon 来守护进程化 crimson-osd。

Crimson 支持以下三个 ObjectStore 后端：

以下是其他两个典型的 OSD ObjectStore 后端：