Sap Hana On Vmware Vsphere With Netapp Fas and All Flash Fas Systems

Technical Report
SAP HANA on VMware vSphere with NetApp

FAS and All Flash FAS Systems
Reference Architecture
Tobias Brandl, NetApp
Erik Rieger, Bhumik Patel, VMware
January 2018 | TR-4338
In partnership with
Abstract
This reference architecture document helps customers design and deploy SAP HANA single
host and multiple host solutions on VMware vSphere virtual machines (VMs) and NetApp®
FAS and All Flash FAS (AFF) storage systems. This reference architecture is a deployed
and documented solution based on experiences with existing VMware and NetApp
customers, real-world simulations, and NetApp Engineering Lab validations. This document
helps customers through the entire project lifecycle, including requirement assessment,
solution design, installation, and administration.
TABLE OF CONTENTS
1 Introduction ........................................................................................................................................... 3
1.1 Introduction to SAP HANA ..............................................................................................................................3
1.2 Introduction to NetApp Storage Systems for SAP HANA ................................................................................3
1.3 Introduction to VMware vSphere for SAP HANA.............................................................................................3
1.4 Customer Requirements .................................................................................................................................5
2 Reference Architecture Design and Deployment .............................................................................. 6

2.1 Hardware ........................................................................................................................................................6
2.2 Software ........................................................................................................................................................10
3 Use Cases ............................................................................................................................................ 13

3.1 SAP HANA Backup and Recovery ................................................................................................................13
3.2 SAP HANA High Availability..........................................................................................................................25
3.3 SAP HANA Disaster Recovery......................................................................................................................25
3.4 SAP HANA System Copy and Refresh .........................................................................................................27
3.5 SAP HANA Relocation ..................................................................................................................................28
4 Conclusion .......................................................................................................................................... 29
Where to Find Additional Information .................................................................................................... 30
Version History ......................................................................................................................................... 30
LIST OF TABLES
Table 1) Disaster recovery options for SAP HANA. ......................................................................................................25
LIST OF FIGURES
Figure 1) VMware vSphere overview. ............................................................................................................................4
Figure 2) Hardware landscape overview. .......................................................................................................................6
Figure 3) Storage overview. ...........................................................................................................................................7
Figure 4) Network overview. ...........................................................................................................................................8
Figure 5) VMware distributed switch configuration. ........................................................................................................9
Figure 6) Volume layout for SAP HANA systems. ........................................................................................................10
Figure 7) Backup architecture. .....................................................................................................................................11
Figure 8) SAP HANA relocation using SAP LAMA. ......................................................................................................29
2 SAP HANA on VMware vSphere and NetApp © 2018 NetApp, Inc. All Rights Reserved.
FAS/AFF Systems
1 Introduction
1.1 Introduction to SAP HANA

SAP HANA, which was developed to address the need of SAP customers for high-speed analytics, has
evolved into a high-speed database for almost all SAP applications. It is the core of SAP’s digital
transformation strategy. SAP HANA is an in-memory database that allows a computer’s main memory to
process a vast quantity of transactional and analytical data.
You can use SAP HANA to develop business applications that support real-time analytics. These
applications are flexible and capable of the performance needed to rapidly adapt to and act upon change.
Even though SAP HANA is an in-memory database, it uses disk-based storage to persist changes. If
there is a system failure or a system shutdown, the NetApp storage system acts as the persistence layer.
The SAP certification program for technology vendors validates functionality by hardware product. SAP
requires that all appliances compatible with SAP HANA be tested and certified before they are used by
customers. Although this certification is performed directly by SAP, server companies are responsible for
building, delivering, and supporting their appliances.
SAP has also created a tailored data center integration (TDI) program that allows customers to build
custom SAP HANA environments outside of the appliance model. This allows customers to use servers,
networks, and storage from certified vendors to build custom SAP HANA environments. To receive SAP
support, customers and partners must configure components and perform tests with tools provided by
SAP to validate that a custom configuration meets SAP HANA performance requirements. More details
about SAP HANA and TDI can be found in the SAP HANA tailored data center integration FAQ.
This document focuses on SAP HANA single host and multiple host deployments as a part of the TDI
program. This includes certified NetApp FAS and NetApp All Flash FAS (AFF) storage systems, certified
VMware vSphere virtualization, and the cloud computing platform.
1.2 Introduction to NetApp Storage Systems for SAP HANA

The NetApp FAS and AFF product families have been certified for use with SAP HANA in TDI projects.
This certified enterprise storage platform is characterized by the NetApp ONTAP® storage operating
system.
This certification is valid for the following current NetApp models:
• FAS8020, FAS8040, FAS8060, FAS8080 EX
• AFF8040, AFF8060, AFF8080 EX
• FAS2650, FAS8200, FAS9000
• AFF A200, AFF A300, AFF A700s, AFF A700
The most current information about certified storage systems can be found on the official SAP HANA
hardware directory.
In addition to the information provided in this document, details on SAP HANA deployments with NetApp
storage systems can be found in the NetApp FAS and AFF configuration guides listed in the references
section.
1.3 Introduction to VMware vSphere for SAP HANA

