sap hana tdi on dell emc xtremio x2 storage … detailed information about the sap hana enterprise...

DELL EMC XTREMIO STORAGE CONFIGURATION BEST PRACTICES FOR SAP HANA TDI

XtremIO X1 and X2 Storage Arrays, Data Protection

March 2018

ABSTRACT

This configuration guide provides configuration best practices for deploying SAP HANA

using SAP tailored data center integration (TDI) on Dell EMC XtremIO X1 and X2 all-

flash storage arrays.

H13984.4

CONFIGURATION GUIDE

Copyright

2 Dell EMC XtremIO Storage Configuration Best Practices for SAP HANA TDI Configuration 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.

Copyright © 2018 Dell Inc. or its subsidiaries. All Rights Reserved. Dell, EMC, Dell EMC and other trademarks are trademarks of Dell Inc. or its subsidiaries. Intel, the Intel logo, the Intel Inside logo, and Xeon are trademarks of Intel Corporation in the U.S. and/or other countries. Other trademarks may be the property of their respective owners. Published in the USA 03/18 Configuration Guide H13984.4.

Dell Inc. believes the information in this document is accurate as of its publication date. The information is subject to change without notice.

Contents

3 Dell EMC XtremIO Storage Configuration Best Practices for SAP HANA TDI XtremIO X1, XtremIO X2, Data ProtectionConfiguration Guide

Contents

Introduction ................................................................................................................................... 4

Technology overview .................................................................................................................... 8

Design recommendations for XtremIO storage for SAP HANA ............................................... 14

XtremIO storage configuration ................................................................................................... 24

Host setup with XtremIO storage ............................................................................................... 28

SAP HANA setup with XtremIO X2 volumes .............................................................................. 30

Data protection for SAP HANA with XtremIO X2 ....................................................................... 32

XtremIO copy and refresh of SAP HANA ................................................................................... 42

References ................................................................................................................................... 51

Introduction


Introduction

Enterprises with large amounts of data need their data to be recent and available in real

time with fast response times and true interactivity. SAP HANA, a real-time data platform

that can be deployed as an on-premises appliance or in the cloud, incorporates software

components that are optimized on proven hardware that is provided by SAP’s SAP HANA

hardware partners. At the core of this platform is the SAP HANA in-memory database.

Dell EMC XtremIOTM is an all-flash storage array featuring a scale-out architecture. The

XtremIO system offers consistently high performance with low latency, efficient storage

with inline data deduplication and compression services, rich application-integrated copy

services, and outstanding management simplicity. XtremIO X2 is the successor to the

first-generation XtremIO storage array, XtremIO X1. XtremIO X2 builds on the unique

features of the XtremIO system to provide greater performance with even more agility and

simplicity for your data center and business.

SAP has certified XtremIO X1 and X2 as enterprise storage arrays that meet all SAP

HANA performance and functional requirements. This certification enables you to deploy

XtremIO for SAP HANA tailored data center integration (TDI) using your existing data

center infrastructure in a fully supported environment.

SAP HANA deployment models

A number of models are available for deploying SAP HANA in your data center. For more

information, see Dell EMC Ready Solutions for SAP HANA.

Figure 1 shows the appliance model and the TDI model.

Figure 1. SAP HANA appliance model compared with the SAP HANA TDI model

SAP HANA appliance model

By default, an SAP HANA appliance includes integrated storage, compute, and network

components. The appliance is pre-certified by SAP and shipped to customers with all

software components installed, including the operating system. You can implement SAP

HANA appliances faster and SAP supports them fully.

Business case

Solution

overview

https://www.dellemc.com/en-us/solutions/business-applications/sap/hana/index.htm

Introduction


SAP HANA TDI model

With the TDI model, customers have greater flexibility and more responsibility for their

data center infrastructure. They align with hardware partners on individual support

models. The SAP HANA servers must still meet the SAP HANA requirements and be

certified SAP HANA servers, but the network and storage components can be shared in

customer environments. Customers can use their existing enterprise storage arrays and

integrate SAP HANA into existing data center infrastructure operations for disaster

recovery, data protection, monitoring, and management. This capability reduces the time-

to-value, risk, and costs of an overall SAP HANA adoption.

XtremIO with SAP HANA

SAP certifies the enterprise storage arrays that are used in SAP HANA TDI deployments

to ensure that they meet the SAP HANA performance and functional requirements. Dell

EMC performed extensive testing on the XtremIO X1 and X2 all-flash storage arrays using

the SAP HANA Hardware Configuration Check Tool (hwcct) with the following SAP

certification scenarios:

XtremIO X1―HANA-HWC-ES 1.0

XtremIO X2―HANA-HWC-ES-1.1

This guide provides storage configuration recommendations for the XtremIO arrays based

on the results of these tests. The recommendations meet SAP performance requirements

and ensure the highest availability for database persistence on disk.

Note: SAP recommends that TDI customers run the hwcct tool in their environment to ensure that

their specific SAP HANA TDI implementation meets the SAP performance criteria. For more

information, see SAP Note 1943937 - Hardware Configuration Check Tool - Central Note (access

requires an SAP username and password).

This guide describes SAP HANA TDI deployments in physical environments. If you plan to

use SAP HANA in VMware virtualized environments on vSphere, see the VMware

Virtualized SAP HANA with Dell EMC Storage Solution Guide.

http://service.sap.com/sap/support/notes/1943937

http://www.emc.com/collateral/technical-documentation/h14721-vmware-virtualized-sap-hana-emc-storage-sg.pdf

http://www.emc.com/collateral/technical-documentation/h14721-vmware-virtualized-sap-hana-emc-storage-sg.pdf

Introduction


The SAP HANA TDI on XtremIO storage solution provides the following benefits:

Integrates SAP HANA with XtremIO X1 and X2 into an existing data center

infrastructure.

Ensures fast and simple setup with little to no storage tuning requirements.

Enables easy transition to the new architecture and provides Dell EMC services to

minimize risk.

Uses shared enterprise storage to rely on already-available, multisite concepts to

benefit from established automation and operations processes.

Achieves data reduction rates of 2:1 when used with SAP HANA System

Replication (HSR) for SAP HANA high availability (HA), multiplying the effective

capacity of the same XtremIO cluster.

Achieves global data reduction with a highly integrated, always-on, inline data

deduplication and compression architecture, increasing the return on investment in

the XtremIO all-flash array.

Enables faster read operations with faster database restarts, host auto-failovers,

log backups, database recoveries, and table loads.

Enables writable XtremeIO Virtual Copies (XVC) of production and nonproduction

SAP HANA databases to be created and refreshed at near-instant speeds for the

entire SAP HANA system copy/refresh and post-copy automation production and

nonproduction lifecycle management process.

Enables efficient storage protection and recovery with the Dell EMC Data DomainTM

system and Dell EMC DD Boost™ software. Greater throughput, a reduced storage

footprint, and reduced network bandwidth requirements are achievable because

only unique data is sent to the Data Domain system.

This guide provides the following information:

An introduction to the key technologies in the SAP HANA TDI on XtremIO solution

A description of the configuration requirements and storage design principles for

XtremIO X1 and X2 enterprise storage arrays for SAP HANA TDI deployments

Best practices for deploying the SAP HANA database on XtremIO X1 and X2

enterprise storage arrays

Detailed instructions for accessing XtremIO X2 storage from the SAP HANA nodes

to set up SAP HANA

Steps for copying and refreshing SAP HANA systems with XVC

Steps for configuring the Data Domain system and DD Boost software for SAP

HANA backup and recovery

This guide is for system integrators, storage administrators, partners, members of Dell

EMC Professional Services, and others who are configuring XtremIO X1 and X2 all-flash

storage arrays to use in a TDI environment for SAP HANA. Users must have appropriate

SAP HANA and XtremIO skills as well as an understanding of SAN technologies and

Linux operating systems.

Key benefits

Scope

Audience

Introduction


Dell EMC and the authors of this document welcome your feedback on the solution and

the solution documentation. Contact [email protected] with your

comments.

Authors: Donagh Keeshan, Werner Katzenberger, Jarvis Zhu, Pete Shi, Aighne Kearney

We value your

feedback

mailto:[email protected]?subject=Feedback:%20Dell%20EMC%20XtremIO%20Storage%20Configuration%20Best%20Practices%20for%20SAP%20HANA%20TDI%20(H13984.4)

Technology overview


Technology overview

The XtremIO array is an all-flash system based on flexible scaling options. The array uses

Dell EMC X-BrickTM building blocks. As Figure 2 shows, X-Brick blocks can be clustered

together to grow performance or capacity, or both, as required. The system incorporates a

user-friendly interface that makes it easy to provision and manage the array.

Figure 2. XtremIO X2 system specifications

The XtremIO array takes advantage of flash technology to provide value across the

following dimensions:

Performance―Predictable and consistent high performance with low sub-

millisecond latency.

Scalability―XtremIO storage can be expanded for capacity only (scale-up) or both

capacity and performance (scale-out).

Efficiency―The core engine implements content-based inline data reduction and

thin provisioning, resulting in better performance due to reduced writes, increased

endurance of the flash disks, and fewer physical capacity requirements.

