See Nova-scheduler How to choose a compute node-5 minutes a day to play with OpenStack (27)

This section focuses on the scheduling mechanism and implementation of Nova-scheduler, which solves the problem of choosing which compute node to start instance on.

When you create a Instance, users ask for resource requirements, such as CPU, memory, and how much disk each needs.
OpenStack defines these requirements in flavor, and the user only needs to specify which flavor to use.

The available flavor are managed in system->flavors.

Flavor mainly defines the four categories of Vcpu,ram,disk and Metadata.
Nova-scheduler will follow flavor to select the appropriate compute node.
Vcpu,ram,disk better understand, and metatdata more interesting, we will discuss in detail later.

The following describes how Nova-scheduler is implemented.

In/etc/nova/nova.conf, Nova is configured by the three parameters of Scheduler_driver,scheduler_available_filters and Scheduler_default_filters Nova-scheduler.

Filter Scheduler

Filter Scheduler is the default scheduler for Nova-scheduler, and the scheduling process is divided into two steps:

1. Select a compute node that satisfies the criteria (run Nova-compute) via filter
2. By weighting calculation (weighting), you select Create Instance on the compute nodes that are optimal (the maximum weight value).

Scheduler_driver=nova.scheduler.filter_scheduler. Filterscheduler

Nova allows the use of third-party scheduler to configure Scheduler_driver.
This once again embodies the openness of OpenStack.

The Scheduler can be filtered in turn using multiple filters, and the filtered nodes are then selected by calculating the weights to select the most suitable node.

is an example of a scheduling process:

1. There are 6 compute nodes at the beginning Host1-host6
2. Filtered through multiple filter layers, Host2 and Host4 did not pass and were brushed off
3. Host1,host3,host5,host6 calculate weight, result Host5 score highest, final selected

Filter

When the filter scheduler needs to perform a dispatch operation, the filter is asked to determine the compute node, and filter returns True or False.

The scheduler_available_filters option in nova.conf is used to configure the scheduler available filter, which, by default, can be used for filtering by all Nova's own filter.

Scheduler_available_filters = Nova.scheduler.filters.all_filters

There is also an option scheduler_default_filters, which specifies the filter that the scheduler really uses, the default values are as follows

Scheduler_default_filters = Retryfilter, Availabilityzonefilter, Ramfilter,
Diskfilter, Computefilter, Computecapabilitiesfilter, Imagepropertiesfilter,
Servergroupantiaffinityfilter, Servergroupaffinityfilter

Filter Scheduler is filtered in the order of the list.
Each filter is described in turn below.

Retryfilter

The role of Retryfilter is to brush out previously scheduled nodes.

Let's take a quick example to understand:
Assuming that the a,b,c three nodes are filtered, finally a is selected to perform the action because of the maximum weight value.
But for some reason, the operation failed on a.
By default, Nova-scheduler will re-perform the filtering operation (the number of repetitions is specified by the scheduler_max_attempts option, which defaults to 3).
Then Retryfilter will brush A directly off, to avoid the operation failed again.
Retryfilter is usually used as the first filter.

Availabilityzonefilter

To improve disaster tolerance and provide isolation services, compute nodes can be partitioned into different availability zones.

For example, a machine in a rack is divided into a availability Zone.
OpenStack defaults to a availability Zone named "Nova", where all compute nodes are initially placed in "Nova".
Users can create their own availability Zone as needed.

When creating Instance, you need to specify which Instance to deploy to in which availability zone.

When Nova-scheduler is doing filtering, it uses availabilityzonefilter to filter out compute nodes that are not part of the specified availability Zone.

Ramfilter

Ramfilter will not be able to meet the flavor memory requirements of the compute nodes filtered out.

For memory there is a point to note:
To increase the system's resource utilization, OpenStack allows OVERCOMMIT to compute the available memory for the node, which can exceed the actual memory size.
The degree of exceeding is controlled by ram_allocation_ratio this parameter in nova.conf, the default value is 1.5

Ram_allocation_ratio = 1.5

The implication is that if the memory of the compute node is 10gb,openstack it will be considered to have 15GB (10*1.5) of memory.

Diskfilter

Diskfilter will not be able to meet the flavor disk requirements of the compute nodes filtered out.

Disk also allows Overcommit, via Disk_allocation_ratio control in nova.conf, with a default value of 1

Disk_allocation_ratio = 1.0

Corefilter

Corefilter will not be able to meet the flavor Vcpus need to filter out the compute nodes.

Vcpus also allows Overcommit, with Cpu_allocation_ratio control in nova.conf, with a default value of 16

Cpu_allocation_ratio = 16.0

