VMWARE VIRTUALIZED SAP HANA WITH DELL EMC STORAGE Storage configuration and connectivity Scale-up and scale-out deployments June 2017 ABSTRACT This solution guide describes best practices for deploying an SAP HANA system on Dell EMC storage arrays in VMware vSphere virtualized environments. H14721.2 This document is not intended for audiences in China, Hong Kong, Taiwan, and Macao. SOLUTION GUIDE
24
Embed
VMware Virtualized SAP HANA with Dell EMC Storage · PDF filerequires an SAP registration ID.) ... The SAP HANA service auto-restart watchdog function monitors the SAP HANA ... VMware
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
VMWARE VIRTUALIZED SAP HANA WITH DELL EMC STORAGE
Storage configuration and connectivity
Scale-up and scale-out deployments
June 2017
ABSTRACT
This solution guide describes best practices for deploying an SAP HANA system on
Dell EMC storage arrays in VMware vSphere virtualized environments.
H14721.2
This document is not intended for audiences in China, Hong Kong, Taiwan,
and Macao.
SOLUTION GUIDE
Copyright
2 VMware Virtualized SAP HANA with Dell EMC Storage Storage configuration and connectivity Solution Guide
The information in this publication is provided as is. Dell Inc. makes no representations or warranties of any kind with respect to the information in this publication, and specifically disclaims implied warranties of merchantability or fitness for a particular purpose.
Use, copying, and distribution of any software described in this publication requires an applicable software license.
Deploying VMware vSphere virtualized SAP HANA on Dell EMC storage
6 VMware Virtualized SAP HANA with Dell EMC Storage Storage configuration and connectivity Solution Guide
Deploying VMware vSphere virtualized SAP HANA on Dell EMC storage
Following SAP’s enhancement of the SAP HANA deployment options with the TDI model,
Dell EMC certified the VMAX, VMAX3, VMAX All Flash, VNX, XtremIO, Unity, VPLEX,
and SC Series block storage platforms for production use in TDI deployments.
Tests with Dell EMC SAP HANA-certified block storage systems confirmed that the arrays
can be used in VMware virtualized environments with only a minor impact on performance
when you follow the guidelines in this document.
As in physical environments, you can install an SAP HANA system in virtualized
environments as a scale-up single-node system or as a scale-out multinode system. The
number of SAP HANA virtual machines that you can install on a single physical server
depends on several factors, including the number of CPU sockets, the server RAM, the
SAP HANA installation use case (production or non-production), and the maximum
scalability supported by SAP and VMware.
Consult the corresponding VMware best practices and recommendations when you create
an SAP HANA virtual machine and need to size and configure memory, CPU,
hyperthreading, and non-uniform memory access (NUMA) nodes for the machine.
Scale-up (single-node) systems
Scale-up systems are primarily used for transactional SAP applications such as the SAP
Business Suite. The SAP HANA database is stored in the RAM of a single virtual
machine, while the SAP HANA persistence is stored on a data and log file system
belonging to this virtual machine.
Figure 1 shows the virtual disk devices used in SAP HANA virtual machines. The virtual
disk that holds the operating system is created during the initial machine configuration and
can reside on any available vSphere datastore. Installing the SAP HANA software
requires a /hana/shared mount point. In scale-up installations, this mount point is
private to the virtual machine and can be a directory under the operating system root
device (if the size meets the requirements), or a separate virtual disk mounted under
/hana/shared. This virtual disk does not have specific performance requirements and
can reside on any multipurpose datastore.
Overview
SAP HANA
deployment
options
Deploying VMware vSphere virtualized SAP HANA on Dell EMC storage
7 VMware Virtualized SAP HANA with Dell EMC Storage Storage configuration and connectivity
Solution Guide
Figure 1. Virtual disks in an SAP HANA scale-up scenario
Scale-out (multinode) systems
Scale-out systems are used primarily for analytic applications such as SAP Business
Warehouse. The SAP HANA database is distributed across multiple virtual machines,
either on a single physical server or across a vSphere cluster consisting of multiple
physical servers. The system uses a “shared-nothing cluster architecture,” in which every
node in a scale-out deployment stores its database persistence on its own data and log
file systems. In a scale-out deployment, the /hana/shared file system must be shared
across all SAP HANA nodes that are part of the scale-out cluster. See SAP HANA shared
file system for configuration guidelines.
High Availability in a vSphere cluster
In a vSphere cluster, you must enable the vSphere HA feature. HA handles the restart of virtual machines on another host that has enough free resources if one of the hosts in the cluster fails. 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:
Figure 2 shows the minimum required vSphere HA settings.
High Availability
considerations
Deploying VMware vSphere virtualized SAP HANA on Dell EMC storage
8 VMware Virtualized SAP HANA with Dell EMC Storage Storage configuration and connectivity Solution Guide
Figure 2. 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.
HA for 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) handles
operating system (OS) failures. The monitoring feature restarts the guest OS 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. Dell EMC recommends setting Heartbeat monitoring sensitivity to High, as
shown in Figure 3.
Deploying VMware vSphere virtualized SAP HANA on Dell EMC storage
9 VMware Virtualized SAP HANA with Dell EMC Storage Storage configuration and connectivity
Solution Guide
Figure 3. Enabling VMware HA VM monitoring
To enable heartbeat monitoring, install and run the VMware tools in the virtual machine.
These tools are installed either as part of the OS (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
EMC 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 installations
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 OS fails.
SAP HANA split-brain condition and host isolation
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. 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
Deploying VMware vSphere virtualized SAP HANA on Dell EMC storage
10 VMware Virtualized SAP HANA with Dell EMC Storage Storage configuration and connectivity Solution Guide
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 a 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:
1. Click SAP HANA Studio > Administration-Perspective > Landscape > Hosts.
2. 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 fix 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. In this
case, 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.
SAP HANA storage devices in virtualized environments
11 VMware Virtualized SAP HANA with Dell EMC Storage Storage configuration and connectivity
Solution Guide
SAP HANA storage devices in virtualized environments
SAP HANA installations on VMware vSphere require the following storage devices:
OS disk (root device) ‒ approximately 10 GB
The disk is created when the virtual machine is deployed. The virtual disk file
(VMDK) can reside on any datastore that meets the installation requirements, that
is, has vMotion support.
SAP home directory: /usr/sap ‒ approximately 50 GB
The /usr/sap directory can be a mount point under the OS root directory. Adjust
the size of the root device correspondingly. Alternatively, you can use and mount a
separate virtual disk under /usr/sap/<SID>. Dell EMC recommends this method
for storage-based cloning and when using SAP instance cloning tools such as SAP
Landscape Management (LaMa).
SAP HANA shared file system: /hana/shared
The /hana/shared file system stores the SAP HANA installation binaries,
configuration files, and trace files. The size of the file system depends on the size of
the SAP HANA installation (database size and number of nodes). See the SAP
HANA white paper SAP HANA Storage Requirements for guidelines on capacity
sizing. The SAP HANA shared file system section of this guide provides
configuration details.
SAP HANA database persistence (data and log)
Each active SAP HANA node (scale-up node or worker node in scale-out
deployments) requires two devices to persist the in-memory database to disk and to
write the transaction log. The SAP performance requirements for the storage
devices apply only to these two file systems, so it is important to consider storage-
configuration best practices when you set up an SAP HANA production
environment. The size of the data and log devices depends on the actual database
size. See the SAP HANA Storage Requirements white paper for more information.
SAP HANA scale-out scenarios require a shared file system that is mounted on every
SAP HANA node within the cluster. The file system stores the installation binaries,
configuration files, and trace files. In physical environments, this file system is generally
provided as a network file system (NFS) share by storage systems with network-attached
storage (NAS) capabilities, such as VNX series unified, Unity, SC Series storage, and
VMAX with eNAS.
If a NAS array is not available, vSphere with native Linux functionality provides a viable
alternative. A Linux virtual machine (non-SAP HANA node) running an NFS server
process provides the NFS share. This process exports a file system that is mounted on all
the SAP HANA cluster nodes. Reliability is achieved using vSphere Fault Tolerance.