Relationship Between Cluster and Associated Resources

1. Cluster | Zone

   Operations on multiple clusters are supported. That is, you can create more than one cluster in a zone, and allocate newly created hosts to different clusters as needed.

2. Cluster | Primary Storage
   • A primary storage can be attached to one or more clusters.
   • A cluster can have one or more primary storages attached.
     The following are primary storages of the same type that a cluster can have:

     • A cluster can have one or more LocalStorage primary storages attached.
     • A cluster can have one or more NFS primary storages attached.
     • A cluster can have one or more Shared Block primary storages attached.
     • A cluster can have one Shared Mount Point primary storages attached.
     • A cluster can have only one Ceph primary storage attached.
     The following are combinations of primary storages that a cluster can have:

     • A cluster can have both a LocalStorage and an NFS primary storage attached.
     • A cluster can have both a LocalStorage and a Shared Mount Point primary storage attached.
     • A cluster can have both a LocalStorage and a Shared Block primary storage attached.
     • A cluster can have both a Ceph and a Shared Block primary storage attached.
     • A cluster can have both a Ceph and more than one Shared Block primary storage attached.
     The following table lists the relationship between primary storages and a cluster, as shown in Table 1.

     Table 1. Relationship Between Primary Storage and Cluster

     Primary Storage	Cluster
     LocalStorage	A cluster can have one or more LocalStorage attached.
     NFS	A cluster can have one or more NFS primary storages attached.
     Shared Block	A cluster can have one or more Shared Block primary storages attached.
     Share Mount Point	A cluster can have one Share Mount Point primary storage attached.
     Ceph	A cluster can have only one Ceph primary storage attached.
     LocalStorage + NFS	A cluster can have one LocalStorage + one NFS attached.
     LocalStorage + SMP	A cluster can have one LocalStorage + one Shared Mount Point attached.
     LocalStorage + Shared Block	A cluster can have one LocalStorage + one Shared Block attached.
     Ceph + Shared Block	A cluster can have one Ceph + one Shared Block attached. A cluster can have one Ceph + multiple Shared Block attached.

   • When you attach multiple LocalStorage primary storages to a cluster, partition the corresponding URLs on the hosts before you add hosts and primary storages, and make sure that each LocalStorage is deployed on an exclusive logical volume or physical disk.
   • A primary storage can be accessed by all hosts in the cluster to which the primary storage belongs.
   • If a primary storage cannot be accessed by hosts in the cluster due to network typology changes in the data center, you can detach the primary storage from the cluster.
   • After you delete a cluster that uses LocalStorage, all hosts and VM instances in the cluster will be deleted. However, volumes and actual snapshot data of these hosts will not be deleted.
   • After you delete a cluster that uses a shared storage, the corresponding VM instances will be stopped. If you add high availability tags to these stopped VM instances, you can restart these VM instances on the hosts in other available clusters.
   • If different clusters have the same network and primary storage attached, you can migrate VM instances across these clusters.
   • After you detach a primary storage from a cluster, ZStack will stop all VM instances in the cluster. You can start these VM instances only when you attach this primary storage to this cluster again.
   • After you put the primary storage where the data disk of a VM instance is located into maintenance mode, the VM instance will be stopped and cannot be started.
3. Customizing the CPU mode of a cluster
   • To make the setting take effect, go to Settings > Global Settings > Advanced, locate Host CPU Model checking, and set the value to true.
   • After you specify the CPU mode of a cluster, you can add hosts of the specified CPU mode only to this cluster.
   • For clusters created in the previous versions, after you upgrade the cloud to 2.3.2, the CPU mode of the cluster is None, which cannot be changed.
4. Cluster | L2 Network
   • A cluster can have one or more L2 networks attached. Also, an L2 network can be attached to one or more clusters.
   • A cluster can have a VXLAN pool attached. The VNIs in the VXLAN pool can be used to create different VxlanNetworks.
   • One NIC can have only one NoVlanNetwork created.
   • For VlanNetwork, different VLAN IDs represent different L2 networks.
   • If hosts in a cluster no longer exist in the layer 2 broadcast domain of an L2 network due to network typology changes in the data center, you can detach the L2 network from the cluster.
   • In addition, when you detach a network from a cluster, ZStack will detach the NICs of all VM instances in the cluster. At this time, the VM instances do not have a NIC. Once a running VM instance is stopped, it cannot be started again. To start the VM instance again, you need to attach a network to the cluster again and attach a NIC to the VM instance.
   • You can add a migration network to perform migration operations. If no migration network is set, the management network will be used for migration by default.
5. Cluster | Backup Storage
   No direct dependency exists between a cluster and a backup storage. A backup storage can provide services for multiple clusters.

   Note:

   • The primary storage and backup storage attached to the same cluster are associated with each other.
   • A Ceph primary storage can work with backup storages of the ImageStore type.
   • The following table lists the relationship between primary storages (PS) and backup storages (BS), as shown in Table 2.

     Table 2. Relations Between Primary Storage and Backup Storage

     PS/BS	ImageStore	SFTP	Ceph
     LocalStorage	○	○	×
     NFS	○	○	×
     Shared Mount Point	○	○	×
     Ceph	○	×	○
     Shared Block	○	×	×

6. Cluster | Host
   • After you disable a cluster, you cannot use this cluster to apply for new resources. In addition, all hosts in the cluster will also be disabled. However, the running VM instances are not affected. Note that after these running VM instances are stopped, they will not be started in the cluster again.
   • After you enable a cluster, you will also enable all hosts in the cluster at the same time.
7. Cluster | Global Settings
   • On the Advanced Settings tab of the details page of a cluster, you can set the memory overcommitting rate, CPU overcommitting rate, and host reserved memory for the cluster. This setting only takes effect for the resources in the cluster. If not set, values set in the global settings will be used by default.
     Note: The values of the advanced setting must be configured according to the needs of different systems and applications. Excessive large values might seriously affect the performance. Please exercise caution.
8. Cluster | DRS

   Dynamic Resource Scheduling (DRS) monitors the load of hosts by cluster, and gives scheduling suggestions according to the configured scheduling strategy. You can migrate VM instances according to the scheduling suggestions to balance the cluster load while effectively improving the cloud stability.

   To make RDS work properly, make sure that:

   • The cluster has only Ceph or Shared Block primary storage.
   • The CPU modes of the hosts in the cluster are consistent.
   • The cluster does not have VM instances that are attached to affinity groups.

   If all the above requirements are met, you can turn on the Switch for RDS on the Advanced Settings tab of the cluster details page. After the switch is turned on, you can configure the scheduling policy on the RDS page. The RDS functionality takes effect after the configurations are completed.