SAP HANA Virtual Machines

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 = noWhen installing SAP HANA using hdbinst, add these parameters to the /usr/sap//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:Click SAP HANA Studio > Administration-Perspective > Landscape > Hosts. Select Configure Hosts for Failover Situation and change the master role to Slave.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

HA in a vSphere clusterIn 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//profile/_HDB_Figure 2 shows the minimum required vSphere HA settings.Figure 2. vSphere HA settingsUsing 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.HA for SAP HANA virtual machinesThe 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.Figure 3. Enabling VMware HA VM monitoringTo 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

Used to route traffic to master node across multiple Scale-out nodes of the SAPP BW database from SAP application servers.Here are the general steps for using a Standard Load Balancer with SAP HANA Scale-out:Deploy multiple instances of SAP HANA in a scale-out configuration. Each instance should be deployed to a separate virtual machine.Install and configure the SAP HANA system according to the requirements for a scale-out configuration.Create a backend pool in the Standard Load Balancer for each instance of SAP HANA. Each backend pool should contain the private IP address of all the virtual machines hosting the SAP HANA Scale-out instance.Create a health probe to identify the Virtual Machine running master node out of all virtual machines hosting Scale-Out of SAP HANA instance. The health probe should check that the SAP HANA Nameserver service SQL Port 315.Create a load balancing rule to route traffic to the backend pool(s) for SAP HANA. The load balancing rule can select HA Ports.Configure the SAP HANA clients to connect to the IP address of the Standard Load Balancer rather than directly to the IP address of the SAP HANA instances. The load balancer will route traffic to the master node based on the load balancing rule & configuration. It can be achieved by updating the SAP Default Profile & HDBUSERSTORE or SSFS keys for connectivity to the HANA database.Advantages of using Standard Load Balancer over multi-node connection strings for HANA scale-out,Standard Load Balancer simplifies the connection string from Application server & 3rd party application.Configuration of SSFS/HDBUSERSTORE is simple with single host configuration v/s multiple host where there is a complexity due to long entries as scale-out can go up to 16 nodes.For 3rd party application, it is complex to maintain multi-node connection string.Lower management overhead as addition/removal of scale-out nodes can be directly managed from Azure Load Balancer backend pool. Single place for managing node details. The configuration will also work for SAP HANA Scale-out HA/DR configuration across zones using single Standard Load Balancer.Scenario#1High-Availability using N+1 Scale-Out deploymentbelow example with SAP BW Scale-Out using VM SKU M128sScenario#2Combined High-Availability & Disaster Recovery using N+1 Scale-Out deployment across zones.Refer below link for more information on the parts of the configurations,SAP HANA scale-out with HSR and Pacemaker on RHEL | Microsoft LearnSAP HANA scale-out with HSR and Pacemaker on SLES | Microsoft LearnAzure Load Balancer Floating IP configuration | Microsoft LearnJitendra Singh is a Program Manager at Microsoft, part of Customer Solutions & Incubation team, responsible for safeguarding SAP Workload On Azure customer scenarios and helping achieve the most out of the cloud investment.

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.SAP HANA high availability in scale-out installationsIn 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. SAP HANA split-brain condition and host isolationIn 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