VMware vSphere is the market leading virtualization platform and an enabling technology for cloud
computing architectures. vSphere enables IT to meet SLA for the most demanding business-critical
applications at the lowest TCO. VMware vSphere delivers control over all IT resources with the highest
efficiency and choice in the industry.
VMware vSphere virtualization solutions provide the following benefits:
FAS/AFF Systems
• Consolidation. VMware virtualization consolidates multiple application servers onto one physical
server, with little or no decrease in overall performance. This arrangement minimizes or eliminates
underutilized server hardware, software, and infrastructure.
• Manageability. The live migration of VMs from server to server and associated storage is performed
with no downtime using VMware vSphere vMotion. This capability simplifies common operations such
as hardware maintenance and VMware vSphere Storage vMotion.
• Availability. High availability (HA) can reduce unplanned downtime and enable higher service levels
for applications. In the event of an unplanned hardware failure, VMware vSphere HA automatically
restarts the affected VMs on another host in a VMware cluster.
• Automation. VMware automated load balancing takes advantage of vMotion and Storage vMotion to
migrate VMs among a set of VMware ESX hosts. VMware vSphere Distributed Resource Scheduler
(DRS) and VMware vSphere Storage DRS enable automatic resource relocation and optimization
decisions for VMs and storage.
• Provisioning. VMware virtualization encapsulates an application into an image that can be
duplicated or moved, greatly reducing the cost of application provisioning and deployment.
• Control. Single pane of glass control, management, and operation of the complete virtualized
infrastructure with the VMware vCenter Server.
Figure 1) VMware vSphere overview.
FAS/AFF Systems
vSphere creates a layer of abstraction between the resources required by an application, the operating
system, and the underlying hardware that provides those resources. vSphere enables multiple, isolated
execution environments to share a single hardware platform and provides each environment with its own
set of hardware resources.
For more information, see the references section at the end of this paper.
vSphere 5.5 Compared to 6.x

The vSphere 6.x enhancement most relevant to VM implementation is an increase in scalability that
allows SAP HANA VMs of up to 4TiB in size with vSphere 6.0. In addition, VMs can be up to 6TiB in size
once certified with vSphere 6.5.
Although vSphere 6.x provides many improvements, including increased scalability, over vSphere 5.x, a
vSphere 5.5-based SAP HANA VM can be migrated to 6.x without difficulty. During migration, the VM
configuration settings must be updated and where needed, changed to run optimally on vSphere 6.x. See
the VMware SAP HANA best practices document for more information about the support status and
different settings.
VMware internal performance tests have shown that an identically configured SAP HANA vSphere 6.x
VM running on the same server system has similar performance to a vSphere 5.5 VM. These tests have
shown few performance benefits for vSphere 6.x in the area of memory management. However, vSphere
6.x VMs have access to more compute resources and provide more resources to an application. The
application can then consume twice as many CPU threads (128) relative to vSphere 5.5 (64).
1.4 Customer Requirements

When the SAP HANA platform is powered using the VMware vSphere virtualization and cloud-computing
platform, it delivers a new deployment architecture to VMware HANA customers. The SAP HANA with
VMware solution provides SAP customers with a data center platform characterized by agility, high
availability, cost savings, and easy provisioning. With this solution, SAP customers can provision
instances of SAP HANA in VMs more quickly and cost effectively.
This joint VMware and NetApp reference architecture addresses the following requirements of customers
running SAP HANA landscapes:
• Lower TCO
 Reduced capital and operating expenditures
 Unified management of SAP HANA with the rest of the virtualized data center (no specialized
staff required)
 Better utilization of existing infrastructure
• Faster time to value
 Rapid, automated provisioning
 Deployment time reduced from days to hours
 Consistency across environments with template provisioning
 Storage cloning for development and test systems
• Higher service levels
 Live migration of SAP HANA VMs across hosts with zero planned downtime by using vSphere
vMotion
 Out-of-the-box high availability up to 99.9%:
 Automatic restarts of SAP HANA VMs to maximize uptime
 Automatic failover to virtual SAP HANA appliances with no data loss
 Easy management of peak analytic workloads
FAS/AFF Systems
 Nondisruptive storage operations
• Efficient NetApp Snapshot® technology-based backups:
 Minimized performance effects on production systems:
 Dramatic reductions in the time required for backup, and restore, and recovery
 A reduction in the amount of disk space needed for backups
 Storage replication for disaster recovery scenarios
2 Reference Architecture Design and Deployment
2.1 Hardware
The infrastructure described in this document is designed to provide a homogeneous landscape and
operational model for both SAP HANA systems and SAP systems running on traditional databases. To
achieve this goal, you can use NetApp systems running ONTAP on the storage layer and VMware
vSphere Enterprise Plus Edition as a hypervisor on top of the compute layer (Figure 2). Production SAP
HANA systems have specific performance requirements, and SAP has defined strict rules and key
performance indicators. Therefore, NetApp highly recommends dedicating parts of the physical
infrastructure exclusively to SAP HANA workloads. Therefore, this document only focuses on SAP HANA
systems. However, the management and operational concepts presented in this document span the
complete environment and include systems other than SAP HANA.
Figure 2) Hardware landscape overview.
Storage Design and Configuration

This solution uses NetApp SAP HANA TDI-certified FAS or AFF systems running ONTAP on primary and
secondary sites to provide storage-based replication for disaster recovery. Depending on customer SLAs,
other disaster recovery options like SAP HANA system replication can be used. Replication is performed
using NetApp SnapMirror® relationships between the two sites. The backup architecture uses the built-in
ONTAP mechanism to back up SAP HANA databases. This storage-based Snapshot backup is a fully
supported and integrated backup solution available since SAP HANA SPS7.
FAS/AFF Systems
In addition, NetApp SnapVault® software is used to replicate Snapshot-based backups to a separate
physical storage system to allow longer-term backup retention. An overview of the storage design is
shown in Figure 3. Storage is sized according to the performance and capacity requirements of the
production SAP HANA systems in a TDI deployment model. Details about correct sizing and configuration
can be found in the SAP HANA on NetApp Systems with NFS Configuration Guide or the respective
document for AFF.
NetApp recommends storing data for SAP HANA systems in NetApp FlexVol® volumes connected
through the NFS protocol. You should also mount these volumes directly into the guest operating systems
because doing so offers greater flexibility and simplified management in heterogeneous landscapes. This
guide focuses on such an NFS-based setup. However, NetApp also supports the use of NetApp storage
systems in a SAN environment connecting FCP LUNs as raw device maps (RDMs) to the SAP HANA
VMs. Details and best practices for the storage setup in SAN environments can be found in the SAP
HANA on NetApp FAS Systems with FC Configuration Guide or the respective document for AFF.
You can also store SAP HANA data in VMware virtual machine disks (VMDKs) provided through NFS or
VMFS datastores. A storage design and sizing approach similar to the NFS or FCP setup should be
considered when planning to use VMDKs. VMware highly recommends creating individual datastores for
SAP HANA data and log VMDKs. The VMware best practices guides for SAP HANA provide more details
for this scenario.
Figure 3) Storage overview.
Network Design and Configuration

