Configuration Best Practices for SAP HANA TDI

Configuration Guide

STORAGE CONFIGURATION BEST PRACTICES FOR SAP HANA TAILORED DATACENTER INTEGRATION ON EMC XTREMIO STORAGE

EMC Solutions Abstract This configuration guide provides information and configuration best practices for customers deploying SAP HANA using SAP tailored datacenter integration (TDI) on an EMC XtremIO® all-flash storage array. With the TDI model, customers can overcome limitations of the SAP HANA appliance model by integrating SAP HANA into an existing, well-established datacenter infrastructure, which provides multiple benefits. March 2016

Copyright © 2015, 2016 EMC Corporation. All Rights Reserved. EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice. The information in this publication is provided as is. EMC Corporation 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 EMC software described in this publication requires an applicable software license. For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com. All trademarks used herein are the property of their respective owners. Part Number H13984.3

2

Storage Configuration Best Practices for SAP HANA Tailored Data Center Integration on EMC XtremIO Storage

Contents Introduction ..........................................................................................................................................4 Technology overview and considerations ..............................................................................................8 Configuration recommendations ........................................................................................................ 17 Configuring EMC XtremIO storage using the XtremIO Storage Management Application ................... 20 Accessing XtremIO storage from the SAP HANA nodes ....................................................................... 34 Using XVC to copy and refresh an SAP HANA System ......................................................................... 37 References ......................................................................................................................................... 46


3

Introduction Enterprises with large amounts of data need their data to be recent and available in real time and at high speed with fast response times and true interactivity. They also need data to be available without any preparation, pre-building of aggregates, or finetuning. SAP HANA, an in-memory platform that can be deployed as an on-premises appliance or in the cloud, combines software components that are optimized on proven hardware provided by SAP’s hardware partners. At the core of this real-time data platform is the SAP HANA in-memory database, which is revolutionary compared to traditional database engines. Solution overview

EMC XtremIO® is the leading all-flash array featuring scale-out architecture and ultrahigh performance. XtremIO enables high and consistent performance at all times while being cost-effective across the board due to its data reduction technologies. SAP has certified XtremIO as an enterprise storage array that meets all SAP HANA performance and functional requirements. This certification enables customers to use XtremIO for SAP HANA tailored data center integration (TDI) deployments in a fully supported environment using their existing data center infrastructures. SAP HANA deployment models Possible SAP Hana deployment models include: 

Appliance model



TDI model



Cloud model

SAP HANA can be deployed in the data center with two different models, as shown in Figure 1:

Figure 1.

SAP HANA appliance model versus TDI model

By default, an SAP HANA appliance includes integrated storage, compute, and network components. The appliance is pre-certified by SAP, built by SAP’s HANA

hardware partners, and shipped to customers with all software components preinstalled, including the operating system (OS) and the SAP HANA software. Since the introduction of SAP HANA, customers have had the option to deploy the platform using the SAP HANA appliance model. However, this model presented customers with the following limitations: 

Limited choice of servers, networks, and storage



Inability to use existing data center infrastructure and operational processes



Fixed sizes for storage capacities (storage was part of the appliance)



Little knowledge and control of the critical components in the SAP HANA appliance



Inability to respond rapidly to unexpected growth demands

Compared to the appliance deployment model, the TDI approach is more open and provides additional flexibility for customers. SAP HANA in a TDI deployment reduces hardware and operational costs, lowers risks, and increases server and network vendor flexibility. The SAP HANA servers still have to meet the SAP HANA requirements and have to be certified SAP HANA servers. However, the network and storage components can now be shared in customer environments. Therefore, customers can use their existing enterprise storage arrays for SAP HANA and seamlessly integrate SAP HANA into existing data center operations like disaster recovery, data protection, monitoring, and management. This capability reduces timeto-value, risk, and costs for an overall SAP HANA adoption. EMC XtremIO array with SAP HANA We1 tested performance using the SAP HANA hardware configuration and check tool (hwcct) and various SAP HANA load generators on the XtremIO enterprise storage array. This configuration guide describes the XtremIO storage configuration recommendations based on the results of those tests. The recommendations meet SAP performance requirements—the SAP HANA TDI key performance indicators (KPIs) for data throughput and latency—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 SAP HANA TDI implementation meets the SAP performance criteria. The test must use the hwcct version used during the XtremIO certification. SAP certified the XtremIO allflash array with the HANA-HWC-ES 1.0 certification scenario; therefore, all hwcct tests with XtremIO must use one of the following: SAP HANA SPS08 hwcct; SAP HANA SPS09 hwcct; a related SAP HANA revision. For more information, see SAP Note 1943937 - Hardware Configuration Check Tool - Central Note. (Access requires an SAP username and password.)

1

In this document, “we” refers to the EMC Engineering team that validated the solution.


5

Key benefits

Scope

This solution provides the following benefits: 

Integrates SAP HANA with XtremIO into an existing data center infrastructure



Uses shared enterprise storage to rely on already-available, multisite concepts to benefit from established automation and operations processes



Enables easy transition to the new architecture and provides EMC services to minimize risk



Uses existing operational processes, skills, and tools, and avoids the major risks and costs associated with operational change



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



Achieves XtremIO data reduction rates of 2:1 when using SAP HANA System Replication (HSR) for SAP HANA High Availability (HA), multiplying the effective capacity of the same XtremIO cluster



