1. Overview of three commonly used filters

AvailabilityZoneFilter: filter backend by availability zone.

CapacityFilter: a capacity filter based on the capacity utilization of the volume backend.

CapabilitiesFilter: Based on extra specs in volume type (for example, the most commonly used volume_backend_name)

In addition to the three commonly used filters, there are also very useful filters such as DifferentBackendFilter, samebackendfilter, driverfilter, instancelocalityfilter, jsonfilter and retryfilter. If you need to know, please learn about them yourself.

AvailabilityZoneFilter is well understood. Since only the backend in a given availability zone is selected, and generally the availability zone is not set separately, basically all backend can pass through this selector. This article will not describe this selector in detail.

2. CapacityFilter

To put it simply, it is a capacity selector. Among all back ends that pass the AvailabilityZoneFilter, all back ends that meet the conditions for this creation are filtered according to the capacity.

Note that this is to select all the backend that meet the requirements of this creation. Never confuse it with the role of weigher. Weigher is to select the best node from all the filters. It can be the backend with the largest capacity remaining, or the backend with the largest percentage of remaining capacity. To understand the specific implementation of weiger, please refer to Weigher introduction

Pit prevention guideline 1: simplify the preparation (thin) and the excess ratio (max)_ over_ subscription_ ratio

scheduler log

2022-07-26 17:38:45.796 1 WARNING cinder.scheduler.filters.capacity_filter [req-ac4d7108-eebd-402e-a1c2-8bf7e247034e] Insufficient free space for thin provisioning. The ratio of provisioned capacity over total capacity 1.15 has exceeded the maximum over subscription ratio 1.00 on host cinder-volume-worker@hitachi_g30h_3_ssd#hitachi_g30h_3_ssd.
2022-07-26 17:38:45.803 1 INFO cinder.scheduler.base_filter [req-ac4d7108-eebd-402e-a1c2-8bf7e247034e] Filtering removed all hosts for the request with volume ID 'f8482e0c-e80a-46bd-91c7-984ac3a5e017'.Filter results: AvailabilityZoneFilter: (start: 219, end: 219), CapacityFilter:(start: 219, end: 215), CapabilitiesFilter: (start: 215, end: 0)

From the above log information, you can see that Hitachi_ g30h_ 3_ The SSD has been filtered because it does not meet the CapacityFilter.
The capacity we created this time is 200G disk, and when we check the capacity of this backend, we find that the remaining capacity of this backend is as high as 400+T

The reason for this problem is that CapacityFilter not only filters based on the remaining capacity of the backend, but also has many other rules. For example, the provisioned ratio here must be less than the maximum over subscription ratio.

provisioned_ratio = (provisioned_capacity_gb + requested_size) / total

When creating a disk, the backend is provisioned_capacity_gb will increase, but the storage may be thin provisioning, so allocated_ capacity_ The capacity actually allocated for GB storage may be only partially allocated or even not allocated.
Therefore, when (provisioned_capacity_gb + 200g requested this time) / total is greater than the maximum super fraction ratio Max set by us_ over_ subscription_ Ratio, even if the actual capacity of the backend is free_ capacity_ There are many GB, and this backend cannot pass the Filter, unless we modify the cinder configuration of this backend to set max_ over_ subscription_ If the ratio is increased, it is possible to continue to create the Filter in the backend because the Filter needs to be provisioned_ratio is less than max_over_subscription_ratio.

provisioned_capacity_gb of prepared capacity
allocated_capacity_gb actual allocated capacity
free_capacity_gb actual remaining capacity
max_ over_ subscription_ The ratio is used to simplify the provision of storage. The value is 1-20. When it is set to 1.0, it means that there is no excess, that is, the capacity with the same actual capacity as the storage can be provided to the user to create

Pit Prevention Guide 2: reserved capacity_ percentage

scheduler log

2022-03-11 12:38:45.716 1 WARNING cinder.scheduler.filters.capacity_filter [req-cad3961a-38ab-40e8-963d-61066a4e415] Insufficient free space for volume creation on host cinder-volume-worker@YZR2_HX_AZ1_SSD1#Pool0 (requested / avail): 100/-895.0
2022-03-11 12:38:45.716 1 INFO cinder.scheduler.base_filter [req-cad3961a-38ab-40e8-963d-61066a4e415] Filtering removed all hosts for the request with volume ID '3752b19f-dd38-4625-a903-82c4f9ecc6c6'.Filter results: AvailabilityZoneFilter: (start: 33, end: 33), CapacityFilter:(start: 33, end: 32), CapabilitiesFilter: (start: 32, end: 0)

From the above log information, you can see that YZR2_ HX_ AZ1_ The backend ssd1 # pool0 does not meet the 100G of this request, but is filtered by CapacityFilter.
When we check the capacity of this backend, we find that the remaining capacity of this backend is free_capacity_gb and 5863G

The reason for this problem is that we set the reserved storage capacity_ The percentage is 5.
Because many storage will affect performance when the capacity reaches a certain bottleneck, we often set a reserved capacity to ensure the safe use of storage.
In this case, the total storage capacity is 135165, and 5% of the reserved capacity is configured, that is, 135165 * 5% = 6758 needs to be reserved. However, 5863 5863 is actually left, which is 895 less than the reserved capacity 6758.
The back-end is Thick, so there is no problem of over splitting. Theoretically, this small amount of 895G can not be created. Just when the screenshot is taken, the block device has been manually created on the storage side, resulting in an increase of 895G in the actual capacity.

3. CapabilitiesFilter

Replenish when free