Copyright 2015 EMC Corporation. All rights reserved. Published in the USA.

Transcription

1 This solution guide describes the disaster recovery modular add-on to the Federation Enterprise Hybrid Cloud Foundation solution for SAP. It introduces the solution architecture and features that ensure disaster recovery of SAP services and operations in the cloud. October 2015

2 Copyright 2015 EMC Corporation. All rights reserved. Published in the USA. Published October 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. EMC2, EMC, VMAX, VNX, ViPR, RecoverPoint, and the EMC logo are registered trademarks or trademarks of EMC Corporation in the United States and other countries. All other trademarks used herein are the property of their respective owners. For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com. Federation Enterprise Hybrid Cloud 3.1 Data Protection for SAP: Disaster Recovery Solution Guide Part Number H

3 Contents Chapter 1 Executive Summary... 4 Document purpose... 5 Audience... 5 Essential reading... 5 Solution purpose... 5 The business challenge... 5 The technology solution... 6 Terminology... 6 Chapter 2 Solution Overview... 8 Overview... 9 Storage... 9 Orchestration... 9 Solution architecture... 9 Logical architecture... 9 DR operational cycle Software resources Chapter 3 Use Cases and Validation Overview Implementing DR for SAP applications Composing an SAP provisioning service on DR-enabled infrastructure Setting costs for DR-enabled storage Validation Use case 1: Failover after disaster Use case 2: Reprotection for Data Center B Use case 3: Planned migration Use case 4: Reprotection for Data Center A Use case 5: Test recovery Chapter 4 Conclusion Conclusion Appendix A References References EMC documentation Other product documentation

4 Chapter 1: Executive Summary This chapter presents the following topics: Document purpose... 5 Audience... 5 Essential reading... 5 Solution purpose... 5 The business challenge... 5 The technology solution... 6 Terminology

5 Chapter 1: Executive Summary This solution guide describes a disaster recovery (DR) add-on solution for the Federation Enterprise Hybrid Cloud for SAP. It is a companion to the Federation Enterprise Hybrid Cloud 3.1: Foundation for SAP Solution Guide. The guide: Introduces the technical components needed to implement and operate the solution Describes EMC s testing and validation of the solution s functionality Evaluates the technical and business value of the solution This guide is intended for executives, managers, SAP architects, cloud administrators, and technical administrators of IT environments who want to implement DR for a hybrid cloud infrastructure-as-a-service (IaaS) platform for managing SAP landscapes. Readers should be familiar with the VMware vrealize TM Suite of products, storage technologies, and general IT functions and requirements and how they fit into a hybrid cloud architecture. This guide provides critical reference information for planning and designing a data protection solution for the hybrid cloud. To understand the concepts, architecture, and functionalities of the Federation Enterprise Hybrid Cloud and how to operate SAP on top of it, you are advised to read the following documents: Federation Enterprise Hybrid Cloud 3.1: Foundation for SAP Solution Guide Federation Enterprise Hybrid Cloud 3.1: Foundation Infrastructure Reference Architecture Guide Federation Enterprise Hybrid Cloud 3.1: Concepts and Architecture Solution Guide Federation Enterprise Hybrid Cloud 3.1: Operations Solution Guide Federation Enterprise Hybrid Cloud 3.1: Security Management Solution Guide Organizations using SAP as a major part of their core business operations require a business continuity strategy to manage risks and prepare for recovery in the event of a disaster. The plan should include specific measures for: Safeguarding the continuity of business operations and protecting revenue Recovering systems to at least a minimum level of operation if an outage occurs A business continuity strategy has three components: backup, continuous availability (CA), and disaster recovery (DR). This solution focuses on the DR component, which aims to increase the availability of SAP landscapes and provide rapid recovery after a severe, isolated technical failure in one or more infrastructure or application components. Enterprises are increasingly transferring mission-critical SAP applications to cloud infrastructures to gain cost savings, simplified management, and data center efficiencies. 5