Global data reduction with a highly integrated, always on, inline data deduplication and compression architecture that increases the return on investment in the XtremIO all-flash array



Faster read operations with faster database restarts enabled by the XtremIO all-flash array, host auto-failovers, log backups, database recoveries, and table loads.



Enables writable virtual copies (XVC) of PROD and non-PROD HANA databases to be created and refreshed at near instant speeds for the entire HANA System/Copy/Refresh and Post Copy Automation PROD and nonPROD lifecycle management process.



Delivers highly efficient writeable XVC copies of PROD and non-PROD HANA landscapes that are highly optimized via inline content addressable deduplication technologies where only net-new data consumes SSD capacity and duplicate IOPS are efficiently managed inline between parent and child XVC snapshot volumes.

This configuration guide describes a solution that uses SAP HANA in a TDI deployment on XtremIO storage that is valid for XtremIO 3.x and 4.x. All configuration recommendations in this document are based on SAP requirements for high availability (HA) and the performance tests and results to meet the SAP KPIs for SAP HANA TDI. This document provides best practices and tips for deploying the SAP HANA database on an EMC XtremIO storage array and includes the following: 

Introduction to the key solution technologies



Description of the configuration requirements for XtremIO with SAP HANA



Detailed instructions for accessing XtremIO storage from the SAP HANA nodes



Steps to copy and refresh SAP HANA systems with XtremIO virtual copies


6

Audience

This configuration guide is intended for system integrators, systems or storage administrators, customers, and partners who need to configure an XtremIO storage array to be used in a TDI environment for SAP HANA.

Terminology

This configuration guide includes the following terminology: Table 1.

Terminology

Term

Definition

SAP HANA standby host

An SAP HANA host waiting to take over processing in case of a worker host failure

SAP HANA worker host

An SAP HANA host that processes data


7

Technology overview and considerations EMC XtremIO system overview

The XtremIO storage array is an all-flash system based on a scale-out architecture. The system uses building blocks, called X-Bricks, which can be clustered together, as shown in Figure 2.

Figure 2.

XtremIO cluster configurations with raw capacity

An X-Brick is composed of two server storage controllers loaded with XtremIO Operating Environment (OE) software, a disk array enclosure (DAE) filled with 25 enterprise flash drives (EFDs), and two battery backup unit (BBU) assemblies. An XtremIO cluster is composed of one or more X-Bricks, depending on the capacity and performance required. X-Bricks come in sizes ranging from a 5 TB Starter X-Brick through 10 TB and 20 TB up to 40 TB so you can scale deep and out to match your workload sizing requirements in the most cost-effective way. The 40 TB X-Brick and the 8 X-Brick cluster are new with XtremIO 4.0. XtremIO uses its multicontroller scale-out design and remote direct memory access (RDMA) fabric to maintain all metadata in memory, which makes XtremIO arrays impervious to changes in workload. Various LUN sizes can be used and, whether I/O patterns are random or sequential, low latency and throughput remain consistently predictable and constant. Scalable performance and storage capacity XtremIO is designed to scale out to meet future performance and capacity needs by using additional X-Bricks. When the cluster expands, resources remain balanced, and data in the array is distributed across all X-Bricks to maintain consistent performance and equivalent flash wear levels.


8

Inline data reduction XtremIO provides inline data reduction by using the following techniques: 

Inline data deduplication—The removal of redundancies from data before it is written to the flash media, and servicing duplicate read/write I/Os more efficiently. XtremIO automatically and globally deduplicates data as the data enters the system. Deduplication is performed in real-time and not as a post-processing operation. With XtremIO, there are no resource-consuming background processes and no additional reads/writes (which are associated with postprocessing). Therefore, deduplication does not negatively affect 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.



Inline data compression—Compression of the already deduplicated data before it is written to the flash media XtremIO automatically compresses data after all duplications have been removed, so compression is performed only for unique data blocks. Data compression is performed in real-time and not as a post-processing operation. This compression reduces the total amount of physical data that needs to be written to the flash media.

Note: The XtremIO system’s inline data reduction and thin provisioning features provide significant space savings, data deduplication, and data compression efficiencies. The raw advantages for applying inline data reduction to an optimized HANA database may vary and can be highly data specific. XtremIO data reduction ratios of approximately 1.6:1 were achieved during our testing with the SAP HANA database.

Thin provisioning XtremIO storage is natively thin provisioned using a small internal block size, which allocates capacity to volumes on demand in fine-grained increments. All volumes in the cluster are thin provisioned, meaning that the cluster consumes capacity only when capacity is needed. XtremIO determines where to place the unique data blocks inside the physical X-Brick cluster after it calculates their fingerprint IDs. Therefore, it never pre-allocates or thick-provisions storage space before writing. Data protection The XtremIO storage system provides high-efficiency "self-healing" double-parity data protection, referred to as XtremIO data protection (XDP). The system requires very little capacity overhead for data protection and metadata space. It does not require dedicated spare drives for rebuilds. Instead, it uses the "hot space" concept, where any free space available in the array can be used for failed-drive reconstructions. The system always reserves sufficient distributed capacity for performing a single rebuild. XDP eliminates the need to explicitly architect different RAID types for HANA to balance performance and capacity, because all SSD Flash modules are under XDP Storage Configuration Best Practices for SAP HANA Tailored Data Center Integration on EMC XtremIO Storage

