Document navigation

What is VM Scheduling Policy?

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.

Functions

Create a VM Scheduling Policy

On the main menu of ZStack Cloud, choose Resource Center > Resource Pool > Resource Service > VM Scheduling Policy. On the VM Scheduling Policy page, click Create VM Scheduling Policy. Then, the Create VM Scheduling Policy page is displayed.

The following lists the four VM scheduling policy creation scenarios:
  • Create VM Exclusive from Each Other Scheduling Policy
  • Create VM Affinitive to Each Other Scheduling Policy
  • Create VMs Exclusive from Hosts Scheduling Policy
  • Create VMs Affinitive to Hosts Scheduling Policy

Create VM Exclusive from Each Other Scheduling Policy

On the displayed page, set the following parameters:
  • Name: Enter a name for the VM scheduling policy.
  • Description: Optional. Enter a description for the VM scheduling policy.
  • Type: Select VM Exclusive from Each Other.
  • Execution Mechanism: The following two mechanisms are provided:
    • Hard: VM instances are forcibly assigned to hosts based on the VM Exclusive from Each Other policy. VM instances in the same VM scheduling group must 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 end up failure upon startup.
    • Soft: VM instances are primarily assigned to hosts based on the VM Exclusive from Each Other policy. If possible, VM instances in the same VM scheduling group should 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 while has sufficient resources.
  • Associate VM Scheduling Group: You can associate a VM scheduling policy with a new or existing VM scheduling group. After the association, the policy takes effect on all VM instances in the VM scheduling group:
    • Existing: Associate the VM scheduling policy with an existing VM scheduling group.
      • VM Scheduling Group: Select an existing VM scheduling group.
    • Create: Create a new VM scheduling group.
      • VM Scheduling Group Name: Enter a name for the VM scheduling group.
      • VM Instance: Select one or more VM instances to add to the scheduling group.
Figure 5. Create VM Scheduling Policy


Create VM Affinitive to Each Other Scheduling Policy

On the displayed page, set the following parameters:
  • Name: Enter a name for the VM scheduling policy.
  • Description: Optional. Enter a description for the VM scheduling policy.
  • Type: Select VM Affinitive to Each Other.
  • Execution Mechanism: The following two mechanisms are provided:
    • Hard: VM instances are forcibly assigned to hosts based on the VM Affinitive to Each Other policy. VM instances in the same VM scheduling group must 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 VM Affinitive to Each Other policy. If possible, VM instances in the same VM scheduling group should 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 while has sufficient resources.
  • Associate VM Scheduling Group: You can associate a VM scheduling policy with a new or existing VM scheduling group. After the association, the policy takes effect on all VM instances in the scheduling group:
    • Existing: Associate the VM scheduling policy with an existing VM scheduling group.
      • VM Scheduling Group: Select an existing VM scheduling group.
    • Create: Create a new VM scheduling group.
      • VM Scheduling Group Name: Enter a name for the VM scheduling group.
      • VM Instance: Select one or more VM instances to add to the scheduling group.
Figure 6. Create VM Scheduling Policy


Create VMs Exclusive from Hosts Scheduling Policy

On the displayed page, set the following parameters:
  • Name: Enter a name for the VM scheduling policy.
  • Description: Optional. Enter a description for the VM scheduling policy.
  • Type: Select VMs Exclusive from Hosts.
  • Execution Mechanism: The following two mechanisms are provided:
    • Hard: VM instances are forcibly assigned to hosts based on the VMs Exclusive from Hosts policy. 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 must not run the 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 VMs Exclusive from Hosts policy. 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 run the host if possible. 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 while has sufficient resources.
  • Associate VM Scheduling Group: You can associate a VM scheduling policy with a new or existing VM scheduling group. After the association, the policy takes effect on all VM instances in the scheduling group:
    • Existing: Associate the VM scheduling policy with an existing VM scheduling group.
      • VM Scheduling Group: Select an existing VM scheduling group.
    • Create: Create a new VM scheduling group.
      • VM Scheduling Group Name: Enter a name for the VM scheduling group.
      • VM Instance: Select one or more VM instances to add to the scheduling group.
  • Associate Host Scheduling Group: You can associate a VM scheduling policy with a new or existing host scheduling group. After the association, the policy takes effect on all hosts in the scheduling group:
    • Existing: Associate the VM scheduling policy with an existing host scheduling group.
      • Host Scheduling Group: Select an existing host scheduling group.
    • Create: Create a new host scheduling group.
      • Host Scheduling Group Name: Enter a name for the host scheduling group.
      • Host: Select one or more hosts to add to the scheduling group.
Figure 7. Create VM Scheduling Policy


Create VMs Affinitive to Hosts Scheduling Policy

On the displayed page, set the following parameters:
  • Name: Enter a name for the VM scheduling policy.
  • Description: Optional. Enter a description for the VM scheduling policy.
  • Type: Select VMs Affinitive to Hosts.
  • Execution Mechanism: The following two mechanisms are provided:
    • Hard: VM instances are forcibly assigned to hosts based on the VMs Affinitive to Hosts policy. A VM instance in a VM scheduling group must run on a host in a host scheduling group. 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 VMs Affinitive to Hosts policy. A VM instance in a VM scheduling group should run on a host in a host scheduling group if possible. 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 while has sufficient resources.
  • Associate VM Scheduling Group: You can associate a VM scheduling policy with a new or existing VM scheduling group. After the association, the policy takes effect on all VM instances in the scheduling group:
    • Existing: Associate the VM scheduling policy with an existing VM scheduling group.
      • VM Scheduling Group: Select an existing VM scheduling group.
    • Create: Create a new VM scheduling group.
      • VM Scheduling Group Name: Enter a name for the VM scheduling group.
      • VM Instance: Select one or more VM instances to add to the scheduling group.
  • Associate Host Scheduling Group: You can associate a VM scheduling policy with a new or existing host scheduling group. After the association, the policy takes effect on all hosts in the scheduling group:
    • Existing: Associate the VM scheduling policy with an existing host scheduling group.
      • Host Scheduling Group: Select an existing host scheduling group.
    • Create: Create a new host scheduling group.
      • Host Scheduling Group Name: Enter a name for the host scheduling group.
      • Host: Select one or more hosts to add to the scheduling group.