6 Chapter 1: Executive Summary DR is essential for mission-critical SAP applications. At the same time, a proper strategy typically requires a significant time and budget investment to meet a company s recovery time objectives (RTOs) and recovery point objectives (RPOs) during disasters. The challenges of designing DR-capable solutions include: Ensuring RTOs and RPOs for a variety of SAP applications in different organizations in a cloud environment Performing periodic recovery plan testing without incurring a huge cost or disruption to the business Minimizing the manual work and reconfiguration effort needed to prepare another site for DR Minimizing the human intervention needed to carry out DR for hundreds of systems Ensuring application consistency for a federated application landscape This solution addresses these challenges by offering automated rapid DR for SAP applications running on the Federation Enterprise Hybrid Cloud. The Federation Enterprise Hybrid Cloud integrates DR as a protection option for applications and virtual machines. You can easily consume the DR option by selecting it when deploying SAP applications from the vrealize Automation self-service catalog. The provisioning process automatically places these systems on storage that is protected remotely by EMC RecoverPoint. Through tight integration with the EMC ViPR Storage Replication Adapter, VMware vcenter Site Recovery Manager interacts with EMC RecoverPoint and orchestrates the whole DR process. The DR integration also automates the recovery of all virtual storage and virtual machines at a recovery or failover site. This DR solution for SAP provides: Increased resilience during disasters by automating failover and failback and by orchestrating the startup sequences for SAP applications Well-organized and highly coordinated recovery plans for a trouble-free failover The convenience of triggering the failover and failback from any surviving site with a few clicks of a button Minimized network overhead during replication Table 1 defines key terms relevant to this solution that are used in this guide. Table 1. Terminology Term ABAP SAP Central Service (ASCS) Additional application server (AAS) Definition An instance in a distributed SAP system that hosts the message server and enqueuer server. An SAP application server instance that is installed in a distributed SAP system. 6

7 Chapter 1: Executive Summary Term Application blueprint Logical template Primary application server (PAS) Recovery point objective (RPO) Recovery time objective (RTO) Definition Logical topology of an application for deployment in vrealize Automation Application Services. An application blueprint captures the structure of an application with logical nodes, their corresponding services, operating systems, dependencies, and default configurations, and network and storage topology requirements. The blueprint is published as a catalog item in the common service catalog. A predefined virtual machine definition in vrealize Automation and Application Services that can be mapped to a cloud template (and supporting services) in the cloud catalog, enabling an application blueprint to remain cloudagnostic. The first application server instance that is installed in a distributed SAP system. The maximum tolerable period in which data might be lost from an IT service. The maximum amount of time allowed to resolve an issue. 7

8 Chapter 2: Solution Overview This chapter presents the following topics: Overview... 9 Solution architecture... 9 Software resources

9 Chapter 2: Solution Overview This solution focuses on the implementation, management, and automation of DR for SAP applications in the Federation Enterprise Hybrid Cloud. It builds on the proven design and integration of EMC RecoverPoint and VMware vcenter Site Recovery Manager to offer the following benefits in a hybrid cloud environment: Continuous data protection for any point-in-time (PIT) recovery Centralized recovery plans Automated failover and failback Nondisruptive testing Planned migration Storage EMC VMAX or VNX storage systems provide the storage at two data centers: a primary data center (Site A) and a recovery data center (Site B). The storage is presented to RecoverPoint appliances (RPAs) at both sites. The RPAs replicate changes from the primary site to the recovery site in accordance with predefined RPOs and RTOs. The storage is kept synchronized between the two sites in an active/passive manner, with synchronization and visibility coordinated by recovery plans in Site Recovery Manager. Orchestration VMware vcenter Orchestrator TM is central to all the customizations and operations used in this solution. vcenter Orchestrator manages operations across several EMC and VMware products, including: EMC ViPR EMC RecoverPoint VMware vrealize Automation VMware vcenter VMware vcenter Site Recovery Manager VMware NSX for vsphere Logical architecture Figure 1 shows the logical architecture of the solution. 9

