2.8. Ceph イレイジャーコーディング
Ceph は、多くのイレイジャーコードアルゴリズムのいずれかを読み込むことができます。Reed-Solomon
アルゴリズムが最も早く一般的に使用されるものになります。イレイジャーコードは、実際には前方誤り訂正 (FEC: forward error correction) コードです。FECコードは、K
チャンクのメッセージを、N
チャンクの「コードワード」と呼ばれる長いメッセージに変換し、Ceph が N
チャンクのサブセットから元のメッセージを復元できるようにします。
具体的には、変数 K
が元のデータチャンク量である N = N = K+M
です。変数 M
は、余分または冗長なチャンクを表し、イレイジャーコードアルゴリズムが障害から保護します。変数 N
は、イレイジャーコーディングプロセス後に作成されたチャンクの合計数です。M
の値は N-K
です。これは、アルゴリズムが K
の元のデータチャンクから N-K
冗長チャンクを計算することを意味します。このアプローチにより、Ceph が元のデータすべてにアクセスできることを保証します。システムが任意の N-K
の障害に対して回復性があります。たとえば、16 の N
設定のうち 10 K
、またはイレイジャーコーディング 10/16
の場合、イレイジャーコードアルゴリズムは 10 ベースチャンク K
に 6 つの追加チャンクを追加します。たとえば、M = K-N
または 16-10 = 6
の設定では、Ceph は 16 チャンク N
を 16 OSD に分散します。元のファイルは、6 つの OSD に障害が発生した場合でも、検証済みの 10 個の N
チャンクから再構築できます。これにより、Red Hat Ceph Storage クラスターがデータを失うことがなくなり、非常に高いレベルのフォールトトレランスが保証されます。
複製されたプールと同様に、イレイジャーコーディングされたプールでは、セットアップ内のプライマリー OSD がすべての書き込み操作を受け取ります。複製されたプールでは、Ceph はセットのセカンダリー OSD 上の配置グループで各オブジェクトのディープコピーを作成します。イレイジャーコーディングの場合、プロセスは少し異なります。コード化されたプールは各オブジェクトを K+M
チャンクとして格納します。これは K
データチャンクと M
コーディングチャンクに分割されます。プールには K+M
のサイズが設定され、これにより Ceph が各チャンクを動作セットの OSD に保管することができます。Ceph は、チャンクのランクをオブジェクトの属性として保存します。プライマリー OSD はペイロードを K+M
チャンクにエンコードし、それらを他の OSD に送信します。プライマリー OSD は、配置グループログの権威バージョンを維持する役割も果たします。
たとえば、一般的な構成では、システム管理者は 5 つの OSD を使用し、そのうちの 2 つの OSD の損失を維持するために、イレイジャーコード化されたプールを作成します。つまり、(K+M = 5
) であり、(M = 2
) になります。
Ceph が、ABCDEFGHI
を含むオブジェクト NYAN をプールに書き込むと、イレイジャーエンコーディングアルゴリズムは、コンテンツを 3 つに分割するだけで、コンテンツを 3 つのデータチャンクに分割します: * ABC
, * DEF
* GHI
コンテンツの長さが K
の倍数でない場合は、アルゴリズムによりコンテンツをパディングします。この関数は、2 つのコーディングチャンクも作成します。4 つ目は YXY
、5 つ目は QGC
が付きます。Ceph は、動作セット内の OSD 上にそれぞれのチャンクを保存します。ここで、NYAN の名前を持つオブジェクトにチャンクが保管されますが、異なる OSD にあります。アルゴリズムは、名前に加えて、チャンクをオブジェクト shard_t
の属性として作成した順番を保持する必要があります。たとえば、チャンク 1 には ABC
が含まれ、Ceph はこれを OSD5 に格納されます。一方、チャンク 4 には YXY
が含まれ、OSD3 に格納されます。
リカバリーのシナリオでは、クライアントはチャンク 1 から 5 を読み取ることで、イレイジャーコーディングされたプールからオブジェクト NYAN を読み込もうとします。OSD は、2 と 5 のチャンクがないことをアルゴリズムに通知します。これらのチャンクは「イレイジャー」と呼ばれます。たとえば、OSD4 が除外されているため、プライマリー OSD はチャンク 5 を読み取ることができませんでした。また、OSD2 は最も遅く、そのチャンクを考慮していなかったため、チャンク 2 を読み取ることができませんでした。ただし、アルゴリズムにチャンクが 3 つあると、すぐに 3 つのチャンク (ABC
を含むチャンク 1、GHI
を含むチャンク 3、YXY
を含むチャンク 4) を読み取ります。次に、オブジェクト ABCDEFGHI
の元のコンテンツと、QGC
を含むチャンク 5 の元のコンテンツを再構築します。
データをチャンクに分割することは、オブジェクトの配置とは無関係です。CRUSH ルールセットとイレイジャーコーディングされたプールプロファイルにより、OSD 上のチャンクの配置が決定されます。たとえば、イレイジャーコードプロファイルで Locally Repairable Code (lrc
) プラグインを使用すると、追加のチャンクが作成され、回復に必要な OSD が少なくなります。たとえば、lrc
プロファイル構成 K=4 M=2 L=3
では、アルゴリズムは、jerasure
プラグインと同じように 6 つのチャンク (K+M
) を作成しますが、局所性の値 (L=3
) では、アルゴリズムはさらに 2 つのチャンクをローカルに作成する必要があります。アルゴリズムは、(K+M)/L
などの追加チャンクを作成します。チャンク 0 を含む OSD が失敗すると、チャンク 1、2、および最初のローカルチャンクを使用してこのチャンクを回復できます。この場合、アルゴリズムは 5 つではなく 3 つのチャンクのみを回復に必要とします。
イレイジャーコーディングされたプールを使用すると、オブジェクトマップが無効になります。
関連情報
- CRUSH、イレイジャーコーディングプロファイル、およびプラグインの詳細は、Red Hat Ceph Storage 4 の『ストレージストラテジーガイド』を参照してください。
- オブジェクトマップの詳細は、「オブジェクトマップ」セクションを参照してください。