7.5. データ配置ストラテジーの作成
Ceph Object Gateway には、default-placement
と呼ばれるデフォルトのストレージポリシーがあります。クラスターにストレージポリシーが 1 つしかない場合は、default-placement
ポリシーで十分です。このデフォルトの配置ポリシーはゾーングループの設定から参照され、ゾーン設定で定義されます。
詳細は、Red Hat Enterprise Linux 用の Red Hat Ceph Storage 4 Ceph Object Gateway ガイドの「ストレージポリシー」セクションを参照してください。
IOPS 最適化、スループットの最適化、容量最適化など、複数のユースケースをサポートするクラスターの場合、ゾーングループ設定の配置ターゲットのセットとゾーン設定の配置プールのセットは各ストレージポリシーを表します。
以下のセクションでは、ストレージポリシーを作成し、それをデフォルトのポリシーに設定する方法を説明します。また、この例では、デフォルトのポリシーがスループット最適化ハードウェアプロファイルを使用することを前提としています。トピックには以下が含まれます。
7.5.1. インデックスプールの作成
デフォルトでは、Ceph Object Gateway はバケットのオブジェクトをインデックスにマッピングするため、ゲートウェイクライアントはバケット内のオブジェクト一覧を他の項目と共に要求できます。一般的なユースケースでは、ユーザーにバケットおよびバケットごとに制限された数のオブジェクトがあるクォータが使用されますが、バケットは列挙可能なオブジェクトを保存できます。バケットが大量のオブジェクトを保存する場合、SSD ドライブや NVMe ドライブなどの高パフォーマンスストレージメディアを使用してデータを保存することで、インデックスのパフォーマンスが大幅に向上します。さらに、バケットのシャード化により、パフォーマンスが大幅に向上します。
PG 数の詳細は、『ストレージストラテジーガイド』の「Ceph Placement Groups (PGs) per Pool Calculator」および「配置グループ」を参照してください。プールの作成に関する詳細は、『ストレージストラテジーガイド』の「プールの作成」セクションを参照してください。
PG per Pool Calculator では、インデックスプールに対してプールあたりの PG 数を少なくすることが推奨されています。ただし、PG 数はサービスプールの PG 数の約 2 倍です。
Red Hat は、インデックスプールの HDD デバイスに対応していません。サポート対象構成の情報については、「Red Hat Ceph Storage: Supported configurations」の記事を参照してください。
インデックスプールを作成するには、ceph osd pool create
にプール名、PG および PGP の数、replicated
データ永続性メソッド、およびルール名を指定して作成します。
バケットが 10 万を超えるオブジェクトを保存する場合は、バケットのオブジェクト数が増える際にインデックスのパフォーマンスが低下しないようにバケットのシャード化を設定します。『Ceph Object Gateway ガイドの設定および管理ガイド』の「バケットシャーディングの構成」セクションを参照してください。元の構成が適切でなくなった場合のバケットの再シャーディングの詳細については、『Ceph Object Gateway ガイド構成および管理ガイド』の「バケットインデックスの再シャーディング」セクションも参照してください。
7.5.2. データプールの作成
データプールは、Ceph Object Gateway が特定のストレージポリシーのオブジェクトデータを保管する場所です。データプールは、減らしたサービスプールの PG 数ではなく、PG 数を完全に補完する必要があります。データプールは、それが実質的に複製するよりも効率的であり、データの耐久性を維持しながら、大幅に容量要件を減らすことができますよう、イレイジャーコーディングを使用して検討 すべきです。
イレイジャーコーディングを使用するには、イレイジャーコードプロファイルを作成します。詳細は、『ストレージストラテジーガイド』の「イレイジャーコーディングプロファイル」セクションを参照してください。
プールの作成後にプロファイルを変更できないため、正しいプロファイルを選択することが重要です。プロファイルを変更するには、別のプロファイルで新しいプールを作成し、オブジェクトを古いプールから新しいプールに移行する必要があります。
デフォルト設定は 2 つのデータチャンクと 1 つのエンコーディングチャンクです。つまり、1 つの OSD のみが失われる可能性があります。回復性が高い場合は、大量のデータおよびエンコーディングチャンクを考慮してください。たとえば、大規模なシステムでは 8 個のデータチャンクと 3 つのエンコーディングチャンクを使用しているため、3 つの OSD が失敗してもデータが失われることはありません。
各データおよびエンコードチャンク SHOULD は、最低でも別のノードまたはホストに保存されます。小規模なクラスターの場合、これにより、大量のデータおよびエンコードチャンクを使用する場合に、rack
の非現実障害ドメインを最低限の CRUSH 障害ドメインとして使用します。そのため、データプールは、最小 CRUSH 障害ドメインとして、host
を持つ別の CRUSH 階層を使用するのが一般的です。Red Hat は、最小障害ドメインとして host
を推奨します。イレイジャーコードチャンクが同じホスト内の OSD に保存されていると、ジャーナルやネットワークカードなどのホストの障害により、データが失われる可能性があります。
データの追加プールを作成するには、ceph osd pool create
にプール名、PG および PGP の数、erasure
データ永続性メソッド、イレイジャーコードプロファイル、およびルール名を指定して実行します。
7.5.3. データ追加プールの作成
data_extra_pool
は、イレイジャーコーディングを使用できないデータ向けです。たとえば、マルチパートアップロードにより、複数部分でのモジションなどの大規模なオブジェクトのアップロードが可能です。これらのパーツは、最初にイレイジャーコーディングなしで保存する必要があります。イレイジャーコーディングは、部分的なアップロードではなく、オブジェクト全体に適用されます。
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
7.5.4. ゾーングループへの配置ターゲットの設定
プールを作成したら、ゾーングループに配置ターゲットを作成します。ゾーングループを取得するには、次のコマンドを実行して、ゾーングループの設定を zonegroup.json
というファイルに出力します。
# radosgw-admin zonegroup get [--rgw-zonegroup=<zonegroup>] > zonegroup.json
ファイルの内容は以下のようになります。
{ "id": "90b28698-e7c3-462c-a42d-4aa780d24eda", "name": "us", "api_name": "us", "is_master": "true", "endpoints": [ "http:\/\/rgw1:80" ], "hostnames": [], "hostnames_s3website": [], "master_zone": "9248cab2-afe7-43d8-a661-a40bf316665e", "zones": [ { "id": "9248cab2-afe7-43d8-a661-a40bf316665e", "name": "us-east", "endpoints": [ "http:\/\/rgw1" ], "log_meta": "true", "log_data": "true", "bucket_index_max_shards": 0, "read_only": "false" }, { "id": "d1024e59-7d28-49d1-8222-af101965a939", "name": "us-west", "endpoints": [ "http:\/\/rgw2:80" ], "log_meta": "false", "log_data": "true", "bucket_index_max_shards": 0, "read_only": "false" } ], "placement_targets": [ { "name": "default-placement", "tags": [] } ], "default_placement": "default-placement", "realm_id": "ae031368-8715-4e27-9a99-0c9468852cfe" }
placement_targets
セクションには、各ストレージポリシーが一覧表示されます。デフォルトでは、default-placement
という配置ターゲットが含まれます。デフォルトの配置ターゲットは、placement_targets
セクションの直後に識別されます。
throughput-optimized
と呼ばれる配置ターゲットをデフォルトターゲットとして throughput-optimized
とすると、ゾーングループ構成の placement_targets
セクションと default_placement
設定を次のように変更する必要があります。
{ ... "placement_targets": [ { "name": "throughput-optimized", "tags": [] } ], "default_placement": "throughput-optimized", ... }
最後に、変更した zonegroup.json
ファイルの設定でゾーングループ構成を設定し、期間を更新します。以下に例を示します。
# radosgw-admin zonegroup set [--rgw-zonegroup=<zonegroup>] --infile zonegroup.json # radosgw-admin period update --commit
7.5.5. ゾーンへの配置プールの設定
ゾーングループに新しい throughput-optimized
配置ターゲットが割り当てられたら、ゾーン設定で throughput-optimized
の配置プールをマッピングします。この手順では、関連するプールへの default-placement
のマッピングが、配置グループの throughput-optimized
セットに置き換えられます。
「ゾーンの取得」の手順を実行し、プール名を表示します。
# radosgw-admin zone get [--rgw-zone=<zone>] > zone.json
us-west
という名前のゾーンを前提とすると、ファイルの内容は以下のようになります。
{ "domain_root": ".rgw.root", "control_pool": ".us-west.rgw.control", "gc_pool": ".us-west.rgw.gc", "log_pool": ".us-west.log", "intent_log_pool": ".us-west.intent-log", "usage_log_pool": ".us-west.usage", "user_keys_pool": ".us-west.users.keys", "user_email_pool": ".us-west.users.email", "user_swift_pool": ".us-west.users.swift", "user_uid_pool": ".us-west.users.uid", "system_key": { "access_key": "", "secret_key": ""}, "placement_pools": [ { "key": "default-placement", "val": { "index_pool": ".us-west.rgw.buckets.index", "data_pool": ".us-west.rgw.buckets", "data_extra_pool": ".us-west.rgw.buckets.non-ec" "index_type": 0 } } ] }
ゾーン設定の placement_pools
セクションは、配置プールのセットを定義します。配置プールの各セットは、ストレージポリシーを定義します。ファイルを変更して default-placement
エントリーを削除し、throughput-optimized
エントリーを、前のステップで作成したプールに置き換えます。以下に例を示します。
{ ... "placement_pools": [ { "key": "throughput-optimized", "val": { "index_pool": ".us-west.rgw.buckets.index", "data_pool": ".us-west.rgw.buckets.throughput"} "data_extra_pool": ".us-west.rgw.buckets.non-ec", "index_type": 0 } ] }
最後に、変更した zone.json
ファイルからゾーン設定を設定し、期間を更新します。以下に例を示します。
# radosgw-admin zone set --rgw-zone={zone-name} --infile zone.json # radosgw-admin period update --commit
index_pool
は、SSD や他の高パフォーマンスストレージを含むインデックスプールおよび CRUSH 階層を参照し、data_pool
は PG に完全補完されたプール、高スループットのホストバスアダプターの CRUSH 階層、ジャーナル用の SAS ドライブおよび SSD を参照します。
7.5.6. データ配置の概要
クライアント要求を処理する際に、Ceph Object Gateway はデフォルトのストレージポリシーとして新たな throughput-optimized
ターゲットを使用します。以下の手順を使用して、マルチサイト構成で異なるゾーンおよびゾーングループに同じターゲットを確立し、必要に応じてプールのゾーン名を置き換えます。
以下の手順を使用して、追加のストレージポリシーを確立します。各ターゲットおよび配置プールのセットの命名は任意です。これには、fast
、streaming
、cold-storage
、またはその他の適切な名前を使用できます。ただし、各セットには、ゾーングループの placement_targets
の下に対応するエントリーが必要であり、ターゲットの 1 つは default_placement
設定で参照される 必要があります。また、ゾーンには、ポリシーごとに構成された対応するプールのセットが必要です。
クライアント要求が X-Storage-Policy
と別のターゲットを指定しない限り、クライアントリクエストは常にデフォルトのターゲットを使用します。オブジェクトゲートウェイクライアントの使用例は、「コンテナーの作成」を参照してください。