10 Chapter 2: Solution Overview Figure 1. Logical architecture of the DR for SAP solution The DR topology for the Federation Enterprise Hybrid Cloud solution provides protection and restart capability for workloads deployed in the cloud. Virtual machines for management and workload are placed on storage protected by RecoverPoint and are managed from Site Recovery Manager. Core Pod The Core Pod hosts a core set of resources that must exist before the remainder of the cloud can be deployed. These core resources include vcenter Server, Microsoft SQL Server 2012, and either the vcloud Networking and Security or VMware NSX for vsphere. The hardware hosting this pod does not have to be managed by cloud components, but the virtual machines that it hosts are a critical foundation of the cloud. The Core Pod is not protected by RecoverPoint or Site Recovery Manager because the virtual machines such as DNS, VMware vcenter, and Site Recovery Manager servers are replicated and synchronized with their own replication technology. NEI Pod The NEI Pod hosts the NSX Edge appliances and NSX Controllers or the vcloud Networking and Security components and becomes the convergence point at which the physical and 10

11 Chapter 2: Solution Overview virtual networks connect. The NEI Pod is not protected by RecoverPoint or Site Recovery Manager. The objects in the NEI Pod are created manually to mirror functionality such as NSX distributed logical switches and routers, NSX dynamic routing, NSX security groups, and NSX security policies (firewall rules) between the two sites. Automation Pod The Automation Pod hosts the virtual machines that automate and manage the cloud infrastructure that supports the workloads consumed by the cloud tenants. The Automation Pod supports the components responsible for functions such as the user portal and automated provisioning, monitoring, metering, and reporting. Workload Pods The Workload Pods are configured and assigned as shared resources in vrealize Automation, to host SAP virtual machines deployed by the different business groups in the hybrid cloud environment. These Workload Pods are deployed as VMware vsphere clusters in VMware vcenter endpoints. ViPR and RecoverPoint Site Recovery Manager integrates with RecoverPoint storage replication and ViPR automated storage services via EMC Storage Replication Adapters (SRAs). The SRAs control the RecoverPoint replication process. DR operational cycle All protected systems undergo a series of six states from failover to failback. Figure 2 shows transitions from one state to another: S1 through S6 represent the protection states at the data centers (DCs). 11

12 Chapter 2: Solution Overview Figure 2. DR operational state transitions Table 2 describes the protection states during the failover and failback processes. Table 2. State S1 S2 S3 Failover and failback transition states Description This solution supports bi-directional replication. Some SAP applications are provisioned on Data Center A, while other virtual machines or SAP applications are provisioned on Data Center B. Both data centers are protected by RPA storage replication. A disaster causes Data Center A to fail. The entire infrastructure becomes unavailable, including the ESXi servers, network, storage, and RPA. All SAP applications on Data Center A become unavailable. Virtual machines on Data Center B remain available. The cloud administrator triggers a DR in Site Recovery Manager at Data Center B. All failed SAP applications become active on Data Center B. Service is restored at Data Center B while Data Center A is being returned to an operational state. Remote protection is no longer possible until the IT department restores the original data center (Data Center A). 12

13 Chapter 2: Solution Overview State S4 S5 S6 Back to S1 Description Data Center A recovers and becomes functional. The Site Recovery Manager server and vcenter server in Data Center A are back online and resynchronized with Data Center B. Storage replication has not yet started. The effort required to rebuild and configure Data Center A depends on the impact on the site. In the worst case, where all hardware devices are irrecoverably damaged, a complete DC rebuild is necessary. The cloud administrator triggers a reprotect operation in Site Recovery Manager to replicate storage data from Data Center B to Data Center A. After reprotection, RPA protects both SAP applications and other virtual machines on Data Center B. No workloads run on Data Center A at this stage. A downtime maintenance operation is scheduled. The cloud administrator triggers a planned migration for SAP applications. After the planned migration, SAP applications run on Data Center A but have yet to re-establish replication as a final post-procedure. Finally, reprotection is triggered again to restore the replication from Data Center A to Data Center B. When this operation is complete, Data Center A becomes protected once again and the environment is now considered to be fully restored to its normal state. 13

