アーキテクチャーガイド

Ceph Storage クラスターは、データオブジェクトを「プール」と呼ばれる論理パーティションに格納します。 Ceph 管理者は、ブロックデバイス、オブジェクトゲートウェイなどの特定タイプのデータ用に、または単にあるユーザーのグループを別のグループから分離するために、プールを作成することができます。

Ceph クライアントの視点からは、ストレージクラスターは非常に簡単です。Ceph クライアントが i/o コンテキスト経由でデータの読み取りまたは書き込みを行う場合は、常 に Ceph Storage クラスターのストレージプールに接続します。クライアントはプール名、ユーザーおよびシークレットキーを指定するため、プールはデータオブジェクトへのアクセス制御が設定された論理パーティションとして機能します。

実際に、Ceph プールは、オブジェクトデータを格納するための論理パーティションのみではありません。プールは、Ceph Storage クラスターがデータを分散し、格納する方法において重要な役割を果たします。ただし、これらの複雑な操作は、Ceph クライアントに対して完全に透過的です。Ceph プールは、以下を定義します。

さらに、CRUSH を使用すると、クライアントは、SSD、SSD ジャーナルを備えたハードドライブ、またはデータと同じドライブにジャーナルを備えたハードドライブなど、特定のタイプのハードウェアにデータを書き込むことができます。CRUSH ルールセットは、プールの障害ドメインとパフォーマンスドメインを決定します。管理者は、プールの作成時に CRUSH ルールセットを設定します。注記： 管理者は 、プールの作成後にプールのルールセットを変更 できませ ん。

クライアントの観点からは、Ceph はエレガントでシンプルです。クライアントは、プールからの読み取りとプールへの書き込みを行うだけです。ただし、プールは、データの耐久性、パフォーマンス、および高可用性において重要な役割を果たします。

ユーザーを特定し、中間者攻撃から保護するために、Ceph は cephx 認証システムを提供し、ユーザーおよびデーモンを認証します。

Cephx は共有シークレットキーを使用して認証を行います。つまり、クライアントとモニタークラスターの両方にはクライアントの秘密鍵のコピーがあります。認証プロトコルにより、両当事者は、実際にキーを公開することなく、キーのコピーを持っていることを互いに証明できます。これは相互認証を提供します。つまり、ユーザーがシークレットキーを所有し、ユーザーにはシークレットキーのコピーがあることを確認します。

何百万ものオブジェクトをクラスターに格納し、それらを個別に管理することは、リソースを大量に消費します。そのため、Ceph は配置グループ(PG)を使用して多数のオブジェクトをより効率的に管理します。

PG は、オブジェクトのコレクションを含むために機能するプールのサブセットです。Ceph は、プールを一連の PG にシャードします。次に、CRUSH アルゴリズムはクラスターマップとクラスターのステータスを考慮し、PG をクラスター内の OSD に均等に、かつ疑似ランダムに分散します。

以下は、その仕組みです。

システム管理者はプールを作成すると、CRUSH はプールのユーザー定義の PG を作成します。通常 PG の数は、データの合理的に細分化されたサブセットになります。たとえば、1 プールの 1 OSD あたり 100 PG は、各 PG にプールのデータの約 1％ が含まれていることを意味します。

Ceph が PG をある OSD から別の OSD に移動する必要がある場合に、PG の数はパフォーマンスに影響を与えます。プールの PG が少なすぎると、Ceph はデータの大部分を同時に移動し、ネットワークの負荷がクラスターのパフォーマンスに悪影響を及ぼします。プールに PG が多すぎると、Ceph は、データのごく一部を移動する際に CPU および RAM を過剰に使用するので、クラスターのパフォーマンスに悪影響を与えます。パフォーマンスを最適化するために PG 数を計算する方法は、「PG Count」を参照してください。

