SAP HANA on vSphere 7 Update 1 – vSphere Clustering Service (vCLS)

Overview

Starting with vSphere 7.0 Update 1, vSphere Cluster Services (vCLS) is enabled by default and runs in all vSphere clusters. VMware would like to make critical cluster services like vSphere High Availability (HA) and vSphere Distributed Resource Scheduler (DRS) always available and vCLS is an initiative to reach the vision.

SAP HANA as the foundation of most SAP business applications is a very critical asset of all companies using SAP solutions for their business. Due to the criticality of these applications for a business it is important to protect and optimally operate SAP HANA.

Running SAP HANA on VMware vSphere provides an easy way to protect and operate it by leveraging vSphere cluster services like vSphere High Availability (HA) or vSphere Distributed Resource Scheduler (DRS), which depends on vCenter Server availability for its configuration and operation.

The dependency of these cluster services on vCenter is not ideal and VMware introduced in the vSphere 7 Update 1 release the vSphere Clustering Service (vCLS), which is the first step to decouple and distribute the control plane for clustering services in vSphere and to remove the vCenter dependency. If vCenter Server becomes unavailable, in future, vCLS will ensures that the cluster services remain available to maintain the resources and health of the workloads that run in the clusters.

vCLS is enabled when you upgrade to vSphere 7.0 Update 1 or when you have a new vSphere 7.0 Update 1 deployment. vCLS is upgraded as part of vCenter Server upgrade.

Architecture

vCLS uses agent virtual machines to maintain cluster services health. Up to maximal three vCLS agent virtual machines (vCLS VMs) are created when you add hosts to clusters. These vCLS VMs, which build the cluster control plane, and are lightweight agent VMs.

vCLS VMs are required to run in each vSphere cluster, distributed within a cluster. vCLS is also enabled on clusters which contain only one or two hosts. In these clusters the number of vCLS VMs is one and two, respectively.

Below figure shows the high-level architecture with the new cluster control plane.

A cluster enabled with vCLS can contain ESXi hosts of different versions if the ESXi versions are compatible with vCenter Server 7.0 Update 1. vCLS works with both vLCM and VUM managed clusters and runs in all vSphere license SKU clusters.

vCLS VM details

vCLS VMs run in every cluster even if cluster services like vSphere DRS or vSphere HA are not enabled on the cluster.

Each vCLS VM has 100MHz and 100MB capacity reserved in the cluster. Depending on the number of vCLS VMs running in the cluster, a max of 400 MHz and 400 MB of capacity can be reserved for these VMs.

In the normal use case these VMs are nearly not noticeable in terms of resource consumption and users are not expected to maintain the lifecycle or state for the agent VMs, they should not be treated like the typical workload VMs.

vCLS VM Resource Allocation
Property Size
Memory 128 MB
CPU 1 vCPU
Hard disk 2 GB

Number of vCLS Agent VMs in Clusters:

Number of Hosts in a Cluster Number of vCLS Agent VMs
1 1
2 2
3 or more 3

vCLS Deployment Guidelines for SAP HANA Landscapes

As of SAP note 2937606 – SAP HANA on VMware vSphere 7.0 in production, which includes the support for vSphere 7.0 Update 1:

“SAP HANA VMs can get co-deployed with SAP non-production HANA or any other workload VMs on the same vSphere ESXi host, as long as the production SAP HANA VMs are not negatively impacted by the co-deployed VMs. In case of negative impact on SAP HANA, SAP may ask to remove any other workload”. Also, “no NUMA node sharing between SAP HANA and non-HANA allowed”.

Due to the mandatory and automated installation process of vCLS VMs, when upgrading to vCenter 7.0 Update 1, it is necessary, because of above guidelines, to check if vCLS VMs got co-deployed on vSphere ESXi hosts that tun SAP HANA production level VMs. If this is the case, then these VMs must get migrated to hosts that do not run SAP HANA production level VMs.

This can get easily achieved by migrating, via vMotion, the vCLS VMs to hosts that do not run SAP HANA production level VMs. If also the automatically selected datastore should get changed, then you can perform a storage vMotion to migrate the VMDKs of a vCLS VMs to a different datastore.

vCLS Deployment Examples for SAP HANA Landscapes

Customers deploy SAP HANA typically on dedicated ESXi hosts. These hosts can be part of small or large clusters (in terms of number of hosts). They can be mixed with hosts running non-SAP HANA workload VMs or can be part of a dedicated SAP HANA only cluster.

Following section provides examples of typical SAP Landscape Clusters and provide some guidelines where to place the up to three lightweight vCLS VMs.

Mixed SAP HANA and non-SAP HANA VM vSphere Cluster

A mixed cluster should be the typical scenario for most customers. In this case check the vCLS VMs if they got deployed on ESXi hosts that run production level SAP HANA VMs and if yes, if the vCLS runs on the same CPU socket as the SAP HANA VM. If this is the case, then migrate these VMs to mixed workload ESXi hosts or CPU sockets that are not used by SAP HANA.

Below figure shows the initial deployed vCLS VMs and how these VMs should get moved (green arrows) to comply with SAP note 2937606. Not shown in this figure are the HA host / HA capacity reserved for HA failover situations.

Dedicated SAP HANA VM vSphere Cluster

Customers may have deployed an SAP HANA cluster with dedicated hosts that run only SAP HANA workload VMs. In this case automatically deployed vCLS VMs cannot get migrated easily to hosts that do not run SAP HANA VMs. Solution is to add existing hosts with non-SAP HANA workload VMs to this cluster. These existing hosts may run any workload like SAP application server VM or infrastructure workload VMs. It is not required to buy new host for this!

Below figure shows the initial deployed vCLS VMs and how these VMs should get moved to cluster added hosts to comply with SAP note 2937606. As before, not shown in this figure are the HA host / HA capacity reserved for HA failover situations.

SAP HANA HCI vSphere Cluster

Just as with the dedicated SAP HANA cluster an SAP HANA HCI cluster may only run SAP HANA workload VMs. As with SAP HANA running on traditional storage, SAP HANA HCI (SAP note 2718982) supports the co-deployment with non-SAP HANA VMs as outlined in SAP note 2937606 (vSphere 7.0) and 2393917 (vSphere 6.5/6.7).

If vCenter gets upgraded to 7.0 U1 then the vCLS VMs will get automatically deployed on SAP HANA HCI nodes. If these nodes are exclusively used for SAP HANA, then these vCLS must get removed and migrated to vSphere hosts that can get easily added to the SAP HANA HCI cluster. To mention is that these hosts do not have to be part of the vSAN or if vSAN does not get used other SAP HANA HCI certified SDS storage solution.

vSphere ESXi hosts that could get added are for instance the host that supports vCenter or SAP application server workload VMs.  In the case of an SAP HANA HCI partner system validation the Retreat Mode can get used which allows you to remove the vCLS VMs.

Summary

By introducing the vSphere Clustering Service (vCLS), VMware is embarking on a journey to remove the vCenter dependency and possible related issues when vCenter server is not available and provides a scalable platform for larger vSphere hosts deployments. Moving the vCLS VM to non-SAP HANA hosts or CPUs that do not run SAP HANA is an easy process and does not disrupt the SAP HANA operation.

Resources and Additional Readings

Posted by Linux Admin