Data protection―The array uses a proprietary flash-optimized data protection

algorithm, XtremIO Data Protection (XDP), which provides superior RAID

performance.

Integrated copy data management―XtremIO technology supports the

consolidation of many different workloads and copies of those workloads (for

example, test and development) on one array. You can create a larger number of

high-performance and space-efficient copies using XVC.

The XtremIO X2 array builds on the unique features of the XtremIO X1 system. The

XtremIO X2 model includes 50 percent more cores and twice as much RAM in the storage

controllers. Coupled with support for 16 Gb Fibre Channel (FC), the X2 model can provide

higher performance with more agility and simplicity for your data center and business.

For more information, see the following documents:

XtremIO X1 System Specifications

XtremIO X2 Specifications

XtremIO storage

array

https://www.emc.com/collateral/data-sheet/h12451-xtremio-4-system-specifications-ss.pdf

http://www.emc.com/collateral/specification-sheet/h16094-xtremio-x2-specification-sheet-ss.pdf

Technology overview


X-Brick blocks

An XtremIO cluster is composed of one or more X-Brick blocks, depending on the

capacity and performance required. An XtremIO X2 X-Brick block is composed of two

server storage controllers loaded with XtremIO Operating Environment (OE) software, a

disk array enclosure (DAE) filled with 18-72 enterprise flash drives (EFDs), and two

battery backup unit (BBU) assemblies.

Figure 3 shows an X-Brick, the basic building block of an XtremIO array.

Figure 3. XtremIO X2 X-Brick block

To accommodate a range of capacity requirements, the XtremIO X2 X-Brick is available in

two configurations, X2-S and X2-R, with different solid-state drive (SSD) sizes and

controller compute power, as follows:

XtremIO X2-S―The S configuration is suitable for lower capacities and higher I/O

density use cases, where deduplication ratios are very large or very large numbers

of active snapshots are used.

XtremIO X2-R―The R configuration is suitable for higher capacity requirements

and generic use cases.

Both configurations fulfill the SAP HANA key performance indicators (KPIs) for enterprise

storage arrays. The initial release of the X2-R supports scale-out of up to four X-Brick

blocks. Future releases will add support for scale-out of up to eight X-Brick blocks. Table

1 provides more information about the X2-S and X2-R configurations.

Table 1. XtremIO X2 X-Brick configurations: X2-S and X2-R

Configuration Minimum raw capacity per X-Brick block

Maximum raw capacity per X-Brick block

Maximum number of X-Brick blocks

X2-S 7.2 TB 28.8 TB 4

X2-R 34.5 TB 138.2 TB 4 (8 after general availability)

Before ordering, decide which option is better for your deployment. You cannot mix the

two X-Brick types in a single cluster/system, and you cannot transform one

X-Brick type to the other.

Technology overview


Scale-out architecture: Linear expansion of capacity and performance

XtremIO storage is designed to scale out to meet future performance and capacity needs

by using additional X-Brick blocks. The XtremIO X2 system begins with a single X-Brick

block, with a minimum of 18 SSDs. When additional capacity is required, the system

scales up, with up to 72 SSDs for a single X-Brick block. You can expand the system for

additional performance and capacity by adding X-Brick blocks.

When the cluster expands, resources remain balanced, and data in the array is distributed

across all X-Brick blocks to maintain consistent performance and equivalent flash wear

levels. With clusters of two or more X-Brick blocks, XtremIO uses a redundant 56 Gb/s

(4xFDR) InfiniBand network for back-end connectivity between the storage controllers,

ensuring a highly available, ultra-low-latency network. Multiple X-Brick clusters include

two InfiniBand switches. A single X-Brick cluster does not require any InfiniBand switches.

Note: An XtremIO X1 array can have up to eight X-Brick blocks in a cluster. With XtremIO X2, the

X2-S and X2-R configurations can have up to four X-Brick blocks in a cluster. Future X2-R models

will support up to eight X-Brick blocks.

Inline data reduction

The XtremIO array provides inline data reduction by using the following techniques.

Inline data deduplication

Inline data deduplication is the removal of duplicate I/O blocks from data before the data

is written to the flash media. XtremIO deduplication is always on and inline, which means

that, unlike many systems on the market, the array deduplicates data as it enters the

system without a need for post-processing. The XtremIO system has no resource-

consuming background processes and none of the additional reads/writes that are

associated with post-processing. Therefore, the process does not negatively affect the

performance of the storage array, does not waste the available resources that are

allocated for the host I/O, and does not consume flash wear cycles. Deduplication is

performed at a global level, which means that no duplicate blocks are written over the

entire array.

Inline data compression

Inline data compression is the compression of the already-deduplicated data before the

data is written to the flash media. The XtremIO system automatically compresses data

after all duplications have been removed, which ensures that the compression is

performed only for unique data blocks. Data compression is performed in real time and

not as a post-processing operation. The compressed data block is then stored on the

array. The nature of the data set determines the overall compressibility rate.

Compression reduces the total amount of physical data that needs to be written on solid-

state drives (SSDs). This reduction minimizes the write amplification (WA) of the SSDs,

improving the endurance of the flash array.

XtremIO inline data reduction with the SAP HANA database

The XtremIO inline data reduction feature provides significant space-saving efficiencies

for SAP environments. The raw advantages of applying inline data reduction to an

optimized SAP HANA database might vary and can be highly data-specific. The SAP

HANA database uses a column format for most of the tables (some tables are stored in a

row store). Because the column format is already highly compressed, the benefit of the

additional XtremIO X2 compression data service is low. The data reduction rate of the

Technology overview


inline deduplication depends primarily on the workload of the application running on top of

the SAP HANA database. We achieved XtremIO data reduction ratios of approximately

1.6:1 in our testing with the SAP HANA database.

Thin provisioning

XtremIO storage is natively thin-provisioned using a small internal block size, which

allocates capacity on demand in fine-grained increments. All volumes in the cluster are

thin-provisioned, which means that the cluster consumes capacity only when capacity is

needed. The array determines where to place the unique data blocks inside the physical

X-Brick cluster after calculating their fingerprint IDs. It never pre-allocates or thick-

provisions storage space before writing.

Data protection

The XtremIO storage system provides "self-healing" double-parity data protection, called

XDP.

The system requires very little capacity overhead for data protection and metadata space,

and does not require dedicated spare drives for rebuilds. Instead, it uses the "hot space"

concept, where any free space that is available in the array can be used for failed-drive

reconstructions. The system always reserves sufficient distributed capacity for performing

a single rebuild.

Because all SSD Flash modules are under XDP protection, XDP eliminates the need to

explicitly design different RAID types for SAP HANA to balance performance and

capacity. Incoming I/O is fully distributed and evenly balanced across all X-Brick blocks

and all SSD modules, regardless of the I/O profile. Accordingly, XDP simplifies capacity

sizing for SAP HANA by taking protection, I/O profile, and complex drive count

calculations out of the equation. The SAP HANA design process is simplified to the

number of X-Brick blocks and choice of capacity for each block.

XtremIO Virtual Copies (XVC)

The XVC snapshot implementation within the XtremIO system uses the array's inline data

reduction to ensure that duplicate data blocks are never written to physical disk within the

array. XVC can be used to provide multiple test and development copies of the SAP

HANA production database. XVC efficiency enables multiple copies of the SAP HANA

database to be created based on demand for maximum business efficiency rather than on

storage capacity or performance limitations. Also, the copies can be refreshed from the

production database volumes to provide the latest data content.

Virtual copies can be refreshed from other virtual copies. This might be useful where data

scrambling with third-party tools is required to protect sensitive data for test and training

systems. Provisioning more virtual copies is an easy and instantaneous process.

SAP HANA is an in-memory database. The data is kept in the RAM of one or multiple

SAP HANA worker hosts. All database operations, such as reads, inserts, updates, and

deletes, are performed in the main memory of the host. This feature differentiates SAP

HANA from other traditional databases, where only a part of the data is cached in RAM

and the remaining data resides on disk.

To ensure that the SAP HANA database can always be restored to its most recent

committed state, persistent storage is used to provide a fallback in case of failure. The log

SAP HANA

database

Technology overview


captures all changes by database transactions (redo logs), and data and undo log

information is automatically saved to disk at regular savepoints.

Scale-up compared to scale-out

As SAP-certified enterprise storage for SAP HANA, XtremIO X1 and X2 arrays can be

used for both single-host SAP HANA (scale-up) systems and multihost SAP HANA (scale-

out) systems in TDI deployments.

In single-host environments, the database needs to fit into the RAM of a single server.

Single-host environments are preferred for online transaction processing (OLTP)-type

workloads such as SAP Business Suite on SAP HANA.

In multihost environments, the database tables are distributed across the RAM of multiple

servers. Multihost environments use worker hosts and standby hosts. A worker host

accepts and processes database requests and is an active component. A standby host

waits for a failure of a worker host so that it can take over its role. This process is called

host auto-failover. A standby has all database services running, but it has no data in RAM.

Because the in-memory capacity in these deployments can be quite high, scale-out SAP

HANA clusters are perfectly suited for online analytical processing (OLAP)-type workloads

