BUSINESS CONTINUITY AND DISASTER RECOVERY WITH EMC VMAX3 FOR SAP HANA TDI DEPLOYMENTS

Transcription

1 BUSINESS CONTINUITY AND DISASTER RECOVERY WITH EMC VMAX3 FOR SAP HANA TDI DEPLOYMENTS Enabled by EMC SRDF and EMC TimeFinder SnapVX EMC Solutions Abstract This solution guide provides a comprehensive set of EMC recommendations and procedures for data protection and availability using SAP HANA with EMC VMAX3 (100K, 200K, and 400K) storage in a Tailored Data Center Integration (TDI) deployment. September 2015

2 Copyright 2015 EMC Corporation. All Rights Reserved. Published September 2015 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 H

3 Table of contents Executive summary... 5 Business case... 5 Solution overview... 5 Introduction... 6 Document purpose... 6 Scope... 6 Audience... 6 Terminology... 6 Solution overview... 9 Overview... 9 EMC VMAX Symmetrix Remote Data Facility Virtual Data Mover synchronous replication TimeFinder SnapVX SAP HANA Scale-up compared with scale-out Disaster recovery in SAP HANA Backups SAP HANA system replication Storage-based replication SAP HANA storage-based replication with VMAX SAP HANA database clones and snapshots with TimeFinder SnapVX Business continuity best-practice use cases for local and remote SAP HANA storage-based replications General requirements Software requirements When to use SRDF/S and SRDF/A SAP HANA considerations Test environment Maintaining the SAP HANA global.ini file at the remote site Use case 1: Establishing remote mirroring for DR protection (synchronous and asynchronous) Process overview Detailed steps

4 Use case 2: Failing over the SAP HANA persistent devices to the remote site when the source site is unavailable (planned or unplanned outages) Process overview Detailed steps Use case 3: Failing back the SAP HANA persistent devices to the source site Process overview Detailed steps Use case 4: Using consistency group technology for disaster protection of an SAP ERP system, SAP LT replication server, and the SAP HANA environment Process overview Detailed steps Use case 5: Creating remote restartable and writeable database clones for repurposing (using an SAP HANA storage snapshot) Process overview Detailed steps Use case 6: Creating local restartable and writeable database clones for rapid database recovery (using TimeFinder SnapVX copy mode) Process overview Detailed steps Use case 7: Using cascaded snapshots to create remote restartable and writeable snapshots (using TimeFinder SnapVX no-copy mode) Process overview Detailed steps Conclusion References EMC documentation SAP documentation

5 Executive summary Business case Customers deploy SAP databases and integrated applications in many missioncritical functions, including manufacturing, financial accounting, inventory management, sales, and marketing. These and other functions are the lifeblood of a business, and interruptions or loss of data can be catastrophic. Ensuring the availability of these systems for the businesses that depend on them requires a comprehensive approach to business continuity planning and execution. SAP landscapes include many separate business-critical modules that all interact and communicate with critical cross-dependent data. In addition, every complex business IT landscape includes not only many SAP systems, but non-sap systems that feed SAP, receive data from SAP, or are critical standalone systems. Recovering these many interrelated systems, or periodically testing the effectiveness of recovery for business and audit requirements, is a unique requirement of federated systems such as SAP. True cross-database, cross-business system recovery is required for a single point in time, in contrast to recovering many individual databases separately. Solution overview EMC VMAX3 storage systems are widely used in mission-critical SAP landscapes with traditional databases. The VMAX3 family now provides the same reliable platform for the SAP HANA database. In this solution, EMC Symmetrix Remote Data Facility (SRDF ) mirroring with consistency technology, combined with EMC TimeFinder SnapVX, enables SAP customers to sync consistently across databases to reliably restore or test the many business functions in the total SAP landscape. SRDF and TimeFinder SnapVX enable complete high availability and business continuity for mission-critical environments for synchronous and asynchronous data protection. 5

6 Introduction Most customers who use the SAP HANA in-memory database in TDI deployments with VMAX3 maintain a copy of the data either locally or remotely to protect their missioncritical applications and the SAP HANA in-memory database against disasters, hardware or software failures, and human errors. While SAP HANA offers disaster recovery (DR) support with backups or with HANA system replication, HANA storage-based replication, based on VMAX3 replication technologies enables customers to seamlessly integrate SAP HANA into their existing business continuity solutions. Document purpose Scope Audience Terminology This solution guide introduces VMAX3 storage replication technologies for SAP HANA. It provides a comprehensive set of best practices and procedures to ensure business continuity in a TDI deployment of SAP HANA with VMAX3 storage. This solution guide: Introduces the key technologies of the solution Describes the design considerations for the solution Provides guidelines for performing SRDF and TimeFinder SnapVX operations Details best practices via use cases that show how the solution can be successfully implemented This guide is intended for database and system administrators, storage administrators, and system architects who are responsible for implementing, maintaining, and protecting robust SAP HANA in-memory databases and storage systems. It assumes that readers have some familiarity with SAP HANA in-memory databases, VMAX3 hardware, VMAX3 software SRDF and TimeFinder SnapVX and are interested in achieving higher database availability and protection. Table 1 lists key solution-specific terminology used in this guide. Table 1. Terminology Term Composite group Device group Definition A user-defined group of device members that can span multiple Symmetrix arrays and RDF groups. A user-defined group comprising a set of devices used for replication (local or remote) purposes. At the time of creation, a device group must be defined as type REGULAR, RDF1, or RDF2 and may contain various device lists for standard, BCV, virtual (VDEV), and remote devices. If the group type is defined as RDF1 or RDF2, the group is considered an RDF device group. 6

