OpenStack：CapacityWeigherは、Cinderスケジューラが選択するストレージプールにどのような影響を与えますか。

CapacityWeigherの仕組み

CapacityWeigherの仕組みをよりよく理解するには、次の情報が重要です。

1. Cinder Scheduler Weights の公式ドキュメントによると、次のようになります。

シンプロビジョニングの場合は、合計容量に最大オーバーサブスクリプション率を掛けて算出された仮想空き容量でホストの重量を測定し、プロビジョニングされた容量を差し引きます。

使用される式は、 total_capacity_gb x max_over_subscription_ratio -provisioned_capacity_gbです。

2. プロビジョニングされた容量は次のように定義されます（ Queenで導入されたプロビジョニングの改善から取得）。

ストレージアレイのプール内のすべてのボリュームが完全にフルである場合にCinderで使用されるストレージアレイのプールで使用される容量。

CapacityWeigherの動作例

上記のフォーラムと情報を使用して、Cinderスケジューラログから次のイベントを取得し、に含まれる値を使用して、各ストレージプールの重みがどのように決定されるかをよりよく理解できます。

Jul 26 21:10:40 xxx-cinder-api-container-3af405ad cinder-scheduler[34121]: 2022-07-26 21:10:40.353 34121 DEBUG cinder.scheduler.filter_scheduler [req-xxxx] Filtered [host 'xxx@xxx#vol01':free_capacity_gb: 10239.99, total_capacity_gb: 10240.0,allocated_capacity_gb: 0, max_over_subscription_ratio: 3.0,reserved_percentage: 0, provisioned_capacity_gb: 0,thin_provisioning_support: True, thick_provisioning_support: False,pools: None,updated at: 2022-07-26 21:10:30.459300, host 'xxx@xxx#vol02':free_capacity_gb: 10239.99, total_capacity_gb: 10240.0,allocated_capacity_gb: 0, max_over_subscription_ratio: 3.0,reserved_percentage: 0, provisioned_capacity_gb: 0,thin_provisioning_support: True, thick_provisioning_support: False,pools: None,updated at: 2022-07-26 21:10:30.459300, host 'xxx@xxx#vol03':free_capacity_gb: 26258.57, total_capacity_gb: 92160.0,allocated_capacity_gb: 90463, max_over_subscription_ratio: 3.0,reserved_percentage: 0, provisioned_capacity_gb: 90463,thin_provisioning_support: True, thick_provisioning_support: False,pools: None,updated at: 2022-07-26 21:10:30.459300, host 'xxx@xxx#vol04':free_capacity_gb: 2948.08, total_capacity_gb: 99804.03,allocated_capacity_gb: 99118, max_over_subscription_ratio: 3.0,reserved_percentage: 0, provisioned_capacity_gb: 99118,thin_provisioning_support: True, thick_provisioning_support: False,pools: None,updated at: 2022-07-26 21:10:30.459300] _get_weighted_candidates 

上記の場合、Cinderスケジューラで使用できるボリュームは次の4つです。

vol01：

free_capacity_gb: 10239.99

total_capacity_gb: 10240.0

allocated_capacity_gb: 0

max_over_subscription_ratio: 3.0

provisioned_capacity_gb: 0

vol02：

free_capacity_gb: 10239.99

total_capacity_gb: 10240.0

allocated_capacity_gb: 0

max_over_subscription_ratio: 3.0

provisioned_capacity_gb: 0

vol03：

free_capacity_gb: 26258.57

total_capacity_gb: 92160.0

allocated_capacity_gb: 90463

max_over_subscription_ratio: 3.0

provisioned_capacity_gb: 90463

vol04：

free_capacity_gb: 2948.08

total_capacity_gb: 99804.03

allocated_capacity_gb: 99118

max_over_subscription_ratio: 3.0

reserved_percentage: 0

provisioned_capacity_gb: 99118

 

上記のボリュームから、次のことがわかります。

• vol01とvol02は空です。  10TBの空きスペースがあります
• VOL03はかなり大きい。  26TBの空き容量があります。  合計容量は92TB
• vol04は もうすぐスペースが足りない  3TBの空き容量があります。  合計容量は 100TB