Figure 8. Create VM Scheduling Policy


Manage a VM Scheduling Policy

On the main menu of ZStack Cloud, choose Resource Center > Resource Pool > Resource Service > VM Scheduling Policy. Then, the VM Scheduling Policy is displayed.

You can perform the following actions on a VM scheduling policy.
Action Description
Create VM Scheduling Policy Create a VM scheduling policy.
Edit VM Scheduling Policy Edit the name and description of a VM scheduling policy.
Enable VM Scheduling Policy Enable a disabled VM scheduling policy.
Disable VM Scheduling Policy Disable an enabled VM scheduling policy.
Note: If you disable a VM scheduling policy, the associated VM instances will not be scheduled based on the policy.
Change Execution Mechanism Changes the execution mechanism of a VM scheduling policy. Two mechanisms are provided: Hard and Soft.
Delete VM Scheduling Policy Delete a VM scheduling policy.
Note: If you delete a VM scheduling policy, the associated VM instances will not be scheduled based on the policy.

Associated Resource of VM Scheduling Policy

On the main menu of ZStack Cloud, choose Resource Center > Resource Pool > Resource Service > VM Scheduling Policy. Then, the VM Scheduling Policy page is displayed.

Create a VM Scheduling Group

On the main menu of ZStack Cloud, choose Resource Center > Resource Pool > Resource Service > VM Scheduling Policy > VM Scheduling Group. On the VM Scheduling Group page, click Create VM Scheduling Group. Then, the Create VM Scheduling Group page is displayed.

On the displayed page, set the following parameters:
  • Name: Enter a name for the VM scheduling group.
  • Description: Optional. Enter a description for the VM scheduling group.
  • VM Instance: Select one or more VM instances to add to the scheduling group.
Figure 9. Create VM Scheduling Group


Manage a VM Scheduling Group

On the main menu of ZStack Cloud, choose Resource Center > Resource Pool > Resource Service > VM Scheduling Policy > VM Scheduling Group. Then, the VM Scheduling Group page is displayed.

The following table lists the actions that you can perform on a VM scheduling group.
Action Description
Create VM Scheduling Group Create a VM scheduling group.
Edit VM Scheduling Group Edit the name and description of a VM scheduling group.
Add VM Instance Add one or more VM instances to a VM scheduling group.
Note: After the addition, the scheduling policies associated with the group take effect on the VM instances immediately.
Remove VM Instance Remove one or more VM instances from a VM scheduling group.
Note: After the removal, the VM instances will no longer be scheduled based on scheduling policies associated with the group.
Delete VM Scheduling Group Delete a VM scheduling group.
Note: If you delete a VM scheduling group, VM scheduling policies associated with the group will also be deleted.

Create a Host Scheduling Group

On the main menu of ZStack Cloud, choose Resource Center > Resource Pool > Resource Service > VM Scheduling Policy > Host Scheduling Group. On the Host Scheduling Group page, click Create Host Scheduling Group. Then, the Create Host Scheduling Group page is displayed.

On the displayed page, set the following parameters:
  • Name: Enter a name for the host scheduling group.
  • Description: Optional. Enter a description for the host scheduling group.
  • Host: Select one or more hosts to add to the scheduling group.
Figure 10. Create Host Scheduling Group


Manage a Host Scheduling Group

On the main menu of ZStack Cloud, choose Resource Center > Resource Pool > Resource Service > VM Scheduling Policy > Host Scheduling Group. Then, the Host Scheduling Group page is displayed.

The following table lists the actions that you can perform on a host scheduling group.
Action Description
Create Host Scheduling Group Create a host scheduling group.
Edit Host Scheduling Group Edit the name and description of a host scheduling group.
Add Host Add one or more hosts to a host scheduling group.
Note: After the addition, the scheduling policies associated with the group take effect on the hosts immediately.
Remove Host Remove one or more hosts from a host scheduling group.
Note: After the removal, the hosts will no longer be scheduled based on scheduling policies associated with the group.
Delete Host Scheduling Group Delete a host scheduling group.
Note: If you delete a host scheduling group, VM scheduling policies associated with the group will also be deleted.

VM Scheduling Policy Practice

VM Exclusive from Each Other (Soft)

About this task

In this practice, you will learn how to use a VM Exclusive from Each Other (Soft) scheduling policy.

Assume that in a zone, a user intends to deploy three business VM instances and prefers these VM instances run separately on three different hosts as much as possible.

To run this practice, follow these steps:
  1. Create three business VM instances.
  2. Create a VM Exclusive from Each Other (Soft) scheduling policy.
  3. Check whether the three business VM instances are deployed on different hosts when conditions allow.