14 Chapter 2: Solution Overview Table 3 lists the main elements of the six states during the failover and failback processes. Table 3. Major elements of the failover and failback processes State Activity Role of Data Center A Role of Data Center B Replication Workloads run on S1 Normal activity Production Recovery Recovery Production A -> B B -> A Data Center A Data Center B S2 S3 S4 A full data center outage occurs after a disaster. Workloads fail over to Data Center B. IT rebuilds Data Center A. Outage Production None Data Center B Outage Production None Data Center B Standby Production None Data Center B S5 Reprotection Recovery Production B -> A Data Center B S6 Migrate workload back to Data Center A. Production Recovery Production B -> A Data Center A Data Center B S1 Reprotection Production Recovery Recovery Production A -> B B -> A Data Center A Data Center B Table 4 lists the software resources that are used in the solution. Table 4. Solution software resources Software Version Purpose Federation Enterprise Hybrid Cloud, Foundation module EMC Federation Enterprise Hybrid Cloud Disaster Recovery Module VMware vrealize Automation Application Services Customization package for storage as a service (STaaS) and foundation workflows Customization package for DR-as-a-service (DRaaS) workflows Application provisioning SAP provisioning module Customization package for provisioning SAP systems, including SAP autostart. For a complete, up-to-date list of the software requirements for the Federation Enterprise Hybrid Cloud, go to the E-Lab Navigator home page. 14

15 Chapter 3: Use Cases and Validation This chapter presents the following topics: Overview Implementing DR for SAP applications Validation

16 Chapter 3: Use Cases and Validation This chapter describes use cases that show how to provision an SAP system on a DRenabled infrastructure, including: Composing an SAP provisioning service on DR-enabled infrastructure Setting costs for DR-enabled storage The chapter also describes how to protect SAP applications from different failure scenarios and shows the flexibility of planned nondisruptive host maintenance. The following scenarios are described and validated: Failover after disaster Reprotection for Data Center B Planned migration Reprotection for Data Center A Test recovery Before creating SAP provisioning services on a DR-enabled infrastructure, refer to the Federation Enterprise Hybrid Cloud 3.1: Operations Solution Guide for instructions for configuring DR services in the vrealize Automation portal. The high-level steps you must perform are the following: 1. Provision DR-enabled storage on both data centers and assign the DR-enabled storage to business group reservations. 2. Create blueprints for SAP production (PRD), development (DEV), and quality assurance (QA) systems by copying from an existing SAP blueprint. Enable a virtual machine restart priority for recovery. 3. Set a storage reservation policy that uses the DR-enabled storage. Composing an SAP provisioning service on DRenabled infrastructure A DR environment presents new considerations for auto provisioning SAP systems. After configuring a reservation and blueprint in the vrealize Automation Center portal, you must compose the SAP provisioning service on vrealize Automation Application Services to deploy an SAP application on the DR-enabled infrastructure. Configurations in this section are changes and enhancements to the existing components that were created in accordance with the specifications in the Federation Enterprise Hybrid Cloud 3.1: Foundation for SAP Solution. To enable an SAP provisioning service on the DR-enabled infrastructure: 1. Log in to the vrealize Automation Application Services portal as a service architect. 2. Select Cloud Providers, and then select the cloud provider for the HR business group. Add the blueprints from vrealize Automation that use DRenabled infrastructure to this group, as shown in Figure 3. 16

17 Chapter 3: Use Cases and Validation Figure 3. Adding a cloud template from vrealize Automation blueprints 3. Select Logical Templates, and then select the SLES11 SP3 for SAP Application logical template. Add the cloud template mappings you created in step 2, as shown in Figure 4. Figure 4. Adding cloud template mappings in the Logical Templates screen 17