7 Term HW Configuration Check Tool (HWCCT) Key performance indicator (KPI) Recovery point objective (RPO) Recovery time objective (RTO) Remote Data Facility (RDF) group SAP HANA standby host SAP HANA worker host Scale-out system Scale-up system <sid>adm Storage group Definition An SAP tool used for the certification process. The tool measures the storage and network performance of an SAP HANA hardware configuration that needs to fulfill a set of SAP KPIs. A threshold that has to be achieved or fulfilled in a test. The maximum time span of data loss that is acceptable in a disaster situation. The maximum time allowed for a secondary or standby system to become available. A user-defined object that provides a collective data transfer path linking volumes of two separate VMAX3 systems. An RDF group enables synchronization of data between the R1 (primary) and R2 (secondary) volume pairs associated with it. At least one physical connection must exist between the two VMAX3 systems within the fabric topology. A passive host within an SAP HANA system. It has all services started but does not accept SQL requests. It waits for the failure of another host and then takes over the persistency and becomes active. A host that is active within an SAP HANA system that is, one that is accepting SQL requests. An SAP HANA system that consists of more than a single host. An SAP HANA system that consists of exactly one host. The administrator user ID of the SAP HANA database. <sid> represents a threecharacter system ID. A logical grouping of up to 4,096 VMAX3 devices. The dynamic LUN addressing feature assigns LUN addresses to the devices in the cascaded storage group when the masking view is created. 7

8 Term Symmetrix Remote Data Facility (SRDF) consistency group Tailored Data Center Integration (TDI) Definition A composite group of RDF devices (RDF1 or RDF2) that has been enabled for remote database consistency. The RDF consistency groups operate in unison to preserve the integrity and dependent-write consistency of a database distributed across multiple arrays. An SAP hardware-partner program for certification of hardware components. The SAP HANA Hardware Directory lists certified components. 8

9 Solution overview Overview EMC VMAX3 This section describes the key components and features used for SAP HANA business continuity with EMC VMAX3. The VMAX3 array is the first enterprise data-services platform built to deliver and manage predictable service levels at scale for hybrid clouds. It is based on EMC s Dynamic Virtual Matrix that delivers agility and efficiency at scale by pooling hundreds of CPU cores and allocating them on demand to meet performance requirements for dynamic mixed workloads. The VMAX3 provides up to three times the performance of previous-generation arrays with double the density. Figure 1 shows the VMAX3 family of storage arrays. Figure 1. VMAX3 storage systems Running on the Dynamic Virtual Matrix is the new HYPERMAX OS, the industry s first converged storage hypervisor and operating system that runs mission-critical data and application services with single-click service-level provisioning. The new storage hypervisor enables the VMAX3 platform to redefine the data center. It brings new levels of efficiency to enterprise workloads by embedding data services (file/object, replication, data mobility) and application services such as database tools, analytics, and extract, transform, load (ETL), which traditionally ran external to the array. VMAX3 arrays deliver mission-critical storage with the scale, performance, availability, and agility required to meet the high demands of extreme data growth in today s and tomorrow s hybrid cloud. Note: Storage Configuration Best Practices for SAP HANA Tailored Data Center Integration on EMC VMAX and VMAX3 Storage Systems White Paper provides more details about configuring the VMAX3 array in an SAP HANA TDI environment. VMAX3 offers several technologies to protect customer data and maintain business continuity in case of unexpected failures both within the data center and across data centers. These technologies include SRDF, Virtual Data Mover (VDM) synchronous replication, and TimeFinder SnapVX. 9

10 Symmetrix Remote Data Facility SRDF is a family of DR, parallel processing, and data migration solutions. SRDF configurations require at least two arrays a primary array and a minimum of one secondary array. The arrays can be located in the same room, in different buildings within the same campus, or hundreds, even thousands, of kilometers apart. In the open-systems host environment: A control host/management server at the production site is connected to the primary array. Primary and secondary sites are connected over SRDF links. The production host writes I/O to R1 devices at the primary site. SRDF mirrors the production I/O to the R2 devices at the secondary site. Symmetrix Remote Data Facility modes SRDF supports the following primary modes of operation: Synchronous The synchronous mode maintains a realtime mirror image of data between the R1 and R2 devices, providing a zero recovery point objective (RPO). Data must be successfully stored in Symmetrix cache at both the primary and the secondary site before an acknowledgment is sent to the production host at the primary site. Asynchronous The asynchronous mode mirrors R1 devices by maintaining a dependent-write-consistent copy of the data on the secondary (R2) site at all times. Asynchronous replication (SRDF/A) session data is transferred in cycles via delta sets from the primary to the secondary site. The point-in-time copy of the data at the secondary site is only slightly behind that on the primary site, giving a near-zero RPO. SRDF/A has little or no impact on performance at the primary site, provided that the SRDF links contain sufficient bandwidth and the secondary array can accept the data as quickly as the data is being sent. Adaptive copy SRDF supports adaptive copy mode as a secondary mode of operation. With adaptive copy mode, R1 and R2 devices can be more than one I/O out of synchronization. Unlike the asynchronous mode, adaptive copy mode does not guarantee a dependent-write-consistent copy of data on R2 devices. The number of tracks out of synchronization between the R1 and the R2 devices at any given time is determined by the maximum skew value. You can set the maximum skew value by using EMC host-based SRDF software. SRDF also supports multisite replication options, including concurrent SRDF, cascaded SRDF, and SRDF/Star, whereby consistent copies of data can be maintained at multiple different locations. Note: EMC Solutions Enabler SRDF Family: CLI User Guide provides more details about SRDF configurations and operations. 10