Procedure

  1. Create three business VM instances.

    On the main menu of ZStack Cloud, choose Resource Center > Resource Pool > Virtual Resource > VM Instance. Then, the VM Instance page is displayed, and you can then batch create three VM instances by fast creation. For more information, see Create a VM Instance (Fast Creation).

  2. Create a VM Exclusive from Each Other (Soft) scheduling policy.

    On the main menu of ZStack Cloud, choose Resource Center > Resource Pool > Resource Service > VM Scheduling Policy. Then, the VM Scheduling Policy page is displayed. Click Create VM Scheduling Policy and the Create VM Scheduling Policy page is displayed.

    On the displayed page, set the following parameters:
    • Name: Enter a name for the VM scheduling policy.
    • Description: Optional. Enter a description for the VM scheduling policy.
    • Type: Select VM Exclusive from Each Other.
    • Execution Mechanism: Supports the mechanisms of Hard and Soft. Here we choose Soft.
      • Hard: VM instances are forcibly assigned to hosts based on the VM Exclusive from Each Other policy. VM instances in the same VM scheduling group must 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 end up failure upon startup.
      • Soft: VM instances are primarily assigned to hosts based on the VM Exclusive from Each Other policy. If possible, VM instances in the same VM scheduling group should 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 while has sufficient resources.
    • Associate VM Scheduling Group: You can associate a VM scheduling policy with a new or existing VM scheduling group. After the association, the policy takes effect on all VM instances in the scheduling group. Here we create a new scheduling group and associate it with the three VM instances created on step1.
      • Existing: Associate the VM scheduling policy with an existing VM scheduling group.
        • VM Scheduling Group: Select an existing VM scheduling group.
      • Create: Create a new VM scheduling group.
        • VM Scheduling Group Name: Enter a name for the VM scheduling group.
        • VM Instance: Select one or more VM instances to add to the scheduling group. Here we add the preceding three VM instances to the scheduling group.
    Figure 11. Create VM Exclusive from Each Other (Soft)


  3. Check whether the three business VM instances are deployed on different hosts when conditions allow.

    On the Overview tab of the VM scheduling group, you can see that the three business VM instances are deployed on three different hosts. This means the VM Exclusive from Each Other (Soft) scheduling policy takes effect.

    Figure 12. Verify Effectiveness of VM Exclusive from Each Other (Soft)


VM Exclusive from Each Other (Hard)

About this task

In this practice, you will learn how to use a VM Exclusive from Each Other (Hard) scheduling policy.

Assume that in a zone, a user intends to deploy three business VM instances and prefers these VM instances are forcibly assigned to three different hosts.

To run this practice, follow these steps:
  1. Create three business VM instances.
  2. Create a VM Exclusive from Each Other (Hard) scheduling policy.
  3. Check whether the three business VM instances are forcibly deployed on three different hosts.

Procedure

  1. Create three business VM instances.

    On the main menu of ZStack Cloud, choose Resource Center > Resource Pool > Virtual Resource > VM Instance. Then, the VM Instance page is displayed, and you can batch create three VM instances by fast creation. For more information, see Create a VM Instance (Fast Creation).

  2. Create a VM Exclusive from Each Other (Hard) scheduling policy.

    On the main menu of ZStack Cloud, choose Resource Center > Resource Pool > Resource Service > VM Scheduling Policy. Then, the VM Scheduling Policy page is displayed. Click Create VM Scheduling Policy, and then the Create VM Scheduling Policy page is displayed.

    On the displayed page, set the following parameters:
    • Name: Enter a name for the VM scheduling policy.
    • Description: Optional. Enter a description for the VM scheduling policy.
    • Type: Select VM Exclusive from Each Other.
    • Execution Mechanism: Supports the mechanisms of Hard and Soft. Here we choose Hard.
      • Hard: VM instances are forcibly assigned to hosts based on the VM Exclusive from Each Other policy. VM instances in the same VM scheduling group must 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 end up failure upon startup.
      • Soft: VM instances are primarily assigned to hosts based on the VM Exclusive from Each Other policy. If possible, VM instances in the same VM scheduling group should 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 while has sufficient resources.
    • Associate VM Scheduling Group: You can associate a VM scheduling policy with a new or existing VM scheduling group. After the association, the policy takes effect on all VM instances in the scheduling group. Here we create a new scheduling group and associate it with VM instances.
      • Existing: Associate the VM scheduling policy with an existing VM scheduling group.
        • VM Scheduling Group: Select an existing VM scheduling group.
      • Create: Create a new VM scheduling group.
        • VM Scheduling Group Name: Enter a name for the VM scheduling group.
        • VM Instance: Select one or more VM instances to add to the scheduling group. Here we add the preceding three VM instances to the scheduling group.
    Figure 13. Create VM Exclusive from Each Other (Hard)


  3. Check whether the three business VM instances are forcibly deployed on three different hosts.

    On the Overview tab of the VM scheduling group, you can see that the three VM instances are forcibly deployed on three different hosts. This means the VM Exclusive from Each Other (Hard) scheduling policy takes effect.

    Figure 14. Verify Effectiveness of VM Exclusive from Each Other (Hard)


VMs Affinitive to Hosts (Soft)

About this task

In this practice, you will learn how to use a VMs Affinitive to Hosts (Soft) scheduling policy.

Assume that in a zone, a user intends to deploy three business VM instances and prefers these VM instances are deployed on the specified Host1 and Host2 as much as possible.

To run this practice, follow these steps:
  1. Create three business VM instances.
  2. Create a VMs Affinitive to Hosts (Soft) scheduling policy.
  3. Check whether the three business VM instances are deployed on the specified two hosts.