18 Chapter 3: Use Cases and Validation 4. Select Applications and then select an appropriate version of the SAP Distributed Installation applications to edit. In our testing, we selected SAP ERP Distributed Installation and clicked version Create new deployment profiles that will use the DR-enabled infrastructure. As Figure 5 shows, we created a new deployment profile named ERP 6.07 PRD with RPO 10min under the HR business group. Figure 5. Creating new deployment profiles to use the DR-enabled infrastructure 5. From the Deployment Profile Creation Wizard, link each node to the DRenabled cloud template you created in step 3. For storage, select the DRenabled storage reservation policy that the cloud storage provisioning service creates automatically in the vrealize Automation portal. As Figure 6 shows, we mapped the SLES 11 SP3 for SAP DR-Enabled cloud template to the ASCS, DB, and PAS instances. We also selected the S1D_S1D- SAP-Plat-PRD DR-Enabled storage reservation policy for additional hard disks in each node. 18

19 Chapter 3: Use Cases and Validation Figure 6. Mapping cloud templates enabled for DR 6. Finish the wizard by assigning appropriate values for vcpus, memory, and disk size for each node. 7. Publish the deployment profile to the vrealize Automation portal. 8. Repeat steps 4 to 7 to create additional deployment profiles as necessary. For example, you may need to provision SAP systems with different RPO requirements. 9. Repeat steps 4 to 8 to configure SAP Standard Installation and SAP AAS Installation. 10. Log in to the vrealize Automation portal as a tenant administrator. Assign the published SAP provisioning applications to an appropriate service and assign the required entitlements in the vrealize Automation portal. From now on, the new SAP items are available in the service catalog, and the SAP system with DR option requested by an end user is provisioned on the DR-enabled infrastructure. Setting costs for DR-enabled storage This solution uses VMware vrealize Business, with its integration with vcenter and vrealize Automation, to provide chargeback information on the storage provisioned to, and consumed in, the hybrid cloud. The ViPR storage provider running in vcenter automatically captures the underlying capabilities of storage provisioned by ViPR. The storage administrator creates storage profiles based on the storage capabilities of the ViPR storage, which is configured to provide multiple storage service offerings. This integration enables vrealize Business to automatically discover and group datastores based on predefined service levels of storage. In this solution, we created separate virtual machine storage profiles for each of the storage capabilities that were automatically captured by the ViPR storage provider, as Figure 7 shows. 19

20 Chapter 3: Use Cases and Validation Figure 7. Creating a virtual machine storage profile After the ViPR storage provider has automatically configured the datastores with the appropriate storage capability, these datastores can be grouped and managed in vrealize Business according to their storage profile. As Figure 8 shows, the cost profiles created in vcenter are discovered by vrealize Business. Figure 8. Setting the cost for DR-enabled storage The business management administrator can group tiered datastores provisioned with ViPR and set the monthly cost per GB as needed to differentiate the cost of various storage service levels. For example, to differentiate DR-enabled storages, we set the monthly cost per GB of S1-DR-Silver DR-enabled storage to $0.4 to reflect the additional cost of RecoverPoint and other hardware required to build the solution. 20