11 Virtual Data Mover synchronous replication Virtual Data Mover (VDM) synchronous replication (also called file auto recovery) provides the ability to use the embedded NAS (enas) for File CLI to manually fail over or move a VDM from a source enas system to a destination enas system. The failover or move uses block-level SRDF synchronous replication (SRDF/S), providing zerodata-loss protection for an unplanned failover. The synchronous replication feature consolidates VDMs, file systems, file-system checkpoint schedules, CIFS servers, NFS file shares, networking, and VDM configurations into their own separate pools. This feature works for a true DR where the source is unavailable. For DR support in the event of an unplanned failover, it provides an option to recover and clean up the source system to prepare it as a future destination. You can also manually initiate failover and reverse operations using the EMC File Auto Recover Manager (FARM). The FARM option provides the ability to automatically fail over a selected sync-replicated VDM on a source enas system to a destination enas system. Use FARM to set up monitoring of configured synch-replication VDMs and to trigger automatic failover due to VDM, file system, control station, or IP network unavailability that would cause the NAS client to lose access to data. TimeFinder SnapVX EMC TimeFinder software delivers point-in-time copies of volumes that can be used for backups, decision support, data warehouse refreshes, or any other process that requires parallel access to production data. HYPERMAX OS 5977 for VMAX3 introduces TimeFinder SnapVX, which enables the creation of nondisruptive point-in-time copies (snapshots) of critical data. SnapVX creates snapshots by storing changed tracks (deltas) directly in the Storage Resource Pool (SRP) of the source device. SnapVX provides low-impact snapshots and clones for VMAX LUNs. SnapVX supports up to 256 snapshots per source volume, which are tracked as versions, with less overhead and simple relationship tracking. You can assign names to identify snapshots, and you can set automatic expiration dates on each snapshot. With SnapVX, you do not need to specify a target device and source/target pairs when you create a snapshot. You can access a point-in-time snapshot by linking it to a host-accessible volume referred to as a target. The target volumes are standard VMAX3 thin LUNs. You can link as many as 1,024 target volumes to one or more snapshots of a single source volume in either of two ways: by linking all 1,024 target volumes to the same snapshot from the source volume or by linking multiple target volumes to multiple snapshots from the same source volume. However, a target volume may only be linked to a single snapshot at a time. By default, targets are linked in a no-copy mode, but you can link targets in a copy mode to create full-copy clones. Snapshots can be cascaded from linked targets, and targets can be linked to snapshots of linked targets. The level of cascading is unlimited, and the cascade can be broken at any point. 11

12 You can break the relationship between a snapshot and a linked target by using the unlink command. You can unlink copy-mode-linked targets once copying is complete, and they will retain a full, useable point-in-time copy of the source volume. After a no-copy-linked target has been unlinked, the target data should not be considered valid because a considerable amount of the data may not be associated with the point in time. The relink command enables you to perform incremental refreshes of linked targets. You can also use it to link a target to a different snapshot of the same source volume. You can issue the relink command to both copy- and no-copy-mode linked targets. This functionality provides an easy way for you to check different points in time, as illustrated in Figure 2, if you are unsure of which one to access. Figure 2. TimeFinder SnapVX SnapVX supports TimeFinder/Clone, TimeFinder VP Snap, and TimeFinder/Mirror via emulations that transparently use SnapVX. This means you can still run scripts that use TimeFinder/Clone, TimeFinder VP Snap, and TimeFinder/Mirror commands, but the underlying mechanism will be SnapVX. Note: SnapVX also supports scenarios where customers may have to place their targets in separate SRPs, on separate disks from their source LUNs. 12

13 SAP HANA SAP HANA is an in-memory database. The data is kept in the RAM of one or multiple SAP HANA worker hosts, and database operations are performed in the main memory of the host. This feature differentiates SAP HANA from other traditional databases, where all data resides on disk and only the current working set is cached in RAM. SAP HANA uses persistent disk storage to provide a fallback in the event of a failure, ensuring that the SAP HANA database can always be restored to its most recent committed state. The in-memory state of the database is persisted every 5 minutes to the disk using the savepoints method. Additionally, all transactions since the last savepoint are captured on disk in redo logs. Scale-up compared with scale-out As an SAP-certified enterprise storage array for SAP HANA, VMAX3 supports both single-host (scale-up) and multihost (scale-out) SAP HANA systems in TDI deployments. In single-host environments, the whole database must 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 is distributed across the RAM of multiple servers. Multihost environments use worker and standby hosts. A worker host is an active component that accepts and processes database requests, while a standby host is a passive component that has all database services running but no data in RAM. It waits for a failure of a worker host so that it can take over its role, a process known as host auto-failover. Because the in-memory capacity requirements 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. A multihost installation can be extended by adding new worker hosts to the system. Disaster recovery in SAP HANA When using the SAP HANA in-memory database in TDI deployments with VMAX3, most customers maintain a local or remote copy of the data for DR protection of their mission-critical applications and SAP HANA in-memory database. SAP HANA offers three levels of DR support: Backups SAP HANA system replication Storage-based replication Each level of support addresses different RPOs within the required recovery time objective (RTO), where RPO denotes the point of consistency to which SAP HANA needs to recover, and RTO denotes the time allowed for a recovery of the SAP HANA system to a specified point of consistency. 13

