2.5. CRUSH Weights
CRUSH アルゴリズムは、新しいデータオブジェクトを PG に、PG を OSD に割り当てる書き込み要求のための一貫した確率分散で、OSD ごとにテラバイトで重み値を割り当てます (規則により)。このため、ベストプラクティスとして、同じタイプおよびサイズのデバイスとともに CRUSH の階層を作成し、同じ重みを割り当てることが推奨されます。また、パフォーマンス特性がデータの分散に影響を及ぼさなくても、CRUSH 階層にパフォーマンス特性が統一されるように、同じ I/O およびスループット特性でデバイスを使用することが推奨されます。
統一されたハードウェアを使用することは常に実用的な設定ではないため、異なるサイズの OSD デバイスを取り入れ、Ceph が大規模なデバイスにより多くのデータを配信し、小さいデバイスにさらに多くのデータが配信するようにできます。
2.5.1. テラバイトでの OSD の重みの設定
CRUSH マップ内の Terabytes で OSD CRUSH 重みを設定するには、以下のコマンドを実行します。
ceph osd crush reweight {name} {weight}
詳細は以下のようになります。
- name
- 説明
- OSD のフルネーム。
- タイプ
- 文字列
- 必須
- Yes
- 例
-
osd.0
- weight
- 説明
-
OSD の CRUSH 加重。これはテラバイト単位で OSD のサイズになります。
1.0
は 1 テラバイトです。 - 型
- double
- 必須
- Yes
- 例
-
2.0
この設定は、OSD を作成するか、OSD の追加直後に CRUSH 重みを調整する際に使用されます。通常、OSD のライフサイクルは変更されません。
2.5.2. バケットの OSD 重みの設定
ceph osd crush reweight
を使用すると、時間がかかる可能性があります。以下を実行して、すべての Ceph OSD 加重をバケット (行、ラック、ノードなど) の下で設定できます。
osd crush reweight-subtree <name>
詳細は以下のようになります。
name
は CRUSH バケットの名前です。
2.5.3. OSD の in
重みの設定
ceph osd in
および ceph osd out
の目的上、OSD はクラスター内 (in
) か、クラスター外 (out
) のいずれかにあります。これは、モニターする OSD のステータスを記録します。ただし、OSD はクラスター内 in
となりますが、修正されるまでは依存したくない機能 (ストレージドライブの置き換え、コントローラーの変更など) 生する可能性があります。
以下を実行して (つまり、テラバイト単位でその重みを変更せずに)、以下のコマンドを実行して、特定の OSD の in
重みを増減できます。
ceph osd reweight {id} {weight}
詳細は以下のようになります。
-
id
は OSD の番号です。 -
weight
は 0.0 ~ 1.0 の範囲です。0
はクラスター内 (in
) には含まれません (つまり、PG がクラスターに割り当てられていません)。1.0 はクラスター内 (in
) です (つまり、OSD は他の OSD と同じ数の PG を受信します)。
2.5.4. 使用状況による OSD の重みの設定
CRUSH は、新しいデータオブジェクトの PG と PG を OSD に割り当てる書き込み要求のための一貫した確率分散を概観するために設計されています。ただし、クラスターは任意に負荷分散される可能性があります。これは、さまざまな理由で発生する可能性があります。以下に例を示します。
- 複数のプール: CRUSH 階層に複数のプールを割り当てることができますが、プールには異なる配置グループの数、サイズ (保存するレプリカ数)、およびオブジェクトサイズの特性を持たせることができます。
-
カスタムクライアント: クライアントからのブロックデバイス、Object Gateway、ファイルシステムシャードデータなどの Ceph クライアント。統一されたサイズの小さい RADOS オブジェクトとして、データをクラスター全体でオブジェクトとしてストライプ化します。したがって、フォレッシングシナリオを除き、CRUSH は通常、その目的を達成します。ただし、クラスターに不安定な状態が生じるもう 1 つのケースがあります。つまり、
librados
を使用してオブジェクトのサイズを正規化せずにデータを保存することです。このシナリオでは、クラスターがアンバランスになります (例: 100 1 MB と 10 4 MB のオブジェクトを格納すると、他よりも多くのデータを持つ OSD が少なくなります)。 - 可能性: 統一されたディストリビューションでは、PG が多い OSD と少ない OSD が発生します。OSD が多数あるクラスターの場合、統計外メモリーはさらに省略されます。
以下を実行することで、使用率に従って OSD を再度有効にできます。
ceph osd reweight-by-utilization [threshold] [weight_change_amount] [number_of_OSDs] [--no-increasing]
以下に例を示します。
ceph osd test-reweight-by-utilization 110 .5 4 --no-increasing
詳細は以下のようになります。
-
threshold
は、OSD がデータストレージ負荷を高くする使用率が低くなり、割り当てられた PG の数が減ります。デフォルト値は120
で、120 % を反映しています。100
以降の値はすべて有効なしきい値です。任意です。 -
weight_change_amount
は重みを変更する量です。有効な値は0.0 - 1.0
より大きいです。デフォルト値は0.05
です。任意です。 -
number_of_OSDs
は、リライトする OSD の最大数です。大規模なクラスターの場合、OSD の数を reweight に制限すると、影響の大きいリバランスが妨げられます。任意です。 -
no-increasing
は、デフォルトで off になっています。reweight-by-utilization
コマンドまたはtest-reweight-by-utilization
コマンドを使用すると、osd 重みを増やすことができます。このオプションを使用すると、OSD の使用率が低くなっている場合でも、OSD の重みが増加しないようにします。任意です。
大規模なクラスターに reweight-by-utilization
を実行することが推奨されます。使用率レートは時間の経過と共に変化する場合があります。また、クラスターのサイズやハードウェアの変化により、使用率の変更を反映するために重み付けを更新しなければならない場合があります。使用率の再行を選択した場合には、使用率、ハードウェア、またはクラスターのサイズの変更としてこのコマンドを再実行する必要がある場合があります。
重みを割り当てる上記またはその他の重みのコマンドを実行すると、このコマンドによって割り当てられる重みが上書きされます (例: osd reweight-by-utilization
、osd crush weight
、osd weight
、in
、または out
)。
2.5.5. PG Distribution による OSD の重みの設定
少数の OSD を持つ CRUSH 階層では、一部の OSD が他の OSD よりも長い PG を取得できるため、負荷が高くなることがあります。以下のコマンドを実行して、この状況に対処するために PG ディストリビューションで OSD を再非推奨にすることができます。
osd reweight-by-pg <poolname>
詳細は以下のようになります。
-
poolname
はプールの名前です。Ceph は、プールの PG を OSD に割り当ててから、このプールの PG ディストリビューションに従って OSD をどのように割り当てるかを検証します。複数のプールを同じ CRUSH 階層に割り当てることができることに注意してください。1 つのプールのディストリビューションに従って OSD を再実行すると、同じ CRUSH 階層に割り当てられた他のプールには、同じサイズ (レプリカの数) と PG が割り当てられていない場合に、意図しない影響が出る可能性があります。
2.5.6. CRUSH ツリーの重みを再計算
CRUSH ツリーバケットは、リーフの重みの合計である必要があります。CRUSH マップの重みを手動で編集する場合は、以下を実行し、CRUSH バケットツリーがバケット内のリーフ OSD の合計を正確に反映するようにする必要があります。
osd crush reweight-all