9

protection. Incoming I/O is fully distributed and evenly balanced across all X-bricks and all SSD modules, regardless of the I/O profile. As a result, XDP simplifies capacity sizing for SAP HANA by taking protection, I/O profile, and complex drive count calculations out of the equation. The HANA design process is simplified to the number of X-Bricks and choice of capacity for each X-Brick. XtremIO Virtual Copies (XVC) XtremIO arrays use XtremIO Virtual Copy (XVC) technology. XVCs are instantaneous image copies of volume data that keep the state of the data exactly as it appeared at the specific point in time the XVC was created. XVC is provided by XtremIO integrated Copy Data Management (iCDM) services– and it consolidates both primary data and associated copies on the same scale-out all-flash array for unprecedented agility and efficiency. The XVC snapshot implementation within XtremIO is entirely metadata-driven and uses the array's inline data reduction to ensure that duplicate data blocks are never written to physical disk within the array. XVC allows instant, high performance copies of any data set and are entirely space- efficient with data services like inline deduplication and compression. XtremIO 4.0 improves on the existing XVC features by supporting consistency groups, snapshot refresh, snapshot set refresh and volume refresh functionality. Refresh operations are immediate and crash-consistent, and have no storage space overhead. Moreover, the refresh operations do not affect host-level SCSI attributes (e.g. UUID’s). This means that by using simple XtremIO commands (GUI, CLI or REST API), administrators can immediately refresh the contents of a volume or snapshot with no need for any host-level LUN-related system administration actions. XVC enables the provisioning of the latest data to test and development teams in an efficient and timely manner. XVC offers the following benefits:

SAP HANA



Powerful, simple, risk-free copy operations



Instant, on-demand in-memory, consistent virtual copies with performance at flash speed



Highly efficient writeable XVC copies where only net-new data consumes SSD capacity



Less expensive than traditional copy data methods



Instantly refresh virtual copies from the production volumes or from other virtual copies. In addition the virtual copies can be used to restore the production volumes.

SAP HANA is an in-memory database. The data is kept in RAM of one or multiple SAP HANA worker hosts. All database operations—like reads, inserts, updates, or 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.


10

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 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 an SAP certified enterprise storage array for SAP HANA, XtremIO can be used for both single-host systems (scale-up) and multihost systems (scale-out) 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 and standby hosts. A worker host is an active component and accepts and processes database requests. A standby host is a passive component. It has all database services running, but no data in RAM. It is waiting for a failure of a worker host so that it can take over its role. This process is called host auto-failover. 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 TDI scalability The SAP HANA TDI scalability defines the number of productive SAP HANA worker hosts (in scale-out installations) or single hosts (in scale-up installations) that can be connected to enterprise storage arrays and still meet the SAP KPIs for enterprise storage. Because the capacity used on disk for the SAP HANA persistence is always related to the RAM capacity of the SAP HANA database, the required capacity on disk for multiple SAP HANA hosts is not the limiting factor in most cases. Enterprise storage arrays can provide much more capacity than required for SAP HANA. The scalability can depend on several other factors, including: 

Array model, cache size, and disk types



Bandwidth, throughput, and latency



Overall use and resource consumption of the array



How SAP HANA hosts are connected to the array

Storage configuration of the SAP HANA persistence SAP HANA file systems Table 2 represents the required file system structure of an SAP HANA setup. The SAP HANA Server Installation and Update Guide on the SAP Help Portal provides more details.


11

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/

Default path to the data directory, which depends on the system ID of the SAP HANA host.

Log volume

/hana/log/

Default path to the log directory, which depends on the system ID of the SAP HANA host.

Sizing In general, the required capacity for the SAP HANA persistence on disk depends on the in-memory database size. The first step to sizing an SAP HANA customer deployment is to perform memory and CPU sizing. For new SAP HANA implementations, size the memory and CPU for an SAP HANA system using the SAP HANA version of the SAP Quick Sizer tool. You can find the tool on the SAP Service Marketplace website, or consult SAP for assistance. For systems that are migrating to SAP HANA, SAP provides tools and reports for proper SAP HANA memory sizing. After you determine the memory requirements, refer to the SAP HANA Storage Requirements white paper for detailed information about minimum required storage capacity in SAP HANA TDI deployments. SAP HANA persistence SAP HANA uses disk storage to maintain the persistency of the in-memory data on disk. SAP HANA persistence prevents data loss due to 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 and one for log files. SAP HANA persists in-memory data by using savepoints. Each SAP HANA service has its own separate savepoints. During a savepoint operation, the SAP HANA database flushes all changed data from memory to the data volumes. 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. Redo log entries are written to the log volumes for all changes to persistent data. In the event of a database restart (for example, after a crash), 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.


12

SAP HANA OS images on XtremIO You can start SAP HANA nodes from either local disks or from SAN and XtremIO devices. If you start nodes from a SAN device, follow the best practices documented in the EMC Host Connectivity Guide for Linux. SAP HANA shared file system on XtremIO In an SAP HANA scale-out implementation, install the SAP HANA database binaries on a shared file system that is exposed to all hosts of a system under the /hana/shared mount point. If a host needs to write a memory dump (which can read up to 90 percent of the RAM size), the memory dump will be stored in this file system. Guided by the specific customer infrastructure and requirements, the options for the file systems are: 