Ceph は、オブジェクトのレプリカを保存するか、オブジェクトのイレイジャーコードチャンクを保存することで、データの損失を防ぎます。Ceph は、オブジェクトまたはオブジェクトのイレイジャーコードチャンクを PG 内に格納するため、Ceph は、オブジェクトのコピーごとまたはオブジェクトのイレイジャーコードチャンクごとに、「動作セット」と呼ばれる OSD のセットに各 PG を複製します。システム管理者は、プール内の PG 数と、レプリカまたは消去コードチャンクの数を判断できます。ただし、CRUSH アルゴリズムは、特定の PG の動作セットに含まれる OSD を計算します。

CRUSH アルゴリズムおよび PGs は Ceph を動的にします。クラスターマップまたはクラスターの状態の変更により、Ceph が PG をある OSD から別の OSD に自動的に移動させる可能性があります。以下にいくつか例を示します。

何十万もの PG のコンテキスト内で何百万ものオブジェクトを管理することで、Ceph Storage クラスターは効率的に拡張、縮小、および障害からの回復を行うことができます。

Ceph クライアントの場合は、librados を介した CRUSH アルゴリズムにより、オブジェクトの読み取りおよび書き込みプロセスが非常にシンプルになります。Ceph クライアントは単にオブジェクトをプールに書き込むか、プールからオブジェクトを読み取ります。動作セットのプライマリー OSD は、Ceph クライアントに代わって、オブジェクトのレプリカまたはオブジェクトのイレイジャーコードチャンクを動作セットのセカンダリー OSD に書き込むことができます。

クラスターマップまたはクラスターの状態が変更されると、OSD が PG を格納する CRUSH 計算も変更されます。たとえば、Ceph クライアントはオブジェクト foo をプール bar に書き込むことができます。CRUSH はオブジェクトを PG 1.a に割り当て、これを OSD 5 に保存します。これにより、OSD 10 および OSD 15 のレプリカがそれぞれ作成されます。OSD 5 が失敗すると、クラスターの状態が変わります。Ceph クライアントがプール bar からオブジェクト foo を読み込むと、librados 経由のクライアントは新しいプライマリー OSD として OSD 10 から自動的に取得されます。

librados を使用する Ceph クライアントは、オブジェクトの書き込みおよび読み取り時に、動作セット内でプライマリー OSD に直接接続します。I/O 操作は集中化ブローカーを使用しないため、ネットワークのオーバーサブスクリプションは通常、Ceph の問題ではありません。

以下の図は、CRUSH がオブジェクトを PG に割り当てる方法、および PG を OSD に割り当てる方法を示しています。CRUSH アルゴリズムでは、動作セットの各 OSD が別の障害ドメインに置かれるように PG を OSD に割り当てます。これは通常、OSD が常に別々のサーバーホストに置かれ、別のラックに置かれることを意味します。

Ceph は CRUSH ルールセットをプールに割り当てます。Ceph クライアントがプールにデータを保存または取得する場合、Ceph は CRUSH ルールセット、ルールセット内のルール、およびデータを保存および取得するためのルールの最上位バケットを特定します。Ceph が CRUSH ルールを処理する際に、オブジェクトの配置グループが含まれるプライマリー OSD を特定します。これにより、クライアントは OSD に直接接続し、配置グループにアクセスして、オブジェクトデータの読み取りまたは書き込みを行うことができます。

配置グループを OSD にマッピングするには、CRUSH マップはバケットタイプの階層リストを定義します。バケットタイプの一覧は、生成された CRUSH マップの types の下にあります。バケット階層を作成する目的は、ドライブタイプ、ホスト、シャーシ、ラック、電源分散ユニット、Pod、行、部屋、およびデータセンターなどの障害ドメインやパフォーマンスドメインによって、リーフノードを分離することです。

