2.6. CRUSH 階層の開発
ストレージ管理者は、Ceph Storage クラスターおよび Object Gateway のデプロイ時に、通常 Ceph Object Gateway にはデフォルトのゾーングループおよびゾーンがあります。Ceph ストレージクラスターにはデフォルトのプールがあり、次に、デフォルトの CRUSH 階層およびデフォルトの CRUSH ルールで CRUSH マップを使用します。
デフォルトの rbd
プールは、デフォルトの CRUSH ルールを使用できます。Ceph クライアントがデフォルトのルールまたは階層を使用してクライアントデータを保存している場合は、それらを削除 しないでください。
実稼働ゲートウェイは通常、ゲートウェイの使用および地理的な場所に従って名前が付けられるカスタムレルム、ゾーングループ、およびゾーンを使用します。また、Ceph ストレージクラスターには、複数の CRUSH 階層を持つ CRUSH マップがあります。
-
サービスプール: 少なくとも 1 つの CRUSH 階層はサービスプール用であり、場合によってはデータ用になります。サービスプールには、
.rgw.root
と、ゾーンに関連付けられたサービスプールが含まれます。サービスプールは、通常単一の CRUSH 階層下にあり、データの持続性のためにレプリケーションを使用します。データプールは CRUSH 階層を使用することもできますが、通常プールはデータの耐久性のためにイレイジャーコーディングで設定されます。 - インデックス: 少なくとも 1 つの CRUSH 階層はインデックスプール用にある 必要があり、CRUSH 階層は SSD ドライブや NVMe ドライブなどの高パフォーマンスのメディアにマップされます。バケットインデックスはパフォーマンスのボトルネックとなる可能性があります。Red Hat は、この CRUSH 階層で SSD または NVMe ドライブを使用することを推奨します。Ceph OSD ジャーナルに使用される SSD または NVMe ドライブのインデックス用にパーティションを作成します。さらに、インデックスはバケットシャーディングで設定する必要があります。
- 配置プール: 各配置ターゲットの配置プールには、バケットインデックス、データバケット、およびバケットの追加が含まれます。これらのプールは、個別の CRUSH 階層下に分類できます。Ceph Object Gateway は複数のストレージポリシーをサポートすることができるため、ストレージポリシーのバケットプールは異なる CRUSH 階層に関連付け、IOPS 最適化、スループット最適化、容量最適化などの異なるユースケースを反映できます。バケットインデックスプールには、SSD ドライブ、NVMe ドライブなどの高性能記憶媒体にバケットインデックスプールをマップするために、独自の CRUSH 階層を使用 すべきです。
2.6.1. CRUSH ルートの作成
管理ノードのコマンドラインから、各 CRUSH 階層に対して CRUSH マップに CRUSH ルートを作成します。また、潜在的にデータストレージプールを担うことができるサービスプールに、少なくとも 1 つの CRUSH 階層がある 必要があります。そのような SSD、NVMe ドライブなどの高性能ストレージメディアにマッピングされたバケットインデックスプールに、少なくとも 1 つの CRUSH 階層がある はずです。
CRUSH 階層の詳細については、Red Hat Ceph Storage Storage Strategies Guide 5の CRUSH Hierarchies セクションを参照してください。
CRUSH マップを手動で編集するには、Red Hat Ceph Storage Storage Strategies Guide 5 の Editing a CRUSH Map セクションを参照してください。
以下の例では、data0
、data1
、および data2
という名前のホストは、同じ物理ホストを参照する CRUSH の階層が複数存在するため、data0-sas-ssd
、data0-index
などの拡張論理名を使用します。
一般的な CRUSH ルートは、SAS ドライブを持つノードとジャーナル用の SSD を表す可能性があります。以下に例を示します。
## # SAS-SSD ROOT DECLARATION ## root sas-ssd { id -1 # do not change unnecessarily # weight 0.000 alg straw hash 0 # rjenkins1 item data2-sas-ssd weight 4.000 item data1-sas-ssd weight 4.000 item data0-sas-ssd weight 4.000 }
バケットインデックスの CRUSH ルートは、SSD や NVMe ドライブなどの高パフォーマンスメディアを表す はずです。OSD ジャーナルを格納する SSD または NVMe メディアにパーティションを作成することを検討してください。以下に例を示します。
## # INDEX ROOT DECLARATION ## root index { id -2 # do not change unnecessarily # weight 0.000 alg straw hash 0 # rjenkins1 item data2-index weight 1.000 item data1-index weight 1.000 item data0-index weight 1.000 }
2.6.2. CRUSH ルールの作成
デフォルトの CRUSH 階層と同様に、CRUSH マップにはデフォルトの CRUSH ルールも含まれます。
デフォルトの rbd
プールはこのルールを使用できます。他のプールを使用して顧客データを保存する場合は、デフォルトのルールを削除しないでください。
CRUSH ルールに関する一般的な情報は、Red Hat Ceph Storage 5 のRed Hat Ceph Storage Storage Strategies Guide で CRUSH rules セクションを参照してください。CRUSH マップを手動で編集するには、Red Hat Ceph Storage 5 の Red Hat Ceph Storage Storage Strategies Guide で Editing a CRUSH map を参照してください。
CRUSH 階層ごとに、CRUSH ルールを作成します。以下の例は、.rgw.root
を含むサービスプールを保存する CRUSH 階層のルールを示しています。この例では、ルート sas-ssd
がメインの CRUSH 階層として機能します。デフォルトのルールと区別するために、rgw-service
という名前を使用します。step take sas-ssd
行は、CRUSH ルートの作成 で作成された sas-ssd
ルートを使用するようにプールに指示します。このルートの子バケットには、SAS ドライブを備えた OSD と、高スループットハードウェア設定のジャーナルに対して SSD または NVMe ドライブなどの高性能ストレージメディアが含まれます。step chooseleaf
の type rack
部分が障害ドメインになります。以下の例では、ラックです。
## # SERVICE RULE DECLARATION ## rule rgw-service { type replicated min_size 1 max_size 10 step take sas-ssd step chooseleaf firstn 0 type rack step emit }
前述の例では、データが 3 回複製される 3 回複製される場合は、同様の数の OSD ノードを含むクラスターに 3 つ以上のラックが存在する必要があります。
type replicated
設定は、データ永続性、レプリカ数、またはイレイジャーコーディングとは 関係ありません。複製
のみがサポートされます。
以下の例は、データプールを保存する CRUSH 階層のルールを示しています。この例では、root sas-ssd
は、サービスルールと同じ CRUSH 階層としてメインの CRUSH 階層として機能します。rgw-throughput
を使用して、デフォルトのルールと rgw-service
と区別します。step take sas-ssd
行は、CRUSH ルートの作成 で作成された sas-ssd
ルートを使用するようにプールに指示します。このルートの子バケットには、SAS ドライブを備えた OSD と、高スループットハードウェア設定の SSD または NVMe ドライブなどの高性能ストレージメディアが含まれます。step chooseleaf
の type host
部分障害ドメインになります。以下の例では、ホストです。ルールは同じ CRUSH 階層を使用し、異なる障害ドメインを使用することに注意してください。
## # THROUGHPUT RULE DECLARATION ## rule rgw-throughput { type replicated min_size 1 max_size 10 step take sas-ssd step chooseleaf firstn 0 type host step emit }
前述の例では、プールが大量のデータでイレイジャーコーディングを使用し、デフォルトよりもエンコーディングのチャンクを使用する場合、イレイジャーコーディングのチャンクを容易にするために、同様の数の OSD ノードを含むクラスター内のラックが少なくとも数ある必要があります。小規模なクラスターの場合、これは実用的ではない可能性があるため、前述の例では host
を CRUSH 障害ドメインとして使用します。
以下の例は、インデックスプールを保存する CRUSH 階層のルールを示しています。この例では、root の index
は主な CRUSH 階層として機能します。rgw-index
を使用して、rgw-service
と rgw-throughput
と区別します。step take index
行は、CRUSH ルートの作成 で作成された index
root を使用するようにプールに指示します。その子バケットには、SSD ドライブ、NVMe ドライブなどの高性能ストレージメディア、または OSD ジャーナルも格納する SSD ドライブまたは NVMe ドライブ上のパーティションが含まれます。step chooseleaf
の type rack
部分が障害ドメインになります。以下の例では、ラックです。
## # INDEX RULE DECLARATION ## rule rgw-index { type replicated min_size 1 max_size 10 step take index step chooseleaf firstn 0 type rack step emit }
2.6.3. 関連情報
- CRUSH 階層に関する一般的な情報は、Red Hat Ceph Storage Storage Strategies Guide の CRUSH Administration セクションを参照してください。