21 Chapter 3: Use Cases and Validation In designing the use cases described in this section, our key business objectives were: Operations: 24 hours a day, 7 days a week RTO: 1 hour RPO: As required for the relevant SAP system. Refer to Table 6 for details. In the test environment, we 1 configured six ESXi hosts for a tenant workload pod, three on each DC. Table 5 shows the host details. Table 5. DC A B List of ESXi hosts ESXi hostnames S1vdccomp55, s1vdccomp56, s1vdccomp57 s2vdccomp55, s2vdccomp56, s2vdccomp57 The two data centers were configured in accordance with the solution architecture shown in Figure 1. We provisioned three 750GB DR-enabled storages with different RPOs for the HR business group on Data Center A. We then deployed three distributed SAP ERP 6.07 systems on those DR-enabled storages to build a typical three-system landscape with production (PRD), development (DEV), and quality assurance (QAS). Table 6 lists the RPO requirements for the provisioned SAP systems: Table 6. RPO requirements for SAP systems SAP system RPO (in minutes) PRD 10 DEV 10 QAS 30 The RPO is defined in the ViPR virtual pool. Figure 9 shows the RPO setting for the virtual pool in which we provisioned a datastore for the SAP PRD system. Figure 9. RPO setting in the ViPR virtual pool 1 In this guide, we refers to the EMC engineering team that tested and validated the solution. 21

22 Chapter 3: Use Cases and Validation When provisioning SAP systems from the vrealize Automation self-service portal, you can specify the SRM Power On Priority for SAP instances so that ASCS is started first, followed by DB, and finally PAS and AAS. Figure 10 shows the start priority for SAP instances. Figure 10. Start priority for SAP instances The workload generator T-code SGEN is used on all SAP systems to simulate workloads. To measure RPO, we developed a customized program to generate one database record per second on all SAP systems. Note: Benchmark results are highly dependent upon workload, specific application requirements, and system design and implementation. Relative system performance will vary as a result of these and other factors. Therefore, this workload should not be used as a substitute for a specific customer application benchmark when critical capacity planning and/or product evaluation decisions are contemplated. All performance data contained in this report was obtained in a rigorously controlled environment. Results obtained in other operating environments may vary significantly. EMC Corporation does not warrant or represent that a user can or will achieve similar performance expressed in transactions per minute. Use case 1: Failover after disaster Test scenario A disaster occurred and resulted in a site outage at Data Center A. This outage could not be recovered within the RTO in Data Center A. A failover to Data Center B was therefore performed to bring services back online. To simulate this hardware failure scenario, we powered off all the ESXi hosts and RPAs in Data Center A. Objectives Procedure All the SAP systems must be restored and back in service within the RTO and RPO. Virtual machines such as DB, ASCS, PAS, and AAS within a SAP system must be started automatically after failover. No errors should appear in the SAP systems. 1. Run the workload generator (SGEN) on all SAP systems for at least 30 minutes. 2. Run the customized program to generate one record per second on all SAP systems. 3. Power off all ESXi servers of workload pods and RPAs in Data Center A. 22

23 Chapter 3: Use Cases and Validation 4. Log in to the vsphere web client in Data Center B and run the recovery operation. Make a note of the failover procedure and timestamp. 5. After the failover, log in to the SAP systems and check the table to determine data loss. Note the data loss time period. 6. Log in to all SAP systems using SAPGUI and check the transactions for errors, including SICK, SM51, SM50, SM21, ST22, and DB Log in to the PAS of all SAP systems and check the log file /usr/sap/<sid>/dvebmgs00/work/available.log to determine the duration of SAP service unavailability. Results and analysis We started the recovery plan from the VMware SRM console, as shown in Figure 11. Data Center A is unavailable so we chose Disaster Recovery in the Recovery Type option. Figure 11. Executing the recovery plan Figure 12 shows details of an SAP DEV PAS instance, demonstrating that the instance is running on the compute resource of Data Center B after the recovery operation. 23

24 Chapter 3: Use Cases and Validation Figure 12. SAP instance running on Data Center B Table 7 shows the observed behaviors of the system when the ESXi hosts failed, along with the reference metrics in minutes. Table 7. Failover test results: Use case 1 Test item Success criterion Results PRD RTO (minutes) <= DEV RTO (minutes) <= QAS RTO (minutes) <= PRD RPO (minutes) <= 10 2 DEV RPO (minutes) <= 10 2 QAS RPO (minutes) <= Autostart of SAP instances SAP instances are started in the correct order. Autostart scripts are executed along with the OS boot. SAP systems are started automatically. Success Errors in the SAP systems Final evaluation 0 0 PASSED The simulated disaster was triggered at 11:25:00. Figure 13 shows the actual recovery time and data loss of the SAP PRD system. 24