OSD を表すリーフノードを除き、残りの階層は任意になります。デフォルトのタイプが要件に適さない場合、管理者は独自のニーズに合わせて定義することができます。CRUSH は、通常は階層内の Ceph OSD ノードをモデル化する有向非巡回グラフをサポートします。そのため、Ceph 管理者は、単一の CRUSH マップで複数の root ノードを持つ複数の階層をサポートできます。たとえば、管理者は、高パフォーマンス用に高コストの SSD を表す階層を作成したり、中程度のパフォーマンス用に SSD ジャーナルを備えた低コストのハードドライブの別の階層を作成したりできます。

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 モニターからクラスターマップへ更新をリクエストすることができます。

RHCS 2 以前のリリースでは、非常に大規模なクラスターのデーモンは、クラスターマップのサイズが大きすぎるとパフォーマンスが遅くなる可能性があります。たとえば、OSD が 10k のクラスターには OSD ごとに 100 PG がある場合があり、これにより、データを効率的に分散するために ~1M PG が使用され、クラスターマップ用に多数のエポックが分散されます。そのため、デーモンは、非常に大きなクラスターを持つ RHCS 2 でより多くの CPU および RAM を使用します。RHCS 3 以降のリリースでは、デーモンは RHCS 2 以前のリリースのようにクラスターの現在の状態を受け取ります。ただし、Ceph Manager (ceph-mgr) デーモンは PG のクエリーを処理するようになり、大規模でパフォーマンスが大幅に改善されました。Red Hat は、数千の OSD を持つ非常に大規模なクラスターに RHCS 3 以降のリリースを使用することを推奨します。

2.5.1. レプリケートされた I/O

Ceph クライアントと同様に、Ceph OSD は Ceph モニターに接続してクラスターマップの最新コピーを取得できます。Ceph OSD も CRUSH アルゴリズムを使用しますが、これを使用してオブジェクトのレプリカを保存する場所を計算します。標準的な書き込みシナリオでは、Ceph クライアントは CRUSH アルゴリズムを使用して、オブジェクトの動作セット内の配置グループ ID とプライマリー OSD を計算します。クライアントがプライマリー OSD にオブジェクトを書き込む際に、プライマリー OSD は格納する必要のあるレプリカ数を見つけます。値は osd_pool_default_size 設定にあります。次に、プライマリー OSD は、オブジェクト ID、プール名、およびクラスターマップを取得し、CRUSH アルゴリズムを使用して動作セットのセカンダリー OSD の ID を計算します。プライマリー OSD はオブジェクトをセカンダリー OSD に書き込みます。プライマリー OSD がセカンダリー OSD から確認応答を受信し、プライマリー OSD 自体がその書き込み操作を完了すると、Ceph クライアントへの書き込み操作が成功したことを確認します。

Ceph クライアントの代わりにデータレプリケーションを実行する機能を使用すると、Ceph OSD デーモンは、高いデータ可用性とデータの安全性を確保しながら、Ceph クライアントをその責務から解放します。

注記

プライマリー OSD とセカンダリー OSD は通常、別の障害ドメインに配置するように設定されています。CRUSH は、障害ドメインについて考慮し、セカンダリー OSD の ID を計算します。

2.5.2. イレイジャーコーディング I/O

Ceph は、多くのイレイジャーコードアルゴリズムのいずれかを読み込むことができます。Reed-Solomon アルゴリズムが最も早く一般的に使用されるものになります。イレイジャーコードは、実際には forward error correction(FEC)コードで、K チャンクのメッセージを N チャンクの「コード単語」と呼ばれる長いメッセージに変換します。これにより、Ceph は N チャンクのサブセットから元のメッセージを復元できます。

具体的には、変数 K が元のデータチャンク量である 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 チャンクから再構築でき、Ceph クラスターはデータが失われないようにし、非常に高いフォールトトレランスを確保します。