Procedure

  1. Create three business VM instances.

    On the main menu of ZStack Cloud, choose Resource Center > Resource Pool > Virtual Resource > VM Instance. Then, the VM Instance page is displayed, and you can batch create three VM instances by fast creation. For more information, see Create a VM Instance (Fast Creation).

  2. Create a VMs Affinitive to Hosts (Soft) scheduling policy.

    On the main menu of ZStack Cloud, choose Resource Center > Resource Pool > Resource Service > VM Scheduling Policy. Then, the VM Scheduling Policy page is displayed. Click Create VM Scheduling Policy, and then the Create VM Scheduling Policy page is displayed.

    On the displayed page, set the following parameters:
    • Name: Enter a name for the VM scheduling policy.
    • Description: Optional. Enter a description for the VM scheduling policy.
    • Type: Select VMs Affinitive to Hosts.
    • Execution Mechanism: Supports the mechanisms of Hard and Soft. Here we choose Soft.
      • Hard: VM instances are forcibly assigned to hosts based on the VM Exclusive from Each Other policy. VM instances in the same VM scheduling group must 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 end up failure upon startup.
      • Soft: VM instances are primarily assigned to hosts based on the VM Exclusive from Each Other policy. If possible, VM instances in the same VM scheduling group should 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 while has sufficient resources.
    • Associate VM Scheduling Group: You can associate a VM scheduling policy with a new or existing VM scheduling group. After the association, the policy takes effect on all VM instances in the scheduling group. Here we create a new scheduling group and associate it with VM instances.
      • Existing: Associate VMs with a existing VM scheduling group.
        • VM Scheduling Group: Choose a existing VM scheduling group.
      • Create: Create a new VM scheduling group.
        • VM Scheduling Group Name: Set the name of the VM scheduling group.
        • VM Instance: Add one or more VM instances to this scheduling group. Here we add the preceding three VM instances.
    • Associate Host Scheduling Group: You can associate a VM scheduling policy with a new or existing host scheduling groups. Here we choose to create a new host scheduling group. After the association, the policy takes effect on all hosts in the scheduling group.
      • Existing: Associate a VM scheduling policy with a existing host scheduling group.
        • Host Scheduling Group: Choose an existing host scheduling group.
      • Create: Create a new host scheduling group.
        • Name: Enter a name for the host scheduling group.
        • Host: Add one or more hosts to this scheduling group. Here we add Host1 and Host2.
    Figure 15. Create VMs Affinitive to Hosts (Soft)


  3. Check whether the three business VM instances are deployed on the specified two hosts.

    On the Overview tab of the VM scheduling group, you can see that the three VM instances are deployed on Host1 and Host2. This means the VMs Affinitive to Hosts (Soft) scheduling policy takes effect.

    Figure 16. Verify Effectiveness of VMs Affinitive to Hosts (Soft)


VMs Affinitive to Hosts (Hard)

About this task

In this practice, you will learn how to use a VMs Affinitive to Hosts (Hard) scheduling policy.

Assume that in a zone, a user intends to deploy three business VM instances and prefers these VM instances are forcibly assigned to Host1 and Host2.

To run this practice, follow these steps:
  1. Create three business VM instances.
  2. Create a VMs Affinitive to Hosts (Hard) scheduling policy.
  3. Check whether the three business VM instances are deployed on the specified two hosts.

Procedure

  1. Create three business VM instances.

    On the main menu of ZStack Cloud, choose Resource Center > Resource Pool > Virtual Resource > VM Instance. Then, the VM Instance page is displayed, and you can batch create three VM instances by fast creation. For more information, see Create a VM Instance (Fast Creation).

  2. Create a VMs Affinitive to Hosts (Hard) scheduling policy.

    On the main menu of ZStack Cloud, choose Resource Center > Resource Pool > Resource Service > VM Scheduling Policy. Then, the VM Scheduling Policy page is displayed. Click Create VM Scheduling Policy, and then the Create VM Scheduling Policy page is displayed.

    On the displayed page, set the following parameters:
    • Name: Enter a name for the VM scheduling policy.
    • Description: Optional. Enter a description for the VM scheduling policy.
    • Type: Select VMs Affinitive to Hosts.
    • Execution Mechanism: Supports the mechanisms of Hard and Soft. Here we choose Hard.
      • Hard: VM instances are forcibly assigned to hosts based on the VM Exclusive from Each Other policy. VM instances in the same VM scheduling group must 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 end up failure upon startup.
      • Soft: VM instances are primarily assigned to hosts based on the VM Exclusive from Each Other policy. If possible, VM instances in the same VM scheduling group should 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 while has sufficient resources.
    • Associate VM Scheduling Group: You can associate a VM scheduling policy with a new or existing VM scheduling group. Here we create a new one and associate it with VMs. After the association, the policy takes effect on all VM instances in the scheduling group.
      • Existing: Associate VMs with a existing VM scheduling group.
        • VM Scheduling Group: Choose an existing VM scheduling group.
      • Create: Create a new VM scheduling group.
        • VM Scheduling Group Name: Enter a name for the VM scheduling group.
        • VM Instance: Select one or more VM instances to add to the scheduling group. Here we add the preceding three VM instances to the scheduling group.
    • Associate Host Scheduling Group: You can associate a VM scheduling policy with a new or existing host scheduling groups. Here we choose to create a new host scheduling group. After the association, the policy takes effect on all hosts in the scheduling group.
      • Existing: Associate a VM scheduling policy with an existing host scheduling group.
        • Host Scheduling Group: Choose an existing host scheduling group.
      • Create: Create a new host scheduling group.
        • Name: Enter a name for the host scheduling group.
        • Host: Add one or more hosts to this scheduling group. Here we add Host1 and Host2.
    Figure 17. Create VMs Affinitive to Hosts (Hard)


  3. Check whether the three business VM instances are deployed on the specified two hosts.

    On the Overview tab of the VM scheduling group, you can see that the three VM instances are deployed on Host1 and Host2. This means the VMs Affinitive to Hosts (Soft) scheduling policy takes effect.

Glossary

Instance

An instance is a virtual machine or server that runs the images of operating systems in Cloud, such as VM instance and elastic baremetal instance.

VM Instance

A VM instance is a virtual machine instance running on a host. A VM instance has its own IP address and can access public networks and run application services.

Volume

A volume provides storage space for a VM instance. Volumes are categorized into root volumes and data volumes.

Root Volume

A root volume provides support for the system operations of a VM instance.

Data Volume

A data volume provides extended storage space for a VM instance.

Image

An image is a template file used to create a VM instance or volume. Images are categorized into system images and volume images.

Instance Offering

An instance offering defines the number of vCPU cores, memory size, network bandwidth, and other configuration settings of VM instances.

Disk Offering

A disk offering defines the capacity and other configuration settings of volumes.

GPU Specification

A GPU specification defines the frame per second (FPS), video memory, resolution, and other configuration settings of a physical or virtual GPU. GPU specifications are categorized into physical GPU specifications and virtual GPU specifications.

vNUMA Configuration

