O027、看nova-scheduler如何选择计算节点
本节重点介绍 nova-scheduler 的调度机制和实现方法：即解决如何选择在那个计算节点上启动 instance 的问题。
创建Instance 时，用户会提出资源需求，例如 CPU、内存、磁盘各需要多少。OpenStack 将这些需求定义在 flavor 中，用户只需要指定用哪个 flavor 就可以了。
我们可以在 Project -> Admin -> System -> Flavor 中查看可用的 flavor
Flavor 主要定义了 VCPU 、RAM 、DISK 和 metadata 这四类。nova-scheduler 会按照flavor 去选择合适的计算节点。VCPU、RAM、DISK 比较好理解，而Metadata 比较有意思，我们后面会讨论。
下面介绍 nova-scheduler 是如何实现调度的。在/etc/nova/nova.conf 中，nova 通过 scheduler_driver 、scheduler_available-filters 和 scheduler_default_filters 这三个参数来配置 nova-scheduler
stack@DevStack-Compute:~$ cat /etc/nova/nova.conf | grep sch
scheduler_default_filters = RetryFilter,AvailabilityZoneFilter,RamFilter,DiskFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter,SameHostFilter,DifferentHostFilter
scheduler_driver = filter_scheduler
Filter scheduler
Filter scheduler 是nova-scheduler 默认的调度器，调度过程分为两步：
1、通过过滤器（filter）选择满足条件的计算节点（运行 nova-compute）
2、通过权重计算（weighting）选择在最优（权重值最大）的计算节点上创建Instance
Nova 允许使用第三方 scheduler ，配置 scheduler_driver 即可。这又一次体现了OpenStack 的开放性。Scheduler 可以使用多个filter 一次进行过滤，过滤之后的节点在通过计算权重选出最合适的节点。
上图是调度过程的一个示例：
1、最开始有6个计算节点 Host1 - Host6
2、通过多个filter 层层过滤，Host2 和 Host4 没有通过
3、Host1、3、5、6 计算权重，结果Host5得分最高，最终入选
Filter
当Filter Scheduler 需要执行调度操作时，会让 filter 对计算节点进行判断，filter 返回 True 或 False 。nova.conf 中的scheduler_available_filters 选项用于配置 scheduler 可用的filter ，默认是所有nova自带的filter都可以用与过滤操作。
scheduler_available_filters = nova.scheduler.filters.all_filters
另外还有一个选项scheduler_default_filters ，用于指定scheduler真正使用的filter ，默认值如下
scheduler_default_filters = RetryFilter,AvailabilityZoneFilter,RamFilter,DiskFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter,SameHostFilter,DifferentHostFilter
scheduler 按照列表中的顺序依次过滤。下面依次介绍每个 filter
RetryFilter
RetryFilter 的作用是刷掉之前已经调度过的节点。
据个例子方便大家理解：假设ABC三个节点都通过了过滤，最终A因为权重值最大被选中执行操作。但由于某个原因，操作在A上失败了。默认情况下nova-scheduler 会重新执行过滤操作（重复次数由scheduler_max_attempts选项指定，默认是3）。那么这个时候 RetryFilter 就会将A直接刷掉，避免操作再次失败。RetryFilter 通常作为第一个filter。
AvailabilityZoneFilter
为提高容灾性和提供隔离服务，可以将计算节点划分到不同的 Availability Zone 中。例如把一个机架上的机器划分在一个 Availability Zone中。OpenStack 默认有一个命名为 Nova 的Availability Zone ，所有计算节点初始都是放在Nova 中。用户可根据需要创建自己的 Availability Zone。
创建 Instance 时，需要指定将 Instance 部署到哪个 Availability Zone中。
nova-scheduler 在做filtering 时，会使用 AvailabilityZoneFilter 将不属于指定 Availability Zone 的计算节点刷掉。
RamFilter
Ramfilter 将不能满足 flavor 内存需求的计算节点过滤掉。
对内存有一点需要注意：为了提高系统的资源使用率，OpenStack 在计算节点可用内存时允许 overcommit ，也就是可以超过实际内存大小。超过的程度是通过 nova.conf中 ram_allocation_ratio 这个参数来控制的，默认值为 1.5
其含义是：如果计算节点的内容为 10G ，OpenStack 则会认为他有 15G （10G * 1.5 ）内存
DiskFilter
DiskFilter 将不能满足flavor 磁盘需求的计算节点过滤掉。Disk 同样允许 overcommit ，通过 nova.conf 中 disk_allocation_ratio 控制，默认值为 1
CoreFilter
CoreFilter 将不能满足 flavor vCPU 需求的计算节点过滤掉。 vCPU 同样允许 overcommit ，通过 nova.conf 中 cpu_allocation_ratio 控制，默认值 16
这就意味着 一个 8 vCPU的计算节点，nova-scheduler 在调度时认为他有 128 个vCPU 。需要提醒的是，nova-scheduler 默认使用的 filter 并没有包含 CoreFilter 。如果要用，可以将 CoreFilter 添加到 nova.conf 的scheduler_default_filter 配置选项中
ComputeFilter
ComputeFilter 保证只有 nova-compute 服务正常工作的计算节点才能够被 nova-scheduler 调度，显然这是一个必选的 filter
ComputeCapabilitiesFilter
根据计算接地那的特性来筛选，这个比较高级，我们举例说明。
假如我们的节点有 x86_64 和 ARM 架构，如果想将 Instance 指定部署到 x86_64 架构的节点上，就可以利用这个过滤器，还记得flavor 中有个 Metadata吗，Compute 的 Capabilities 就在 Metadata 中指定。
如果没有指定 设置 Metadata ，这个过滤器不会起作用，所有节点都会通过。
下面是Metadatalist 和 创建 Instance时选择 Metadata的界面
ServerGroupAntiAffinityFilter
这个过滤器可以尽量将 Instance 分散部署到不同的节点上。
例如有 inst1 inst2 inst3 三个instance ，计算节点有ABC，为保证分散部署，进行如下操作：
1、创建一个 anti-affinity 策略的 server group “group-1”
nova server-group-create --policy anti-affinity group-1
请注意，这里的server group 其实是instance group，并不是计算节点的 group
2、依次创建 instance inst1、inst2、inst3 并放到group-1中
nova boot --image IMAGE_ID --flavor 1 --hint group=group-1 inst1
nova boot --image IMAGE_ID --flavor 1 --hint group=group-1 inst2
nova boot --image IMAGE_ID --flavor 1 --hint group=group-1 inst3
因为group-1的策略是 Antiaffinity ,调度时ServerGroupAntiAffinityFilter 会将 inst1 、inst2、inst3 部署到不同计算节点 ABC 上。
创建 instance 时如果没有指定 server group ，改所有计算节点会直接通过该过滤器
ServerGroupAffinityFilter
与ServerGroupAntiAffinityFilter 正好相反，该过滤器会尽量将 instance 部署到同一个计算节点上。方法与ServerGroupAntiAffinityFilter 类似
nova server-group-create --policy affinity group-2
nova boot --image IMAGE_ID --flavor 1 --hint group=group-2 inst1
nova boot --image IMAGE_ID --flavor 1 --hint group=group-2 inst2
nova boot --image IMAGE_ID --flavor 1 --hint group=group-2 inst3
Weight
经过前面一堆的过滤器，nova-scheduler 选出了能够部署 instance 的计算节点。如果有多个计算节点通过了过滤器，那么最终会选择哪个节点呢？
Scheduler 会对每个计算节点打分，得分最高的获胜。打分的过程就是weight，翻译过来就是计算权重值，那么 Scheduler 是根据什么来计算权重值呢？
目前 nova-scheduler 的默认实现是根据计算节点空闲的内存量计算权重值：内存空闲越多，权重就越大，instance 将部署到当前空闲内存最多的计算节点上。
日志
是时候完整的回顾一下 nova-scheduler 的工作过程了。整个过程都被记录到 nova-scheduler 的日志文件中。比如当我们部署一个 instance 时打开 nova-scheduler 的日志 /opt/stack/logs/n-sch.log （非 DevStack 安装的话，日志在 /var/log/nova/scheduler.log）
日志显示初始有两个host（在我们的实验环境中就是 DevStack-Controller 和 DevStack-Compute），依次经过9个过滤器，两个节点都通过了，那么接下来就是weight了。可以看出因为 DevStack-Controller 的空闲内存比较多，权重值就大，最终会选在在 DevStack-Controller 上创建instance
注意：要显示 debug日志，需要在配置文件中打开debug选项。
nova-scheduler 就是这些内容了，比较灵活，也比较复杂。