14 While SAP HANA offers DR support through backups or SAP HANA system replication, SAP HANA storage-based replication enables customers to seamlessly integrate SAP HANA into their existing business continuity solutions based on VMAX3 replication technologies and using federated DR strategies. Backups Backups protect the primary SAP HANA persistence against a storage failure. Therefore, the SAP HANA backup target should never be on the same storage array as the primary SAP HANA persistence. Backup systems can typically replicate the backup storage to a remote system to protect against a site failure. With SAP HANA backups, the RPO can be minutes or hours, depending on the frequency at which you are doing SAP HANA backups. The RTO with backups can be several hours, because an SAP HANA backup must be restored to the persistence and then read into memory before the database is available. Note: EMC offers SAP HANA backup solutions based on EMC NetWorker and EMC Data Domain data protection technology. For more information on these technologies, see the following EMC white papers: Protecting SAP HANA with EMC Networker and Protecting SAP HANA with Data Domain Boost for Databases and Applications. SAP HANA system replication SAP HANA system replication is an application-based DR solution whereby a secondary standby SAP HANA system is configured as an exact copy of the active primary system. Each secondary system must consist of the same number of active SAP HANA nodes. As with storage-based replication, SAP HANA system replication requires a reliable connection between the primary and secondary sites. The replication technology supports multiple replication modes: synchronous, synchronous in-memory, and asynchronous. With SAP HANA system replication, only the database content is replicated to the secondary site. Note: Beginning with SAP HANA Support Package Stack (SPS) 09, dynamic tiering is available with SAP Sybase IQ. At this time, neither SPS 09 nor SPS 10 supports the transfer of dynamic tiering contents using system replication. Storage-based replication Storage-based replication in SAP HANA TDI deployments provides a reliable, consistent, and convenient method to protect against a site failure. The SAP HANA primary persistence is replicated to a secondary site via storage-based replication technologies. Depending on your RTO and RPO requirements and the distance between the primary and secondary site, implementation of synchronous storagebased replication (RPO=0) or asynchronous storage-based replication (RPO 0) is possible. If a disaster occurs, the RTO is typically the time it takes to start up the SAP HANA database at the secondary site. 14

15 Offering several benefits that are not provided by system replication, SAP HANA storage-based replication: Replicates the SAP HANA database persistence to ensure that it is available at the secondary site Can include applications and data outside of SAP HANA in the consistency technology of the storage arrays, thus creating a consistent point-in-time image of the overall business applications at the secondary site In addition to replicating the SAP HANA database persistence, you can integrate replication of components such as the OS boot volumes, the SAP HANA shared file system (which includes the binaries and configuration files), and applications other than SAP HANA into a storage-based replication strategy, thus enabling a federated DR strategy. This solution guide describes several use cases for SAP HANA local and remote storage-based replication on VMAX3 storage arrays. Note: SAP HANA Administration Guide provides more details about the different DR solutions and their advantages and disadvantages. SAP HANA storagebased replication with VMAX3 The demand for database protection and availability increases as data grows in size and as databases become more interconnected. In the event of a disaster whether a natural disaster or one caused by human error or hardware or software failure, an organization is measured by its ability to resume operations quickly, seamlessly, and with the minimum amount of data loss. A valid backup and restartable image of the entire information infrastructure helps achieve RPO, RTO, and service-level agreement goals. VMAX3 SRDF guarantees that the persistent devices of the SAP HANA database are replicated to the remote site, thus ensuring the existence of a remote restartable copy of the SAP HANA database. SAP HANA database clones and snapshots with TimeFinder SnapVX Every mission-critical system has a need for multiple copies of data. In addition to maintaining the protection of the primary production databases, multiple copies serve as copies for test systems and for business and IT testing of remote-site DR validation. With VMAX3, using TimeFinder SnapVX software in combination with SAP HANA storage snapshots of the in-memory database, you can create or refresh multiple copies of the SAP HANA database persistence (data and log). You can create these multiple copies, either full volume clones or snapshots, in seconds, regardless of the database size. When SnapVX establishes a snapshot, you can link it to a target device. The target device s data is immediately available to the SAP HANA nodes, even as data copy operations continue in the background. 15