vNUMA uses CPU pinning to passthrough the topology of associated host physical NUMA (pNUMA) nodes to a VM instance, generating a topology of virtual NUMA (vNUMA) nodes for the VM instance. This topology enables a vCPU on a vNUMA node to primarily access the local memory and thus improves VM performance.

NUMA (Non-Uniform Memory Access)

Non-uniform memory access (NUMA) is a computer memory design where the memory access time depends on the memory location relative to the CPU. Under NUMA, a processor can access its own local memory faster than non-local memory and thus improves VM performance.

pNUMA Node (physical NUMA Node)

A pNUMA node (physical NUMA node) is a host NUMA node predefined based on the host NUMA architecture. It is used to manage the CPUs and memory of the host.

pNUMA Topology (physical NUMA Topology)

A pNUMA topology (physical NUMA topology) is the topology of the host NUMA nodes predefined by the CPU vendor based on the host NUMA architecture.

vNUMA Node (virtual NUMA Node)

A vNUMA node (virtual NUMA node) is generated by passing-through associated pNUMA nodes via CPU pinning. It is used to manage the CPUs and memory of a VM instance.

vNUMA Topology (virtual NUMA Topology)

A vNUMA topology (virtual NUMA topology) is the topology of VM NUMA nodes generated by passing-through associated pNUMA nodes via CPU pinning.

Local Memory

Local memory is the memory that a CPU (pCPU or vCPU) accesses through the Uncore iMC (Integrated Memory Controller) of the same NUMA (pNUMA or vNUMA) node. Compared with accessing non-local memory, accessing local memory has lower latencies.

CPU Pinning

CPU pinning assigns the virtual CPUs (vCPUs) of a VM instance to specific physical CPUs (pCPUs) of the host, which improves VM performance.

EmulatorPin Configuration

EmulatorPin assigns all other threads than virtual CPU (vCPU) threads and IO threads of a VM instance to physical CPUs (pCPUs) of the host so that these threads run on assigned pCPUs.

Auto-Scaling Group

An auto-scaling group is a group of VM instances that are used for the same scenarios. An auto-scaling group can automatically scale out or in based on application workloads or health status of VM instances in the group.

Snapshot

A snapshot is a point-in-time capture of data status in a volume.

Affinity Group

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.

Zone

A zone is a logical group of resources such as clusters, L2 networks, and primary storage. Zone is the largest resource scope defined in the Cloud.

Cluster

A cluster is a logical group of hosts (compute nodes).

Host

A host provides compute, network, and storage resources for VM instances.

Primary Storage

A primary storage is one or more servers that store volume files of VM instances. These files include root volume snapshots, data volume snapshots, image caches, root volumes, and data volumes.

Image Storage

An image storage is a storage server that stores VM image templates, including ISO image files.

iSCSI Storage

iSCSI storage is an SAN storage that uses the iSCSI protocol for data transmission. You can add an iSCSI SAN block as a Shared Block primary storage or pass through the block to a VM instance.

FC Storage

FC storage is an SAN storage that uses the FC technology for data transmission. You can add an FC SAN block as a Shared Block primary storage or pass through the block to a VM instance.

NVMe Storage

A type of storage implemented via the NVMe-oF (NVMe over fabrics) protocol. You can add a block device configured from an NVMe storage as SharedBlock primary storage.

L2 Network

An L2 network is a layer 2 broadcast domain used for layer 2 isolation. Generally, L2 networks are identified by names of devices on the physical network.

VXLAN Pool

A VXLAN pool is a collection of VXLAN networks established based on VXLAN Tunnel Endpoints (VTEPs). The VNI of each VXLAN network in a VXLAN pool must be unique.

L3 Network

An L3 network includes IP ranges, gateway, DNS, and other network configurations that are used by VM instances.

Public Network

Generally, a public network is a logical network that is connected to the Internet. However, in an environment that has no access to the Internet, you can also create a public network.

Flat Network

A flat network is connected to the network where the host is located and has direct access to the Internet. VM instances in a flat network can access public networks by using elastic IP addresses.

VPC Network

A VPC network is a private network where VM instances can be created. A VM instance in a VPC network can access the Internet through a VPC vRouter.

Management Network

A management network is used to manage physical resources in the Cloud. For example, you can create a management network to manage access to hosts, primary storage, image storage, and VPC vRouters.

Flow Network

A flow network is a dedicated network for port mirror transmission. You can use a flow network to transmit the mirrors of data packets of NIC ports to the target ports.

VPC vRouter

A VPC vRouter is a dedicated VM instance that provides multiple network services.

VPC vRouter HA Group

A VPC vRouter HA group consists of two VPC vRouters. Either VPC vRouter can be a primary or secondary VPC vRouter for the group. If the primary VPC vRouter does not work as expected, the VPC vRouter becomes the secondary VPC vRouter in the group to ensure high availability of business.

vRouter Image

A vRouter image encapsulates network services and can be used to create VPC vRouters.

Dedicated-Performance LB Image

A dedicated-performance load balancer (LB) image encapsulates dedicated-performance load-balancing services and can be used to create load balancer instances. However, a dedicated-performance load balancer image cannot be used to create VM instances.

vRouter Offering

A vRouter offering defines the number of vCPU cores, memory size, image, management network, and public network configuration settings of VPC vRouters. You can use a vRouter offering to create VPC vRouters that can provide network services for public networks and VPC networks.

LB Instance Offering

A load balancer (LB) instance offering defines the CPU, memory, image, and management network configuration settings used to create LB instances. LB instances provide load balancing services for the public network, flat network, and VPC network.

SDN Controller

The SDN controller is the core of the SDN architecture, responsible for centralized management and control of network devices.

SDN Cluster

A cluster of dedicated VM instances designed to provide highly available SDN capabilities.

SDN Instance

A dedicated VM instance designed to provide SDN network capabilities.

SDN Image

An SDN image encapsulates an SDN software and can be used to create SDN instances.

SDN Instance Offering