Because all data for SAP HANA instances, including performance-critical data and log volumes for the
database, is provided through NFS in this solution, proper network design and configuration are crucial. A
dedicated storage network is used to separate the NFS traffic from communication and user access traffic
between SAP HANA nodes. Each SAP HANA node requires a redundant dedicated network connection
with a minimum of 10Gb of bandwidth. 40GbE is also supported. This network must extend end to end
from the storage layer through network switching and computing up to the guest operating system hosted
on VMware vSphere. In addition to the physical switching infrastructure, a VMware distributed switch
(vDS) is used to provide adequate performance and manageability of network traffic at the hypervisor
layer.
FAS/AFF Systems
Figure 4) Network overview.
As is shown in Figure 4, each SAP HANA node uses a dedicated port group on the VMware distributed
switch. This port group allows for enhanced quality of service (QoS) and dedicated assignment of
physical network interface cards (NICs) on the ESX hosts. To use dedicated physical NICs while
preserving HA capabilities if there was a NIC failure, the dedicated physical NIC is configured as an
active uplink. Additional NICs are configured as standby uplinks in the teaming and failover settings of the
SAP HANA port group. In addition, jumbo frames (MTU 9,000) must be enabled end to end on physical
and virtual switches. In addition, turn off flow control on all 10GbE ports on servers, switches, and storage
systems. Figure 5 shows an example of such a configuration.
Note: In contrast to previous versions of this document, the latency sensitivity settings for VMs should
be left set to normal (default value).
For some NFS version and OS combinations, LRO (large receive offload) might need to be
turned off.
For all other network configuration guidelines, see the respective VMware best practices guides
for SAP HANA.
FAS/AFF Systems
Figure 5) VMware distributed switch configuration.
Computing Design and Configuration

Only SAP HANA certified and supported server systems can be used for SAP HANA production systems.
If VMware virtualization is used, these systems should also be VMware certified. Verify the SAP and
VMware support status before implementation.
At the time of writing, SAP provides full production support for SAP HANA on VMware vSphere 5.5 with
all SAP deployment options. vSphere 6.0 and 6.5 is fully supported for SAP HANA single host
deployments. SAP HANA multiple host support with vSphere 6.x was not available at the time of writing.
For an up-to-date support statement for SAP HANA on VMware vSphere, see the SAP HANA on VMware
Wiki Pages and the listed SAP support notes.
Advanced vSphere Datacenter features such as VMware vMotion, DRS, or VMware HA are supported by
SAP and VMware. These features can be used with single or multiple SAP HANA instances on the
virtualized infrastructure.
When sizing the compute environment, you must provide target SAP HANA instances available on the
ESX hosts with sufficient main memory. Due to the in-memory architecture of SAP HANA, memory
overcommitment is not supported. You can use SAP HANA VM system memory sizes of up to 1TB with
vSphere 5.5 and up to 4TB with vSphere 6.x. Once validated, vRAM sizes up to 6TB are supported with
vSphere 6.5.
You must provide proper bandwidth for high-performance storage access through NFS for the SAP HANA
instances. Therefore, at least one dedicated physical NIC per SAP HANA node serving as uplink to the
VMware distributed switch must be available on each server. For more information, see the section
“Network Design and Configuration.”
You should set up and configure SAP HANA VMs according to the VMware best practices guide for SAP
HANA single host and multiple host deployments on the SAP and VMware Virtualization page.
FAS/AFF Systems
2.2 Software
SAP HANA Deployment and Configuration

The installation of a new SAP HANA database on a VMware VM with NetApp storage can be subdivided
into the following tasks:
• VM deployment. One or more new VMs must be deployed for the SAP HANA database according to
the configuration rules and requirements described in the VMware SAP HANA best practices guides.
The VMs can be deployed by using a predefined template or by performing a fresh installation of an
operating system that supports SAP HANA. Examples include SUSE Linux Enterprise Server 11
Service Pack 3 (or later) and Red Hat Enterprise Linux for SAP HANA 6.5. As an addition to the
configuration guidelines from the best practices guides, a dedicated virtual NIC using the VMXNET3
driver for SAP HANA storage access must be added to each VM.
• Storage deployment. Figure 6 shows the volume configuration for four single-node SAP HANA
systems. The data and log volume of each SAP HANA system is distributed to different storage
controllers. For example, volume SID1_data is configured on controller A, and volume SID1_log is
configured on controller B. For each SAP HANA node, a data volume; a log volume; and a volume for
executables, configuration, and application logs are configured.
Figure 6) Volume layout for SAP HANA systems.
The volumes for a single SAP HANA system are directly mounted to the provisioned guest operating
system using the dedicated network connection to the storage. Storage and volume configuration
details can be found in the respective NetApp configuration guides.
• SAP HANA installation. After the VM, OS, and storage preparation steps are completed, a standard
SAP HANA installation is performed according to the SAP HANA installation and administration
guide. If you manage the SAP HANA database or application servers with SAP Landscape
Management (LaMa), including the relocation functionality, you should configure a virtual host name
for the database prior to the installation. When you deploy a VMware virtualized SAP HANA multiple
host system, a stand-by host is not required to protect the system. The steps for multiple host system
installation without a stand-by host are described in the VMware SAP HANA best practices guide.
FAS/AFF Systems
Application and Data Management Design
NetApp SnapCenter for SAP HANA

