12.2. Crimson と Classic Ceph OSD アーキテクチャーの違い

古典的な ceph-osd アーキテクチャーでは、メッセンジャースレッドがネットワークからクライアントメッセージを読み取り、メッセージを OP キューに置きます。次に、osd-op スレッドプールがメッセージを取得し、トランザクションを作成して、現在のデフォルトの ObjectStore 実装である BlueStore のキューに入れます。次に、BlueStore の kv_queue は、このトランザクションとキュー内のその他のものを取得し、rocksdb がトランザクションをコミットするのを同時に待ち、完了コールバックをフィニッシャーキューに置きます。次に、フィニッシャースレッドは完了コールバックを取得し、送信するメッセンジャースレッドを置き換えるためにキューに入れます。

これらの各アクションには、キューの内容に対するスレッド間の調整が必要です。pg state の場合、競合をロックするために、複数のスレッドが PG の内部メタデータにアクセスする必要がある場合があります。

プロセッサー使用量の増加に伴うこのロック競合は、タスクとコアの数に応じて急速に拡大し、特定のシナリオではすべてのロックポイントがスケーリングのボトルネックになる可能性があります。さらに、これらのロックとキューは、競合していない場合でも遅延コストが発生します。この遅延により、スレッドプールとタスクキューが悪化します。これは、ブックキーピングの作業によりワーカースレッド間でタスクが委任され、ロックによってコンテキストの切り替えが強制される可能性があるためです。

ceph-osd アーキテクチャーとは異なり、Crimson では、コンテキストの切り替えや、基礎となるストレージ操作で要求されない場合はブロックすることなく、単一の I/O 操作を単一のコア上で完了できます。ただし、一部の操作では、非同期プロセスが完了するまで待機できる必要があります｡これは､おそらくリカバリーや基盤となるデバイスなどのシステムの状態に応じて非決定的に異なります。

Crimson は Seastar と呼ばれる C++ フレームワークを使用します。これは高度に非同期エンジンであり、通常、各コアに固定された 1 つのスレッドを事前に割り当てます。これらは、コア間で状態を分割し、ロックを回避できるように、コア間で作業を分割します。Seastar では、I/O 操作はターゲットオブジェクトに基づいてスレッドのグループに分割されます。I/O 操作を実行するステージを異なるスレッドグループに分割するのではなく、すべてのパイプラインステージを 1 つのスレッド内で実行します。操作をブロックする必要がある場合、コアの Seastar リアクターは別の同時操作に切り替えて進行します。

理想的には、実行中の各非ブロッキングタスクが完了するか協調的に譲歩するまで CPU を所有するため、すべてのロックとコンテキストスイッチが不要になります。他のスレッドが同時にタスクをプリエンプトすることはできません。データパス内の他のシャードとの通信が必要ない場合、理想的なパフォーマンスは、I/O デバイスが制限に達するまでコアの数に比例して増加します。OSD レベルでは PG がすべての IO をシャーディングするため、この設計は Ceph OSD によく適合します。

ceph-osd とは異なり、crimson-osd は、デーモン化オプションが有効になっている場合でも、それ自体をデーモン化しません。サポートされている Linux ディストリビューションはアプリケーションをデーモン化できる systemd を使用するため、crimson-osd をデーモン化しないでください。sysvinit では、start-stop-daemon を使用して crimson-osd をデーモン化します。

Crimson では次の 3 つの ObjectStore バックエンドがサポートされています。

以下は、他の 2 つの古典的な OSD ObjectStore バックエンドです。