複製されたプールと同様に、イレイジャーコーディングされたプールでは、セットアップ内のプライマリー 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 つのデータチャンクに分割します。1 つ目は ABC、2 番目の DEF、および最後の GHI が含まれます。コンテンツの長さが K の倍数でない場合は、アルゴリズムによりコンテンツをパディングします。この関数は、2 つのコーディングチャンクも作成します。4 つ目は YXY で、5 つ目は GQC が付きます。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 の元のコンテンツと、GQC を含むチャンク 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 3 の『ストレージ戦略』 を参照してください。

注記

イレイジャーコーディングされたプールを使用すると、オブジェクトマップが無効になります。オブジェクトマップの詳細は、「オブジェクトマップ」セクションを 参照し てください。

Objectstore は、OSD の raw ブロックデバイスに低レベルのインターフェースを提供します。クライアントがデータの読み取りまたは書き込みを行うと、ObjectStore インターフェースと対話します。Ceph 書き込み操作は、基本的に ACID トランザクションです。つまり、原子性、一貫性、分離、および 耐久性 を提供します。ObjectStore は、トランザクション が 原子性 を提供するために、オールオアナッシングになるようにします。ObjectStore は、オブジェクトセマンティクスも処理します。Overview セクションにあるように、ストレージクラスターに保存されているオブジェクトには、一意の識別子、オブジェクトデータ、およびメタデータがあります。したがって、ObjectStore は Ceph オブジェクトセマンティクスが正しいことを確認して 整合性 を提供します。ObjectStoreは、書き込み操作で Sequencer を呼び出して ACID トランザクションの 分離 部分も提供し、Ceph 書き込み操作が順番に実行されるようにします。これとは対照的に、OSD のレプリケーションまたはイレイジャーコーディング機能は ACID トランザクションの Durability コンポーネントを提供します。ObjectStore は、ストレージメディアへの低レベルのインターフェースであるため、パフォーマンスの統計も提供します。

Ceph は、データを保管するための具体的な方法を実装します。

通常、管理者は FileStore および BlueStore にのみ対応するため、以下のセクションではこれらの実装についてのみ詳しく説明します。

2.6.1. FileStore

FileStore は Ceph の元のストレージ実装の 1 つで、最も広く使用されている実装です。Ceph プロジェクトは 2004 年に開始した場合、Ceph はストレージのハードディスクドライブのみに依存します。これは、ソリッドステートドライブまたは PCI 表現を介した不揮発性メモリーへの有線性もありませんでした。FileStore は、raw ブロックデバイスと直接対話するのではなく、ファイルシステム（通常は xfs ）と対話します。ObjectStore がオブジェクトのセマンティクスを処理して FileStore に渡すと、FileStore は配置グループをディレクトリー、オブジェクトをファイルとして扱い、メタデータを XATTR または omap エントリーとして扱います。

FileStore は、オープンソースのファイルシステムのセマンティクスを活用し、別のドライブでジャーナルトランザクションを使用する利点を提供します。FileStore には 不利な点もあります。FileStore の欠点の 1 つは、Ceph 書き込み操作は基本的に ACID トランザクションであることです。原子性 を実現するため、Ceph FileStore はデータを書き込む前に すべて のトランザクションをジャーナル化します。データのジャーナリングと書き込みに同じドライブを使用する場合は、書き込みレイテンシーが大きくなり、書き込みペナルティーが発生します。開発者は、トランザクションがあるのにコピーオンライトセマンティクスがあり、データを同時に書き込む可能性があるため、btrfs ファイルシステムのフォーマットが最終的にデフォルトのファイルシステムフォーマットであると見なしています。ただし、btrfs は、実稼働システムの Ceph プロジェクトの信頼性要件を満たさない。したがって、FileStore は通常 btrfs の代わりに ext4 ファイルシステムおよび xfs ファイルシステムを使用します。

