跳转到主内容

Openstack：CapacityWeigher 如何影响 Cinder 调度程序选择哪个存储池？

  1. 最后更新
  2. 另存为PDF
Views:
60
Visibility:
Public
Votes:
1
Category:
openstack
Specialty:
virt
Last Updated:

适用于

OpenStack

回答

当有多个精简配置的存储池可用时，Cinder 驱动程序利用 CapacityWeigher 来确定要配置到哪个存储池。 

  • CapacityWeigher 的工作原理

为了更好地了解 CapacityWeigher 的工作原理，以下信息是关键：

  1. 根据 Cinder Scheduler Weights 官方文档：

对于精简配置，按虚拟空闲容量对主机进行加权，虚拟空闲容量通过总容量乘以最大超额订阅比率并减去已配置容量来计算

使用的公式是： total_capacity_gb x max_over_subscription_ratio - provisioned_capacity_gb

  1. 调配的容量定义如下（取自 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 调度程序使用：

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 几乎用尽了空间。  有 3 TB 可用。  总容量为 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=auto

有一个可配置的选项，允许 Cinder 调整 CapacityWeigher 处理 max_over_subscription_ratio 的方式。  例如，如果您无法拥有所有相同 total_capacity_gb 的存储池，那么您可以在 cinder.conf 中配置  max_over_subscription_ratio = 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 计算，并可以开始偏向较小的存储池。 

追加信息

网络研讨会：Cinder Scheduler 揭秘

NetApp provides no representations or warranties regarding the accuracy or reliability or serviceability of any information or recommendations provided in this publication or with respect to any results that may be obtained by the use of the information or observance of any recommendations provided herein. The information in this document is distributed AS IS and the use of this information or the implementation of any recommendations or techniques herein is a customer's responsibility and depends on the customer's ability to evaluate and integrate them into the customer's operational environment. This document and the information contained herein may be used solely in connection with the NetApp products discussed in this document.