16 Business continuity best-practice use cases for local and remote SAP HANA storage-based replications SAP HANA can be enhanced with various business continuity solutions. EMC SRDF replicates the SAP HANA persistent devices to a remote site, either nearby or at a long distance. The business continuity solutions provide DR protection by using SRDF in synchronous mode for close distances or asynchronous mode for long distances. Adding EMC TimeFinder SnapVX extends the database recovery protection to include a remote restartable and writeable replica of SAP HANA persistent devices for repurposing. On the source site, EMC TimeFinder SnapVX clones can provide rapid recovery of the database. The use cases in this guide provide best practices for implementing SAP HANA storage-based replication on VMAX3 arrays, using proven SRDF replication technology that is already in wide use by customers. The use cases introduce TimeFinder SnapVX, which combines the best aspects of previous TimeFinder offerings, adding new ease-of-use features and increased scalability. The use cases illustrate how SnapVX creates point-in-time copies of volumes, which can be used for backups, decision support, data warehouse refreshes, or any other process. They also demonstrate how SRDF can be implemented to provide remote restartable SAP HANA databases. The business continuity use cases, which include descriptions and command examples for reference, are as follows: Use case 1: Establishing remote mirroring for DR protection (synchronous and asynchronous) Use case 2: Failing over the SAP HANA persistent devices to the remote site when the source site is unavailable (planned or unplanned outages) Use case 3: Failing back the SAP HANA persistent devices to the source site Use case 4: Using consistency group technology for disaster protection of an SAP ERP system, SAP LT replication server, and the SAP HANA environment Use case 5: Creating remote restartable and writeable database clones for repurposing (using an SAP HANA storage snapshot) Use case 6: Creating local restartable and writeable database clones for rapid database recovery (using TimeFinder SnapVX copy mode) Use case 7: Using cascaded snapshots to create remote restartable and writeable snapshots (using TimeFinder SnapVX no-copy mode) 16

17 General requirements Software requirements When to use SRDF/S and SRDF/A Before an SAP HANA DR solution in an SAP HANA TDI scenario can be established, the following requirements must be met: An SRDF license and SRDF consistency group license must be applied on both the source and destination VMAX3. The RDF daemon must be applied to the management server and the SYMAPI_USE_RDFD option must be enabled. An SRDF connection must exist between the source and the destination. SRDF links are logical connections between Symmetrix SRDF groups and their ports, which are physically connected by cables, routers, extenders, switches, and other network devices. The destination array must be configured with the same SAP HANA volumes. For guidance, see the EMC white paper Storage Configuration Best Practices for SAP HANA Tailored Data Center Integration on EMC VMAX and VMAX3 Storage Systems. The local and destination arrays must be configured with the SAP HANA volumes that will be used as targets for SnapVX operations. These volumes must be visible to the SAP HANA servers via storage groups and masking views. The use cases have been tested using the following software versions. Ensure that your environment is at least at these levels: SAP HANA 1.0 SPS 09 rev96 SUSE Linux SLES11 for SAP Applications SP3 SRDF/S is a limited-distance solution that is typically implemented in campus or metro environments: In campus solutions, data is typically transmitted over fiber-optic cable, using VMAX3 and SAN equipment with a distance of 66 km or less and using channel extenders or long-distance fiber-optic cable. In metro solutions, the distance is typically less than 100 km. Wide area network (WAN) provides SRDF connectivity over long distances, using telecommunication networks such as IP, synchronous optical networking (SONET), or asynchronous transfer mode (ATM). SRDF/A must be used in all WAN implementations. Whether SRDF/S can be used in campus or metro implementations depends on the bandwidth available for the SAP HANA persistence and the latency of IOPS. SAP provides a Hardware Configuration Check Tool (HWCCT), which must be used to validate the bandwidth and latency of the SAP HANA persistent storage. The validation results must meet the SAP HANA key performance indicators (KPIs) for the persistent storage layer, which are also available from SAP. This applies to nonreplicated environments. Consult your SAP representative for exceptions for the KPIs for replicated environments. 17

18 SAP HANA considerations To reuse a consistent copy of the SAP HANA persistence in another SAP HANA installation, consider the following: SAP HANA stores hostnames within the persistence. EMC recommends using virtual hostnames with identical names in both installations. For more information, see SAP HANA Administration Guide. If you are also copying the SAP HANA shared file system, take particular care with the configuration files. For more information, see SAP HANA Administration Guide. These use cases do not include the replication of an SAP HANA shared file system, which includes the binaries and configuration files. Both sites must have access to the same NFS share with the SAP HANA shared file system, or SAP HANA must be installed at the DR site on a local NFS share. The SAP HANA installation at the DR site must be identical to the installation at the production site in terms of number of workers, standby nodes, RAM sizes, and SAP HANA SID. Note: If a shared block file system (OCFS2, GFS2) is used for the SAP HANA shared file system, you can use the VMAX3 SRDF for those devices also. If the SAP HANA shared file system is provided by VMAX3 enas, then the VDM synchronous replication feature provides the ability to manually fail over a VDM from a local enas system to a remote enas system via block-level SRDF, but only with synchronous replication (SRDF/S). This guide does not discuss these scenarios. Test environment The use cases described in this document have been tested in a scale-out SAP HANA deployment with three worker nodes and one standby node on a local VMAX3 100K array connected via SRDF to a remote VMAX3 200K array, as shown in Figure 3. Figure 3. Test environment 18