ext4 の短所の 1 つは、XATTRs（約 4k）のストレージが非常に制限されていることです。したがって、xfs は FileStore の推奨ファイルシステムになりました。これは、特に約 64k の XATR のストレージが多いためです。ただし、64k は、大規模なサムネイル画像を持つ可能性のあるムービルの図など、大規模なメタデータを必要とするオブジェクトの制限です。ObjectStore および FileStore は ObjectMap または omap で拡張されました。

Ceph の商用サポートが 2012 で起動されると、SSD は引き続き高価でした。ただし、SSD ドライブでジャーナル書き込み操作を実行し、高速 SAS ハードディスクドライブにオブジェクトデータを保存する機能を使用すると、高スループットおよび高 I/o ワークロードのパフォーマンス特性が提供されます。SSD へのジャーナリングによりパフォーマンスが大幅に向上しましたが、xfs は引き続きトランザクションを書き込んでから書き込んでいました。そのため、SSD でペナルティーが低くしても、FileStore では 2 回書き込みペナルティーが維持されます。

FileStore は配置グループをディレクトリーとして処理します。初期クラスターの場合、問題の有無はほとんど表示されません。ただし、Ceph クラスターは拡張する傾向があります。管理者は新規ノードおよび OSD を追加する際に、配置グループの数を増やす必要があります。FileStore では、オブジェクトデータはディレクトリー内のファイルとして、配置グループを表すディレクトリーに置かれます。したがって、配置グループの数を増やす場合は、ファイル内のオブジェクトデータは異なるディレクトリーに移動する必要があります。Ceph は 32 ビットのハッシュアルゴリズムを使用してオブジェクトをランダムに分散します。その一部はオブジェクトのファイル名に組み込まれています。これは、データをアドレス指定および再分配するための非効率的なアプローチです。

Ceph クラスターは、多くの自己監視および管理操作を自動的に実行します。たとえば、Ceph OSD はクラスターの正常性を確認し、Ceph モニターに報告することができます。CRUSH を使用してオブジェクトを配置グループに割り当て、配置グループを OSD のセットに割り当てることにより、Ceph OSD は CRUSH アルゴリズムを使用して、クラスターのバランスを取り直したり、OSD 障害から動的に回復したりできます。以下のセクションでは、Ceph が実行する操作の一部を説明します。

2.7.3. リバランスおよびリカバリー

管理者が Ceph OSD を Ceph Storage クラスターに追加する際に、Ceph はクラスターマップを更新します。変更されたクラスターマップは CRUSH 計算の入力を変更するため、クラスターマップへのこの変更は、オブジェクトの配置も変更します。CRUSH はデータを均等に配置しますが、疑似ランダムに配置します。そのため、管理者が新しい OSD を追加すると、移動するデータはごくわずかになります。通常、データ量は、クラスター内のデータの合計量で分割される新規 OSD 数です。たとえば、50 個の OSD があるクラスターでは、OSD を追加すると、データの 1/50 または 2％ が移動する可能性があります。

以下の図は、一部の PG が既存の OSD（OSD 1 および OSD 2）から新規 OSD(OSD 3)に移行する一部のリバランスプロセスを示しています。リバランスを行う場合でも、CRUSH は安定しています。配置グループの多くは元の設定のままであり、各 OSD には容量が追加されるため、クラスターのリバランス後に新しい OSD に負荷が急増することはありません。

CRUSH アルゴリズムで有効化されたスケーラビリティーに加え、Ceph も高可用性を維持する必要があります。つまり、Ceph クライアントは、クラスターのパフォーマンスが低下した状態にある場合や、モニターに障害が発生した場合でも、データの読み取りと書き込みができる必要があります。

2.8.3. CephX

cephx 認証プロトコルは、Kerberos と同様に動作します。