NFS server based shared file system.



NAS systems such as EMC VNX®, EMC VMAX3®-embedded NAS (eNAS), or EMC Isilon® can be used to provide an NFS share for the HANA shared file system.



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

SAP HANA I/O patterns The SAP HANA persistent file systems have different I/O patterns, which are described in detail in the SAP white paper SAP HANA Storage Requirements. The SAP HANA workload is predominantly write-intensive during normal operations.

Data file system Access to the data file system is primarily random, with various block sizes going from small (4K) up to large (64M) 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 various block sizes from 4 K up to 1 M. Because data to the log file system is written synchronously on commits, a low latency for I/O to the storage device is important, especially for the smaller 4 K and 16 K block sizes. As with the data file system, during normal database operations, most of 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 XtremIO 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


13

operations with XtremIO, using HANA to load both column and row tables into memory. Test results showed faster reads ranging from 15 percent to 60 percent with XtremIO. 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 a HANA restart, only the row tables are loaded into memory, while column tables are lazy loaded into memory after the database restart. The number and size of the row tables will therefore influence the restart times.

Virtual environments Customers have the option to run SAP HANA on VMware virtualized infrastructure (VMware vSphere). Some restrictions and limitations apply to virtualized environments, such as the maximum RAM size of an SAP HANA node. Review corresponding SAP OSS notes and follow VMware best practices to deploy SAP HANA on vSphere. For the SAP HANA persistence on XtremIO arrays, all configuration recommendations in this document also apply to virtual environments. However, with virtual environments you should also consider the following: 

SAP HANA persistence in virtual environment—Add the data and log LUN for a 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 VMFS datastore and add it as the data or log LUN to the SAP HANA virtual machine. Refer to VMware best practices for an optimized virtual SCSI adapter.



vSphere Multipathing—An SAP HANA virtual machine does not use Linux Device Mapper 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 EMC PowerPath®/VE to intelligently manage I/O paths and to optimize I/O performance.

SAP HANA system replication on XtremIO for High Availability Using two identical single-host (scale-up) 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 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. 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 will have a longer RTO because the data is not loaded into memory.


14

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 in-line, delivering an optimal storage footprint. SAP HANA in general is not very susceptible to deduplication because HANA uses a shadow page concept on disk level (copy-on-write) and the order of the pages will change. 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 in-line data reduction can benefit from deduplication. To prove this unique benefit of XtremIO for SAP HSR, we set up a test on an XtremIO Two XBrick cluster using a single-host HANA system installed with the /hana/data, /hana/log and /hana/shared volumes mounted from the XtremIO array. We then loaded HANA with randomized data to grow the database to approximately 170 GB. Figure 3 shows the XtremIO storage dashboard and the data reduction ratios before SAP HSR is implemented.

Figure 3.

Data reduction for a single host 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 additional delta load to the primary system to grow the database to 185 GB. For detailed information on system replication, refer to the SAP website resource How To Perform System Replication for SAP HANA. Figure 4 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 only 15


15

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

Figure 4.

Data reduction for a single host HANA system with HSR enabled

Note: All data reduction ratios were obtained in a laboratory environment with a generated test dataset. XtremIO data reduction is global; therefore we removed all other data and volumes from the Two X-Brick before the test to accurately reflect the ratios in the XtremIO dashboard. Results might vary in environments with different HANA datasets and dataset sizes, or where data already exists on the array.

SAP HANA storage-based replication with XtremIO and RecoverPoint Customers who deploy SAP landscapes with XtremIO can be assured that their mission-critical data is protected and available remotely on XtremIO with RecoverPoint, using asynchronous snap based replication. The new XtremIO solution with RecoverPoint provides a fully featured, robust product to cover all 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 also 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 HANA database to a consistent point-in-time. Note: For more information on this solution please refer to the Business Continuity and

Disaster Recovery with EMC XtremIO for SAP HANA TDI Solution Guide.


16

Configuration recommendations Introduction

The following configuration recommendations apply to production SAP HANA systems deployed on an EMC XtremIO storage array. Production SAP HANA systems in TDI environments must meet SAP KPIs. Therefore, special configuration requirements apply and are described in the following sections.

Host connectivity

The SAP HANA nodes connect to the XtremIO array through a Fibre Channel (FC) SAN. All SAN components require 8 Gb/s link speed. The SAN topology should follow best practices with all redundant components and links.

Storage controller requirements

Consider the following best practices when connecting SAP HANA nodes to the storage controller ports of an XtremIO array: 