19 Each VMAX3 array has a management server connected with the EMC Solutions Enabler command line (SYMCLI) installed. The use cases described in the following sections use SYMCLI commands. The same number of SAP HANA nodes must be available at the remote site or standby SAP HANA appliance. The nodes use the R2 devices for their SAP HANA persistence when a failover occurs. Table 2 shows the local and remote storage groups and device IDs used for the SAP HANA installation as well as those used as linked targets for the TimeFinder SnapVX operations. The Use case row refers to the use cases in this guide where the storage groups and the devices contained within them are used. The device IDs in the table are color-coded to correspond to the devices shown in the figures in the related use-case sections of this guide. Table 2. Local and remote storage groups and device IDs SAP HANA persistence Local storage group and device ID Remote storage group and device ID SAP HANA node VMAX3 device size HANA_ SG_R1 HANA_LNK _TGT HANA_ SG_R2 HANA _SS HANA_LNK_ TGT HANA_ CS_QA HANA_CS _TRN HANA_CS _DEV Use case 1,2,3 6 1,2,3 5 7 Server 01 DATA Server 01 LOG Server 02 DATA Server 02 LOG Server 03 DATA Server 03 LOG 512 GB E 01A B GB 01C E A 512 GB 01A 03F 01B C GB 01D C F B 512 GB 01B E D GB 01E D A C Note: For SRDF replications, we used a single consistency group and RDF group that included all the SAP HANA persistent devices (data and log), as shown in Table 2. 19

20 Maintaining the SAP HANA global.ini file at the remote site The storage section in the SAP HANA global.ini file contains the references from the SAP HANA storage partitions to the storage LUNs. EMC uses the UUID of the LUN to identify the correct storage devices. You can identify the UUIDs using either of the following two methods: From the SAP HANA node For example, type the following command on the SAP HANA node to identify the UUID of a 512 GB data LUN: server01: ~ # multipath ll grep B1 512G The command returns the following: dm-35 EMC,SYMMETRIX Size=512G features='0' hwhandler='0' wp=rw The string is the UUID of the corresponding storage LUN. Linux adds a preceding 3 to the storage UUID. From a management server using SYMCLI, if the VMAX3 device ID is known For example, type the following command to display the UUID for device ID 01A: C:\Windows\system32>symdev sid 016 list wwn findstr 01A The command returns the following: 0001A Not Visible RDF1+TDEV Note: SYMCLI displays the UUID without the preceding 3. The SAP HANA global.ini file should then look like this example: Note: If SAP HANA needs to start at the secondary site with the mirrored R2 devices or the linked target devices, ensure that the storage section of the global.ini file contains the UUIDs pointing to the R2 or linked target devices. 20

21 Use case 1: Establishing remote mirroring for DR protection (synchronous and asynchronous) This use case describes how to establish remote mirroring for DR protection using EMC SRDF in a synchronous or an asynchronous mode. The protection is established on the SAP HANA database persistent (data and log) devices. In this use case, the R1 devices in the source VMAX3 are replicated to the R2 devices in the target VMAX3. While the replication is active, writing to the R2 devices is not possible. Figure 4 illustrates this use case. Figure 4. Establishing remote mirroring Process overview The following steps summarize the process for establishing remote mirroring from the source site to the target site. See Detailed steps for command examples. 1. Create an RDF group between the two sites. 2. Create the device pairs text file. 3. Create device pairs and set the RDF mode. 4. Create the composite group HANA_CG and add the devices. 5. Perform initial synchronization of SRDF in adaptive copy disk mode. 21

22 6. After the SRDF target is synchronized with the source, change the replication mode to SRDF/S or SRDF/A. 7. Enable consistency using composite group HANA_CG. Detailed steps The following steps include command examples. Note: EMC Solutions Enabler SRDF Family: CLI User Guide provides a full explanation of the command structure. 1. Create an RDF group between the two sites: symrdf addgrp label HANA_RDF rdfg 1 sid 790 dir 1E:04,3E:05 remote_sid 016 remote_dir 1E:05:3E:05 2. On the management server, create a text file that lists the source and the target device pairs. Map the source data1 LUN with the target data1 LUN, the source data2 LUN with the target data2 LUN, and so on. #cat HANAPAIRS.txt A 01A 01B 01B 01E 01C D 01C 01E 01D 3. Create the device pairs in the HANA_RDF group and set the RDF mode to adaptive copy disk mode. The target devices must be write_disabled. symdev sid 016 dev 019, 01A, 01B, 01C, 01D, 01E write_disable symrdf createpair sid 790 file HANAPAIRS.txt rdfg 1 type R1 invalidate R2 rdf_mode acp_disk 4. Create composite group HANA_CG and add the local SAP HANA devices to this group. symcg type RDF1 create HANA_CG rdf_consistency symcg sid 790 cg HANA_CG add dev 019 data 1 symcg sid 790 cg HANA_CG add dev 01A data 2 symcg sid 790 cg HANA_CG add dev 01B data 3 symcg sid 790 cg HANA_CG add dev 01C log 1 symcg sid 790 cg HANA_CG add dev 01D log 2 symcg sid 790 cg HANA_CG add dev 01E log 3 Ensure that a composite group similar to HANA_CG is created on the management server at the remote site. Type the following command to display the composite group details: symrdf cg HANA_CG query 22

