Openstack：CapacityWeigher 如何影响 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 调度程序使用：

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。

尽管 vol04 的空间已经所剩无几，Cinder 调度程序仍然会在 Cinder 卷配置期间选择它：

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=自动

有一个可配置选项，允许 Cinder 调整 CapacityWeigher 的处理方式max_over_subscription_ratio。  例如，如果您无法拥有所有相同total_capacity_gb，然后你可以配置max_over_subscription_ratio = auto在 cinder.conf 中。  根据精简配置文档中的“超额订阅”部分：

当使用 auto 时，Cinder 将自动计算max_over_subscription_ratio根据已配置容量和已用空间。这允许在池生命周期开始时创建大量卷，并在可用空间接近 0 或预留限制时开始限制创建。

要点/结论

1.  total_capacity_gb 是 CapacityWeigher 计算中的一个重要因素，
2. 在使用精简配置卷时，free_capacity_gb未评估
3. 配置每个 Cinder 后端的后备存储池具有类似的total_capacity_gb这可能是确保 Cinder 调度程序不会总是选择较大的存储池的一个重要因素。  如上例所示，当使用一个几乎已满的 100TB 卷和另一个空的 10TB 卷时，100TB 卷将继续具有更高的权重，因为total_capacity_gb
4. 如果无法将每个存储池的大小设置为相同，请考虑使用max_over_subscription_ratio = auto。这使得 Cinder 能够调整max_over_subscription_ratio根据预置容量和已用空间。  这将改变 CapacityWeigher 的计算方式，并开始优先选择较小的存储池。