cinderボリュームのプロビジョニング時にvol04が選択されるため、スペースがほとんど不足していても、cinderスケジューラによってvol04が選択されます。

Jul 26 21:10:40 xxx-cinder-api-container-3af405ad cinder-scheduler[34121]: 2022-07-26 21:10:40.355 34121 DEBUG cinder.scheduler.host_manager [req-xxx] Weighed [WeighedHost [host: xxx@xxx#vol04, weight: 1.0], WeighedHost [host: xxx@xxx#vol03, weight: 0.9158061824185525], WeighedHost [host: xxx@xxx#vol01, weight: 0.0], WeighedHost [host: xxx@xxx#vol02, weight: 0.0]] get_weighed_backends 

これを理解するために、CapacityWeigherの計算（total_capacity_gb x max_over_subscription_ratio -provisioned_capacity_gb）を実行します。

vol01：

10240 x 3 - 0 = 30720

vol02：

10240 x 3 - 0 = 30720

vol03：

92160 x 3 - 90463 = 186017

vol04：

99804 x 3 - 99118 = 200294

 

上記の計算では、が total_capacity_gb より高い重量を駆動することがわかります。  他のボリュームの空き容量が大幅に増えても、vol04の重みが最も大きいままです。

vol03のサイズを大きくしたら?

vol03':free_capacity_gb: 36605.8, total_capacity_gb: 102400.0,allocated_capacity_gb: 90563, max_over_subscription_ratio: 3.0,reserved_percentage: 0, provisioned_capacity_gb: 90563

新しい大きなvol03を使用してウェイトを再計算します。

vol03：

102400 x 3 - 90563 = 216637

vol04：

99804 x 3 - 99113 = 200299

VOL03の重量が大きいことがわかりました。  その結果、これがストレージプールとして選択されます。

Jul 26 21:58:46 usw1infr001-cinder-api-container-3af405ad cinder-scheduler[34121]: 2022-07-26 21:58:46.259 34121 DEBUG cinder.scheduler.host_manager [req-xxx] Weighed [WeighedHost [host: xxx@xxx#vol03, weight: 1.0], WeighedHost [host: xxx@xxx#vol04, weight: 0.9121225600671266], WeighedHost [host: xxx@xxx#vol01, weight: 0.0], WeighedHost [host: xxx@xxx#vol02, weight: 0.0]] get_weighed_backends

 

max_over_subscription_ratio = auto

Cinder でCapacityWeigherの処理方法を調整できる設定可能なオプションがあり max_over_subscription_ratioます。  たとえば、 total_capacity_gb max_over_subscription_ratio = auto cinder.confで設定できるストレージプールよりも、すべて同じストレージプールを持つことができない場合があります。  シンプロビジョニング に関するドキュメントのオーバーサブスクリプションに従って、次の手順を実行します。

autoを使用すると max_over_subscription_ratio 、プロビジョニング済み容量と使用済みスペースに基づいてが自動的に計算されます。これにより、プールのライフサイクルの開始時に多数のボリュームを作成でき、空きスペースが0またはリザーブされた制限に近づくにつれて作成が制限され始めます。

重要なポイント/結論

1.  total_capacity_gb は CapacityWeigher計算の重要な要素です。
2. シンプロビジョニングボリュームを使用する場合、 free_capacity_gb は評価されません。
3. Cinderバックエンドの各バッキングストレージプール を類似したものに設定すること total_capacity_gb は、大容量のストレージプールがCinderスケジューラによって常に選択されるとは限りません。  上の例に示すように、ほぼフルの100TBボリュームともう1つの空の10TBボリュームを使用している場合、100TBのボリュームの重みは次の理由で引き続き高くなります。total_capacity_gb
4. 各ストレージプールのサイズを同じに設定できない場合は、の使用を検討して max_over_subscription_ratio = autoください。これにより max_over_subscription_ratio 、プロビジョニング済みの容量と使用済みスペースに基づいてCinderを調整できます。  これにより、  CapacityWeigherの計算が変更され、より小さなストレージプールを優先することができます。