23 5. Perform the initial synchronization of SRDF in adaptive copy disk mode: symrdf cg HANA_CG establish Type the following command to verify the status of the synchronization: symrdf cg HANA_CG query After the values for R2 Inv Tracks are close to zero, continue with the next step. 6. When the replication nears completion and a limited number of invalid tracks are outstanding between the source and the target, change the replication mode to SRDF/S or SRDF/A. For SRDF/S, set protection mode to synchronous: symrdf cg HANA_CG set mode sync For SRDF/A, set protection mode to asynchronous: symrdf cg HANA_CG set mode async Type the following command to verify the new status of the RDF pairs: symrdf cg HANA_CG query For SRDF/S, the RDF pair state is synchronized. For SRDF/A, the state is consistent. 7. Enable consistency for the group HANA_CG: symcg cg HANA_CG enable Type the following command to ensure the consistency of the RDF pairs: symrdf cg HANA_CG query Note: Prior to VMAX3, creating a Delta Set Extension (DSE) pool was required. A DSE pool contains save devices where delta set data is offloaded to protect SRDF/A sessions from a longer duration of unbalance. With VMAX3, you no longer have to create the DSE pool. The DSE is enabled by default and is configurable as a percentage of the total SRP. 23

24 Use case 2: Failing over the SAP HANA persistent devices to the remote site when the source site is unavailable (planned or unplanned outages) This use case explains the options to move or fail over the SAP HANA persistent devices to the remote site, as illustrated in Figure 5, by using SRDF/S or SRDF/A. If a disaster occurs, use this use case to enable the database persistence (R2 devices) for the standby SAP HANA installation at the remote site. Figure 5. Failover of SAP HANA persistent devices After the source site is repaired and is back online, establish replication from the destination to the source array, as shown in Figure 6, by swapping the personality of the R1 and R2 devices. This ensures that the production data is protected while SAP HANA is running at the remote site. 24

25 Figure 6. Enabling protection with production running on the remote site Process overview The following steps summarize the process for failing over to the remote site. See Detailed steps for command examples. 1. Create composite group HANA_CG_REMOTE and add devices on the remote management server. 2. Disable the RDF consistency mode for composite group HANA_CG. 3. Fail over composite group HANA_CG_REMOTE to write-enable the R2 devices. 4. If the failover to the remote site is scheduled and the source VMAX3 is available: a. Swap the personality of the composite group HANA_CG_REMOTE. b. Establish the composite group HANA_CG_REMOTE. c. Enable the RDF consistency mode for composite group HANA_CG_REMOTE. 25

26 Detailed steps The following steps include command examples. Note: EMC Solutions Enabler SRDF Family: CLI User Guide provides a full explanation of the command structure. 1. Create composite group HANA_CG_REMOTE and add the local SAP HANA devices to this group: symcg type RDF2 create HANA_CG_REMOTE rdf_consistency symcg sid 016 cg HANA_CG_REMOTE add dev 01A data1 symcg sid 016 cg HANA_CG_REMOTE add dev 01B data2 symcg sid 016 cg HANA_CG_REMOTE add dev 01E data3 symcg sid 016 cg HANA_CG_REMOTE add dev 019 log1 symcg sid 016 cg HANA_CG_REMOTE add dev 01C log2 symcg sid 016 cg HANA_CG_REMOTE add dev 01D log3 2. Disable the RDF consistency mode for composite group HANA_CG: symcg cg HANA_CG disable Type the following command to verify the RDF consistency of the group. symrdf cg HANA_CG query 3. Fail over composite group HANA_CG_REMOTE to write-enable the R2 devices: symrdf cg HANA_CG_REMOTE failover Note: If consistency is enabled on SRDF/A-capable devices within the group, then the force option must be applied for failover. The R2 devices in the composite group HANA_CG_REMOTE are now in a read/write enabled state. Type the following command to verify the status of the devices. symrdf cg HANA_CG_REMOTE query SAP HANA can now be restarted at the remote site. Ensure that the global.ini file of the standby SAP HANA servers contains the partition entries with the pointers to the UUIDs of the R2 devices. 4. If the failover to the remote site is scheduled and the source VMAX3 is available, or the source site is back online after a disaster, swap the personality of the devices. This changes the R2 devices to R1 devices and vice versa and ensures that production can run on the remote site during replication to the source site. Run the query command to verify the status of the device. When the values for RDF Pair STATE are Failed Over or Partitioned, the personality of the devices can be swapped and the RDF link re-established to continue storage replication. 26

27 a. Swap the personality of the composite group HANA_CG_REMOTE: symrdf cg HANA_CG_REMOTE swap The personality of the devices is changed from R2 to R1 and vice versa. Type the following command to verify the personality swap: symrdf cg HANA_CG_REMOTE query b. Establish the composite group HANA_CG_REMOTE: symrdf cg HANA_CG_REMOTE establish The RDF link is re-established. Type the following command to verify the status of the synchronization: symrdf cg HANA_CG_REMOTE query c. Enable the RDF consistency mode for composite group HANA_CG_REMOTE: symcg cg HANA_CG_REMOTE enable Type the following command to verify the status of the synchronization: symrdf cg HANA_CG_REMOTE query 27