An SDN instance offering defines the CPU, memory, SDN image, and management network configuration used for creating SDN instances.

Security Group

A security group provides security control services for VM NICs. It filters the ingress or egress TCP, UDP, and ICMP packets of VM NICs based on the specified security rules.

VIP

In bridged network environments, a virtual IP address (VIP) provides network services such as serving as an elastic IP address (EIP), port forwarding, load balancing, IPsec tunneling. When a VIP provides the preceding network services, packets are sent to the VIP and then routed to the destination network where VM instances are located.

EIP

An elastic IP address (EIP) functions based on the NAT technology. IP addresses in a private network are translated into an EIP that is in another network. This way, private networks can be accessed from other networks by using EIPs.

Port Forwarding

Port forwarding functions based on the layer-3 forwarding service of VPC vRouters. This service forwards traffic flows of the specified IP addresses and ports in a public network to specified ports of VM instances by using the specified protocol. If your public IP addresses are insufficient, you can configure port forwarding for multiple VM instances by using one public IP address and port.

Load Balancer

A load balancer distributes traffic flows of a virtual IP address to backend servers. It automatically inspects the availability of backend servers and isolates unavailable servers during traffic distribution. This way, the load balancer improves the availability and service capability of your business.

Listener

A listener monitors the frontend requests of a load balancer and distributes the requests to a backend server based on the specified policy. In addition, the listener performs health checks on backend servers.

Forwarding Rule

A forwarding rule forwards the requests from different domain names or URLs to different backend server groups.

Backend Server Group

A backend server group is a group of backend servers that handles requests distributed by load balancers. It is the basic unit for traffic distribution by load balancer instances.

Backend Server

A backend server handles requests distributed by a load balancer. You can add a VM instance on the Cloud or a server on a third-party cloud as a backend server.

Frontend Network

A frontend network is a type of network that is associated with a load balancer. Requests from the network are distributed by the load balancer to backend servers based on a specified policy.

Backend Network

A backend network is a type of network that is associated with a load balancer. Requests from frontend networks are distributed by the load balancer to servers in the backend network.

Load Balancer Instance

A load balancer instance is a custom VM instance used to provide load balancing services.

Certificate

If you select HTTPS for a listener, associate it with a certificate to make the listener take effect. You can upload either a certificate or certificate chain.

Firewall

A firewall is an access control policy that monitors ingress and egress traffic of VPC vRouters and decides whether to allow or block specific traffic based on the associated rule sets and rules.

Firewall Rule Set

A firewall rule set is a set of rules that a firewall uses to defend against network attacks. You need to associate a rule set with the egress or ingress flow direction of VPC vRouter NICs to make the rule set take effect.

Firewall Rule

A firewall rule is an access control entry associated with the egress or ingress flow direction of VPC vRouter NICs to defend against network attacks. A firewall rule includes rule priority, match condition, and behavior.

Rule Template

A rule template is a template that you can select when you add rules to a rule set or a firewall.

IP/Port Set

An IP or port set is a set of IP addresses or ports that you can select when you add rules to a rule set or a firewall.

IPsec Tunnel

An IPSec tunnel encrypts and verifies IP packets that transmit over a virtual private network (VPN) from one site to another.

OSPF Area

An Open Shortest Path First (OSPF) area is divided from an autonomous system based on the OSPF protocol. This simplifies the hierarchical management of vRouters.

NetFlow

A NetFlow monitors the ingress and egress traffic of the NICs of VPC vRouters. The supported versions of data flows are V5 and V9.

Port Mirroring

Port mirroring mirrors the traffic data of VM NICs and sends the traffic data to the target ports. This allows for the analysis of data packets of ports and simplifies the monitoring and management of data traffic and makes it easier to locate network errors and exceptions.

Route Table

A route table contains information about various routes that you configure. Route entries in a route table must include the destination network, next hop, and route priority.

CloudFormation

CloudFormation is a service that simplifies the management of cloud resources and automates deployment and O&S. You can create a stack template to configure cloud resources and their dependencies. This way, resources can be automatically configured and deployed in batches. CloudFormation provides easy management of the lifecycle of cloud resources and integrates automatic O&S into API and SDK.

Resource Stack

A resource stack is a stack of resources that are configured by using a stack template. The resources in the stack have dependencies with each other. You can manage resources in the stack by managing the resource stack.

Stack Template

A stack template is a UTF8-encoded file based on which you can create resource stacks. The stack template defines the resources that you want, the dependencies between the resources, and the configuration settings of the resources. When you use a stack template to create a resource stack, CloudFormation parses the template and the resources are automatically created and configured.

Sample Template

A sample template is a commonly used resource stack. You can use a sample template provide by the Cloud to create resource stacks.

Designer

A designer is a CloudFormation tool that allows you to orchestrate cloud resources. You can drag and drop resources on a canvas and use lines to establish dependencies between the resources.

Baremetal Cluster

A baremetal cluster consists of baremetal chassis. You can manage baremetal chassis by managing a baremetal cluster where the chassis reside.

Deployment Server

A deployment server is a server that provides PXE service and console proxy service for baremetal chassis.

Baremetal Chassis

A baremetal chassis is used to create a baremetal instance and is identified based on the BMC interface and IPMI configuration setting.

Preconfigured Template

A preconfigured template is used to create a preconfigured file that allows for unattended batch installation of an operating system for baremetal instances.

Baremetal Instance

A baremetal instance is an instantiated baremetal chassis.

Elastic Baremetal Management

Elastic Baremetal Management provides dedicated physical servers for your applications to ensure high performance and stability. In addition, this feature allows elastic scaling. You can apply for and scale resources based on your needs.

Provision Network

A provision network is a dedicated network for PXE boot and image downloads while creating elastic baremetal instances in a gateway proxy cluster.

Elastic Baremetal Cluster

Provides a separated cluster to manage baremetal nodes.

Gateway Node