NetApp ONTAP software provides a built-in mechanism to back up SAP HANA databases. Storage-
based Snapshot backups are a fully supported and integrated backup solution available for SAP HANA
SPS7 and higher.
Storage-based Snapshot backups are implemented by using the NetApp SnapCenter® plug-in for SAP
HANA, which allows consistent storage-based Snapshot backups by using the interfaces provided by the
SAP HANA database. SnapCenter registers the Snapshot backups in the SAP HANA backup catalog so
that the backups are visible within the SAP HANA studio. They can then be selected for restore and
recovery operations.
By using SnapVault software, the Snapshot copies that were created on the primary storage can be
replicated to the secondary backup storage controlled by SnapCenter. Different backup retention policies
can be defined for backups on the primary storage and backups on the secondary storage. The
SnapCenter plug-in for SAP HANA manages the retention of Snapshot copy-based data backups and log
backups, including the housekeeping of the backup catalog. SnapCenter plug-in for SAP HANA also
allows you to perform a block-integrity check of the SAP HANA database by running a file-based backup.
The database logs can be backed up directly to the secondary storage by using an NFS mount, as shown
in Figure 7.
Figure 7) Backup architecture.
Storage-based Snapshot backups provide significant advantages compared to file-based backups. The
advantages include the following:
• Fast backup (less than a minute)
• Fast restore on the storage layer (less than a minute)
• No performance impact on the SAP HANA database host, network, or storage during backup
• Space-efficient and bandwidth-efficient replication to secondary storage based on block changes
To install the SnapCenter software and the SAP HANA plug-in, complete the following high-level steps:
FAS/AFF Systems
1. Install the SAP HANA hdbsql client software on a management server (communication host). The
management server can be a small additional VM deployed in the VMware vSphere environment; it
can be the host where SnapCenter is installed, or the SAP HANA host itself. More details about the
different deployment options can be found in the TR-4614: SAP HANA Backup and Recovery with
SnapCenter.
2. Install the SnapCenter software as described in the SnapCenter Software 3.0 Installation and Setup
Guide. SnapCenter requires management access to the FAS or AFF systems.
To perform the configuration, complete the following steps:
1. Create a backup user in SAP HANA and create the SAP HANA user store configuration.
2. Prepare SnapVault replication on all storage controllers.
3. Create volumes on the secondary storage controller.
4. Initialize the SnapVault relationships for database volumes.
5. Configure the SnapCenter framework and the SAP HANA plug-in.
A detailed description of the installation and configuration steps is provided in the TR-4614: SAP
HANA Backup and Recovery with SnapCenter.
SAP Landscape Management Configuration

The enterprise edition of the SAP LaMa software helps users reduce the TCO of their SAP systems and
improve their business agility. This software simplifies and automates the configuration, provisioning,
deployment, monitoring, and management of their systems in both physical and virtualized
infrastructures.
SAP LaMa provides a central point of control for assigning computing hosts and managing instances in
the system landscape. SAP LaMa is built on the following four key principles:
• Unification. Reduce the time and effort to transition to virtual and cloud environments by decoupling
the application from the underlying infrastructure. Transitions are also facilitated by a unified view and
management of the hardware, software, and virtualization layers and automated system relocation.
• Completion. Improve the ability to respond to business needs with support for the configuration,
deployment, monitoring, and management of your SAP systems and landscapes in both physical and
virtualized infrastructures. This support provides you with more infrastructure options and faster time
to value.
• Simplification. Simplify management of SAP landscapes by providing end-to-end visibility of your
systems, automating capacity management and other key functions, and hiding the technical
complexities of physical and virtualized infrastructures from day-to-day operations.
• Automation. Reduce the capital investment in and operational costs of your SAP systems with
capabilities that simplify and automate system copy, system clone, and system refresh operations.
You can also schedule system operations in advance with a built-in task planner and the leverage
virtualization to reduce hardware requirements and improve host utilization.
SAP LaMa is an optional component of this reference architecture. However, it can significantly improve
the manageability of SAP and SAP HANA landscapes, particularly when relocating SAP HANA systems
between virtual and physical servers. It is also useful when dealing with SAP HANA system replication
scenarios.
SAP LaMa is installed as an additional management system in the landscape. The installation of SAP
LaMa and the configuration of managed SAP landscapes are described in the document SAP Landscape
Management 3.0, Enterprise Edition.
FAS/AFF Systems
3 Use Cases
This section describes various important use cases for managing and operating SAP HANA
environments. We focus on some specific options and benefits that are available when running SAP
HANA on VMware vSphere and NetApp systems.
3.1 SAP HANA Backup and Recovery
Backup and Recovery with NFS, NFS Datastores, or Raw Device Mapping
This section provides an overview of backup and restore operations with SAP HANA stored in the
following ways:
• On NFS volumes mounted directly to the guest OS
• On NFS datastores
• On RDM disks mapped to the VM in an FCP environment
Backup
You can create SAP HANA Snapshot copy-based database backups by using the SnapCenter GUI, the
command line, the built-in SnapCenter scheduler, or an external scheduler such as the SAP LaMa task
scheduler.
When SnapCenter is backing up the database, it performs the following steps:
1. It triggers an SAP HANA synchronized backup save point to create a consistent database image on
the persistence layer.
2. It creates storage Snapshot copies for all data volumes of the database.
3. It registers the storage Snapshot backup within the SAP HANA backup catalog.
4. It deletes the SAP HANA backup save point.
5. It starts a SnapVault update for all data volumes (if configured and enabled).
6. It deletes storage Snapshot copies and deletes backups in the SAP HANA backup catalog based on
the defined retention policy for backups at the primary storage. Snapshot copies on the secondary
system are deleted based on the retention policy defined in ONTAP.
7. It deletes all log backups that are older than the oldest data backup on the file system and within the
SAP HANA backup catalog. This step is only executed if log backup cleanup is enabled. The
following screenshot depicts the SAP HANA backup catalog.
FAS/AFF Systems
This process is valid for NAS environments with NFS, and SAN environments using FCP and RDM.
In a setup where SAP HANA data is stored in VMDKs on NFS datastores, the NetApp volumes used for
the respective VMware datastores must be added to the HANA backup configuration in SnapCenter.
Note: Snapshot-based backups are always performed on the NetApp FlexVol volume level for each
SAP HANA system individually. If VMDKs of multiple different SAP HANA systems are stored
within the same datastore, Snapshot copies for these different SAP HANA systems are created in
the same volume. This might lead to a situation where the maximum number of possible
Snapshot copies per volume is reached and no further backups are possible. Therefore,
datastore layout and SAP HANA VMDK placement must be carefully planned ahead to avoid this
situation. Follow the VMware best practices for datastore layout.
Restore and Recovery