ユーザー/アクターが Ceph クライアントを呼び出してモニターに接続します。Kerberos とは異なり、各モニターはユーザーを認証して鍵を配布できるため、cephx を使用する際に単一障害点やボトルネックはありません。このモニターは、Ceph サービスの取得に使用するセッションキーが含まれる Kerberos チケットと同様の認証データ構造を返します。このセッションキー自体はユーザーの永続的なシークレットキーで暗号化されるため、ユーザーだけが Ceph モニターからサービスを要求することができます。次に、クライアントはセッションキーを使用してモニターから必要なサービスを要求し、モニターはクライアントに実際にデータを処理する OSD に対してクライアントを認証するチケットと共にクライアントを提供します。Ceph モニターおよび OSD はシークレットを共有しているため、クライアントはモニターが提供するチケットをクラスター内の任意の OSD またはメタデータサーバーと共に使用することができます。攻撃者は、Kerberos のように cephx チケットの有効期限が切れるため、攻撃者は取得した期限切れのチケットまたはセッションキーを誤って使用できません。この形式の認証は、通信媒体にアクセスできる攻撃者が、ユーザーの秘密鍵が期限切れになる前に漏えいしない限り、別のユーザーの ID で偽のメッセージを作成したり、別のユーザーの正当なメッセージを変更したりすることを防ぎます。

cephx を使用するには、管理者は最初にユーザーを設定する必要があります。以下の図では、client.admin ユーザーはコマンドラインから ceph auth get-or-create-key を呼び出して、ユーザー名およびシークレットキーを生成します。Ceph の auth サブシステムはユーザー名およびキーを生成し、モニターでコピーを保存し、ユーザーのシークレットを client.admin ユーザーに送り返します。つまり、クライアントとモニターが秘密鍵を共有していることを意味します。

注記

client.admin ユーザーは、安全にユーザー ID とシークレットキーを提供する必要があります。

最新のアプリケーションには、非同期通信機能を備えた単純なオブジェクトストレージインターフェースが必要です。Ceph Storage Cluster は、非同期通信機能を備えたシンプルなオブジェクトストレージインターフェースを提供します。このインターフェースは、クラスター全体でオブジェクトへの直接並行アクセスを提供します。

Ceph クライアントは、永続的な関心をオブジェクトに登録し、プライマリ OSD へのセッションを開いたままにすることができます。クライアントは、通知メッセージおよびペイロードをすべてのウォッチャーに送信し、ウォッチャーが通知を受信したときに通知を受信できます。これにより、クライアントは同期/通信チャネルとして、任意のオブジェクトを使用できます。

必須の排他的ロックは、複数のマウントが設定されている場合に、RBD を単一のクライアントにロックする機能です。これは、マウントされた複数のクライアントが同じオブジェクトに書き込もうとした場合の書き込みの競合状況に対処する上で役立ちます。この機能は、前セクションで説明した object-watch-notify で構築されます。したがって、書き込み時に、あるクライアントがオブジェクトに排他ロックを最初に確立すると、マウントされた別のクライアントは、書き込み前にピアがオブジェクトにロックを設定したかどうかを最初に確認します。

この機能を有効にすると、1 つのクライアントのみが一度に RBD デバイスを変更することができます。特に、スナップショットの作成/削除 などの操作中に内部 RBD 構造を変更する場合などです。また、障害が発生したクライアントをある程度保護します。たとえば、仮想マシンが応答していないように見え、他の場所で同じディスクを使用してそのコピーを開始した場合、最初の仮想マシンは Ceph でブラックリストに登録され、新しい仮想マシンを破損することはできません。

必須の排他的ロックは、デフォルトでは有効になっていません。イメージの作成時に、--image-features パラメーターを使用して明示的に有効にする必要があります。以下に例を示します。

rbd -p mypool create myimage --size 102400 --image-features 5

ここで、数値の 5 は、1 と 4 の合計であり、1 は階層化サポートを有効にし、4 は排他的ロックサポートを有効にします。したがって、上記のコマンドは 100 GB rbd イメージを作成し、階層化および排他的ロックを有効にします。

必須の排他的ロックも object map の前提条件となります。排他的なロックサポートを有効にしないと、オブジェクトマップのサポートを有効にすることはできません。