A gateway node is a node where the ingress and egress traffic of the Cloud and elastic baremetal instances in gateway proxy clusters is forwarded.

Baremetal Node

A baremetal node is used to create a baremetal instance and is identified based on the BMC interface and IPMI configuration setting.

Elastic Baremetal Instance

An elastic baremetal instance has the same performance as physical servers and allows elastic scaling. You can apply for and scale resources based on your needs.

Elastic Baremetal Offering

An elastic baremetal offering defines the number of vCPU cores, memory size, CPU architecture, CPU model, and other configuration settings of elastic baremetal instances.

vCenter

The Cloud allows you to take over vCenter and manage resources on the vCenter.

VM Instance

A VM instance is an ESXi virtual machine instance running on a host. A VM instance has its own IP address to access public networks and can run application services.

Network

A vCenter network defines the network settings of VM instances on vCenter, such as IP range, gateway, DNS, and network services.

Volume

A volume provides storage space for a VM instance on vCenter. A volume attached to a VM instance can be used as a root volume or data volume. A root volume provides support for the system operations of a VM instance. A data volume provides extended storage space for a VM instance.

Image

An image is a template file used to create a VM instance or volume on vCenter. Images are categorized into system images and volume images.

Event Message

Event Message displays event alarm messages of vCenter that is took over by the Cloud. This feature allows you to locate errors and exceptions efficiently.

Network Topology

A network topology visualizes the network architecture of the Cloud. It allows for efficient planning, management, and improvement of network architecture. Network topologies can be categorized into global topologies and custom topologies.

Performance Analysis

Performance Analysis displays the performance metrics of key resources monitored externally or internally in the Cloud. You can view the performance analysis or export the analysis report as needed to improve the O&M efficiency.

Capacity Management

Capacity Management visualizes the capacities and usages of key resources in the Cloud. You can use this feature to improve O&S efficiency.

MN Monitoring

Management Node (MN) monitoring allows you to view the health status of each management node when you use multiple management nodes to achieve high availability.

Alarm

An alarm is used to monitor the status of time-series data and events and respond to the status change. Alarms can be categorized into resource alarm, event alarm, and extended alarm.

One-Click Alarm

A one-click alarm integrates multiple metrics of a resource. You can create one-click alarms for multiple resources to monitor these resources.

Alarm Template

An alarm template is a template of alarm rules. If you associate an alarm template with a resource group, an alarm is created to monitor the resources in the group.

Resource Group

A resource group consists of resources grouped based on your business needs. If you associate an alarm template with a resource group, the alarm rules specified by the template take effect on all the resources in the group.

Message Template

A message template specifies the text template of a resource alarm message or event alarm message sent to an SNS system.

Message Source

A message source is used to take over extended alarm messages. If you configure alarms for message sources, extended alarm messages can be sent to various endpoints.

Endpoint

An endpoint is a method that users obtain subscribed messages. Endpoints are categorized into system endpoints, email, DingTalk, HTTP application, short message service, and Microsoft Teams.

Alarm Message

An alarm message is a message sent the time when an alarm is triggered.

Current Task

A current task is an ongoing operation performed in the Cloud. You can perform centralized management over ongoing operations.

Operation Log

An operation log is a chronological record of operations on the specified objects and their operation results.

Audit

Audit monitors and records all activities on the Cloud. You can use this feature to implement operation tracking, cybersecurity classified protection compliance, security analysis, troubleshooting, and automatic O&M.

Log Collection

Allows you to collect with one click the log data from the Cloud and various nodes on the Cloud generated in the specified time period and download the log data.

One-Click Inspection

Comprehensively inspects the health status of key resources and services of the Cloud and scores their healthiness based on the inspection results. In addition, the one-click inspection service provides O&M suggestions and inspection reports.

Backup Management

Backup management integrates multiple disaster recovery technologies such as incremental backup and full backup that are suitable for multiple business scenarios. You can implement local backup and remote backup based on your business needs.

Backup Job

You can create a backup job to back up local VM instances, volumes, or databases to a specified storage server on a regular basis.

Local Backup Data

Local backup data of VM instances, volumes, and databases is stored in the local backup server.

Local Backup Server

A local backup server is located at the local data center and is used to store local backup data.

Remote Backup Server

A remote backup server is located at a remote data center or a public cloud and is used to store remote backup data.

Continuous Data Protection (CDP)

Continuous Data Protection (CDP) provides second-level and fine-grained continuous backups for important business systems in VM instances, allowing users to restore VM data to a specific time state, and retrieve files without restoring the system.

CDP Task

You can create a CDP task to continuously back up your VM data to a specified backup server to achieve continuous data protection and recovery.

CDP Data

The backup data generated from continuous data protection on VM instances is stored in local backup servers.

Recovery Point

A recovery point is a data point generated during continuous data protection. A recovery point corresponds to a data record within the recovery point interval specified by the user.

Locked Recovery Point

You can lock or unlock a recovery point as needed. After a recovery point is locked, data of the recovery point will not be automatically cleared or deleted.

Recovery Task

A recovery task helps you quickly restore data by specifying a CDP task and recovery point, and allows you to view the recovery progress and logs in a more friendly way.

Cryptography Security Compliance

The Cryptography Security Compliance service provides applications with cloud security capabilities based on commercial cryptography, meeting the requirements of commercial cryptography application security assessments.

HSM Pool

An HSM pool is a logical group of hardware security modules (HSMs) and is used to provide unified cryptography services such as signature validation and encryption.

HSM

A hardware security module (HSM) is a dedicated device that encrypts, decrypts, and authenticates information by using the cryptographic technology.

Platform Cryptography Security Compliance

Enables the Cloud to meet the requirements of Cryptography Security Compliance through the cryptography capabilities provided by HSM pools.

Certificate Login

Authenticates the identity of a user by using a UKey device.

Data Protection

Protects important data on the Cloud to ensure the data confidentiality and integrity.

Scheduled Job

A scheduled job defines that a specific action be implemented at a specified time based on a scheduler.