This means that a compute node of 8 Vcpus, Nova-scheduler at the time of dispatch, considers it to have 128 Vcpus.
What you need to be reminded of:
Nova-scheduler the filter used by default does not contain Corefilter.
If you want to use it, you can add Corefilter to the nova.conf scheduler_default_filters configuration option.

Computefilter

The computefilter guarantees that only compute nodes that are nova-compute services can be nova-scheduler dispatched.
Computefilter is obviously a must-choose filter.

Computecapabilitiesfilter

Computecapabilitiesfilter is filtered according to the characteristics of the compute nodes.

This is more advanced, we illustrate.
For example, our nodes have x86_64 and ARM architectures, and if you want to assign Instance to a node in the x86_64 architecture, you can take advantage of computecapabilitiesfilter.

Remember there is a Metadata in the flavor, Compute capabilitie S is in the Metadata designation.

"Compute Host Capabilities" lists all the settings that can be capabilities.

By clicking "+" after "Architecture", you can specify a specific schema in the list on the right.

When configured, Computecapabilitiesfilter will only filter out x86_64 nodes when scheduling.
If Metadata,computecapabilitiesfilter is not set, all nodes will be filtered.

Imagepropertiesfilter

Imagepropertiesfilter filters the matching compute nodes based on the properties of the selected image.
Similar to flavor, image has metadata, which is used to specify its properties.

For example, if you want an image to run on a KVM hypervisor only, you can specify it with the "hypervisor Type" property.

Click "+", then select "KVM" in the list on the right.

Once configured, the Imagepropertiesfilter will only filter the KVM nodes when scheduling.
If the metadata,imagepropertiesfilter of the Image is not set, all nodes will be filtered.

Servergroupantiaffinityfilter

Servergroupantiaffinityfilter can deploy Instance to different nodes as much as possible.

For example, there are inst1,inst2 and inst3 three instance, compute nodes are a, B, and C.
To ensure decentralized deployment, do the following:

1. Create a anti-affinity policy for the server group "Group-1"

Nova Server-group-create–policy anti-affinity group-1

Note that the server group here is actually the instance group, not the Compute node group.

1. Create Instance, and put Inst1, Inst2, and Inst3 in 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

Because Group-1 's strategy is antiaffinity, Servergroupantiaffinityfilter will deploy Inst1, Inst2, and inst3 to different compute nodes A, B, and C when scheduled.

Currently, you can only specify the server group in the CLI to create instance.

When you create instance, the server Group,servergroupantiaffinityfilter is passed directly without any filtering.

Servergroupaffinityfilter

As opposed to Servergroupantiaffinityfilter, Servergroupaffinityfilter will deploy instance to the same compute node as much as possible.
Method is similar

1. Create a affinity policy for the server group "Group-2"

Nova Server-group-create–policy Affinity Group-2

1. Create instance, and put Inst1, Inst2, and Inst3 in 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

Because Group-2 's strategy is Affinity, Servergroupaffinityfilter will deploy Inst1, Inst2, and inst3 to the same compute node when scheduled.

When you create instance, the server Group,servergroupaffinityfilter is passed directly without any filtering.

Weight

After filtering the previous stack of filters, Nova-scheduler selected compute nodes capable of deploying instance.
If more than one compute node passes the filter, which node is ultimately selected?

Scheduler will score each compute node with the highest score wins.
The process of scoring is weight, translation comes to calculate the weight value, then scheduler is based on what to calculate the weight value?

The default implementation of Nova-scheduler currently calculates the weight value based on the amount of memory idle by the COMPUTE nodes:
The more free memory, the greater the weight, the instance will be deployed to the compute nodes that currently have the most free memory.

Log

It's time to take a complete look back at the Nova-scheduler work process.
The entire process is recorded in the Nova-scheduler log.
Like when we deploy a instance,

Open Nova-scheduler Log/opt/stack/logs/n-sch.log (not devstack install its log in/var/log/nova/scheduler.log)

The log shows the initial two hosts (Devstack-controller and devstack-compute1 in our experimental environment), followed by a filter of 9 filter (Retryfilter, Availabilityzonefilter, Ramfilter,
Diskfilter, Computefilter, Computecapabilitiesfilter, Imagepropertiesfilter,
Servergroupantiaffinityfilter, Servergroupaffinityfilter), two compute nodes have passed.

Then it's time to weight the following:

You can see that because Devstack-controller has more free memory than devstack-compute1 (7466 > 3434), the weight value is large (1.0 > 0.4599), and finally Devstack-controller is selected.

Note: To display the debug log, you need to open the debug option in/etc/nova/nova.conf

[DEFAULT]
debug = True

Nova-scheduler is the content, slightly more complex ha (because of flexibility), we can digest this two days.

We discuss nova-compute in the next section.

See Nova-scheduler How to choose a compute node-5 minutes a day to play with OpenStack (27)