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.