with very large data sets, such as SAP Business Warehouse (BW) on SAP HANA.

SAP HANA file systems

Table 2 describes the required file system structure of an SAP HANA setup. For more

information, see the SAP HANA Server Installation and Update Guide on the SAP Help

Portal.

Table 2. SAP HANA file system structure

File system Default path Description

Root / Root partition.

Installation path

/hana/shared/

Mount directory, which is used for shared files between all hosts in an SAP HANA system. This directory must be accessible to each of the servers in the SAP HANA scale-out system.

System instance

/usr/sap Path to the local SAP system instance directories.

Data volume

/hana/data/<SID> Default path to the data directory, which depends on the system ID of the SAP HANA host.

Log volume /hana/log/<SID> Default path to the log directory, which depends on the system ID of the SAP HANA host.

SAP HANA persistence

SAP HANA uses disk storage to maintain the persistence of the in-memory data on disk.

SAP HANA persistence prevents a loss of data in the event of a power outage and

enables host auto-failover, where a standby SAP HANA host takes over the in-memory

data and redo logs of a failed worker host in scale-out installations. For these purposes,

each SAP HANA worker host (scale-out) or single host (scale-up) requires two file

systems on disk storage, one for data files and one for log files.

http://help.sap.com/hana_platform/

http://help.sap.com/hana_platform/

Technology overview


SAP HANA persists in-memory data by using savepoints. Each SAP HANA service has its

own separate savepoints. The data belonging to a savepoint represents a consistent state

of the data on disk and remains so until the next savepoint operation has completed.

During a savepoint operation, the SAP HANA database flushes all changed data from

memory to the data volumes. Redo log entries are written to the log volumes for all

changes to persistent data. In the case of a database restart (after a crash, for example),

the data from the last completed savepoint can be read from the data volumes, and the

redo log entries that were written to the log volumes since the last savepoint can be

replayed.

SAP HANA I/O patterns

The SAP HANA persistent file systems have different I/O patterns. For more information,

see SAP HANA Storage Requirements. During normal operations, the SAP HANA

workload is predominantly write-intensive.

Data file system

Access to the data file system is primarily random, with various block sizes going from

small (4 KB) up to large (64 MB) blocks. The data is written asynchronously with parallel

I/O to the data file system. During normal operations, most of the data file system I/O

operations are writes. Data is read from the data file system only during a database

restart, HA failover, or column store table load.

Log file system

All changes in the database are captured in the redo log on the log file system. The log

file is written with sequential I/O with block sizes ranging from 4 KB up to 1 MB.

Because data is written synchronously to the log file system on commits, a low latency for

I/O to the storage device is important, especially for the smaller 4 KB and 16 KB block

sizes.

As with the data file system, during normal database operations, most I/O operations of

the log file system are writes. Data is only read from the log file system during a database

restart, HA failover, or log backup or database recovery.

Faster reads with the XtremIO array

XtremIO all-flash arrays provide benefits in high-read scenarios. We compared read

operations with traditional disk storage arrays without flash technology to the read

operations with XtremIO, using SAP HANA to load both column and row tables into

memory. Test results with the XtremIO array showed faster reads ranging from 15 percent

to 60 percent. The larger the dataset, the greater the benefit. The faster read operations

with XtremIO all-flash arrays enable faster database restarts, host auto-failovers, log

backups, database recoveries, and table loads (including lazy loads).

Note: With an SAP HANA restart, only the row tables are loaded into memory, while column

tables are lazy-loaded into memory after the database restart. Therefore, the number and size of

the row tables influence the restart times.

http://scn.sap.com/docs/DOC-62595

Design recommendations for XtremIO storage for SAP HANA


Virtual environments

You have the option to run SAP HANA on the VMware vSphere virtualized infrastructure.

Some restrictions apply to virtualized environments, such as the maximum RAM size of

an SAP HANA node. See the corresponding SAP OSS notes and follow VMware best

practices to deploy SAP HANA on vSphere.

For the SAP HANA persistence on XtremIO arrays, all physical configuration

recommendations in this guide also apply to virtual environments. With virtual

environments, also consider the following recommendations:

SAP HANA persistence in a virtual environment—Add the data and log LUN fora virtual SAP HANA host to the ESX host and create a Virtual Machine File System(VMFS) datastore for each LUN. You can then create one virtual disk per VMFSdatastore and add it as the data or log LUN to the SAP HANA virtual machine. SeeVMware best practices for an optimized virtual SCSI adapter.

vSphere Multipathing—An SAP HANA virtual machine does not use Linux DeviceMapper Multipath within the virtual machine. The data and log LUNs are visible as a

single device. For example, /dev/sdb and the XFS file system must be created on

this single device.

On the ESX host, we recommended using Dell EMC PowerPathTM/VE to

intelligently manage I/O paths and optimize I/O performance.


SAP HANA production systems in TDI environments must meet the SAP KPIs. Unless

otherwise stated, the configuration recommendations in the following sections apply to

SAP HANA production systems that are deployed on both XtremIO X1 and X2 storage

arrays.

The scalability of SAP HANA depends primarily on the number of configured X-Brick

blocks in either XtremIO X1 or X2 systems.

XtremIO X1 scalability

Table 3 shows the number of X-Brick blocks and the maximum number of SAP HANA

worker hosts that can be connected to XtremIO X1 arrays.

Table 3. XtremIO X1 scalability

Number of XtremIO X-Brick blocks per cluster

Maximum number of SAP HANA worker nodes

1 4

2 8

4 14

6 20

XtremIO

scalability



The scalability numbers in the table are recommendations that are based on SAP HANA

performance tests that we performed on one-brick and two-brick clusters without

competing workloads. Use these guidelines to estimate the initial number of SAP HANA

production nodes that can be connected to a specific XtremIO X1 cluster configuration.

XtremIO X2 scalability

Table 4 shows the results of tests that we performed on XtremIO X2 X-Brick clusters

using the SAP HANA hardware configuration check tool (hwcct). We tested one-brick and

two-brick clusters separately and performed the tests without competing workloads. Use

the guidelines in Table 4 to estimate the initial number of SAP HANA production nodes

that can be connected to a specific XtremIO X2 cluster configuration.

Table 4. XtremIO X2 scalability

Configuration

Number of SAP HANA production nodes

Dedicated 16 GB/s FC ports (minimum/recommended)

Usable capacity (TB)1

X2-S X2-R

One-brick cluster

7 2/4 5.4–24 27–123

Two-brick cluster

14 4/8 11–48 55–246

Three-brick cluster

21 6/12 16–72 83–369

Four-brick cluster

28 8/16 21–97 111–493

Five-brick cluster

35 10/20 To be determined

(tbd)2

tbd

Six-brick cluster

42 12/24 tbd tbd

Seven-brick cluster

49 14/28 tbd tbd

Eight-brick cluster

56 16/32 tbd tbd

1 Usable capacity is the amount of unique, noncompressible data that can be written into the array.

2 These numbers are not available at the time of writing. To find out when the larger clusters will be

available, contact your Dell EMC representative.

The XtremIO X2 systems can scale up and scale out depending on the requirements of

the business. If the SAP HANA nodes require additional capacity, you can scale up an

XtremIO X2 X-Brick by adding up to 72 additional SSDs per X-Brick block. If additional

SAP HANA nodes are required and the existing X-Brick blocks already support seven

SAP HANA nodes, you can scale out the system by adding X-Brick blocks.



Nonproduction SAP HANA systems

SAP has not defined KPIs for nonproduction SAP HANA systems, and users of

nonproduction SAP HANA systems might be willing to accept higher response times and

lower performance. For this reason, the XtremIO X2 system can support more

nonproduction SAP HANA nodes than the numbers that are specified in Table 5.

As a general rule, use the number of worker nodes in Table 5 multiplied by 1.5 to

determine the number of nonproduction SAP HANA nodes that your setup supports.

Mixed production and nonproduction SAP HANA systems

Most customers run a mix of production and non-production SAP HANA systems in their

environment. Use the following examples to determine the number of SAP HANA nodes

that can be connected to your XtremIO X2 system.

Example 1

One-brick cluster with a maximum of seven production SAP HANA nodes:

Three production SAP HANA nodes, running

Four additional slots for production SAP HANA nodes, unused

Up to six (4 x 1.5) possible nonproduction SAP HANA nodes

Example 2

Four-brick cluster with a maximum of 28 production SAP HANA nodes:

12 production SAP HANA nodes, running

16 additional slots for production SAP HANA nodes, unused

Up to 24 (16 x 1.5) possible nonproduction SAP HANA nodes

Mixed workloads

In some environments, customers might plan to run mixed (production and nonproduction)

SAP HANA systems, as well as non SAP HANA workloads such as traditional SAP

NetWeaver or non SAP workloads. Consider the workload characteristics and

requirements of the non SAP HANA workload to avoid a negative impact on the

performance of the SAP HANA system.

An XtremIO X2 one-brick cluster can provide 6 GB/s bandwidth with 100 percent reads

and approximately 1.8 GB/s bandwidth with 100 percent writes. The maximum read KPI