Restore and recovery of an SAP HANA database are performed using SAP HANA Studio and the
SnapCenter as follows:
1. Start the recovery process in SAP HANA Studio. Provide a valid log backup location and select a
valid data backup from the catalog. The external backup ID reflects the Snapshot name on the
storage level. The Snapshot name is needed later on for the restore process.
2. Within SnapCenter, restore the data volume of the SAP HANA system. The volume can be restored
either from the primary storage or from any existing SnapVault target location. As an alternative to a
volume restore, single-file restore is possible as well.
3. After the data is restored, the backup catalog view in SAP HANA studio must be refreshed. It then
shows that the restored backup is available for recovery. SAP HANA studio then performs the
remaining steps of the recovery process automatically.
In a setup where SAP HANA data is stored in VMDKs, the restore type (for example, volume or single-file
restore) is dependent on the datastore layout. Typically, single-file restore is the most appropriate way to
restore the VMDK where the SAP HANA datafiles are stored. The following screenshot depicts single-file
restore for SAP HANA stored in VMDKs.
More details about the backup and recovery procedures, including a detailed description about backup
replication, can be found in TR-4614: SAP HANA Backup and Recovery with SnapCenter.
Backup and Recovery with FCP and VMFS Datastores

In an FCP environment where the SAP HANA data and log files are stored on VMDKs in VMFS
datastores, the backup and recovery workflows are slightly different compared to the description above.
This section describes more details of this scenario.
FAS/AFF Systems
SAP HANA Database
We used an empty SAP HANA single-node database for all tests. The installed version of the SAP HANA
1.0 database is SPS12 running on the SuSE SLES 11 SP3 operating system. The following screenshot
depicts an SAP HANA H01 test database.
VMware Datastores for SAP HANA

The SAP HANA database installation requires three separate areas on the file system to store persistent
data:
• SAP HANA data. For database data files.
• SAP HANA log. For database online redo log files.
• SAP HANA shared. For binaries, trace files, configuration files, and so on.
According to the following VMware best practices:
• Architecture Guidelines and Best Practices for Deployments of SAP HANA on VMware vSphere, p.
55
• Best Practices and Recommendations for Scale-Out Deployments of SAP HANA on VMware
vSphere, p. 72
VMware highly recommends that you create a storage layout with separate and isolated VMware
datastores for SAP HANA data and log files.
According to the best practices for SAP HANA on NetApp with FC (TR-4436), create one LUN per
volume. The VMDKs for the shared area can be stored on a shared datastore for multiple SAP HANA
instances or on an NFS volume mounted to the OS directly.
The required datastores for the SAP HANA database can be provisioned using the NetApp Virtual
Storage Console (VSC). The following screenshots show the creation of the datastore for the SAP HANA
data volume. Because the used lab environment does not have an FC connection to the NetApp storage
system on all ESX hosts, the datastore is directly provisioned on one of the connected hosts instead of
the complete vSphere cluster.
1. Right-click the ESX cluster or (as shown in this case) dedicated ESX hosts and navigate to NetApp
VSC. Select the Provision Datastore option.
FAS/AFF Systems
2. Fill necessary information in the Provision Datastore wizard. The following screenshot depicts the
datastore summary in this example.
FAS/AFF Systems
With these settings, the VSC creates the following volume and LUN on the NetApp storage system
called Jamaica.
The following screenshot depicts the NetApp LUN for the datastore.
FAS/AFF Systems
VMware Virtual Machine for SAP HANA
To run the SAP HANA database, a separate VM is deployed. Separate VMDKs for SAP HANA data and
log files are added to the VM and stored in the respective datastores.
The VMDKs for data and log show up as regular SCSI devices inside the VM guest OS. These devices
have been formatted using the XFS file system and have been mounted to the appropriate location within
the file system according to the SAP HANA requirements (described in TR-4436).
FAS/AFF Systems
Backup of SAP HANA Database
The backup workflow is identical to the workflow described in TR-4614: SAP HANA Backup and Recovery
with SnapCenter.
The following screenshots show a backup run in the lab environment.
The backup job is detailed in the SnapCenter job view.
The related storage Snapshot copy resulting from the SAP HANA backup is shown in NetApp System
Manager.
FAS/AFF Systems
After successful completion the new backup is visible in the SAP HANA backup catalog in SAP HANA
studio.
Restore and Recovery of SAP HANA Database

The following sections describe how to restore and recover an SAP HANA database using either volume-
based restore or single-file restore. Although volume-based restores offer an easy method of restoring
Snapshot copy backups, additional actions are required for an active storage replication relationship (for
example, SnapVault or SnapMirror). In this case, a single-file restore might be more appropriate. For
more details, see TR-4614: SAP HANA Backup and Recovery with SnapCenter.
Volume-Based Restore
The following workflow describes the volume-based restore option.
1. Power off the SAP HANA virtual machine
2. Start the restore process in the SnapCenter GUI.
FAS/AFF Systems
3. Provide the restore details. Select Complete Resource as the restore type to perform a volume-level
restore. No other input is required.
4. Run the restore process and wait until it has successfully finished.
FAS/AFF Systems
5. Power on the SAP HANA virtual machine.
6. Start recovery in SAP HANA Studio.
7. Proceed through the wizard until the list of available backups is displayed. The restored backup is
flagged as available.
FAS/AFF Systems
8. Complete the SAP HANA recovery as usual.
FAS/AFF Systems
Single-File Restore
The single-file restore workflow is nearly the same as the volume-based restore. The only difference is
the actual restore operation option that is selected in SnapCenter.
1. Power off the SAP HANA virtual machine.
2. Start the restore process in the SnapCenter GUI.
3. Provide the restore details. Select File level as the restore type and select the LUN to restore.
4. Run the restore process and wait until it finishes successfully.
FAS/AFF Systems
5. Run the remaining steps (5 through 8) described in the volume-based restore workflow.
3.2 SAP HANA High Availability