Scheduler

A scheduler is used to schedule jobs. It is suitable for business scenarios that last for a long time.

Tag

A tag is used to mark resources. You can use a tag to search for and aggregate resources.

Migration Service

The Cloud provides V2V migration service that allows you to migrate VM instances and data from other virtualized platform to the current cloud platform.

ZMigrate Migration Service

A migration service installed from Application Market that migrates VM instances and their data from VMware environments to the current cloud platform.

V2V Migration

V2V Migration allows you to migrate VM instances from the VMware or KVM platform to the current cloud platform.

V2V Conversion Host

A V2V conversion host is a host in the destination cluster that you need to specify during V2V migration to cache VM instances and data when you implement V2V migration. After the VM instances and data are cached in the V2Vconversion host, they are migrated to the destination primary storage.

User

A user is a natural person that constructs the most basic unit in Tenant Management.

User Group

A user group is a collection of natural persons or a collection of project members. You can use a user group to grant permissions.

Role

A role is a collection of permissions that can be granted to users. A user that assumes a role can call API operations based on the permissions specified by the role. Roles are categorized into platform roles and project roles.

Single Sign-On

The Single Sign-On service provided by the Cloud. It supports seamless access to SSO systems. Through the service, related users can directly log in to the Cloud and manage cloud resources.

Project

A project is a task that needs to be accomplished by specific personnel at a specified time. In Tenant Management, you can plan resources at the project granularity and allocate an independent resource pool to a project. The word Tenant in Tenant Management mainly refers to projects. A project is a tenant.

Project Member

A project member is a member in a project who is granted permissions on specific project resources and can use the resources to accomplish tasks. Project members include the project admin, project managers, and normal project members.

Process Management

Process management is part of ticket management that manages the processes related to the resources of projects. Processes can be categorized into default processes and custom processes.

My Approvals

In the Cloud, only the administrator and project administrators are granted approval permissions. the administrator and project administrators can approve or reject a ticket. If a ticket is approved, resources are automatically deployed and allocated to the specified project.

Bills

A bill is the expense of resources totaled at a specified time period. Billing is accurate to the second. Bills can be categorized into project bills, department bills, and account bills.

Pricing List

A pricing list is a list of unit prices of different resources. The unit price of a resource is set based on the specification and usage time of the resource.

Console Proxy

Console proxy allows you to log in to a VM instance by using the IP address of a proxy.

AccessKey Management

An AccessKey pair is a security credential that one party authorizes another party to call API operations and access its resources in the Cloud. AccessKey pairs shall be kept confidential.

IP Allowlist/Blocklist

An IP allowlist or blocklist identifies and filters IP addresses that access the Cloud. You can create an IP allowlist or blocklist to improve access control of the Cloud.

Application Center

Application Market allows you to add applications to the Cloud and then access the applications with one click. It extends the functionality of the Cloud. You can add default applications through the built-in installation package or add more applications through URLs.

Sub-Account Management

A sub-account can be created by the admin or synced from an SSO authentication system and is managed by the admin. Resources created under a sub-account are managed by the sub-account.

Theme and Appearance

You can customize the theme and appearance of the Cloud.

Email Server

If you select Email as the endpoint of an alarm, you need to set an email server. Then alarm messages are sent to the email server.

Log Server

A log server is used to collect management node logs or the platform operation logs. You can add a log server to the cloud and use the collected logs for operation trace or troubleshooting. This makes your O&M more efficient.

Global Setting

Global Setting allows you to configure settings that take effect on the whole platform.

Scenario Template

Scenario Template provides multiple templates that encapsulate scenario-based global settings. You can apply a template globally with one click based on your business needs. This improves your O&M efficiency.

HA Policy

HA Policy is a mechanism that ensures sustained and stable running of the business if VM instances are unexpectedly stopped or are errored because of errors occurring to compute, network, or storage resources associated with the VM instances. By enabling this feature, you can customize VM HA policies to ensure your business continuity and stability.

Time Management

Manages the Cloud system time and allows you to configure time servers for the Cloud. After you configure NTP time servers for the Cloud, the clock of the time servers is synced with all nodes of the Cloud.

GPU Device

A GPU device is a powerful microprocessor with high computational capabilities. You can use a GPU device to handle intricate graphics rendering and parallel computing jobs, thus improving the efficiency of businesses such as graphic production, video processing, and machine learning.

Script Library

The script library stores and manages script files centrally. By executing scripts on VM instances, you can complete complex O&M operations and automated jobs.

XML Hook

An XML Hook is a script that can flexibly insert or modify parameters in XML files of VM instances. By attaching an XML Hook to a VM instance, you can customize VM configurations and enable specialized functionalities.

Container Service

A simple and user-friendly container management service, providing features like GPU management & scheduling, multi-tenancy, multi-cluster, quota configuration, CI/CD. and microservice. The service reduces the container using complexity and aligns well with traditional user's habits, helping you easily manage and deploy your container cluster, and enjoy the benefits of cloud-native technologies in a quick and convenient way.

Advanced Monitoring Server

An advanced monitoring server is a dedicated VM instance used to receive advanced monitoring data of load balancers and other resources.

Advanced Monitoring Server Image

An advanced monitoring server image encapsulates the advanced monitoring service and can be used to create advanced monitoring server.

Advanced Monitoring Server Offering

An advanced monitoring server offering defines the CPU cores, memory size, image, management network, and public network configurations of advanced monitoring server. You can use an advanced monitoring server offering to create advanced monitoring servers.

Plugin Management

You can package extended resources or tools into standardized plugins for quick installation and integration, expanding the Cloud capabilities.

Region Management

A region is a self-contained cloud environment with independent management node(s), networks, hardware, and cloud resources. ZStack IAM enabled user synchronization and SSO across multiple regions.
VM Scheduling Policy Tutorial | 5.5.38 | ZStack Cloud · ZCF | ZStack Resource Center