2.5. Ceph Object Gateway の考慮事項
ストレージクラスターの設計に関するもう 1 つの重要な点として、ストレージクラスターが 1 つのデータセンターサイトにあるか、複数のデータセンターサイトにまたがるかどうかを判別することです。マルチサイトストレージクラスターは、地理的に分散したフェイルオーバーと、長期的な停電、地震、ハリケーン、洪水、その他の災害からの復旧の恩恵を受けます。さらに、マルチサイトストレージクラスターは active-active 設定を持つことができ、クライアントアプリケーションを最も近い利用可能なストレージクラスターに転送できます。これは、コンテンツ配信ネットワークに適したストレージストラテジーです。データをクライアントのできるだけ近くに配置することを検討してください。これは、ストリーミング 4k ビデオなど、スループット集約型のワークロードに重要です。
Red Hat は、Ceph のストレージプールを作成する前に、レルム、ゾーングループ、およびゾーン名を特定することが推奨されます。一部のプール名の先頭に、ゾーン名を標準の命名規則として追加します。
関連情報
- 詳細は、Red Hat Ceph Storage Object Gateway ガイドの マルチサイトの設定および管理 セクションを参照してください。
2.5.1. 管理データストレージ
Ceph Object Gateway は、インスタンスのゾーン設定で定義された一連のプールに管理データを保存します。たとえば、後続のセクションで説明したバケット、ユーザー、ユーザークォータおよび使用状況の統計は、Ceph Storage Cluster のプールに保存されます。デフォルトでは、Ceph Object Gateway は以下のプールを作成し、それらをデフォルトゾーンにマッピングします。
-
.rgw.root -
.default.rgw.control -
.default.rgw.meta -
.default.rgw.log -
.default.rgw.buckets.index -
.default.rgw.buckets.data -
.default.rgw.buckets.non-ec
.default.rgw.buckets.index プールは、Ceph Object Gateway でバケットが作成された後にのみ作成されます。一方、データはバケットにアップロードされた後に .default.rgw.buckets.data プールが作成されます。
CRUSH ルールセットと配置グループの数を設定することができるように、これらのプールを手動で作成することを検討してください。一般的な設定では、Ceph Object Gateway の管理データを格納するプールは、管理データに 10 個のプールがあるため、多くの場合、同じ CRUSH ルールセットを使用し、使用する配置グループの数を少なくします。
Red Hat は、.rgw.root プールとサービスプールは同じ CRUSH 階層を使用し、CRUSH ルールの障害ドメインとして少なくとも node を使用することを推奨しています。Red Hat では、データの耐久性には replicated を使用し、.rgw.root プールには erasure を使用せず、サービスプールを使用することを推奨します。
mon_pg_warn_max_per_osd 設定は、プールに過剰な配置グループを割り当てると警告します (つまりデフォルトでは 300)。この値は、ニーズやハードウェアの能力に合わせて調整することができ、n は OSD あたりの PG の最大数です。
mon_pg_warn_max_per_osd = n
.rgw.root を含むサービスプールの場合は、Ceph placement groups (PGs) per pool calculator から提案される PG 数は、Ceph OSD あたりのターゲットの PG よりもはるかに少なくなります。また、Ceph OSD の数が、calculator のステップ 4 で設定されていることを確認します。
ガベッジコレクションは、OMAP ではなく通常の RADOS オブジェクトで .log プールを使用します。今後のリリースでは、より多くの機能はメタデータを .log プールに保管します。したがって、Red Hat は、.log プールに NVMe/SSD Ceph OSD を使用することを推奨しています。
.RGW.root プール
Ceph Object Gateway 設定が保存されるプール。これには、レルム、ゾーングループ、およびゾーンが含まれます。通常、その名前はゾーン名の前に追加されません。
サービスプール
サービスプールは、サービス制御、ガベージコレクション、ロギング、ユーザー情報、および使用方法に関連するオブジェクトを保存します。慣例により、これらのプール名には、プール名の前にゾーン名が付加されます。
-
.ZONE_NAME.rgw.control: コントロールプール。 -
.ZONE_NAME.log: ログプールには、すべてのバケット/コンテナーのログおよび create、read、update、および delete などのオブジェクトアクションが含まれます。 -
.ZONE_NAME.rgw.buckets.index: このプールはバケットのインデックスを保存します。 -
.ZONE_NAME.rgw.buckets.data: このプールはバケットのデータを格納します。 -
.ZONE_NAME.rgw.meta: メタデータプールは user_keys およびその他の重要なメタデータを保存します。 -
.ZONE_NAME.meta:users.uid: ユーザー ID プールには、一意のユーザー ID のマップが含まれます。 -
.ZONE_NAME.meta:users.keys: キープールには、各ユーザー ID のアクセスキーおよびシークレットキーが含まれます。 -
.ZONE_NAME.meta:users.email: メールプールには、ユーザー ID に関連付けられたメールアドレスが含まれます。 -
.ZONE_NAME.meta:users.swift: Swift プールには、ユーザー ID の Swift サブユーザー情報が含まれます。
関連情報
- 詳細は、Red Hat Ceph Storage Object Gateway ガイドの プールについて セクションを参照してください。
- 詳細は、Red Hat Ceph Storage ストラテジーガイド を参照してください。
2.5.2. インデックスプール
Ceph Object Gateway で使用する OSD ハードウェアを選択する場合 (ユースケースに関係なく)、インデックスプールを保存するために、SSD または NVMe ドライブのいずれかの高パフォーマンスドライブが 1 つ以上ある OSD ノードが必要です。これは、バケットに多数のオブジェクトが含まれる場合は、特に重要になります。
Red Hat Ceph Storage が Bluestore を実行している場合には、NVMe ドライブを別のプールではなく block.db デバイスとしてデプロイすることを推奨します。
Ceph Object Gateway インデックスデータはオブジェクトマップ (OMAP) にのみ書き込まれます。BlueStore の OMAP データは、OSD の block.db デバイスにあります。NVMe ドライブが HDD OSD の block.db デバイスとして機能し、インデックスプールが HDD OSD によって保持されている場合、インデックスデータは block.db デバイスにのみ書き込まれます。block.db パーティション/lvm がブロックの 4% に正しくサイズ設定されている限り、BlueStore ではこの設定だけで十分です。
Red Hat は、インデックスプールの HDD デバイスに対応していません。サポート対象設定の情報については、Red Hat Ceph Storage: Supported configurations の記事を参照してください。
インデックスエントリーは約 200 バイトのデータで、rocksdb に OMAP として保存されます。これはごくわずかな量のデータですが、Ceph Object Gateway を使用すると、1 つのバケットに数千万から数億のオブジェクトが含まれる可能性があります。インデックスプールを高性能ストレージメディアの CRUSH 階層にマッピングすることにより、バケットに非常に多くのオブジェクトが含まれている場合に、レイテンシーが短くなり、パフォーマンスが劇的に向上します。
実稼働クラスターでは、標準の OSD ノードには OSD ジャーナルを保存するための SSD または NVMe ドライブが 1 つ以上と、インデックスプールまたは block.db デバイスが含まれます。同じ物理ドライブには、別のパーティションまたは論理ボリュームを使用します。
2.5.3. データプール
データプールは、Ceph Object Gateway が特定のストレージポリシーのオブジェクトデータを保管する場所です。データプールは、サービスプールの PG 数を減らすのではなく、配置グループ (PG) を完全に補完します。データプールのイレイジャーコーディングの使用を検討してください。これはレプリケーションよりも大幅に効率的であり、データの持続性を維持しつつ容量要件を大幅に減らすことができます。
イレイジャーコーディングを使用するには、イレイジャーコードプロファイルを作成します。詳細は、Red Hat Ceph Storage ストレージ戦略ガイド の コードプロファイルの消去 セクションを参照してください。
プールの作成後にプロファイルを変更できないため、正しいプロファイルを選択することが重要です。プロファイルを変更するには、別のプロファイルで新しいプールを作成し、オブジェクトを古いプールから新しいプールに移行する必要があります。
デフォルト設定は、2 つのデータチャンク (k) と 2 つのエンコーディングチャンク (m) です。つまり、1 つの OSD のみが失われる可能性があります。回復性が高い場合は、大量のデータおよびエンコーディングチャンクを考慮してください。たとえば、一部の大規模なシステムでは、8 データチャンクと 3 つのエンコーディングチャンクが使用され、データを失うことなく 3 つの OSD が失敗することが可能になります。
各データおよびエンコードチャンク SHOULD は、最低でも別のノードまたはホストに保存されます。小規模なストレージクラスターの場合、これにより、大量のデータおよびエンコードチャンクを使用する場合に、rack の非現実障害ドメインを最低限の CRUSH 障害ドメインとして使用します。そのため、データプールは、最小 CRUSH 障害ドメインとして、host を持つ別の CRUSH 階層を使用するのが一般的です。Red Hat は、最小障害ドメインとして host を推奨します。イレイジャーコードチャンクが同じホスト内の Ceph OSD に保存されていると、ジャーナルやネットワークカードなどのホストの障害により、データが失われる可能性があります。
データの追加プールを作成するには、ceph osd pool create コマンドにプール名、PG および PGP の数、erasure データ永続性メソッド、イレイジャーコードプロファイル、およびルール名を指定して実行します。
2.5.4. データ追加プール
data_extra_pool は、イレイジャーコーディングを使用できないデータ向けです。たとえば、マルチパートアップロードにより、複数部分でのモジションなどの大規模なオブジェクトのアップロードが可能です。これらのパーツは、最初にイレイジャーコーディングなしで保存する必要があります。イレイジャーコーディングは、部分的なアップロードではなく、オブジェクト全体に適用されます。
placement group (PG) per Pool Calculator では、data_extra_pool 対してプールあたりの PG 数を少なくすることが推奨されています。ただし、PG 数はサービスプールとバケットインデックスプールと同じ PG の約 2 倍です。
データの追加プールを作成するには、ceph osd pool create コマンドにプール名、PG および PGP の数、replicated データ永続性メソッド、およびルール名を指定して作成します。以下に例を示します。
# ceph osd pool create .us-west.rgw.buckets.non-ec 64 64 replicated rgw-service
