A VM scheduling policy is a resource orchestration policy based on which VM instances are assigned hosts to achieve the high performance and high availability of businesses.
Concepts
The VM scheduling policy involves the following key concepts:
ZStack Cloud provides four types of scheduling policies, and each policy can be executed based on two execution mechanisms. You can schedule a VM instance by associating it with different scheduling policies and execution mechanisms to meet the needs of different business scenarios.
Four types of VM scheduling policies: VM Exclusive from Each Other, VM Affinitive to Each Other, VMs Exclusive from Hosts, and VMs Affinitive to Hosts.
VM Exclusive from Each Other: VM instances in the same VM scheduling group should not/must not run on the same host.
VM Affinitive to Each Other: VM instances in the same VM scheduling group should/must run on the same host.
VMs Exclusive from Hosts: Given any one of the VM instances in a VM scheduling group and any one of the hosts in a host scheduling group, the VM instance should not/must not run the host.
VMs Affinitive to Hosts: Given any one of the VM instances in a VM scheduling group and any one of the hosts in a host scheduling group, the VM instance should/must run the host.
A VM scheduling policy can be executed based on either of the two execution mechanisms: Hard and Soft. Hard execution mechanism requires VM instances to strictly comply with their associated scheduling policies, while Soft execution mechanisms allows for some flexibility in policy execution when the hosts do not have sufficient resources.
Hard: VM instances are forcibly assigned to hosts based on the associated VM scheduling policies. For example, if you associate the VM Exclusive from Each Other policy with a VM scheduling group and select the Hard mechanism for the policy, any two of the VM instances in the scheduling group are not allowed to run on the same host. If no host is available to be scheduled based on the policy for a VM instance, the VM instance will end up failure upon startup.
Soft: VM instances are primarily assigned to hosts based on the associated VM scheduling policies. For example, if you associate the VM Exclusive from Each Other policy with a VM scheduling group and select the Soft mechanism for the policy, any two of the VM instances in the scheduling group will primarily not run on the same host. If no host is available to be scheduled based on the policy for a VM instance, the VM instance will attempt to run on a host that does not satisfy the policy.
A VM scheduling group is the basic unit for VM instances to associate with the VM scheduling policies.
A VM instance can only be added to one VM scheduling group. After the addition, the VM instance will be scheduled based on the associated scheduling policies.
A VM scheduling group can associate with one or more scheduling policies.
A scheduling policy can associate with one VM scheduling group.
Deleting a VM scheduling group also deletes its associated VM scheduling policies.
Host scheduling group is the basic unit for hosts to associate with host scheduling policies. You can use a host scheduling group when you select VMs Affinitive to Hosts or VMs Exclusive from Hosts policies.
A host can only be added to one host scheduling group. After the addition, the host will be scheduled based on the associated scheduling policies.
A host scheduling group can associate with one or more scheduling policies.
A scheduling policy can associate with one VM scheduling group.
Deleting a host scheduling group also deletes its associated VM scheduling policies.
Fundamentals
ZStack Cloud supports adding VM instances to a VM scheduling group, and executing a VM scheduling policy by associating a scheduling policy with the VM scheduling group.
If you associate a VM scheduling group with a VM Exclusive from Each Other or VM Affinitive to Each Other scheduling policy, you do not need to specify a host scheduling group, as the VM instance will be assigned to hosts based on the policy and execution mechanism.
If you associate a VM scheduling group with a VMs Affinitive to Hosts or VMs Exclusive from Hosts scheduling policy, you need to specify the corresponding host scheduling groups and the VM instance will be assigned to hosts based on the policy and execution mechanism.
In the following section, you will learn how the four scheduling policies work through four scenario illustrations.
Scenario 1: Assume that there are three hosts in the zone: Host1, Host2, and Host3. VM scheduling group A has been associated with the VM Exclusive from Each Other scheduling policy. VM1 and VM2 have joined VM scheduling group A and run on Host1 and Host2 respectively. In this setting, if you join VM3 to VM scheduling group A, the way how VM3 is scheduled under different execution mechanisms will be as follows:
Under the Hard execution mechanism, VM3 follows the policy of VM Exclusive from Each Other:
If Host3 has sufficient resources, VM3 can start and run normally on Host3.
If Host3 does not have sufficient resources, then VM3 cannot start.
Under the Soft execution mechanism, VM3 follows the policy of VM Exclusive from Each Other and first chooses to start on Host3:
If Host3 has sufficient resources, VM3 can start and run normally on Host3.
If Host3 does not have sufficient resources, VM3 tries to start on other host that has available resources. In this scenario, VM3 starts and runs on Host2.
Figure 1. VM Exclusive from Each Other (Hard/Soft)
Scenario 2: Assume that there are two hosts in the zone: Host1 and Host2. VM scheduling group A has been associated with the VM Affinitive to Each Other scheduling policy. VM1 and VM2 have joined VM scheduling group A and run on Host1. In this setting, if you join VM3 to VM scheduling group A, the way how VM3 is scheduled under different execution mechanisms will be as follows:
Under the Hard execution mechanism, VM3 follows the policy of VM Affinitive to Each Other:
If Host1 has sufficient resources, VM3 can start and run normally on Host1.
If Host1 does not have sufficient resources, VM3 cannot start.
Under the Soft execution mechanism, VM3 follows the policy of VM Affinitive to Each Other and first chooses to start on Host1:
If Host1 has sufficient resources, VM3 can start and run normally on Host1.
If Host3 does not have sufficient resources, VM3 tries to start on other host that has available resources. In this scenario, VM3 starts and runs on Host2.
Figure 2. VM Affinitive to Each Other (Hard/Soft)
Scenario 3: Assume that there are three hosts in the zone: Host1, Host2, and Host3. VM scheduling group A has been associated with the VMs Exclusive from Hosts scheduling policy. VM1 and VM2 have joined VM scheduling group A and run on Host1. Host scheduling group A has also been associated with the VMs Exclusive from Hosts scheduling policy. Host2 and Host3 have joined host scheduling group A, with each of these hosts running two VMs respectively. In this setting, if you join VM3 to VM scheduling group A, the way how VM3 is scheduled under different execution mechanisms will be as follows:
Under the Hard execution mechanism, VM3 and hosts in the host scheduling group A follow the policy of VMs Exclusive from Hosts:
If Host1 has sufficient resources, VM3 can start and run normally on Host1.
If Host1 does not have sufficient resources, VM3 cannot start.
Under the Soft execution mechanism, VM3 and hosts in the host scheduling group A follow the policy of VMs Exclusive from Hosts and VM3 first chooses to start on Host1:
If Host1 has sufficient resources, VM3 can start and run normally on Host1.
If Host1 does not have sufficient resources, VM3 tries to start on other host that has available resources. In this scenario, VM3 starts and runs on Host2.
Figure 3. VMs Exclusive from Hosts (Hard/Soft)
Scenario 4: Assume that there are three hosts in the zone: Host1, Host2, and Host3. VM scheduling group A has been associated with the VMs Affinitive to Hosts scheduling policy. VM1~VM5 have joined VM scheduling group A and run on Host2 and Host3 respectively. Host scheduling group A has also been associated with the VMs Affinitive to Hosts scheduling policy, and Host2 and Host3 have joined the host scheduling group A. In this setting, if you join VM6 to VM scheduling group A, the way how VM6 is scheduled under different execution mechanisms will be as follows:
Under the Hard execution mechanism, VM6 and hosts in the host scheduling group A follow the policy of VMs Affinitive to Hosts:
If Host2 or Host3 have sufficient resources, VM6 can start and run normally on Host2 or Host3.
If Host2 and Host3 do not have sufficient resources, VM6 cannot start.
Under the Soft execution mechanism, VM6 and hosts in the host scheduling group A follow the policy of VMs Affinitive to Hosts and VM6 first chooses to start on Host2 or Host3:
If Host2 or Host3 have sufficient resources, VM6 can start and run normally on Host2 or Host3.
If both Host2 and Host3 do not have sufficient resources, VM6 tries to start on other host that has available resources. In this scenario, VM6 starts and runs on Host1.
Figure 4. VMs Affinitive to Hosts (Hard/Soft)
Advantages
VM scheduling policy has the following advantages:
Comprehensive & Flexible:
ZStack Cloud provides four types of scheduling policies matched with two execution mechanisms to define mutual exclusion/affinity relationships between VM instances and between VM instances and hosts. Various scheduling policies can be flexibly combined to meet the needs of all mainstream business scenarios.
ZStack Cloud supports the association of one or more scheduling policies with multiple VM instances in the VM scheduling group, as well as the removal of these policies from the VM instances in the VM scheduling group, which is simple and efficient.
ZStack Cloud intuitively displays the VM scheduling status and provides quick conflict resolution operations to facilitate users to grasp business scheduling dynamics in real time and make timely adjustments.
Powerful & Reliable:
ZStack Cloud supports exclusion/affinity between the same/different businesses, achieving business isolation/efficient communication and ensuring high business performance and reliability.
You can flexibly configure the failure domains in VM businesses through host scheduling groups. ZStack Cloud supports single host deployment, batch hosts deployment within a single cluster, and cross-cluster hosts deployment to avoid single point of failure. This ensures business stability and improves physical resource utilization.
Use Cases
In the following part, we introduce some use cases for the VM Exclusive from Each Other (Hard/Soft) and VMs Affinitive to Hosts (Hard/Soft) scheduling policies.
VM Exclusive from Each Other (Hard):
In this case, we have two VM instances that run an active-backup database. The two VM instances are required to be deployed on different hosts to ensure business high availability.
Example: A user deploys two VMs for hosting a main and a backup MySQL database respectively, with a requirement that the two VM instances to be deployed on different hosts to minimize the risk of business downtime. Due to automatic deployment, the user does not know which hosts have available resources. At this point, the user can choose a VM Exclusive from Each Other (Hard) policy to ensure that the two VMs run on two different hosts, ensuring the business high availability.
VM Exclusive from Each Other (Soft):
In this case, we want the nodes with different roles in Hadoop to be spread across different hosts, so as to improve the overall system performance.
Example: When deploying a Hadoop system, the user cannot predict the total number of nodes for different roles such as namenode, datanode, jobtracker, tasktracker. However, it's clear that deploying these nodes on different hosts would enhance efficiency. The VM Exclusive from Each Other (Soft) policy can help distribute the Hadoop cluster across as many different hosts as possible, thereby alleviating I/O pressure and improving the overall system performance.
VMs Affinitive to Hosts (Hard):
In this case, we want to deploy the business VM instances on hosts with a specified CPU frequency, thereby ensuring the business stability.
Example: A user deploys four VM instances running important businesses and requires these VM intances run on the hosts that have a high CPU frequency. Given that there are limited hosts that can meet this CPU frequency requirement, the user can choose a VMs Affinitive to Hosts (Hard) policy to force these VM instances run on the specified hosts to ensure business stability.
VMs Affinitive to Hosts (Soft):
In this case, we want VM instances that run different businesses are deployed to hosts in the same rack as much as possible, so as to facilitate efficient communication between businesses.
Example: A user deploys four VM instances that run different businesses that require frequent intercommunication. In this case, minimizing the physical distance between the VM instances can significantly reduce communication latency. At this point, the user can choose a VMs Affinitive to Hosts (Soft) policy to deploy the VM instances on the specified hosts, thereby promoting efficient business intercommunication.
