If you are running on vSphere 7.0 or have recently upgraded your VMware infrastructure to 7.0 you probably might have noticed a vCLS VM or may be multiple VM's named vCLS (1), vCLS (2), vCLS (3) in your vCenter.
VMware has introduced this new service called the VMware vSphere Cluster Services (vCLS) in vSphere 7.0 Update 1 release. vCLS ensures that even if vCenter Server becomes unavailable, cluster services remain available to maintain the resources and health of the workloads that run in the clusters.
In this series of blogs lets discuss about it's architecture, resources, operations and other features in more detail.
vCLS Architecture -
vCLS uses agent virtual machines to maintain cluster services health. The vCLS agent virtual machines (vCLS VMs) are created when you add hosts to clusters. The basic architecture for the vCLS control plane consists of maximum 3 VM's which are placed on separate hosts in a cluster. New anti-affinity rules are applied automatically. Every three minutes a check is performed, if multiple vCLS VMs are located on a single host they will be automatically redistributed to different hosts.
In a small cluster with less than 3 ESXi hosts, the number of agent VM's is equal to the number of ESXi hosts. If you have one host you will have one VM, with two hosts two VMs. These VMs are managed by vSphere Cluster Services and administrators are not expected to maintain the lifecycle or state for the agent VMs. These VM's should not be treated like the typical workload VMs.
Datastore selection for vCLS VMs -
The datastore for vCLS VMs is automatically selected based on ranking all the datastores connected to the hosts inside the cluster. If no shared storage is available, the agent VMs are placed on local storage. A datastore with more free space is preferred and the algorithm tries not to place more than one vCLS VM on the same datastore. You can only change the datastore of vCLS VMs after they are deployed and powered on. If a cluster is formed before shared storage is configured on the ESXi hosts(eg. in case of vSAN) it is strongly recommended to move the vCLS agent VMs to shared storage after. Starting with vSphere 7.0 U3 you can select the datastore on which you want to provision the vCLS VMs.
If you want to move the VMDKs for vCLS VMs to a different datastore or attach a different storage policy, you can reconfigure vCLS VMs. You can perform a storage vMotion to migrate vCLS VMs to a different datastore. You can tag vCLS VMs or attach custom attributes if you want to group them separately from workload VMs, for instance if you have a specific meta-data strategy for all VMs that run in a datacenter.
When a datastore is placed in maintenance mode, if the datastore hosts vCLS VMs, you must manually apply storage vMotion to the vCLS VMs to move them to a new location or put the cluster in retreat mode.
vCLS VM Resources -
The vCLS agent VM's are lightweight, meaning that the resource utilization is very minimum. The agent VMs run a customized Photon OS. The resource specification per agent VM is listed in the below table -
The 2 GB virtual disk is thin provisioned. Also, as you see in the above table there’s no network adapter configured. You must be wondering how does vCLS communicate if it does not have any NIC. It leverages a VMCI/vSOCKET interface to communicate with the hypervisor.
You would not be able to see the vCLS VM's in the Host and Clusters overview in the vSphere Client. The VMs and Templates view has a new folder created, named vCLS which contains all the vCLS agent VM's. With multiple clusters, all vCLS agent VMs will show, numbered consecutively.
Operations -
As mentioned above, the agent VM's are maintained by vCLS. There is no need for the administrators to power off these VM's. If you try to power off the agent VM, it will show warning like below -
When you put a host into maintenance mode, the vCLS agent VMs are migrated to other hosts within the cluster like regular VMs.
Administrators should not perform any operations on these VMs(remove, rename, etc.) unless guided by VMware support or explicitly listed as supported operation in any documentation.
The lifecycle for vCLS agent VMs is maintained by the vSphere ESX Agent Manager (EAM). The Agent Manager creates the VMs automatically, or re-creates/powers-on the VMs when users try to power-off or delete the VMs.
Now the question comes that why do we see vCLS VMs with a number higher than 3? (eg “vCLS (8)” or “vCLS (20)”). During maintenance ESX Agent Manager (EAM) can delete and re-provision the VMs when deemed needed. When a new VM is provisioned the counter will go up. If an administrator tries to delete a VM, a new vCLS VM's get's provisioned immediately and the counter goes up.
With this I'll wrap up this post here. In the next part, we will discuss more about cluster service health, retreat mode and few other functions.
I hope this was informative and thank you for reading!
*** Explore | Share | Grow ***
Comments