28 Use case 3: Failing back the SAP HANA persistent devices to the source site This use case illustrates moving or failing back the SAP HANA persistent devices to the source site using SRDF/S or SRDF/A. Note: Be absolutely sure which data is needed. In this use case, the data at the remote site is restored to the source VMAX system. Process overview The following steps summarize the process for failing back to the source site. See Detailed steps for command examples. 1. If the source site was not available for a period of time, return the configuration to the source site for composite group HANA_CG: a. Set the RDF mode to adaptive copy disk to minimize the performance impact of a full restore. b. Restore data from the remote VMAX to the source site. c. Set data protection to synchronous or asynchronous. d. Re-enable consistency using composite group HANA _CG. 2. Swap the personality of the devices to return the configuration to the source site for composite group HANA_CG. Note: A scheduled failover will have minimal changes between the source and target site. a. Fail over composite group HANA_CG. b. Swap the personality of the composite group HANA_CG. c. Establish the composite group HANA_CG. d. Re-enable consistency using composite group HANA _CG. Detailed steps The following steps include command examples. Note: Perform these steps from the management server at the source site and using the composite group HANA_CG. Note: EMC Solutions Enabler SRDF Family: CLI User Guide provides a full explanation of the command structure. 1. To minimize impact when the source site is unavailable, return the composite group HANA_CG to the source site: Type the following command to verify the status of the device: symrdf cg HANA_CG query 28

29 If a new or recovered VMAX system is on the source site, the value for RDF Pair State is Split and you should perform a full data restore as follows: a. To reduce the impact of a full restore, set the RDF mode to adaptive copy disk mode: symrdf cg HANA_CG set mode acp_disk b. Restore data from the remote VMAX3 to the source site: symrdf cg HANA_CG restore -full The R1 devices in the composite group HANA_CG are now read/write enabled. Type the following command to verify the status of the synchronization: symrdf cg HANA_CG query When the values for R1 Inv Tracks are close to zero, continue with the next step. c. When the replication nears completion and a limited number of invalid tracks are outstanding between the source and the target, change the replication mode to SRDF/S or SRDF/A. For SRDF/S, set protection mode to synchronous: symrdf cg HANA_CG set mode sync For SRDF/A, set protection mode to asynchronous: symrdf cg HANA_CG set mode sync d. Re-enable consistency for the group HANA_CG: symcg cg HANA_CG enable 2. In a scheduled failover process, make a personality swap of the devices to return to the source site for HANA_CG: a. Type the following command to verify the status of the device: symrdf cg HANA_CG query When the replication is synchronized for RDF Pair STATE, fail over composite group HANA_CG: symrdf cg HANA_CG failover b. Swap the personality of the composite group HANA_CG: symrdf cg HANA_CG swap The personality of the devices is changed from R2 to R1 and vice versa. 29

30 c. Establish the composite group HANA_CG: symrdf cg HANA_CG establish d. Re-enable consistency for the group HANA_CG: symcg cg HANA_CG enable 30

31 Use case 4: Using consistency group technology for disaster protection of an SAP ERP system, SAP LT replication server, and the SAP HANA environment In this use case we extend use cases 1, 2, and 3 by adding other SAP application devices to the composite group to show the benefits of VMAX consistency group technology. In this use case, an SAP ERP system on Oracle DB is using SAP LT replication server to replicate data in real time to the SAP HANA environment. In a failover scenario, the consistency group technology ensures that you can restart the SAP ERP, the SAP LT replication server, and SAP HANA at the remote site to a consistent point in time. Thus, when the SAP LT replication jobs are manually restarted, replication from the SAP ERP system to SAP HANA can continue without tables having to be dropped and reloaded into SAP HANA to ensure data consistency between both systems. The R1 devices in the source VMAX3 are replicated to the R2 devices in the target VMAX3. While the replication is active, writing to the R2 devices is not possible. Figure 7 illustrates this use case. Figure 7. Establishing remote mirroring of multiple SAP applications Note: The dotted red circles in the figure represent a composite group containing SAP HANA persistence and the SAP application devices. Remote-site replication from the SAP ERP to SAP HANA via the SAP LT replication server occurs only when you fail over. 31

32 Process overview The following steps summarize the process for establishing remote mirroring from the source site to the target site. See Detailed steps for command examples. 1. Create the ERP device pairs text file. 2. Create device pairs and set the RDF mode. 3. Add devices to the composite group HANA_CG. 4. Add devices to the remote composite group HANA_CG_REMOTE. 5. Set the RDF mode to adaptive copy. 6. Perform synchronization of SRDF in adaptive copy disk mode. 7. After the SRDF target is synchronized with the source, change the replication mode to SRDF/S or SRDF/A. 8. Enable consistency for composite group HANA_CG. Detailed steps The following steps include command examples. Note: EMC Solutions Enabler SRDF Family: CLI User Guide provides a full explanation of the command structure. 1. On the management server, create a text file that lists the source and the target device pairs. Map the source SAP ERP SAPMNT LUN with the target SAP ERP SAPMNT LUN, the source SAP ERP USRSAP LUN with the target SAP ERP USRSAP LUN, and so on with the SAP LT replication server LUNS. #cat ERPPAIRS.txt D E F Create the device pairs in the HANA_RDF group and set the RDF mode to adaptive copy disk mode. The target devices must be write_disabled. symdev sid 016 dev 03D, 03E,03F, 046, 047, 048 write_disable symrdf createpair sid 790 file ERPPAIRS.txt rdfg 1 type R1 invalidate R2 rdf_mode acp_disk 3. Add the local SAP ERP and SAP LT devices to the existing composite group HANA_CG: symcg sid 790 cg HANA_CG add dev 025 ERP_SAPMNT symcg sid 790 cg HANA_CG add dev 026 ERP_USRSAP symcg sid 790 cg HANA_CG add dev 027 ERP_ORACLE symcg sid 790 cg HANA_CG add dev 028 SLT_SAPMNT 32