1. 常用三个Filter的概述
AvailabilityZoneFilter: 按可用区过滤后端。
CapacityFilter: 基于卷后端的容量利用率的容量过滤器。
CapabilitiesFilter: 基于volume type中的extra specs(例如最常用的volume_backend_name)
除此三个常用的Filter外，还有DifferentBackendFilter，SameBackendFilter, DriverFilter, InstanceLocalityFilter, JsonFilter, RetryFilter等非常用Filter，如有需要，请自行了解。
AvailabilityZoneFilter很好理解，根据只选择给定的可用区内的后端，而一般不会单独设置可用区，所以基本上所有后端都能通过这个选择器，本文也不再详细讲述这个选择器。
2. CapacityFilter
简单来说就是容量选择器，在所有通过AvailabilityZoneFilter的后端中，根据容量来过滤出所有满足本次创建条件的后端。
注意这里是选择所有出满足本次创建的后端，千万不要和后续的Weigher作用搞混了，Weigher是从所有通过Filter里选出最优节点，可以是容量剩余最多的后端，可以是剩余容量百分比最多的后端等等。想了解weiger具体实现的，可以参考Weigher介绍
防坑指南1: 精简置备thin与超分比max_over_subscription_ratio
scheduler日志
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)
由上面日志信息可以看到hitachi_g30h_3_ssd已经不满足CapacityFilter而被过滤。
我们本次创建的容量是200G的磁盘，而我们查看这个后端的容量时发现该后端剩余容量高达400+T
产生这个问题的原因就是CapacityFilter不仅仅是单纯的根据后端剩余容量进行过滤，还有很多其余的规则，比如这里的provisioned ratio必须小于maximum over subscription ratio。
provisioned_ratio = (provisioned_capacity_gb + requested_size) / total
当创建一个磁盘时该后端provisioned_capacity_gb会增加，但由于存储可能是精简置备，所以allocated_capacity_gb存储实际分配的容量可能只分配一部分，甚至不分配。
所以当(provisioned_capacity_gb+本次请求的200G) / total 大于了我们设置的最大超分比max_over_subscription_ratio时，即使后端实际容量free_capacity_gb还有很多，这个后端也无法通过过滤，除非我们修改该后端的cinder配置将max_over_subscription_ratio调大，才可能继续在该后端继续创建，因为Filter需要provisioned_ratio小于max_over_subscription_ratio。
provisioned_capacity_gb 已置备的容量
allocated_capacity_gb 实际已分配的容量
free_capacity_gb 实际剩余的容量
max_over_subscription_ratio 超分比，用于精简置备存储，取值为1-20，当设置为1.0时表示不超分，即最多能够置备和存储的实际容量大小相同的容量给用户创建
防坑指南2: 预留容量reserved_percentage
scheduler日志
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)
从上面日志信息可以看到YZR2_HX_AZ1_SSD1#Pool0这个后端不满足本次请求的100G，而被CapacityFilter过滤。
我们查看这个后端的容量时发现该后端剩余容量free_capacity_gb还有5863G
产生这个问题的原因是我们设置了存储预留容量reserved_percentage为5。
因为很多存储在容量到达一定瓶颈时会影响性能，所以往往我们会设置一个预留容量以保证存储的安全使用。
而在这个问题中存储的总容量是135165，配置了保留容量5%，那就是需要保留135165*5%=6758, 但是实际还剩5863 5863已经比保留容量6758少了895。
该后端是Thick厚置备，所以不存在超分的问题，理论上这少的895G也是无法创建的，只是刚好截图的时候，已经人为在存储侧手动创建了块设备，导致容量实际使用容量多了895G。
3. CapabilitiesFilter
创建云硬盘类型(volume-type)时可以指定每个volume provider自己的特性Capabilities，比如thin provision(精简置备), hypermetro(双活)等等。
volume type 可以根据需要定义若干个 Capabilities ，详细描述 volume的属性。volume type 的作用与 nova 的flavor类似。
()[root@busybox-openstack-5fbfcd556c-q8lcq /]# cinder extra-specs-list
+--------------------------------------+------+----------------------------------+
| ID | Name | extra_specs |
+--------------------------------------+------+----------------------------------+
| d70437f4-fda6-4c43-9c59-6a2ffc11bab4 | hdd | {u'volume_backend_name': u'hdd'} |
+--------------------------------------+------+----------------------------------+
例如上面这个叫做hdd的云硬盘类型，只有一个叫做“volume_backend_name”的特性，这是最重要的也是必须的特性，这个值对应我们在为cinder配置多后端时，给每个后端存储设置的唯一的volume_backend_name。
CapabilitiesFilter会在通过CapacityFilter筛选出所有满足容量的后端中，根据特性筛选出指定后端，例如这里的volume_backend_name，其作用是为存储节点的volume provider 命名。这样 CapabilitiesFilter 就可以通过 volume type 的volume_backend_name 筛选出指定的 volume provider
在2 CapacityFilter介绍中提到的两个防坑指南中CapabilitiesFilter的筛选结果end均为0就是因为已经云硬盘类型设置的volume_backend_name 已经被CapacityFilter过滤了。文章来源：https://www.toymoban.com/news/detail-739092.html
()[root@busybox-openstack-5fbfcd556c-q8lcq /]# cinder extra-specs-list
+--------------------------------------+--------+--------------------------------------------+
| ID | Name | extra_specs |
+--------------------------------------+--------+--------------------------------------------+
| 7ea60657-661e-421e-8784-2bb78f0d93a5 | huawei | {u'capabilities:hypermetro': u'<is> true'} |
| d70437f4-fda6-4c43-9c59-6a2ffc11bab4 | hdd | {u'volume_backend_name': u'hdd'} |
+--------------------------------------+--------+--------------------------------------------+
再例如huawei这个云硬盘类型的capabilities:hypermetro=‘<is> true’，是标明这个云硬盘类型是要创建双活的后端存储。文章来源地址https://www.toymoban.com/news/detail-739092.html
到了这里，关于Cinder调度之Filter介绍的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
