2.6. Ceph の入出力操作

Ceph クライアントは、Ceph モニターから「クラスターマップ」を取得し、プールにバインドして、プールの配置グループ内にあるオブジェクトに対して入力/出力 (I/O) を実行します。プールの CRUSH ルールセットと配置グループの数は、Ceph がデータを配置する方法を決定する主要な要因です。クラスターマップの最新バージョンでは、クライアントは、クラスター内のすべてのモニターおよび OSD、およびそれらの現在の状態を認識します。ただし、クライアントはオブジェクトの場所について何も知りません。

クライアントが必要とする入力は、オブジェクト ID とプール名のみです。これは単純な方法です。Ceph はデータを名前付きプールに保管します。クライアントがプールに名前付きのオブジェクトを保存する場合は、オブジェクト名、ハッシュコード、プール名の PG 数およびプール名を入力として取り、次に CRUSH (Controlled Replication Under Scalable Hashing) は配置グループの ID および配置グループのプライマリー OSD を計算します。

Ceph クライアントは、以下の手順を使用して PG ID を計算します。

Ceph Storage クラスターのトポロジーおよび状態は、セッション時に比較的安定しています。librados を介して Ceph クライアントにオブジェクトの場所を計算する権限を付与することは、クライアントが読み取り/書き込み操作ごとにチャットセッションを介してストレージクラスターにクエリーを実行することを要求するよりもはるかに高速です。CRUSH アルゴリズムにより、クライアントはオブジェクトが 保存される 場所を計算でき、クライアントが動作セットのプライマリー OSD に直接アクセスできる ようにし、オブジェクト内のデータを保存または取得できるようにします。エクサバイト規模のクラスターには数千もの OSD があるため、クライアントと Ceph OSD 間のネットワークオーバーサブスクリプションは重大な問題ではありません。クラスターの状態が変更された場合は、クライアントは単に Ceph モニターからクラスターマップへ更新をリクエストすることができます。

Red Hat Ceph Storage 2 以前のリリースでは、クラスターマップが大きくなりすぎると、非常に大きなクラスター内のデーモンのパフォーマンスが低下する可能性があります。たとえば、OSD が 10000 のクラスターには OSD ごとに 100 の PG があり、データを効率的に分散するために約 1 MB の PG になり、クラスターマップには多数のエポックがあります。したがって、デーモンは、非常に大きなクラスターを持つ Red Hat Ceph Storage 2 でより多くの CPU および RAM を使用します。Red Hat Ceph Storage 3 以降のリリースの場合、デーモンは Red Hat Ceph Storage 2 以前のリリースのようにクラスターの最新の状態を受信します。ただし、Ceph Manager (ceph-mgr) デーモンは PG のクエリーを処理するようになり、大規模でパフォーマンスが大幅に改善されました。