25 Chapter 3: Use Cases and Validation Figure 13. Actual SAP service recovery time and data loss This use case shows that with EMC RecoverPoint and VMware SRM, SAP applications that are protected by the DR solution are successfully failed over to the remote data center within the designated RPO and RTO. VMware SRM orchestrates the entire failover process without the need for manual intervention. Use case 2: Reprotection for Data Center B Test scenario After Data Center A is rebuilt, the customer plans to reprotect SAP systems that are running on Data Center B. The replication direction is reversed. Objectives Procedure The SAP systems must reverse the replication direction. No service interruption of SAP systems should occur. 1. Run the workload generator (SGEN) on all SAP systems. 2. Run the customized program to generate one record per second on all SAP systems. 3. Log in to the vsphere web client in Data Center B and run the reprotect operation. If errors occurred, fix the errors and rerun reprotect. 4. During the reprotection process, check continuously to see if the SAP GUI stays connected. 5. After reprotection, log in to the PAS of all SAP systems and check the log file /usr/sap/<sid>/dvebmgs00/work/available.log to find out whether an SAP service interruption occurred. Results and analysis Table 8 shows the observed behaviors of the system during reprotection, along with the reference metrics in minutes. Table 8. Reprotection test results Test item Success criterion Results Duration of reprotection (minutes) Direction of replication must be reversed completely. Successful (252 minutes) SAP service interruption 0 0 Final evaluation PASSED 25

26 Chapter 3: Use Cases and Validation A full initial replication is triggered on RPA. The total duration of reprotection depends on the total capacity of the volumes in the consistency groups and the WAN bandwidth between two DCs. Use case 3: Planned migration Test scenario After Data Center B is reprotected, the customer plans to migrate SAP applications from Data Center B back to Data Center A to balance resource usage. A planned downtime is required. Objectives Procedure All the SAP systems must be migrated and back in service within the RTO. The RPO must be zero. Virtual machines within an SAP system, such as DB, ASCS, PAS, and AAS, must be started automatically after failover. No errors should appear in the SAP systems. 1. Note the latest entries in the database table for all SAP systems, and then shut down all SAP systems. 2. Log in to the vsphere web client in Data Center A and run the planned migration operation. Note the migration procedure and timestamp. 3. After the planned migration, log in to the SAP system using the SAP GUI and check the transactions for any errors, including SICK, SM51, SM50, SM21, ST22, and DB Check the latest entries for all SAP systems in the database table to determine data loss. 5. Log in to the PAS of all SAP systems and check the log file /usr/sap/<sid>/dvebmgs00/work/available.log to determine the duration of SAP service unavailability. Results and analysis We started the recovery plan from the VMware SRM console. In the Recovery Type option, we chose Planned migration so that VMware SRM would gracefully shut down SAP systems before migration. Table 9 shows the observed behaviors of the system during planned migration, along with reference metrics in minutes. Table 9. Planned migration test results Test item Success criterion Results PRD RTO (minutes) <= DEV RTO (minutes) <= QAS RTO (minutes) <= PRD RPO (minutes) 0 0 DEV RPO (minutes) 0 0 QAS RPO (minutes)

27 Chapter 3: Use Cases and Validation Test item Success criterion Results Auto start of SAP instances SAP instances are started in the correct order. Success Autostart scripts are executed along with the operating system boot. SAP systems are started automatically. Errors in the SAP systems Final evaluation 0 0 PASSED Figure 14 shows the database record of three SAP systems before and after planned migration, indicating no data loss. Figure 14. Actual recovery time and data loss This use case shows that with RecoverPoint and SRM, SAP applications that are protected by the DR solution are successfully migrated to the remote data center within the designated RTO and with no data loss. Use case 4: Reprotection for Data Center A Test scenario After Data Center A is rebuilt, the customer plans to reprotect SAP systems that are running on Data Center B. The replication direction is reversed. 27

