Nova 调度器 filter 深度调优
默认 Nova 调度有 10+ filter，但大集群下默认配置往往不够。本文是我的调优实战记录。
调度流程
- 拉所有 hypervisor 列表
- 过 filter 链，每个 filter 排除一批
- 剩下的过 weigher，按权重排序
- 取 top 1（或前 N，从中随机选）
性能瓶颈：filter 链越长越慢。1000 节点集群默认配置，调度一次要 5+ 秒。
减 filter
不需要的 filter 直接删，比如：
[filter_scheduler]
enabled_filters = AvailabilityZoneFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter
我删掉的：
- RetryFilter：默认重试机制，集群正常时无用
- CoreFilter / RamFilter / DiskFilter：已被 PlacementFilter 取代（Ocata 之后）
- SameHostFilter / DifferentHostFilter：很少用到
- PciPassthroughFilter：没 GPU/PCI 场景删掉
Placement 是关键
Pike 之后 Nova 引入 Placement API，资源跟踪从 Nova-scheduler 移到 Placement service。优先用 Placement 而不是 filter 做资源筛选：
[scheduler]
query_placement_for_image_type_support = True
limit_tenants_to_placement_aggregate = True
Placement 查询是 SQL JOIN，10000 节点也是毫秒级，filter 是 Python 循环。
Weigher 调优
[filter_scheduler]
weight_classes = nova.scheduler.weights.all_weighers
ram_weight_multiplier = 1.0
disk_weight_multiplier = 0.5
io_ops_weight_multiplier = -2.0
build_failure_weight_multiplier = -1000000.0
实战意义：
- ram_weight_multiplier > 0：偏好 RAM 多的节点（spread 模式）
- < 0：偏好 RAM 少的节点（pack 模式，节省机器）
- build_failure_weight_multiplier 负超大：最近构建失败的节点强制避开
大集群必加：host subset size
[filter_scheduler]
host_subset_size = 5
调度时不取 top 1，而是从前 5 个里随机选。避免羊群效应——同时多个 VM 调度都选同一个最空节点，结果撞车。
监控
# scheduler 调度时间
grep "Scheduling decision" /var/log/nova/nova-scheduler.log | awk '{print $NF}'
# 失败率
grep NoValidHost /var/log/nova/nova-scheduler.log | wc -l
教训：1000 节点以上集群 nova-scheduler 跑得慢，第一步是看 Placement 有没有用上，filter 越少越好。