There are several options available to address high-availability requirements for SAP HANA. There are
integral SAP HANA options like SAP HANA service auto-restart, SAP HANA host auto-failover for multiple
host deployments, and SAP HANA system replication in combination. These features can be used with
cluster management software like SuSE SLES HA. In an SAP HANA environment deployed on VMware
vSphere, VMware HA functionality offers an easy and yet powerful alternative to address most customer
SLAs for high availability.
The VMware HA feature for SAP HANA is applicable to both SAP HANA single-node and multiple host
deployments. In addition, it doesn’t require stand-by VMs and specific SAP HANA HA and disaster
recovery (DR) provider implementations, as is the case for the SAP HANA host auto-failover functionality.
For more information about the different HA options in a VMware virtualized SAP HANA environment,
read the VMware best practices guide for SAP HANA.
3.3 SAP HANA Disaster Recovery

Different options are available to prepare SAP HANA environments for DR scenarios. SAP HANA itself
provides DR capabilities on the application level using SAP HANA system replication. This process can
be used for both synchronous and asynchronous replication of data to a disaster site. The other options
are based on storage-based replication. For SAP HANA databases on NetApp systems, either
asynchronous replication using SnapMirror software or synchronous replication using NetApp
MetroCluster™ software can be used. Table 1 compares the recovery point objectives (RPOs) and
recovery time objectives (RTOs) of the different DR solutions.
Table 1) Disaster recovery options for SAP HANA.
SAP HANA System SAP HANA System NetApp SnapCenter NetApp

Replication with Replication with and SnapMirror MetroCluster
Dedicated DR Shared DR Servers
Servers
RTO Very low – hot Medium – cold Medium – cold Medium – cold
standby standby standby standby
FAS/AFF Systems
SAP HANA System SAP HANA System NetApp SnapCenter NetApp
Replication with Replication with and SnapMirror MetroCluster
Dedicated DR Shared DR Servers
Servers
RPO = 0 min Synchronous Synchronous N/A Synchronous
replication replication replication
RPO > 30 min Asynchronous Asynchronous Asynchronous N/A

replication replication replication
Servers can be No Yes Yes Yes

used for dev/test
Replication of No No Yes Yes

non-database
data
Disaster recovery No No Yes No

image usable for
dev/test refresh
Multiple images No No Yes Yes

to address logical
corruption
Asynchronous replication is handled by the SAP HANA plug-in for SnapCenter. This plug-in also
manages the Snapshot copy-based backup solution (see the previous section). In SAP HANA
environments based on vSphere, the disaster recovery process can be further optimized and streamlined
by using preconfigured VM templates for the DR site. In the case of a disaster, these VMs can be quickly
deployed on demand or powered on if they already exist.
In response to a disaster, use the following procedure for a failover of SAP HANA systems using
asynchronous storage replication and vSphere:
1. Deploy an SAP HANA disaster VM on the DR site from an existing template or power on an already
deployed VM.
2. Break the SnapMirror relationship on the target storage system that was used to asynchronously
replicate data to the DR site. Restore the DR volumes to an existing (usually the latest) storage
Snapshot copy.
3. Stop any SAP HANA nonproduction system on the DR site if the hardware resources have been
sized to run either nonproduction systems or DR systems exclusively.
Mount the DR volumes on the target VM and adjust the network settings if needed. If the SAP HANA
system is set up according to the SAP adaptive computing principle, mounting the volumes and adjusting
network settings can be performed using the prepare functionality of SAP LaMa (see also the use case
Follow the best practices for SAP HANA vMotion as outlined in the VMware HANA best practices
document starting on page 35.
4. SAP LaMa Relocation).
5. Start SAP HANA. If the configuration of the SAP HANA system on the DR site is not identical to the
production site, some postprocessing steps must be performed before starting SAP HANA.
See TR-4646 SAP HANA Disaster Recovery with Asynchronous Storage Replication Using SnapCenter
3.0 for more details.
FAS/AFF Systems
3.4 SAP HANA System Copy and Refresh
Typical SAP landscapes consist of one or more production SAP systems along with a number of
development, test, training, project, and sandbox systems. These non-production systems are often
created or refreshed based on data from the production system. This is also the case for system
landscapes based on SAP HANA databases.
Homogeneous system copies can be created by recovering an existing data backup. Using NetApp
Snapshot integration for backups along with NetApp FlexClone® technology and vSphere rapid VM
deployment, this task can be performed within minutes instead of hours or even days. Snapshot
integration can also save a significant amount of storage space because no data is copied initially. The
overall procedure differs slightly depending on whether you are performing an initial system copy or you
are refreshing an existing SAP HANA database.
For an initial system copy, you must first install the target system. You can then perform the database
refresh using the following steps:
1. Shut down the target database and unmount the data volume from the server.
2. Use the SnapCenter software to create a clone of the source database either by using an existing
backup or by creating a new backup on demand. The SnapCenter software creates the volume
clones and assigns export policies.
3. Mount the cloned data volume on the target host using the existing original mount point of the target
database.
4. The database must be recovered based on the cloned backup. There are two options for this
process:
 If the SAP HANA database should be rolled forward, a copy of the respective log files must be
