Red Hat Training
A Red Hat training course is available for Red Hat Ceph Storage
第7章 ストレージストラテジーの開発
実稼働環境での使用に Ceph Storage クラスターおよび Ceph Object Gateway をセットアップする際の困難な要素の 1 つは、効果的なストレージ計画を定義することです。ストレージ計画には、以下の要素が含まれます。
ストレージストラテジーおよびコマンドラインの使用方法に関する一般的なガイダンスは、『Red Hat Ceph Storage 3 ストレージ戦略 』ガイドを参照してください。
7.1. 想定されるオブジェクト数の検討
Red Hat Ceph Storage 3.1 以降では、追加の引数が ceph osd pool create コマンドに追加されました。新しい引数はストレージプールのオブジェクト数を設定し、この引数は FileStore を使用してストレージプールを作成する場合にのみ機能します。予想されるオブジェクト数を設定すると、大規模なオブジェクト数を見積もるストレージプールにのみ適用されます。プールの作成時に予想されるオブジェクト数を設定すると、配置グループフォルダー分割は即座に行われ、ランタイム時には実行されません。
この動作はすべての Ceph ユースケースに影響を与える可能性がありますが、Object Gateway のユースケースへの影響はより重要です。これは、Object Gateway には多くのオブジェクトが含まれるストレージプールを持つ可能性があるため、default.rgw.buckets.data ストレージプールになります。
[expected-num-objects] 値を設定すると、ランタイムパフォーマンスが向上します。以下に挙げる理由を以下に示します。
-
FileStoreは、オブジェクトをxfsファイルシステムのファイルとして保存します。FileStoreは、これらのオブジェクトファイルをディレクトリーに保存します。オブジェクトカウントが増減するにつれ、FileStoreはディレクトリーを分割またはマージして、オブジェクトを妥当な範囲内に保つことができます。詳細なfilestore_merge_threshold、filestore_split_multipleおよびfilestore_split_rand_factor設定により、この動作が管理されます。 -
FileStoreは分割またはマージ操作時にオブジェクトをあるディレクトリーから別のディレクトリーに移動する必要があるため、FileStoreの分割およびマージ動作にはパフォーマンスに影響があります。FileStoreの使用時に Red Hat Ceph Storage 3.1 以降のリリースでこのパフォーマンスのペナルティーを避けるには、ストレージ管理者がプールを作成するプール BEFORE の予想されるオブジェクト数を予測することが重要です。 -
ゲートウェイクライアントは、ゲートウェイオブジェクトを保存および取得します。このオブジェクトは、1 つ以上の Ceph Storage クラスターオブジェクトとして保存されます。つまり、クライアントオブジェクトは、オブジェクトのストライピングにより 1 つ以上の Ceph Storage クラスターオブジェクトのストレージを呼び出すことができます。たとえば、クライアントが 40 MB のビデオオブジェクトを保存する場合、Ceph Object Gateway はビデオオブジェクトを一連の 10 4 MB のオブジェクトにストライプ化し、クラスター内の異なる OSD に保存します。ストライピングは、並列処理によりパフォーマンスの向上を提供します。高度な
rgw_obj_stripe_size構成設定は、ストライプサイズを制御し、プールの作成後に CANNOT を変更します。
予想されるオブジェクト数を見積もるには、Red Hat Ceph Storage クラスターのストレージ容量でベースとなります。ストレージ容量には、3 つの概算サイズがあります。
- small = 250 TB
- 中 = 1 PB
- Large = 2 PB+
詳細は、『 Red Hat Ceph Storage Hardware Selection Guide 』を参照してください。
OSD のディスクサイズが 4 TB と仮定すると、これらのサイズは以下のように OSD の数を指定します。
- small = 250 TB = 63 OSD
- medium = 1 PB = 256 OSD
- Large = 2 PB+ = 512 OSDs
Red Hat は、以下の式を使用して、ストレージプールごとに予想されるオブジェクト数を決定することを推奨します。
1 m x OSD 数
3 つの概算サイズでは、予想されるオブジェクト数を 63M、256M、および 512M にそれぞれ設定する必要があります。
もう 1 つの考慮事項として、バケットインデックスエントリーは約 200 バイトのデータであり、leveldb にオブジェクトマップ(omap)として保存されます。これは rgw_obj_stripe_size よりも小さいため、バケットインデックスの予想されるオブジェクト数は、クライアントが保存および取得するゲートウェイオブジェクトの数と同じである必要があります。
プールの作成時に、予想されるオブジェクトの数を指定し、filestore_merge_threshold が負の値に設定され、ランタイム時にではなくプールの作成時に配置グループフォルダー分割が実行されるようにします。
ストレージプールが作成されている間、ディレクトリー構造は配置されます。これにはしばらく時間がかかり、ストレージクラスターのリソースを消費します。予想されるオブジェクト数が高すぎる（例： 1 trillion）設定されている場合、OSD の停止タイムアウトが発生する可能性があります。
