Home > Workload Solutions > SAP > Guides > VMware Virtualized SAP HANA with Dell Storage > HA considerations
In a vSphere cluster, you must enable the vSphere HA feature. If one of the hosts in the cluster fails, the HA feature is responsible for the restart of virtual machines on another host that has enough free resources. To ensure that SAP HANA starts automatically with the virtual machine, enable the SAP HANA service autostart feature either at the time of the SAP HANA installation or by setting the autostart option to 1 in the following file:
/hana/shared/<SID>/profile/<SID>_HDB<InstNo>_<hostname>
Figure 2 shows the minimum required vSphere HA settings.
Using vSphere host groups, VM groups, and affinity rules, the administrator can control which hosts in the vSphere cluster are allowed to run SAP HANA virtual machines.
The SAP HANA service auto-restart watchdog function monitors the SAP HANA application and the associated services within a virtual machine. The watchdog function automatically detects a failure and restarts the corresponding SAP HANA process—nameserver, indexserver, and so on.
The VMware HA virtual machine monitoring feature Guest not heartbeating responds to operating system failures by restarting the guest operating system of the virtual machine as well as SAP HANA on the same host. (The SAP HANA autostart option must be enabled.) Enable the monitoring feature when you enable vSphere HA, as shown in Figure 2.
Set Heartbeat monitoring sensitivity to High, as shown in Figure 3.
To enable heartbeat monitoring, install and run the VMware tools in the virtual machine. These tools are installed either as part of the operating (open-vm-tools) or by using the vSphere Web client and the virtual machine’s context menu: select Guest OS > Install VMware Tools.
In addition to heartbeat polling, VM Monitoring monitors the virtual machine’s I/O activity. When heartbeats are not received and no disk or network activity has occurred over the last 120 seconds, the virtual machine is reset by default. The administrator can change the advanced setting das.iostatsInterval to modify this 120-second interval. Dell Technologies recommends aligning das.iostatsInterval with the failure interval you selected in the vSphere HA VM Monitoring section in the vSphere Web client.
In an SAP HANA scale-out installation on physical servers, you can deploy a standby server to enable the SAP HANA host auto-failover functionality. If one of the active SAP HANA servers (workers) fails, the SAP HANA nameserver triggers a failover to the standby host.
In VMware virtualized environments, an SAP HANA standby host is not required and does not work with the default SAP HANA storage connector. Instead, the VMware HA feature restarts the SAP HANA virtual machines on another host in the cluster when a physical host fails, or on the same host if just the virtual machine operating system fails.
In physical SAP HANA scale-out installations with shared storage, the first installed node becomes the master nameserver, Master 1, and the second and the third installed nodes become master candidates Master 2 and Master 3 respectively. SAP HANA experiences a split-brain situation if multiple hosts try to become the master nameserver or indexserver and to access the same data (persistence) from disk. Such a situation might occur if the host of the master nameserver becomes isolated from the network but can still access the shared disk storage and a master candidate tries to take over the master role. Physical SAP HANA installations use techniques such as SCSI-3 persistent reservation to prevent this situation.
The standby master nameserver candidates are not required in VMware virtualized environments. Because VMware HA restarts the existing master nameserver quickly enough, promoting a new node to the master role is not necessary. To prevent SAP HANA from using Master 2 and Master 3 candidates in scale-out installations, set the following entries in the global.ini file:
[communication]
listeninterface = .global
[persistence]
basepath_shared = no
When installing SAP HANA using hdbinst, add these parameters to the /usr/sap/<SID>/SYS/global/hdb/custom/config/global.ini file after the first node has been installed.
When using hdblcm for an SAP HANA scale-out installation, create a default global.ini file with the above entries in a temporary directory. The
--custom_cfg installation parameter must point to this temporary directory.
In existing SAP HANA installations that already have multiple master candidates (Master 2 and Master 3), disable the failover mechanism by removing the nameserver roles Master 2 and Master 3:
If a network failure occurs whereby a physical ESXi host becomes disconnected from the network but all virtual machines on the host are still running, the VMware HA Host Isolation rule and the associated response are applied. The default response leaves all virtual machines powered on, as shown in Figure 2. Because a virtualized SAP HANA scale-out cluster does not have a standby node to take over the function (master nameserver) of the unresponsive node on the isolated host, a split-brain situation cannot occur. The default response allows the administrator to investigate and resolve the network issue, or to power off the isolated host, which then causes VMware HA to restart the virtual machines on another host.
It is also possible to set the “Host Isolation” response to Power off and restart VMs. The host is powered off and the virtual machines are restarted automatically on another host that still has network connectivity.
With only one SAP HANA master nameserver candidate and the VMware HA Host Isolation rules, a master nameserver can exist only once and therefore a split-brain condition cannot occur.