for an SAP HANA node is 400 MB/s, while the maximum write KPI is 200 MB/s.

Example

One-brick cluster:

Three production SAP HANA nodes:

3 x 400 MB/s read = 1,200 MB/s read bandwidth required

3 x 200 MB/s write = 600 MB/s write bandwidth required

Three nonproduction SAP HANA nodes (divide KPIs by 1.5):

3 x 267 MB/s = 801 MB/s read bandwidth required

3 x 133 MB/s = 399 MB/s write bandwidth required



Total SAP HANA bandwidth requirements:

Approximately 2 GB/s read (1,200 + 801)

Approximately 1 GB/s write (600 + 399)

Bandwidth available for non SAP HANA workloads:

6 GB/s – 2 GB/s = 4 GB/s read bandwidth required

1.8 GB/s – 1 GB/s = 600 MB/s write bandwidth required

We recommend that you regularly monitor mixed environments and verify the

performance of the SAP HANA production nodes.



This section addresses general considerations that arise when you connect SAP HANA to

an XtremIO array.

Host connectivity

The SAP HANA nodes connect to the XtremIO array through a Fibre Channel (FC) SAN.

Follow these recommendations:

Ensure that the SAN topology follows best practices with all redundant components

and links.

Establish dual fabric between the SAP HANA nodes and the XtremIO storage

arrays.

Set a link speed of 16 GB/s on the switch ports.

The SAP HANA nodes require one connection to each fabric. For HA, use two host bus

adapters (HBAs). A single dual-port HBA is a single point of failure (SPOF). We

recommend a link speed of 16 Gb/s on the HBAs. SAP HANA requires a minimum link

speed of 8 Gb/s.

XtremIO connectivity

Consider the following best practices when connecting SAP HANA nodes to the storage

controller ports of an XtremIO array:

Never connect a single HBA to both ports of the same storage controller.

Balance the hosts between the storage controllers to provide a distributed load across all target ports.

Connect all SAP HANA hosts to all storage controller ports.

Note: XtremIO X1 arrays use 8 Gb/s FC ports. XtremIO X2 arrays use 16 Gb/s FC ports.

Figure 4 shows the back of the XtremIO X1 X-Brick with 2-port FC I/O modules (8 Gb/s)

for host connectivity. Each SAP HANA node must connect to two FC ports, one to storage

controller (SC) 1 and one to SC 2.

Figure 4. Rear view of an XtremIO X-Brick

SAN connectivity



Each XtremIO X2 brick has two storage controllers (SC1 and SC2), each with two 16 Gb/s

FC ports (SC1-target3, SC1-target4, SC2-target3, SC2-target4), as shown in Figure 5.

Figure 5. XtremIO X2 brick with storage controllers

Connect the target3 ports to your Fabric-A and the target4 ports to your Fabric-B. In an XtremIO X2 cluster with multiple X-Brick blocks, connect all FC ports similarly.

Zoning

We recommend single-initiator (HBA), dual-target (storage FC ports) zoning (four paths

per host).

With a single XtremIO X2 brick, you must zone HBA1 of the SAP HANA hosts in Fabric-A

to the target3 ports on both storage controllers and HBA2 in Fabric-B to both target4

ports. This configuration results in four active data paths from the SAP HANA host to a

storage device, as shown in Figure 6.

Figure 6. XtremIO X2 one-brick cluster



The total number of production SAP HANA nodes that are zoned to a storage port cannot

exceed seven.

In an XtremIO X2 cluster with multiple X-Brick blocks, distribute the connections evenly

across all storage controllers and target ports. Table 5 and Figure 7 show an example of

an XtremIO X2 three-brick cluster with 21 connected SAP HANA nodes. Connections are

evenly distributed across all front-end ports, and each of the SAP HANA nodes has four

active paths.

Table 5. XtremIO X2 cluster example with 21 connected nodes

Node HBA Connection

Nodes 1–7 HBA1 Brick-1 – SC1 – target3

HBA1 Brick-2 – SC1 – target3











Figure 7. XtremIO X2 three-brick cluster with 21 connected nodes



Volume mapping

The XtremIO array uses volume mapping to assign storage to a host. Initiator groups

contain the initiators (WWNs) from the HBAs of the SAP HANA host. Each SAP HANA

host must be connected to the XtremIO system with at least two HBAs for redundancy.

Create one initiator group for every connected SAP HANA node.

An SAP HANA scale-out cluster uses the shared-nothing concept for the persistence of

the database. With shared-nothing persistence, each SAP HANA worker host uses its

own pair of data and log volumes and has exclusive access to these volumes during

normal operations. If an SAP HANA worker host fails, the SAP HANA persistence of the

failed host is mounted to a standby host. This concept requires that all persistent devices

be visible to all SAP HANA hosts because every host can become a worker or a standby

host. Therefore, all SAP HANA data and log volumes must be mapped to each SAP

HANA host using initiator groups.

Using LUN 0 with XtremIO storage

This section provides information about using LUN 0 with Linux. For more information,

see the Dell EMC Host Connectivity Guide for Linux.

The following output to the iSCSI command indicates that the device at 1:0:0:0 is the

XtremIO cluster controller:

[1:0:0:0] storage XtremIO XtremApp 3000 –

In this case, an XtremIO volume with LUN 0 is inaccessible to the host.

To access a volume with a LUN 0 on a Linux host, perform the following steps.

Note: If you do not complete the following steps, you must start with LUN 1 when configuring the

LUN IDs for the XtremIO array.

Run one of the following commands to remove the controller device:

# /usr/bin/rescan-scsi-bus.sh –r

Note: -r enables the device removal.

# echo 1 > /sys/class/scsi_device/1:0:0:0/device/delete

Run the following command:

# /usr/bin/rescan-scsi-bus.sh

Note: Some Linux versions might require a host restart instead of a rescan.

Every SAP HANA node requires storage devices and capacity for the following items:

Operating system boot image

SAP HANA installation (/hana/shared)

SAP HANA persistence (data and log)

Backup

Capacity

requirements

http://www.emc.com/collateral/TechnicalDocument/docu5128.pdf



For more information, see SAP HANA Storage Requirements. The formulas for capacity

sizing in this document are subject to change by SAP. Always check these formulas

before you determine capacity requirements.

Operating system boot image

When the SAP HANA nodes boot from a volume on XtremIO (boot from SAN), include the required capacity for the operating system in the overall capacity calculation for the SAP HANA installation. Every SAP HANA node requires approximately 100 GB capacity for the

operating system. This capacity includes space for the /usr/sap/ directory.

When booting from SAN, follow the best practices in the Dell EMC Host Connectivity

Guide for Linux.

SAP HANA installation (/hana/shared/)

To install the SAP HANA binaries, as well as the configuration files, traces, and logs,

ensure that every SAP HANA node has access to a file system that is mounted under the

local /hana/shared/ mount point. An SAP HANA scale-out cluster requires a single

shared file system that is mounted on every node. Most SAP HANA installations use an

NFS file system. The file system you choose depends on your infrastructure and

requirements. The options for the file systems are:

NFS-server-based shared file system.

NAS systems such as the Dell EMC UnityTM system, Dell EMC VMAXTM embedded NAS (eNAS), or Dell EMC IsilonTM system, which can be used to provide an NFS share for the SAP HANA shared file system.

XtremIO block storage, which can create a shared file system using a cluster file system such as a General Parallel File System (GPFS) or an Oracle Cluster File System 2 (OCFS2) on top of the block LUNs. SUSE provides OCFS2 capabilities with the HA package (a SUSE license is required). The HA package is also part of the SUSE Linux Enterprise Server (SLES) for SAP applications distribution that is used by most of the SAP HANA appliance vendors.

Calculate the size of the /hana/shared/ file system using the formula in SAP HANA

Storage Requirements. The latest version of that document uses the following formulas

for calculation:

Single node (scale-up):