Never connect a single host bus adapter (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. The more I/O paths available to a host, the better the SAP HANA performance. 8 Gb/s FC ports are required. While 10 Gb/s iSCSI might be an option, it has not been validated with SAP HANA. 2 Gb/s or 4 Gb/s FC ports are not supported with SAP HANA.

Figure 5 shows the back of the XtremIO 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 5.

Rear view of an XtremIO X-Brick


17

XtremIO scalability In an XtremIO array, the scalability of SAP HANA depends primarily on the number of configured X-Bricks. Table 3 shows the number of X-Bricks and the maximum number of SAP HANA worker hosts that can be connected. Table 3.

XtremIO scalability

Number of XtremIO X-Bricks

Maximum number of SAP HANA worker nodes

Single X-Brick cluster

4

Two X-Brick cluster

8

Four X-Brick cluster

14

Six X-Brick cluster

20

The SAP HANA hwcct tool can be used in customer environments to validate the SAP HANA performance and determine the maximum possible number of SAP HANA hosts on a given storage array. The scalability numbers in Table 3 for the XtremIO storage array are recommendations based on SAP HANA performance tests on Single X-Brick and Two X-Brick clusters without competing workloads. Applying the scaling from Table 3, the new Eight XBrick would support 26 nodes. Note: If the intention is to share the XtremIO array with other workloads in a production environment, customers are responsible for ensuring that the SAP HANA performance is not impacted. If SAP HANA performance is impacted, customers should move the competing workload to another array. Sharing mixed workloads with SAP HANA in nonproduction environments is acceptable where performance is not a key requirement.

Volume mapping

XtremIO uses volume mapping to assign storage to a host. All SAP HANA data and log volumes must be mapped to each SAP HANA host. A mapping consists of the following components: 

Initiator Group—Contains the initiators (WWNs) from the HBAs of the SAP HANA host. Each SAP HANA host should be connected to the XtremIO system with at least two HBAs for redundancy.



Storage Group—An SAP HANA scale-out cluster uses the shared-nothing concept for the persistence of the database. That means 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, the XtremIO storage groups of an SAP HANA database must contain all persistent devices of the database cluster. The SAP HANA name server in combination with the SAP HANA storage connector API takes care of proper mounting and I/O fencing of the persistence.


18

Using LUN 0 with XtremIO storage

This section provides information about using LUN 0 with 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, complete 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.

1.

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

# /usr/bin/rescan-scsi-bus.sh –r Note: -r enables the device removal.



2.

# 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.


19

Configuring EMC XtremIO storage using the XtremIO Storage Management Application The XtremIO internal architecture eliminates complex setups and tuning steps. You can use the XtremIO Storage Management Application shown in Figure 6 to complete the integral 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 6.

XtremIO Storage Management Application

Use the step-by-step instructions in the following sections as an example. Creating a volume tag

A volume tag refers to a logical grouping of volume objects. Creating volume tags simplifies volume management. To create a volume tag, complete the following steps: 1.

In the Configuration window, right-click Volumes on the Virtual tab and select Create Volume Tag. The Create Volume Tag dialog box appears, as shown in Figure 7.


20

Figure 7. Create volume tag

2.

Type a volume tag and click OK. The new volume tag appears under Volumes.

Creating volumes

Each SAP HANA node requires two volumes for persistence, one for data and one for logs. To create volumes, complete the following steps: 1.

From the menu bar, click Configuration.

2.

In the Volumes tag, shown in Figure 8, click Create Volume.

Figure 8.

3.

Creating volumes

In the Create Volumes dialog box, provide values for the following parameters: 

Name—The name of the volume



Size—The amount of disk space allocated for this volume



Volume Type—One of the following types to define the logical block (LB) size and alignment-offset: 

Normal (512 LBs)



4 KB LBs


21



Legacy Windows (offset: 63)



Small IO Alerts—Enabled if you want an alert to be sent when small I/O less than 4 KB is detected



Unaligned IO Alerts—Enabled if you want an alert to be sent when unaligned I/O is detected



VAAI TP Alerts—Enabled if you want an alert to be sent when the storage capacity reaches the set limit The summary line displays the number of volumes defined in the list and their total disk space, as shown in Figure 9.

Figure 9.

4.

Create Volumes summary screen

To add multiple volumes at the same time, click Add Multiple. Figure 10 shows the screen that appears. Specify the following: number of volumes to add, name and starting index if required, volume size, and logical block size.


22

Figure 10. Add Multiple Volumes

5.

Do one of the following: 

If you do not want to add the new volumes to a volume tag, click Finish.



If you want to add the new volumes to a volume tag, do the following: a.

Click Next. The Manage Volume Tags dialog box appears, as shown in Figure 11.

Figure 11. Selecting the volume tag


23

b.

Select the appropriate volume tag.

c.

Click Finish.

The volumes are created and appear in the Volume tab of the Configuration window. To view the volumes: 6.


7.

In the Virtual tab, expand Volumes and click a volume tag to list the volumes relevant to that volume tag, as shown in Figure 12.

Figure 12. Viewing volumes


24

Resizing a volume

As the database grows over time or during very heavy workloads, a disk-full event could 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 resize a volume: 1.

In the Volumes tab in the Configuration workspace, right-click the volume and select Modify Volume. The Modify Volume dialog box appears, as shown in Figure 13.

Figure 13. Modifying a volume

2.

In the Size field, type the volume size.

3.

Select or clear the Volume Alerts options to enable or disable the corresponding alerts.

4.

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


25

Creating an initiator group tag

An initiator group tag refers to a logical grouping of objects such as initiator groups. Creating tags simplifies object management. To create an initiator group tag: 1.

In the Configuration window, right-click Initiator Groups on the Virtual tab and select Create Initiator Group Tag. The Create Initiator Group Tag dialog box appears, as shown in Figure 14.

Figure 14. Creating a new initiator group tag

2.

Type a tag name and click OK. The new tag appears under Initiator Groups.

Creating initiator groups

You can add initiators to the cluster by defining them in an initiator group. You can define initiators either when you create a group, as described here, or later by using the Edit Initiator Group option. To create an initiator group: 1.


2.

In the Initiator Groups panel, shown in Figure 15, click Create initiator group.

Figure 15. Creating an initiator group

3.

In the Create Initiator Group dialog box, shown in Figure 16, type a name for the group.


26

Figure 16. Specifying initiator group name

4.

To add initiators to the new initiator group, click Add. The Add Initiator dialog box appears, as shown in Figure 17.


27

Figure 17. Specifying initiator name and worldwide name

5.

Specify the following parameters: 

Initiator Name—The name that identifies the initiator in the GUI or CLI lists



Operating System—The operating system running on the server.



Initiator Port Address—The SCSI identification of the initiator port, whose address depends on the port type, as follows: 



iSCSI ports—Addresses are in IQN or EUI format, For example: o

eui.02004567A425678D

o

iqn.1991-05.com.microsoft:win-1htai3q0tmg

Fibre Channel ports—Addresses using uppercase or lowercase hexadecimal digits are valid using the following formats: o

XX:XX:XX:XX:XX:XX:XX:XX

o

XXXXXXXXXXXXXXXX

o

0xXXXXXXXXXXXXXXXX

Note: To see unused port addresses, click the down-arrow next to the Initiator Port Address field in the Add Initiator dialog box. If the initiator was not previously discovered, the list box is empty and you must type the initiator port address.


28

6.



Initiator (credentials)—If CHAP Discovery is enabled for initiators, configure the initiator’s discovery credentials (username and password) and confirm the password. If CHAP Authentication is enabled for initiators, configure the initiator’s authentication credentials (username and password) and confirm the password.



Cluster (credentials)—If mutual CHAP discovery is enabled, configure the cluster’s Discovery credentials (username and password) and confirm the password. If mutual CHAP authentication is enabled, configure the cluster’s authentication credentials (username and password) and confirm the password. Click OK. The initiator is added to the new initiator group.

7.

If you want to add more initiators to the group, repeat steps 4 through 6.

8.

If you want to add the new initiator group to an iniator tag, in the Move Initiator Group to Folder dialog box, click Next and select a folder from the list.

9.

Click Finish. The new initiator group is created and appears under Initiator Groups in the Configuration workspace.

Viewing the initiator group properties

To view initiator group properties: 1.


2.

On the Virtual tab, expand the Initiator Groups and select an initiator group tag. The number of initiators groups contained in the initiator group tag is displayed in parentheses next to the tag name. The initiator group, its associated initiators, and other information (such as mapping) appear in the Initiator Group tab window, as shown in Figure 18.


29

Figure 18. Viewing initiator properties

Mapping a volume to an initiator group

To enable initiators within an initiator group to access disk space on a volume, map the volume to the initiator group. When you map a volume to an initiator group, a LUN is automatically assigned. The LUN number appears in the Selected Volumes panel of the Configuration workspace. You can map an initiator group to multiple volumes. The first mapping of the initiator group receives a LUN of zero. Additional mappings receive LUNs in sequential order. You can change these numbers later to any LUN. To map a volume to an initiator group: 1.


2.

On the Virtual tab, expand Volumes, as shown in Figure 19, and select the volume tag and associated volumes you want to map. To select multiple volumes, hold down the Shift key and select the volumes.

Figure 19. Select volumes to map


30

3.

Select Create/Modify Mapping. In the Create/Modify Volumes Mapping dialog box, select the initiator group to which you want to map the volume, as shown in Figure 20.

Figure 20. Select initiator group to map


31

4.

In the Select LUNs dialog box, click Map All, and then click Finish. The selected volumes are mapped to the initiator groups, as shown in Figure 21.

Figure 21. LUN mapping configuration

Viewing volume and initiator group mappings

To view volume mappings: 1.


2.

On the Virtual tab, expand Volumes and select the volume tag. Then select the volumes whose mappings to initiator groups you want to view.


32

To select multiple volumes, hold down the Shift key and select the volumes.

Figure 22. Selecting multiple volumes to view initiator group mappings

You can view initiator group mappings as follows: 3.


4.

In the Virtual tab, expand Initiator Groups and select the initiator groups tag. Then select the initiator groups whose volume mappings you want to view. To select multiple initiator groups, hold down the Shift key and select the groups.


33

Accessing XtremIO storage from the SAP HANA nodes The SAP HANA database requires a Linux SUSE SLES11 or a Red Hat RHEL 6.5 OS on the SAP HANA nodes. To access the XtremIO block devices from the SAP HANA nodes, ensure that zoning is properly configured based on SAN best practices. The EMC XtremIO Storage Array Host Configuration Guide provides more details. To access the block devices from the SAP HANA nodes, first enable native Linux Enable native Linux multipathing multipathing. Follow the steps described in the EMC Host Connectivity Guide for Linux to enable DM-MPIO on Red Hat Linux RHEL 6.5 or SUSE SLES11. (DM-MPIO) Figure 23 shows a sample multipath.conf file.

Figure 23. Sample multipath.conf file

The SAP HANA persistent devices should be visible on an SAP HANA worker host after a restart or a rescan (rescan-scsi-bus.sh command). To verify that all devices are present and each device has the number of active paths you configured, as shown in Figure 24, type the following command: Multipath –ll

Figure 24. Sample Multipath –ll


34

EMC uses the UUID of the LUN to identify the correct storage devices. To view the identifier of an XtremIO LUN, go to the Volume tab in the configuration workspace in the XtremIO Storage Management Application. The UUIDs are listed in the NAA Identifier column. Refer to Figure 12 for an example. Note: Linux adds a preceding 3 to the storage UUID.

XFS file system

The XFS file system provides best performance for both SAP HANA data and log block devices. To format a block device with the XFS file system, run the following command on the SAP HANA node: $ mkfs.xfs /dev/mapper/3514f0c5117200021 Note: Run this command for all block devices.

If for some reason you must expand a file system, run the xfs_growfs command on the Linux host after you expand the volume on the XtremIO system. Resizing a volume on page 25 provides details on how to expand a volume. SAP HANA storage connector

In an SAP HANA scale-out environment with worker and standby nodes, the SAP HANA storage connector for FC (fcClient) mounts and unmounts the devices to the SAP HANA nodes. In addition to mounting the devices, the storage connector also writes SCSI-3 persistent reservations (PRs) to the devices using the Linux sg_persist command. This is called I/O fencing and ensures that at a given time only one SAP HANA worker host has access to a set of data and log devices. SAP HANA global.ini file The storage connector API is controlled in the storage section of the SAP HANA global.ini file. The storage section of the file contains entries for the block devices with optional mount options. You can run the multipath –ll command on the SAP HANA hosts to determine the World Wide identifiers (WWIDs) of the partition entries.


35

Figure 25 is an example of a global.ini file.

Figure 25. Sample global.ini file Note: The SAP HANA Administration Guide and the SAP HANA Server Installation and Update Guide on the SAP Help Portal provide more details on the SAP HANA storage connector and how to configure the global.ini file.


36

Using XVC to copy and refresh an SAP HANA System XtremIO virtual copies are entirely metadata-driven snapshots that use the array’s inline data reduction. XtremIO virtual copies can be used to provide multiple test and development copies of the SAP HANA production database. In addition, they can be refreshed from the production database volumes to provide the latest data content. Virtual copies can also be refreshed from other virtual copies. This could be particularly useful where some data scrambling might be required with third party tools to protect sensitive data for test and training systems. Provisioning more virtual copies is an easy and instantaneous process. XVC efficiency enables multiple copies of the SAP HANA database to be created based on demand for maximum business efficiency, rather than based on storage capacity or performance limitations. Process Overview To make a copy of an SAP HANA system, create a copy of the /hana/shared file system and the 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. 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 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 EMC storage integrator (ESI) 4.0 for SAP LVM.

SAP HANA shared file system considerations In a scale-up system the installation path /hana/shared containing the HANA binaries may reside on an XtremIO block device. Because there is no requirement 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 /hana/shared directory is residing on a shared file system, the /hana/shared/ directory can be copied manually to the /hana/shared/ but must maintain permissions and owners. For example, for our tests we used the command:


37

cp -rp source_SID target_SID

where the –rp flag copies recursively and keeps permissions. 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. All three system identifiers—host name, SID, and instance number—can be changed together or individually from the SAP HANA database lifecycle manager graphical user or command-line interface. Mounted SID Preparation If the 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 4.

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

Detailed steps to copy a SAP HANA database using XVC 1.

Create an XtremIO Consistency Group of the SAP HANA system production persistence volumes from the configuration menu on the XMS application as shown in Figure 26.


38

Figure 26. Creating a consistency group with the HANA persistence volumes

2.

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

Figure 27. Creating a snapshot of the consistency group

3.

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


39

Figure 28. Mapping the snapshot set to target hosts

4.

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

Note: An existing target HANA installation is not required.

5.

Mount the target installation path (/hana/shared) which has been manually copied. Then mount the target data and log volumes on the target host(s). a.

In scaleout HANA systems that are using the storage connector, it is not necessary to mount the data and log volumes on the target hosts. However, it is necessary to do some preparations on the storage section of the copied global.ini and update NAA identifiers (UUID’s) to the XVC snapshot devices as shown in Figure 29.

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

6.

Register the new SAP HANA system on the target hosts. a.

Log on to the SAP HANA target host and change directories to the SAP HANA resident HDBLCM directory: cd //hdblcm

b.

Start the register and rename the task: i

To register hosts using the SAP HANA database lifecycle manager command-line interface: ./hdblcm and choose Register and Rename SAP HANA System

ii

Enter the target host name, SID, and instance number as you step through the Register and Rename wizard. Confirm all parameters to execute the SAP HANA system rename as shown in Figure 30.


40

Figure 30. Register and Rename parameter summary

License key after copy of an SAP HANA System The license key for an SAP HANA database is based on the system ID and the landscape ID. If you rename an SAP HANA system, this 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 which had only a temporary license; the system will be locked immediately until a new license is applied. Note: For more information about the copying and renaming of a SAP HANA system, refer to the SAP HANA Administration Guide.

XtremIO 4.0 refresh with SAP HANA copy systems.

XtremIO refresh operations are instantaneous and crash-consistent but most do not significantly affect host-level SCSI attributes (for example, NAA identifiers). Process Overview Stop the virtual copy system and unmount the /hana/data/SID, /hana/log/SID volumes. It is not necessary to unmount the installation path /hana/shared. Once the data and log volumes are unmounted, refresh the XVC snapshot from either the parent consistency group (CG) or select an existing snapshot as shown in Figure 31. When the refresh is complete the same devices can be mounted again to the target SID mount points because the host-level SCSI attributes and the UUID’s have not been changed. When using the XtremIO snapshot refresh feature with SAP HANA, it is important to understand that the topology of the HANA system is contained in the data and log volumes within the nameserver directory of the master node. After a snapshot Storage Configuration Best Practices for SAP HANA Tailored Data Center Integration on EMC XtremIO Storage

41

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, use the SAP HANA executable hdbnsutil on the target master nameserver. As sidadm call: hdbnsutil -convertTopology Once complete, the HANA System copy can be started with the refreshed data. Detailed steps to refresh a SAP HANA database using XVC In a single host/scale-up HANA system: 1.

Stop the HANA database.

2.

Unmount the volumes /hana/data/SID, /hana/log SID. Note: The installation path /hana/shared 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 HANA system, then in order to successfully refresh the HANA system the /hana/shared device should be removed 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.

3.

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


42

Figure 31. Selecting a CG or snaphot to refresh from

4.

Mount the volumes to the same target SID mountpoints.

5.

Execute hdnnsutil –convertTopology as sidadm as shown in Figure 32.

6.

Start the HANA database. In a scale-out 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 HANA system. Note: For scale-out HANA systems the /hana/shared volume is not added to the consistency group as it resides on a shared filesystem.

7.

Stop the HANA database.

8.

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

9.

Execute hdnnsutil –convertTopology as sidadm. As 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 in order to convert the system identifiers.


43

Figure 32. Converting topology of a 2+0 scale-out HANA system

10. Start the 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 and there is 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 de-duplicated and then compressed. We executed some tests to observe the space savings. In these tests, the used capacities of the virtual and physical volumes were compared when using XVC to create and refresh HANA system copies. The data points are shown in Figure 33. 1.

First, we installed a populated database called PRD as shown in Figure 33.

2.

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

3.

We added some data scrambling and additional load to the CPY database, from which multiple copies can be provided for test and development teams with any sensitive data removed. The volume capacity grew by 42 GB but the physical capacity only grew by 30 GB because of XtremIO data reduction technologies even on the virtual copies.

4.

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

5.

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


44

Figure 33. Physical used capacity compared to volume used capacity

As shown in Figure 34, from the XMS dashboard we can observe great storage space efficiency when comparing 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 array.

Figure 34. XMS storage dashboard before and after virtual copies created


45

References EMC documentation

You can find the following documents on EMC Online Support: 

EMC Host Connectivity Guide for Linux



EMC XtremIO Storage Array User Guide



EMC XtremIO Storage Array Hardware Installation and Upgrade Guide



EMC XtremIO Storage Array Operations Guide



EMC XtremIO Storage Array Host Configuration Guide



Introduction to the EMX XtremIO Storage Array



XtremIO Integrated Copy Data Management



Introduction to XtremIO Snapshots



Business Continuity and Disaster Recovery with EMC XtremIO for SAP HANA TDI

VMware documentation

You can find the following VMware document on the VMware website:

SAP documentation

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



Best Practices and Recommendations for Scale-up Deployments of SAP HANA on VMware vSphere



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 tailored data center integration 

SAP HANA TDI - FAQ



How To Perform System Replication for SAP HANA

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

Deployment option notes 

Note 1681092–Multiple SAP HANA databases on one appliance


46



Note 1661202–Support for multiple applications on SAP HANA

Note 1943937–Hardware Configuration Check Tool Note 1666670–BW on SAP HANA; Landscape deployment planning Virtualization note Note 1788665–SAP HANA running on VMware vSphere VMs Best practices 

Sizing Approaches for SAP HANA–Lessons Learned



Enterprise Storage Architecture–Planning Guide



Elements of a Software Change Management Strategy



Technical Deployment Options for SAP Systems with SAP HANA - Best Practice


47

Configuration Best Practices for SAP HANA TDI

Configuration Best Practices for SAP HANA TDI

Suggest Documents

Configuration Best Practices for SAP HANA TDI

SAP HANA Best Practices Guide - Amazon AWS

DELL EMC STORAGE OFFERS FOR SAP HANA TDI

SUSE High Availability Configuration Guidelines for SAP HANA Using ... [PDF]

SAP HANA

SAP HANA

SAP HANA

Deployment for SAP HANA or SAP BWA

Deployment for SAP HANA or SAP BWA

Lenovo Solution for SAP HANA

Best Practices for Migrating SAP Environments

Configuration Best Practices for Motorola/Symbol Wireless ...

Lenovo Solution for SAP HANA

sap hana buyers guide

SAP HANA sur AWS

Session 0414 NEW! SAP HANA Information Composer - SAP HANA ...

Who is my SAP HANA DBA? - SAP HANA Distinguished Engineers

SAP HANA appliance: Revision 47 of SAP HANA database Summary ...

SAP Solution Manager & SAP HANA - ASUG.com

SAP HANA or SAP BWA Deployment Services

SAP HANA Modeling Guide - SAP Help Portal

SAP HANA Modeling Guide - SAP Help Portal

SAP HANA Modeling Guide - SAP Help Portal

PDF Download SAP HANA Certification Guide Best ... - Google Sites