必須の排他的ロックは、ミラーリングのためのいくつかの基本的な作業も行います。

オブジェクトマップは、クライアントが rbd イメージに書き込む際にサポートする RADOS オブジェクトの存在を追跡する機能です。書き込みが発生すると、その書き込みはバッキング RADOS オブジェクト内のオフセットに変換されます。オブジェクトマップ機能が有効になっている場合、これらの RADOS オブジェクトの存在が追跡されます。したがって、オブジェクトが実際に存在するかどうかを知ることができます。オブジェクトマップは、librbd クライアントのメモリー内に保持されるため、存在しないことがわかっているオブジェクトを OSD に照会することを回避できます。つまり、オブジェクトマップは実際に存在するオブジェクトのインデックスです。

オブジェクトマップは、以下のような特定の操作に有益です。

縮小サイズ変更操作は、末尾のオブジェクトが削除される部分的な削除のようなものです。

エクスポート操作は、RADOS から要求されるオブジェクトを認識します。

コピー操作では、どのオブジェクトが存在し、コピーする必要があるかを認識します。潜在的に数百、数千の可能なオブジェクトを反復する必要はありません。

フラット化操作は、クローンへのすべての親オブジェクトのコピーアップを実行して、クローンを親から切り離すことができるようにします。つまり、子クローンから親スナップショットへの参照を削除できます。したがって、すべての潜在的なオブジェクトの代わりに、コピーアップは存在するオブジェクトに対してのみ行われます。

削除操作は、イメージに存在するオブジェクトのみを削除します。

読み取り操作は、存在しないことがわかっているオブジェクトの読み取りをスキップします。

そのため、サイズ変更（縮小のみ）、エクスポート、コピー、フラット化、および削除などの操作の場合、これらの操作は影響を受けた RADOS オブジェクトすべて（存在するかどうかに関係なく）に対して操作を発行する必要があります。オブジェクトマップを有効にすると、オブジェクトが存在しない場合は、操作を発行する必要はありません。

たとえば、1 TB のスパース RBD イメージがある場合は、数百、数千というバッキングする RADOS オブジェクトが含まれる可能性があります。オブジェクトマップを有効にしない削除操作では、イメージの潜在的な オブジェクトごとに remove object 操作を実行する必要があります。ただし、オブジェクトマップが有効な場合は、存在するオブジェクトの remove object 操作のみを実行する必要があります。

オブジェクトマップは、実際のオブジェクトを持たないが、親からオブジェクトを取得するクローンに対して価値があります。クローンで作成されたイメージがある場合、クローンには最初にオブジェクトがなく、すべての読み取りは親にリダイレクトされます。したがって、オブジェクトマップは、オブジェクトマップがない場合と同様に読み取りを改善できます。最初に、クローンの OSD に対して読み取り操作を発行する必要があります。それが失敗すると、オブジェクトマップを有効にして、親に対して別の読み取りを発行します。存在しないことがわかっているオブジェクトの読み取りをスキップします。

オブジェクトマップは、デフォルトでは有効になっていません。イメージの作成時に、--image-features パラメーターを使用して明示的に有効にする必要があります。また、必須の排他的ロック （前のセクションで説明）は、オブジェクトマップ の前提条件です。排他的なロックサポートを有効にしないと、オブジェクトマップのサポートを有効にすることはできません。イメージの作成時にオブジェクトマップのサポートを有効にするには、以下を実行します。

rbd -p mypool create myimage --size 102400 --image-features 13

ここで、数値の 13 は、1 と 4、8 の合計であり、1 は階層化サポートを有効にし、4 は排他的ロックサポートを有効にして、8 は、オブジェクトマップサポートを有効にします。したがって、上記のコマンドは 100 GB rbd イメージを作成し、階層化、排他ロックおよびオブジェクトマップを有効にします。