available at the target host. The log files should be available either as a physical copy of the files
or by mounting the source log volume.
 The database can also be recovered without any logs if only the data up to the point in time of the
Snapshot backup is required. In this case, no additional logs must be copied.
5. To finalize the database refresh, the database must be recovered (see the section “SAP HANA
Backup and Recovery”). Start the SAP HANA recovery process using SAP HANA Studio and the
Snapshot backup information that was used to clone the volumes. If the database should be rolled
forward, make sure to provide the log backup location of the source system, as is seen in the
following screenshot, not the one from the target system.
6. After the database is completely recovered, the standard steps needed to complete a homogeneous
system copy on the SAP system (for example, logical system name conversion (BDLS), adjusting
remote function call connections (RFC), and so on) must be performed.
FAS/AFF Systems
More details about the different options for SAP HANA system copy and refresh processes can be found
in TR-4439: Optimizing SAP Lifecycle Management with NetApp Solutions for SAP HANA.
3.5 SAP HANA Relocation
VMware vMotion
VMware vMotion, a key feature of enterprise virtual infrastructure, enables live migration of a running VM
from one physical host to another. Migration of a VM with vMotion preserves the precise execution state
of a VM consisting of physical memory, storage, and the virtual device state (including CPU, network and
disk adapters, and SVGA). The VM continues to run throughout the migration process with minimal
impact on user workload and no disruption to network connectivity.
vMotion is a business continuity solution that brings invaluable benefits to administrators because it helps
prevent application downtime, enables zero-downtime maintenance and troubleshooting and improves
flexibility. vMotion is a key enabler of several VMware technologies, including vSphere DRS and vSphere
distributed power management (DPM). These technologies together create a dynamic, automated, and
self-optimizing data center.
Some of the features of vMotion include:
• Live migration of an entire VM across vSphere hosts without any requirement for shared storage
• A multi-NIC capability that transparently load-balances vMotion traffic over all of the NICs enabled by
vMotion
• Concurrent vMotion migrations to reduce overall migration time in VM evacuation scenarios
• Live migration on metro networks with round-trip latencies of up to 10ms
Follow the best practices for SAP HANA vMotion as outlined in the VMware HANA best practices
document starting on page 35.
SAP LaMa Relocation

SAP systems can be installed using the SAP adaptive computing approach to enable application
virtualization for SAP systems by decoupling the application from the operating system. Installing SAP
systems as adaptive-enabled systems is supported for all current systems based on NetWeaver,
including SAP HANA. Such systems can be relocated from one operating system to another, including
relocation from physical servers to VMs and back.
There are two important prerequisites for this functionality. First, all data that belongs to an SAP system
must reside on an enterprise storage system, and, second, this data must be made available on all
possible target hosts. These requirements are fulfilled with a certified NFS-based SAP HANA installation
on NetApp storage.
Using application virtualization for an SAP HANA database adds a great deal of flexibility to the
landscape. In particular, application virtualization overcomes temporary hardware constraints for large
SAP HANA systems that might currently prevent customers from running those SAP HANA databases on
VMs. For the time being, large SAP HANA database systems can be installed on physical servers. When
support for larger VMs is available, SAP HANA databases can easily be relocated to the vSphere
environment.
The process to relocate an SAP HANA database has the following main steps:
1. Stop the SAP HANA database.
2. Run the unprepare step of the SAP HANA database on the source host. In this step, the assigned
virtual IP address is removed from the operating system, and the SAP HANA volumes are
unmounted.
FAS/AFF Systems
3. Prepare the SAP HANA database on the target host. A virtual IP address is added to the target host,
and all necessary SAP HANA volumes are mounted.
4. Start the SAP HANA database on the target host. This can be another VM or a physical server.
These steps can be performed manually using SAP HANA studio to start and stop the database and
operating system commands for IP address handling and storage volume mounting and unmounting. If
SAP LAMA is installed in the environment, the built-in LAMA relocation functionality can be used as
shown in Figure 8.
Figure 8) SAP HANA relocation using SAP LAMA.
The relocate functionality of SAP LAMA is part of the standard edition. Therefore, no additional license is
needed for use.
4 Conclusion
SAP HANA customers require a high level of performance and data availability while preserving the
flexibility, manageability, and operational benefits of modern virtualized data centers. They typically have
large numbers of systems that are frequently created from copies of large production databases. These
customers cannot afford extended periods of downtime or performance degradation because of backups
or replication.
NetApp and VMware provide a complete end-to-end SAP HANA system environment and solution that
allows customers to maintain a high level of data security while still meeting stringent performance and
availability requirements.
FAS/AFF Systems
Where to Find Additional Information
To learn more about the information described in this document, see the following documents and/or
websites:
• TR-4290: SAP HANA on NetApp FAS Systems - Configuration Guide
http://www.netapp.com/us/media/tr-4290.pdf
• TR-4384: SAP HANA on NetApp FAS Systems with Fibre Channel Protocol - Configuration Guide
• TR-4435: SAP HANA on NetApp All Flash FAS Systems with NFS - Configuration Guide
• TR-4436: SAP HANA on NetApp All Flash FAS Systems with Fibre Channel Protocol - Configuration
Guide
• TR-4279: SAP HANA Disaster Recovery with Asynchronous Storage Replication Using SnapCreator
3.0
• TR-4614: SAP HANA Backup and Recovery with SnapCenter
• TR-4439: Optimizing SAP Lifecycle Management with NetApp Solutions for SAP HANA
• VMware SAP HANA Best Practices, Recommendations for Scale-Up and –Out deployments and
FAQ documents:
https://www.vmware.com/business-critical-apps/sap-virtualization/sap-hana
• VMware SAP HANA Best Practices and Architecture Guidelines:
https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/whitepaper/sap_hana_on_vm
ware_vsphere_best_practices_guide-white-paper.pdf
• SAP HANA on VMware vSphere SCN Blog:
https://wiki.scn.sap.com/wiki/display/VIRTUALIZATION/SAP+HANA+on+VMware+vSphere
• FAQ–SAP HANA tailored data center integration
http://www.sap.com/documents/2016/05/e8705aae-717c-0010-82c7-eda71af511fa.html
• Overview–SAP HANA tailored data center integration
http://www.sap.com/documents/2016/05/827c26ba-717c-0010-82c7-eda71af511fa.html
• White paper–SAP HANA Storage Requirements
http://www.sap.com/documents/2015/03/74cdb554-5a7c-0010-82c7-eda71af511fa.html
• SAP certified enterprise storage for SAP HANA
http://global.sap.com/community/ebook/2014-09-02-hana-hardware/enEN/enterprise-storage.html
• SAP Landscape Management 3.0, Enterprise Edition
http://help.sap.com/nwlvm
• SAP HANA Administration Guide
http://help.sap.com/hana/SAP_HANA_Administration_Guide_en.pdf
• SAP Note 1844468–Homogenous system copy on SAP HANA
http://service.sap.com/sap/support/notes/1844468
Version History
Version Date Document Version History
1.0 September 2014 Initial version
FAS/AFF Systems
Version Date Document Version History
2.0 April 2016 Update reflecting current product versions and support
3.0 March 2017 Update reflecting current product versions and support, including
backup and restore with VMFS datastores
4.0 December 2017 Update reflecting simplified restore process with FCP
FAS/AFF Systems
Refer to the Interoperability Matrix Tool (IMT) on the NetApp Support site to validate that the exact
product and feature versions described in this document are supported for your specific environment. The
NetApp IMT defines the product components and versions that can be used to construct configurations
that are supported by NetApp. Specific results depend on each customer’s installation in accordance with
published specifications.
Copyright Information
Copyright © 1994–2018 NetApp, Inc. All rights reserved. Printed in the U.S. No part of this document
covered by copyright may be reproduced in any form or by any means—graphic, electronic, or
mechanical, including photocopying, recording, taping, or storage in an electronic retrieval system—
without prior written permission of the copyright owner.
Software derived from copyrighted NetApp material is subject to the following license and disclaimer:
THIS SOFTWARE IS PROVIDED BY NETAPP “AS IS” AND WITHOUT ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, WHICH ARE HEREBY
DISCLAIMED. IN NO EVENT SHALL NETAPP BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
THE POSSIBILITY OF SUCH DAMAGE.
NetApp reserves the right to change any products described herein at any time, and without notice.
NetApp assumes no responsibility or liability arising from the use of products described herein, except as
expressly agreed to in writing by NetApp. The use or purchase of this product does not convey a license
under any patent rights, trademark rights, or any other intellectual property rights of NetApp.
The product described in this manual may be protected by one or more U.S. patents, foreign patents, or
pending applications.
RESTRICTED RIGHTS LEGEND: Use, duplication, or disclosure by the government is subject to
restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software
clause at DFARS 252.277-7103 (October 1988) and FAR 52-227-19 (June 1987).
Trademark Information
NETAPP, the NETAPP logo, and the marks listed at http://www.netapp.com/TM are trademarks of
NetApp, Inc. Other company and product names may be trademarks of their respective owners.
TR-4338-0118
FAS/AFF Systems

