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

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

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

随着处理器使用量增加的增加，处理器使用率会快速扩展任务和内核数量，每个锁定点可能会成为某些情况下的扩展瓶颈。此外，即使未延续，这些锁定和队列也会产生延迟成本。由于此延迟，线程池和任务队列 deteriorate，因为工作线程和锁定之间的委派任务可以强制上下文切换。

与 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 选项。不要守护进程化 crimson-osd，因为支持的 Linux 发行版使用 systemd，它可以对应用程序进行守护进程化。使用 sysvinit 时，使用 start-stop-daemon 来守护进程化 crimson-osd。

Crimson 支持以下三个 ObjectStore 后端：

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