28 Chapter 3: Use Cases and Validation Objectives and procedure The test objectives and procedure are the same as in Use case 2: Reprotection for Data Center B. Results and analysis Table 10 shows the observed behaviors of the system during reprotection, along with reference metrics in minutes. Table 10. Reprotection test results for Data Center A Test item Success criterion Results Duration of reprotection (minutes) Direction of replication must be reversed completely Successful (4 minutes) SAP Service interruption 0 0 Final evaluation PASSED Use case 5: Test recovery Test scenario To ensure a successful failover after a real disaster, the customer must validate the recovery plan without interrupting the running SAP systems. Objectives Procedure The recovery plan is executed successfully in test mode. The SAP virtual machines are powered on at the remote data center with the network isolated. The running SAP systems are not affected. 1. Log in to the vsphere web client in Data Center A and run the recovery plan in test mode. Note the test recovery procedure and timestamp. 2. Check whether the SAP virtual machines are powered on at the remote data center. 3. Check whether the network of SAP virtual machines is isolated. Results and analysis We started the recovery plan in test mode from the VMware SRM console. After successful execution of the recovery plan, the replicated datastores were mounted on the ESXi hosts at the remote DC and the SAP virtual machines were powered on. During the test, the running SAP systems at the production data center were not affected. Figure 15 shows that the networks of SAP virtual machines in test recovery are isolated. 28

29 Chapter 3: Use Cases and Validation Figure 15. Isolated network of SAP virtual machines in test recovery This use case demonstrates that with the test recovery, customers can perform periodic validation of a recovery plan without incurring a huge cost or disruption to the business. 29

30 Chapter 4: Conclusion This chapter presents the following topics: Conclusion

31 Chapter 4: Conclusion This solution offers effective, efficient, and affordable DR protection for critical business functions. This strategy significantly improves business agility and scales out for SAP production systems with varying needs. The Federation Enterprise Hybrid Cloud for SAP integrates the best of EMC and VMware products and enables customers to protect SAP system landscapes from disasters such as the outage of an entire Data Center. With the integration of ViPR, vcenter Orchestrator, and vrealize Automation, cloud administrators can request DR-enabled storage through the vrealize Automation self-service portal and end users can provision SAP systems on DRenabled infrastructures with just a few clicks. With the integration of RecoverPoint and vcenter Site Recovery Manager, the DR processes are automated and orchestrated in their entirety with just a few clicks. The solution provides the following protection benefits for SAP systems: Business continuity for mission-critical SAP applications in a cloud environment. Cloud tenants have the option to easily deploy their most critical SAP systems on the DR infrastructures described in this solution. The DR costs are captured in the chargeback report. The failover and failback processes do not require additional intervention from the tenants. Rapid and automated DR in a cloud environment. The DR administrator can easily complete the entire DR process with a few clicks. This is critical to ensuring RTO in a large-scale cloud environment. 31

32 Appendix A: References This appendix presents the following topics: References

33 Appendix A: References EMC documentation The following documents are available on EMC.com or EMC Online Support. Access to online support depends on your login credentials. If you do not have access to a document, contact your Federation representative. Federation Enterprise Hybrid Cloud 3.1: Foundation Infrastructure Reference Architecture Guide Federation Enterprise Hybrid Cloud 3.1: Concepts and Architecture Solution Guide Federation Enterprise Hybrid Cloud 3.1: Operations Solution Guide Federation Enterprise Hybrid Cloud 3.1: Security Management Solution Guide Federation Enterprise Hybrid Cloud 3.1: Foundation for SAP Solution Guide EMC Cloud-Enabled Infrastructure for SAP: HA and Application Mobility Bundle RecoverPoint 4.1 Administrator's Guide Other product documentation The following document is available from Site Recovery Manager Administration: vcenter Site Recovery Manager