ストレージデバイスにはスループットの制限があり、パフォーマンスとスケーラビリティーに影響を及ぼします。したがって、ストレージシステムは多くの場合、複数のストレージデバイス間で連続した情報の連続した情報プライピングに対応し、スループットとパフォーマンスを向上させることができます。データストライピングの最も一般的な形式は RAID から来ています。Ceph のストライピングに最も類似する RAID タイプは、RAID 0、つまり「ストライプ化ボリューム」です。 Ceph のストライピングでは、RAID 0 ストライピングのスループット、n-way RAID ミラーリングの信頼性、および迅速なリカバリーを提供します。

Ceph には、Ceph Block Device、Ceph Filesystem、および Ceph Object Storage の 3 種類のクライアントがあります。Ceph クライアントは、提供される表現形式からユーザー（ブロックデバイスイメージ、RESTful オブジェクト、CephFS ファイルシステムディレクトリー）から Ceph Storage クラスターのストレージのオブジェクトに変換します。

最も単純な Ceph のストライプ化形式には、1 つのオブジェクトのストライプ数が含まれます。Ceph クライアントは、オブジェクトが最大容量になるまで Ceph Storage Cluster オブジェクトにストライプユニットを書き込みます。その後、データの追加のストライプ用に別のオブジェクトを作成します。ストライプ化の最も単純な形式は、小さなブロックデバイスイメージ、S3 または Swift オブジェクトにとって十分と言えます。ただし、この単純な形式では、配置グループ全体にデータを分散する Ceph の機能をを最大限に活用しないため、パフォーマンスはそれほど向上しません。以下の図は、ストライプ化の最も単純な形式を示しています。

大規模なイメージサイズ、大規模な S3 または Swift オブジェクト（ビデオなど）を予測できる場合には、オブジェクトセット内の複数のオブジェクトにクライアントデータを取り除くことで、パフォーマンスを大幅に改善できる可能性があります。クライアントが対応するオブジェクトに並列にストライプユニットを書き込むと、書き込みパフォーマンスが大幅に向上します。オブジェクトは異なる配置グループにマッピングされ、さらに異なる OSD にマッピングされるため、それぞれの書き込みは最大書き込み速度で並行して行われます。1 つのディスクへの書き込みは、ヘッドの移動（シークあたり 6 ミリ秒など）と 1 つのデバイスの帯域幅（例： 100MB/s）によって制限されます。Ceph は、（異なる配置グループおよび OSD にマップする）複数のオブジェクトへの書き込みを分散することで、ドライブごとのシーク数を減らし、複数のドライブのスループットを組み合わせて書き込み（または読み取り）の速度を大幅に向上させることができます。

以下の図では、クライアントデータは、4 つのオブジェクトで構成されるオブジェクトセット (以下の図の object set 1) でストライプ化されます。最初のストライプユニットは、object 0 の stripe unit 0 です。4 番目のストライプユニットは、object 3 の stripe unit 3 です。4 番目のストライプを作成したら、クライアントはオブジェクトセットがいっぱいかどうかを判断します。オブジェクトセットが満杯でない場合は、クライアントは最初のオブジェクトにストライプを書き始めます（以下の図のオブジェクト 0 ）。オブジェクトセットが満杯になると、クライアントは新しいオブジェクトセット（以下の図のobject set 2 ）を作成し、新しいオブジェクトセット（以下の図のオブジェクト4 ）の最初のオブジェクトで最初のストライプ（ストライプユニット 16）への書き込みを開始します。

3 つの重要な変数が、Ceph によるデータのストライプ化方法を決定します。

Ceph クライアントがデータをストライプユニットにストライプ化し、ストライプユニットをオブジェクトにマッピングすると、Ceph の CRUSH アルゴリズムは、オブジェクトをストレージディスクにファイルとして保存する前に、オブジェクトを配置グループにマッピングし、配置グループを CephOSD デーモンにマッピングします。