Sap Hana On Vmware Vsphere With Netapp Fas and All Flash Fas Systems

Uploaded by

Copyright:

Available Formats

Sap Hana On Vmware Vsphere With Netapp Fas and All Flash Fas Systems

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sap Hana On Vmware Vsphere With Netapp Fas and All Flash Fas Systems

Uploaded by

Copyright:

Available Formats

Technical Report

SAP HANA on VMware vSphere with NetApp

1.2 Introduction to NetApp Storage Systems for SAP HANA ................................................................................3

1.3 Introduction to VMware vSphere for SAP HANA.............................................................................................3

1.4 Customer Requirements .................................................................................................................................5

2 Reference Architecture Design and Deployment .............................................................................. 6

2.2 Software ........................................................................................................................................................10

3 Use Cases ............................................................................................................................................ 13

3.3 SAP HANA Disaster Recovery......................................................................................................................25

3.4 SAP HANA System Copy and Refresh .........................................................................................................27

3.5 SAP HANA Relocation ..................................................................................................................................28

Where to Find Additional Information .................................................................................................... 30

Version History ......................................................................................................................................... 30

1.1 Introduction to SAP HANA

1.2 Introduction to NetApp Storage Systems for SAP HANA

1.3 Introduction to VMware vSphere for SAP HANA

Figure 1) VMware vSphere overview.

vSphere 5.5 Compared to 6.x

1.4 Customer Requirements

2 Reference Architecture Design and Deployment

Figure 2) Hardware landscape overview.

Storage Design and Configuration

Figure 3) Storage overview.

Network Design and Configuration

Computing Design and Configuration

SAP HANA Deployment and Configuration

Figure 6) Volume layout for SAP HANA systems.

NetApp SnapCenter for SAP HANA

Figure 7) Backup architecture.

SAP Landscape Management Configuration

3.1 SAP HANA Backup and Recovery

Restore and Recovery

Backup and Recovery with FCP and VMFS Datastores

VMware Datastores for SAP HANA

Restore and Recovery of SAP HANA Database

4. Run the restore process and wait until it finishes successfully.

3.2 SAP HANA High Availability

3.3 SAP HANA Disaster Recovery

Table 1) Disaster recovery options for SAP HANA.

SAP HANA System SAP HANA System NetApp SnapCenter NetApp

RPO > 30 min Asynchronous Asynchronous Asynchronous N/A

Servers can be No Yes Yes Yes

Replication of No No Yes Yes

Disaster recovery No No Yes No

Multiple images No No Yes Yes

3.5 SAP HANA Relocation

SAP LaMa Relocation

Figure 8) SAP HANA relocation using SAP LAMA.

You might also like

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.