Sizeinstallation(single-node= MIN(1 x RAM; 1 TB)

Multinode (scale-out):

Sizeinstallation(scale-out) = 1 x RAM_of_worker per 4 worker nodes

SAP HANA persistence (data and log)

The SAP HANA in-memory database requires disk storage to:

Maintain the persistence of the in-memory data on disk to prevent data loss that is caused by a power outage and to allow a host auto-failover. During a host auto-failover, a standby SAP HANA host takes over the in-memory data of a failed worker host in scale-out installations.

Log information about data changes (redo log).

https://www.sap.com/documents/2015/03/74cdb554-5a7c-0010-82c7-eda71af511fa.html







Every SAP HANA node (scale-up) or worker node (scale-out) requires two disk volumes

to save the in-memory database on disk (data) and to keep a redo log (log). The size of

these volumes depends on the anticipated total memory requirement of the database and

the RAM size of the node. To prepare the disk sizing, SAP provides several tools and

documents, as described in SAP HANA Storage Requirements. The latest version of that

document provides the following formulas to calculate the size of the data volume:

Option 1—If an application-specific sizing program can be used:

Sizedata = 1.2x anticipated net disk space for data

where net disk space is the anticipated total memory requirement of the database

plus an additional 20 percent free space. If the database is distributed across

multiple nodes in a scale-out cluster, net disk space must be divided by the number

of SAP HANA worker nodes in the cluster. For example, if net disk space is 2 TB

and the scale-out cluster consists of four worker nodes, then every node must be

assigned a 616 GB data volume (2 TB/4 = 512 GB x 1.2 = 616 GB).

If the net disk space is unknown at the time of the storage sizing, use the RAM size

of the node plus 20 percent free space for a capacity calculation of the data file

system.

Option 2—If no application-specific sizing program is available, the recommended

size of the data volume of a given SAP HANA system is equal to the total memory

required for that system:

Sizedata = 1 x RAM

The size of the log volume depends on the RAM size of the node.

SAP HANA Storage Requirements provides the following formulas to calculate the

minimum size of the log volume:

[systems ≤ 512 GB ] Sizeredolog = 1/2 x RAM

[systems > 512 GB ] Sizeredolog(min) = 512 GB

Backup

SAP HANA supports backup to a file system or use of SAP-certified third-party tools. Dell

EMC supports data protection strategies for SAP HANA backup using Data Domain

systems and DD Boost software. Although an SAP HANA backup to an NFS file system

on a Unity all-flash or hybrid array is possible, Dell EMC does not recommend backing up

the SAP HANA database to the storage array where the primary persistence resides. If

you plan to back up SAP HANA to an NFS file system on a different Unity array, see SAP

HANA Storage Requirements for information about sizing the backup file system. The

capacity depends not only on the data size and the frequency of change operations in the

database, but also on the backup generations kept on disk.





XtremIO storage configuration



The XtremIO internal architecture eliminates complex setups and fine-tuning steps. You

can use the XtremIO Storage Management Application (shown in Figure 8) to complete

the storage configuration tasks required to:

Create the SAP HANA storage volumes

Create SAP HANA initiator groups

Map the volumes to the SAP HANA nodes

Figure 8. XtremIO Storage Management Application

The following sections provide step-by-step instructions for completing these tasks.

The XtremIO flash-based data protection algorithm offers performance that is better than

RAID 1 with capacity savings that are better than RAID 5, and protection comparable to

RAID 6. It provides dual parity with as little as 10 percent capacity overhead. Creating

storage volumes (LUNs) for the persistence of the SAP HANA nodes is a simple process

that you can complete using the XtremIO management dashboard, as shown in Figure 9.

Creating storage

volumes



Figure 9. XtremIO management dashboard

To create storage volumes:

1. In the XtremIO management dashboard, select Configuration > Volumes, and

then click New.

The New Volumes screen appears, as shown in Figure 10.

Figure 10. New Volumes screen

2. Provide the following values: number of volumes, a name prefix, and the size of

the volumes to be created. Click Apply to confirm.

The data and log files of an SAP HANA node are the persistence layer of the database.

Each SAP HANA node (aside from standby nodes in a scale-out cluster) requires one

volume for the data file system and a second volume for the log file system. For



instructions about how to size the data and log volumes, see SAP HANA Storage

Requirements.

Volume resizing

As the database grows over time or during very heavy workloads, a disk-full event might

occur and cause the SAP HANA database to stop working. Therefore, you must ensure

that the data and log volumes always contain adequate space. If you need to expand the

size of a data or log file system, you must first increase the size of the volume on the

XtremIO array. To do this, right-click the volume and select Modify Volume.

Note: After you resize a volume, the host must perform a full rescan.

After the SAP HANA nodes are connected and zoned to the XtremIO X2 cluster, their

HBA WWNs are automatically registered in the XtremIO X2 cluster. A host reboot might

be required.

On the SAP HANA node, view the HBA WWNs by using the command shown in Figure

11.

Figure 11. Viewing the HBA WWNs of the SAP HANA nodes

In this example, the host has four HBA ports (two dual-port HBAs), but only two ports are

connected, zoned, and visible in the XtremIO X2 cluster. Create the initiator groups as

follows:

1. In the XtremIO X2 management dashboard, select Configuration > Initiator

Groups, and then click New.

2. Specify an initiator group name (that is, the hostname).

3. From the list of initiators, select the two initiators that belong to this node.

4. From the OS list box, select Linux, and then click Apply to create the initiator

group.

5. Repeat this procedure to create one initiator group for every connected SAP

HANA node.

After you create the initator groups, map the devices to the groups as follows:

1. In the XtremIO X2 management dashboard, select Configuration > Initiator

Groups.

The Storage Configuration screen appears, as shown in Figure 12.

Creating initiator

groups

Mapping devices





Figure 12. Storage Configuration screen

2. Map devices as follows:

If you are configuring an SAP HANA single-node (scale-up) cluster:

i Select the initiator group of the single node, and then click the Mapping

icon.

ii In the Mapping screen, select the pair of data and log volumes you

need to assign to this node.

iii Click Next, and then click Apply.

If you are configuring a multinode (scale-out) cluster:

i Select the initiator groups of all the nodes, including the standby node,

of the SAP HANA multinode cluster, and then click the Mapping icon.

ii In the Mapping screen, select all pairs of data and log volumes of the

SAP HANA cluster.

iii Click Next, and then click Apply.

All the data and log volumes are now visible to all the SAP HANA nodes.

Host setup with XtremIO storage



The instructions in this section assume prior completion of basic installation and

configuration on the SAP HANA nodes, as follows:

The operating system is installed and correctly configured in accordance with the SAP recommendations.

An SAP HANA shared file system, /hana/shared/, has been created on a NAS

system. Alternatively, you are employing a cluster file system, such as OCFS2 or GFS, for the SAP HANA shared file system.

Note: A shared file system for /hana/shared/ is required only for SAP HANA scale-out

installations.

Linux native multipathing (DM-MPIO) is installed on the SAP HANA nodes.

All network settings and bandwidth requirements for internode communications are configured in accordance with the SAP network requirements. For more information, see SAP HANA Network Requirements.

SSH keys have been exchanged between all SAP HANA nodes.

System time synchronization has been configured using an NTP server.

Note: SAP HANA can be installed only on certified server hardware. A certified SAP HANA expert

must perform the installation.

Enable Linux native multipathing as follows:

1. Modify the /etc/multipath.conf file with the following entries:

defaults { user_friendly_names no }

device {

vendor "XtremIO"

product "XtremApp"

path_selector "service-time 0"

# path_selector "queue-length 0"

path_grouping_policy "multibus"

rr_min_io_rq "1"

path_checker "tur"

failback "immediate"

fast_io_fail_tmo 15

}

Note: You can use the path_selector parameter queue-length 0 instead of service-

time 0. However, performance tests with the various SAP HANA block sizes and I/O

types (random and sequential) have shown a slightly better performance using

service-time 0.

2. Restart multipathing as follows:

# service multipathd restart

Prerequisites

Enabling Linux

native

multipathing

(DM-MPIO)

https://www.sap.com/documents/2016/08/1cd2c2fb-807c-0010-82c7-eda71af511fa.html



In SAP HANA scale-up (single-node) scenarios, the SAP HANA node has access to a

single data volume and a single log volume. In an SAP HANA scale-out cluster, all data

and log volumes must be visible to every node in the SAP HANA cluster. To achieve this

visibility, either run the rescan-scsi-bus.sh command or reboot each node.

1. Verify that the volumes are visible by running the following commands on one of

the nodes:

c460-09q:~ # multipath -ll | grep XtremIO -B6

3514f0c5046000014 dm-14 XtremIO,XtremApp

size=512G features='1 retain_attached_hw_handler'

hwhandler='0' wp=rw

`-+- policy='queue-length 0' prio=1 status=active

|- 1:0:0:20 sdv 65:80 active ready running

|- 1:0:3:20 sdcp 69:208 active ready running

|- 3:0:1:20 sder 129:48 active ready running

`- 3:0:2:20 sdfp 130:176 active ready running

3514f0c504600000b dm-4 XtremIO,XtremApp

size=1.0T features='1 retain_attached_hw_handler'

hwhandler='0' wp=rw

`-+- policy='queue-length 0' prio=1 status=active

|- 1:0:0:11 sdm 8:192 active ready running

|- 1:0:3:11 sdcg 69:64 active ready running

|- 3:0:1:11 sdei 128:160 active ready running

`- 3:0:2:11 sdfg 130:32 active ready running

The example shows two volumes, one 512 GB volume for the SAP HANA log and

one 1 TB volume for the SAP HANA data.

The unique device identifier of the multipath device with a preceding 3 must

match the WWN of the volumes that were created in the XtremIO X2

management dashboard.

2. Next, initialize the devices and create the Linux XFS file system on each of the

devices by running the mkfs.xfs command, as shown in the following examples:

# mkfs.xfs /dev/mapper/3514f0c5046000014

# mkfs.xfs /dev/mapper/3514f0c504600000b

After all the file systems are created, you are ready to install an SAP HANA database for

either a scale-out or a scale-up scenario.

Initializing the

SAP HANA

persistence

SAP HANA setup with XtremIO X2 volumes



Note: Ensure that you use the XtremIO X2 volumes that you created for the SAP HANA

persistence for the SAP HANA installation. See Creating storage volumes on page 24.

Install SAP HANA as follows:

1. For single-node scale-up systems, premount the data and log volumes under the

following mount points: /hana/data and /hana/log. For example:

# mkdir –p /hana/data

# mkdir –p /hana/log

# mount /dev/mapper/3514f0c5046000014 /hana/log –o inode64

# mount /dev/mapper/3514f0c504600000b /hana/data –o

inode64,nobarrier

2. Install SAP HANA by running either the hdblcm command or the hdblcmgui

command.

3. Prepare a customized global.ini file, as in the following example, and save

the file to a shared user directory such as /hana/shared/hana_cfg:

[storage]

ha_provider = hdb_ha.fcClient

partition_*_*__prtype = 5

partition_*_data__mountoptions = -o relatime,inode64

partition_*_log__mountoptions = -o

relatime,inode64,nobarrier

partition_1_data__wwid = 3514f0c5046000001

partition_1_log__wwid = 3514f0c504600000d


partition_2_log__wwid = 3514f0c504600000e


partition_3_log__wwid = 3514f0c504600000f


partition_4_log__wwid = 3514f0c5046000010

In SAP HANA scale-out scenarios, the SAP HANA storage connector is responsible

for mounting the persistence. The entries in the SAP HANA global.ini file

define which storage volumes belong to a corresponding SAP HANA partition.

4. If you used hdblcm to install SAP HANA, use the parameter –storage_cfg= to

point to this directory, as in the following example:

# hdblcm --action=install --

storage_cfg=/hana/shared/hana_cfg …

Configure the SAP HANA file I/O layer to optimize file I/O for a specified storage solution

and file system. All XtremIO X2 storage volumes use the Linux XFS file system for the

SAP HANA persistence. After you install the SAP HANA persistence on the XtremIO X2

volumes, set the following file I/O layer parameter for optimal I/O processing:

max_parallel_io_requests=128

Installing SAP

HANA

Optimizing file

I/O after SAP

HANA

installation



Setting the file I/O layer parameter in SAP HANA 1.0

For SAP HANA 1.0 installations, run the SAP HANA hdbparam command as <sid>adm

in the Linux shell:

$ su - <sid>adm

$ hdbparam –p # lists current parameter setting

$ hdbparam –-paramset fileio.max_parallel_io_requests=128

Setting the file I/O layer parameter in SAP HANA 2.0

For SAP HANA 2.0 installations, complete the following steps:

1. In SAP HANA Studio, select Administration Perspective > Configuration >

global.ini > fileio.

2. Double-click max_parallel_io_requests, and then change the default value from

64 to 128.

For more information, see SAP Note 2399079: Elimination of hdbparam in HANA 2.

Access requires an SAP username and password.

https://launchpad.support.sap.com/#/notes/0002399079

Data protection for SAP HANA with XtremIO X2



Data Domain deduplication storage systems enable you to redefine SAP backup, archive,

and availability with deduplication and consolidated data protection. Data Domain systems

work seamlessly with a range of backup, archive, and enterprise applications.

Dell EMC’s new generation of midsize and large enterprise Data Domain systems are

powered with flash SSD. For more information, see the Dell EMC Data Domain

Deduplication Storage Systems specification sheet. By consolidating backup and archive

data on a Data Domain system, you can reduce storage requirements, making disks cost-

effective for onsite retention and highly efficient for network-based replication to disaster

recovery sites.

Data Domain Boost connection to SAP HANA backup interface

The SAP HANA database provides a backup interface called Backint for SAP HANA. This

backup interface enables third-party backup tools such as Data Domain Boost for

Databases and Applications (DDBDA) to connect to the backup and recovery capabilities

of the SAP HANA database. Because Backint for SAP HANA is fully integrated into the

SAP HANA database, you can individually configure data and log backups to be created

and recovered using DDBDA.

A DDBDA backup to a Data Domain system takes advantage of the DD Boost feature as

follows:

The DD Boost library API enables the backup software to communicate with the

Data Domain system.

The DD Boost distributed segment processing (DSP) component reviews the data

that is already stored on the Data Domain system and sends only unique data for

storage. The DSP component enables the backup data to be deduplicated on the

database or application host to reduce the amount of data that is transferred over

the network. During the restore of a backup to the client, the Data Domain system

converts the stored data to its original non-deduplicated state before sending the

data over the network.

Configuring Data Domain for SAP HANA

Configure the Data Domain system as follows:

1. Install Data Domain Boost for Enterprise Applications (DDBEA) software on the

operating system of the database host.

2. Manually create the following subdirectory if it does not already exist:

/usr/sap/<SID>/SYS/global/hdb/opt

3. Copy the /opt/ddbda/bin/hdbbackint file to the subdirectory that is

specified in the preceding step, or, as shown in Figure 13, create a symbolic link

that points to the executable file from the following directory:

/usr/sap/<SID>/SYS/global/hdb/opt/hdbbackint

Backup and

recovery with

Data Domain

systems

https://www.emc.com/collateral/specification-sheet/h11340-datadomain-ss.pdf




Figure 13. Creating a symbolic link for hdbbackint

4. Modify the parameter settings of the SAP HANA template configuration file

/opt/ddbda/config/sap_hana_ddbda.utl, as shown in Figure 14.

t

Figure 14. Modifying the configuration file parameter settings

5. Configure the DDBDA lockbox using ddbmadmin –P –Z <configuration_file>,

where <configuration_file> is the file that you used in step 4.

Note: If you are configuring the multinode cluster, repeat steps 2–5 for all nodes.

6. In SAP HANA Studio, specify the location of the DDBDA configuration file for data

and log backup, as shown in Figure 15.

Figure 15. Specifying the DDBDA configuration file location

For more information about configuring DD Boost software with SAP HANA, see the Dell

EMC Data Domain Boost for Enterprise Applications and ProtectPoint Database

Application Agent Installation and Administration Guide.

Backing up the database from SAP HANA Studio

Back up the SAP HANA database as follows:

https://support.emc.com/docu85245_Data-Domain-Boost-for-Enterprise-Applications-and-ProtectPoint-Database-Application-Agent-4.0-Installation-and-Administration-Guide.pdf?language=en_US





1. Log in to SAP HANA Studio, and then select Backup and Recovery, as shown in

Figure 16.

Figure 16. SAP HANA Studio Backup and Recovery screen

2. Select the tenant database, as shown in Figure 17. Note that the LOAD database

is for illustration purposes only.

Figure 17. Specifying the tenant database

3. Select Backint as the destination type, as shown in Figure 18.



Figure 18. Specifying the backup destination

4. Review the backup settings, as shown in Figure 19 and click Finish to start the

backup.

Figure 19. Review Backup Settings screen

As Figure 20 shows, the total-compression factor achieved in the first backup is 2.0x, a

space saving of 50 percent for data backed up to the Data Domain device.



Figure 20. First-round backup: Compression ratio

The network throughput is approximately 100 MB/s, as shown in Figure 21.

Figure 21. First-round backup: Network throughput

Next, we generated an addtional one percent (2 GB) of data in the SAP HANA database

and then ran the backup again. The total compression changed to 38.7x, as shown in

Figure 22.

Figure 22. Second-round backup: Compression ratio

Note: We used the 1 GbE port for testing. The Data Domain system supports a 10 GbE port for

better performance.

The network throughput in the second round was 7 MB/s, as shown in Figure 23.



Figure 23. Second-round backup: Network throughput

These test results show that Data Domain backed up only the changed data in the second backup round. Also, the network bandwidth was reduced in the second round, saving network resources.

The results also show a throughput of 208.14 MB/s in SAP HANA Studio, as shown in Figure 24.

Figure 24. Throughput in SAP HANA Studio

Because DDBoost provided deduplication on the server side, the throughput in SAP

HANA Studio was greater than the network throughput. Only the changed data was sent

to Data Domain over the network, reducing the network throughput on the Data Domain

side.

Note: These test results e were obtained in our laboratory environment. Results might vary in

different environments.

Recover the database with SAP HANA Studio

Restore the SAP HANA database to the point when you backed it up as follows:

1. Log in to the SAP HANA Studio, and then choose Backup and Recovery.

2. Select the tenant database.



3. Select Recover the database to the most recent state, as shown in Figure 25.

Figure 25. Specifying the recovery type

4. Specify a location for the log backups, as shown in Figure 26.

Figure 26. Specifying the log backup location

5. Select the point in time to which you want to restore the database, as shown in

Figure 27.



Figure 27. Specifying a recovery point in time

6. Select Third-Party Backup Tool (Backint) as the backup tool.

7. Review the recovery settings, as shown in Figure 28, and click Finish.

Figure 28. Tenant database recovery settings



DDBDA with Data Domain

Using DDBDA software with Data Domain provides the following benefits:

Greater throughput because the DD Boost library sends only unique data (instead

of all the data) to the Data Domain system

Significantly reduced network bandwidth requirements because only the unique

data is sent to the Data Domain system over the network

Our testing shows that using DD Boost software with the Data Domain system

significantly reduced the backup and archiving storage requirements. The initial size of the

SAP HANA database was 206 GB. After the first backup to Data Domain using DD Boost,

the second backup required only 105 GB of storage.

After growing the database to 208 GB (a change of approximately 1 percent), we

performed a second backup of the SAP HANA database. Because the deduplication

process with DD Boost software occurs on the database host, only the changed data is

transferred to Data Domain. The second backup of the SAP HANA database required

only 4.7 GB of storage on the Data Domain system.

When you deploy SAP landscapes with XtremIO, you can be assured that your mission-

critical data is protected and available remotely on XtremIO with Dell EMC

RecoverPointTM data protection, using asynchronous snap-based replication.

The XtremIO solution with RecoverPoint continuous data protection provides a fully

featured, robust product to meet disaster and operational recovery needs. XtremIO with

RecoverPoint ensures that the persistent devices of the SAP HANA database are

replicated to the remote site, ensuring the existence of a consistent, remote, restartable

copy of the SAP HANA database. A local copy can be included for local and rapid

protection. This solution also provides the ability to restore data from the disaster recovery

site without failing over, while enabling an operational recovery of the production SAP

HANA database to a consistent point-in-time (PIT).

For more information, see the Business Continuity and Disaster Recovery with EMC

XtremIO for SAP HANA TDI Solution Guide.

This section demonstrates XtremIO data reduction technologies by using SAP HANA

System Replication (HSR) for SAP HANA HA on the same XtremIO array to achieve

space savings with data reduction rates of 2:1.

Using two identical single-host (scale-up) SAP HANA systems and with HSR enabled,

SAP HANA replicates all data to a secondary dedicated SAP HANA system. The

secondary system operates in recovery mode, not accepting SQL commands. Each

server process on the secondary system establishes a connection and continually

communicates with its primary counterpart. Data is constantly preloaded in memory and

persisted to disk on the secondary system to minimize the recovery time objective (RTO).

The two SAP HANA systems can be configured into a cluster with SUSE Linux HA

extensions using a virtual IP to automate the takeover process and provide a minimum

RTO. After the takeover, the data is already loaded in memory and the secondary system

is fully operational.

SAP HANA

storage-based

replication with

XtremIO and

RecoverPoint

SAP HANA

system

replication for

high availability

http://www.emc.com/collateral/technical-documentation/h14761-business-continuity-recovery-xtremio-sap-hana-tdi-sg.pdf




Note: System replication for HA is best suited for single-host systems where the

minimum RTO is sought. For scale-out systems, the recommended HA option is host

auto-failover using standby nodes and the storage connector. The host auto-failover can

also be used for single-hosts systems, but has a longer RTO because the data is not

loaded into memory.

XtremIO writes only unique changed storage blocks. Duplicate data blocks do not

translate into physical data writes and are replaced with in-memory metadata pointers that

enable a single physical block on XtremIO to be referenced multiple times. After data

blocks are globally deduplicated on XtremIO, the remaining unique data blocks are

compressed inline, delivering an optimal storage footprint.

SAP HANA in general is not susceptible to deduplication because it uses a shadow page

concept on disk level (copy-on-write) and the order of the pages changes. The

compression rates are typically lower than traditional databases because the SAP HANA

column store compresses automatically and optimizes the compression after any

changes. The achieved compression rates on XtremIO might vary depending on the

dataset.

With SAP HANA, HSR transactions are committed to both the primary and secondary

systems, and XtremIO inline data reduction can benefit from deduplication. To confirm this

unique benefit of XtremIO for SAP HSR, we tested an XtremIO X1 two-brick cluster using

a single-host SAP HANA system installed with the /hana/data, /hana/log, and

/hana/shared volumes mounted from the XtremIO array. We then loaded SAP HANA

with randomized data to grow the database to approximately 170 GB. Figure 29 shows

the XtremIO storage dashboard and the data reduction ratios before SAP HSR is

implemented.

Figure 29. Data reduction for a single-host SAP HANA system with data

We then installed a second identical SAP HANA system and enabled synchronous

system replication. After the initial data transfer to the secondary system, we added a

small delta load to the primary system to grow the database to 185 GB. For more

information about system replication, see How to Perform System Replication for SAP

HANA.



XtremIO copy and refresh of SAP HANA


Figure 30 shows the XtremIO storage dashboard and the data reduction ratios after SAP

HSR is implemented. Because of the deduplication ratio of 1.9:1 resulting from SAP HSR,

the data reduction ratio expanded to 2.1:1. With the secondary identical system, the

volume capacity (what is visible to the hosts) grew by approximately 80 percent, but the

physical capacity (what is actually written to disk) grew by approximately 15 percent,

indicating significant disk savings because of the reduced storage space consumption.

Figure 30. Data reduction for a single host SAP HANA system with HSR enabled

Note: We obtained all of these data reduction ratios in a laboratory environment with a generated

test dataset using an XtremIO X1 array. Similar or better results can be expected with the new

XtremIO X2 array. Because XtremIO data reduction is global, we removed all other data and

volumes from the XtremIO two-brick cluster before the test to accurately reflect the ratios in the

XtremIO dashboard. Results might vary in environments with different SAP HANA datasets and

dataset sizes, or where data already exists on the array.


XtremIO virtual copies (XVC) are entirely metadata-driven snapshots that use the array’s

inline data reduction feature. Provisioning more virtual copies is an easy and

instantaneous process.

Note: Although the screen images in this section reference the XtremIO X1 array and GUI, the

information provided also applies to the XtremIO X2 array.

To make a copy of an SAP HANA system, create a copy of the /hana/shared file

system and the SAP HANA database persistence (data and log volumes), and register the

SAP HANA system copy on new hosts. Perform a system copy with the SAP HANA

database lifecycle manager (HDBLCM) using an XtremIO virtual copy of the SAP HANA

system.

XtremIO copy

operations



An XtremIO Consistency Group (CG) is a group of volumes that can be used to create a

consistent snapshot across all of the volumes in the group. To ensure a consistent

snapshot (XVC) of the SAP HANA database, create a CG containing all the data and log

volumes. The snapshot operation of a CG creates a snapshot set, which contains the

consistent snapshot volumes that were created when the snapshot was taken.

Copying an SAP HANA system produces a new SAP HANA system with the same

landscape as the existing one, but with potentially different system identifiers.

Note: The focus in this guide is on the SAP HANA database copy using XVC. To copy the

application systems based on ABAP or JAVA, use Software Provisioning Manager (SWPM) and

consider post-copy tasks. Use SAP LVM to automate the E2E provisioning process. XtremIO is

supported with Dell EMC Storage Integrator (ESI) 4.0 for SAP LVM.

SAP HANA shared file system considerations

In a scale-up system the /hana/shared installation path containing the HANA binaries

might reside on an XtremIO block device. Because no requirement exists to share this file

system with other hosts, it can also reside on an NAS or server-based NFS.

In an SAP HANA scale-out implementation, the SAP HANA database binaries must be

installed on a shared file system that is exposed to all hosts of a system under the

/hana/shared mount point. This can be provided either by NAS, or by a server-based

NFS on block storage.

In cases where the /hana/shared directory is residing on a shared file system, the

/hana/shared/<source_SID> directory can be copied manually to the

/hana/shared/<target_SID> but must maintain permissions and owners. For

example, for our tests we used the command:

cp -rp source_SID target_SID

where the –rp flag copies recursively and keeps permissions.

SAP HANA system identifiers

System identifiers are required parameters that you set during the SAP HANA system

installation. In some cases, it is necessary to change the originally configured system

identifiers, for example, when public hostnames are used or when a new SID or instance

number is required. You can change all three system identifiers—host name, SID, and

instance number—together or individually from the SAP HANA database lifecycle

manager GUI or CLI.

Preparing mounted SID

If the SAP HANA SID is included in the mount points, and you want to change the SID,

you have to create mount points with the new target SID before running HDBLCM to

rename the SID of the system.



Table 6. Sample source and target mounts which include the SID

Source SID Target SID

/hana/shared/PRD /hana/shared/DEV

/hana/data/PRD/mnt000x /hana/data/DEV/mnt000x

/hana/log/PRD/mnt0000x /hana/log/DEV/mnt000x

Copying an SAP HANA database using XVC

Follow these steps:

1. Create an XtremIO Consistency Group of the SAP HANA system productionpersistence volumes from the Configuration menu on the XMS application, asshown in Figure 31.

Figure 31. Creating a consistency group with the SAP HANA persistence volumes

Create a writable snapshot set of the production CG, as shown in Figure 32. You can create any number of writable snapshot sets from the production CG.



Figure 32. Creating a snapshot of the consistency group

Map the volumes of the snapshot set to the target hosts and create the NAA identifiers (UUIDs) as shown in Figure 33.

Figure 33. Mapping the snapshot set to target hosts

Prepare the mount points on the target host(s) depending on whether you intend to copy the SAP HANA system with the target SID.

Note: An existing target SAP HANA installation is not required.

Mount the target installation path that has been manually copied

(/hana/shared), and then mount the target data and log volumes on the target

host(s).

In scale-out SAP HANA systems that are using the storage connector, it is not

necessary to mount the data and log volumes on the target hosts. It is necessary

to perform some preparations on the storage section of the copied global.ini

and to update NAA identifiers (UUIDs) to the XVC snapshot devices, as shown in

Figure 34.

Figure 34. Update the snapshot UUID’s in the global.ini

Register the new SAP HANA system on the target hosts as follows:

a. Log on to the SAP HANA target host and change directories to the SAP

HANA resident HDBLCM directory by using the following command:

cd </hana/shared>/<targetSID>/hdblcm



b. Start the register and rename the task:

i To register hosts using the SAP HANA database lifecycle manager

command-line interface, type /hdblcm, and then choose Register and

Rename SAP HANA System.

ii As prompted by the Register and Rename wizard, type the target host

name, SID, and instance number.

iii Confirm all parameters for the SAP HANA system rename operation, as

shown in Figure 35.

Figure 35. Register and Rename parameters summary

Applying a new license after copying an SAP HANA system

The license key for an SAP HANA database is based on the system ID and the landscape

ID. Renaming an SAP HANA system usually invalidates the permanent SAP license when

the SID or the landscape ID changes. A temporary license is installed and must be

replaced within 28 days. If you rename an SAP HANA system that had only a temporary

license, the system is locked until a new license is applied.

For more information, see the SAP HANA Administration Guide, which is available on the

SAP Help Portal.

XtremIO refresh operations are instantaneous and crash-consistent but most do not

significantly affect host-level SCSI attributes such as NAA identifiers.

Process overview

Stop the virtual copy system and unmount the /hana/data/SID and /hana/log/SID

volumes. It is not necessary to unmount the /hana/shared installation path. After the

data and log volumes are unmounted, refresh the XVC snapshot from the parent

XtremIO refresh

with SAP HANA

copy systems

http://help.sap.com/hana/



consistency group (CG) or select an existing snapshot, as shown in Figure 36. After the

refresh is complete, you can mount the same devices again to the target SID mount

points because the host-level SCSI attributes and the UUIDs have not been changed.

When using the XtremIO snapshot refresh feature with SAP HANA, it is important to

understand that the topology of the SAP HANA system is contained in the data and log

volumes within the nameserver directory of the master node. After a snapshot refresh, the

topology contains the system identifiers (hostname, SID, instance number, landscape ID)

of the source system from which the target is being refreshed. Depending on the copy

source, the system identifiers might be different from the target system’s environment.

To quickly and easily convert the topology from the source system identifiers to the target

system identifiers, as a sidadm user, run the following hdbnsutil command on the

target master nameserver:

hdbnsutil -convertTopology

After the conversion is complete, you can start the SAP HANA system copy with the refreshed data.

Refreshing an SAP HANA database using XVC

In a single-host or scale-up SAP HANA system:

Stop the SAP HANA database.

2. Unmount the /hana/data/SID and /hana/log SID volumes.

Note: The /hana/shared installation path for a scale-up system can reside on a block

device on the XtremIO array. If the /hana/shared device was included in the CG for

creating the copy of the SAP HANA system, remove the /hana/shared device from

the source CG because the target system has already been registered and renamed.

The initial snapshot of the /hana/shared device can continue to be mapped to the

target host and used.

Refresh the snapshot on the XtremIO array either from another snapshot set or from the parent CG, as shown in Figure 36.



Figure 36. Selecting a CG or snapshot from which to refresh

Mount the volumes to the same target SID mount points.

Run hdnnsutil –convertTopology as sidadm.

Start the SAP HANA database.

In a scale-out SAP HANA system using the storage connector, the process is

simplified because the storage connector mounts and unmounts the data and log

volumes during a stop and start of the system.

Note: For scale-out SAP HANA systems, the /hana/shared volume is not added to the

consistency group because it resides on a shared filesystem.

Stop the SAP HANA database.

Refresh the XVC snapshot set on XtremIO from another snapshot set or the parent CG.

Run hdnnsutil –convertTopology as sidadm, as shown in Figure 37.

Because the NAA identifiers are not affected and are already defined in the

global.ini, the data and log volumes of the master nameserver are

temporarily mounted to convert the system identifiers.



Figure 37. Converting the topology of a 2+0 scale-out SAP HANA system

Start the SAP HANA database.

XtremIO iCDM space-saving efficiencies

XtremIO virtual copies of the SAP HANA database are 100 percent space-efficient. No

traditional full-copy is needed for repurposing with XtremIO. You can create multiple

XtremIO virtual copies of a consistency group in the XtremIO array with no increase in the

physical disk capacity at the storage level. All XtremIO virtual copies use data reduction

services. As users begin to make changes to their database copies, the modified blocks

are first deduplicated and then compressed.

We ran some tests to observe the space savings with XtremIO X1 arrays. These tests

compared the used capacities of the virtual and physical volumes when we used XVC to

create and refresh SAP HANA system copies. Figure 38 shows the data points.

We ran the tests as follows:

We installed a populated database called PRD.

We created a virtual copy of the PRD database, called CPY, mounted it, and brought it online.

We added some data scrambling and load to the CPY database from which multiple copies can be provided for test and development teams with sensitive data removed.

As Figure 38 shows, the volume capacity grew by 42 GB. The physical capacity

grew by only 30 GB because of XtremIO data reduction technologies on the

virtual copies.

We created three more virtual copies of the PRD (QAS, DEV, and SDX) and brought them online.

We refreshed the QAS system from the CPY system containing the scrambled data and additional load.



Figure 38. Physical used capacity compared to volume used capacity

From the XMS Storage Dashboard, as shown in Figure 39, we can observe significant

storage space efficiency when we compare the production database on the left to the

same database on the right with four virtual copies, which increased the overall efficiency

for the XtremIO all-flash array.

Figure 39. XMS storage dashboard before and after creation of virtual copies

References


References

The following documentation on Dell EMC.com or Dell EMC Online Support provides

useful and relevant information. If you do not have access to a document, contact your

Dell EMC representative.

Introduction to Dell EMC XtremIO X2 Storage Array

Dell EMC Host Connectivity Guide for Linux

Dell EMC XtremIO Storage Array Host Configuration Guide

XtremIO Integrated Copy Data Management Solution Overview

Introduction to XtremIO Virtual Copies

Business Continuity and Disaster Recovery with EMC XtremIO for SAP HANA

Tailored Data Center Integration Solution Guide

Dell EMC Data Domain Boost for Enterprise Applications and ProtectPoint

Database Application Agent Installation and Administration Guide

Dell EMC Data Domain Deduplication Storage Systems Spec Sheet

Dell EMC Data Domain Operating System 6.1 Administration Guide

You can find the following SAP HANA documentation on the SAP Help Portal:

SAP HANA Master Guide

SAP HANA Server Installation and Update Guide

SAP HANA Technical Operations Manual

SAP HANA Administration Guide

SAP HANA Storage Requirements

Web resources

SAP HANA Platform

SAP HANA One

SAP HANA Enterprise Cloud

SAP HANA TDI - Overview

SAP HANA Tailored Data Center Integration Frequently Asked Questions

How To Perform System Replication for SAP HANA

Dell EMC

documentation

SAP

documentation

https://www.dellemc.com/en-us/index.htm

https://support.emc.com/

https://www.emc.com/collateral/white-papers/h16444-introduction-xtremio-x2-storage-array-wp.pdf

https://www.emc.com/collateral/TechnicalDocument/docu5128.pdf

https://support.emc.com/docu56210_XtremIO-Host-Configuration-Guide.pdf

https://www.emc.com/collateral/solution-overview/h14591-xtremio-icdm-so.pdf

https://www.emc.com/collateral/solution-overview/h14591-xtremio-icdm-so.pdf

https://www.emc.com/collateral/white-paper/h13035-wp-introduction-to-xtremio-snapshots.pdf






https://www.emc.com/collateral/TechnicalDocument/docu85190.pdf

http://help.sap.com/hana/

http://help.sap.com/hana_appliance

http://help.sap.com/hana_one

http://www.saphana.com/entcloud

https://scn.sap.com/docs/DOC-63140

http://go.sap.com/documents/2016/05/e8705aae-717c-0010-82c7-eda71af511fa.html

http://go.sap.com/documents/2016/05/e8705aae-717c-0010-82c7-eda71af511fa.html


References


SAP Notes

Note: The following documentation requires an SAP username and password.

SAP Note 1943937: Hardware Configuration Check Tool - Central Note

SAP Note 1969700: SQL statement collection for SAP HANA

SAP Note 1999930: SAP HANA I/O Analysis

SAP Note 2399079: Elimination of hdbparam in HANA 2

SAP Note 1788665: SAP HANA running on VMware vSphere VMs

Additional SAP documentation

Note: The following documentation requires an SAP username and password.

Sizing Approaches for SAP HANA–Lessons Learned

Enterprise Storage Architecture–Planning Guide

Elements of a Software Change Management Strategy

https://service.sap.com/sap/support/notes/1943937




https://service.sap.com/sap/support/notes/1788665

https://service.sap.com/~sapidb/011000358700000050632013E

https://service.sap.com/~sapidb/011000358700000050612013E

http://service.sap.com/~sapidb/011000358700000669992013E/171_Elements_of_a_SW_CMS.pdf

sap hana tdi on dell emc xtremio x2 storage … detailed information about the sap hana enterprise...

Documents