emc xtremio advanced data service for sap business suite white

White Paper

EMC Solutions

Abstract

This white paper describes how SAP Business Suite on EMC® XtremIO™ can integrate into an existing data center infrastructure and provide data protection, high availability, operational recovery, and simplified system refreshes for SAP landscapes.

November 2015

EMC XTREMIO ADVANCED DATA SERVICE FOR SAP BUSINESS SUITE

• Reliable local and remote data protection • Simplified refresh of SAP test landscape from production

EMC XtremIO Advanced Data Service for SAP Business Suite White Paper

2

Copyright © 2015 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 H14589

http://www.emc.com/legal/emc-corporation-trademarks.htm

http://www.emc.com/legal/emc-corporation-trademarks.htm

3 EMC XtremIO Advanced Data Service for SAP Business Suite White Paper

Table of contents

Executive summary ............................................................................................................................. 5 Business case .................................................................................................................................. 5 Solution overview ............................................................................................................................ 6 Key results/ recommendations ........................................................................................................ 6 Purpose ........................................................................................................................................... 7 Scope .............................................................................................................................................. 7 Audience.......................................................................................................................................... 7

Technology overview .......................................................................................................................... 7 Overview .......................................................................................................................................... 7 EMC XtremIO .................................................................................................................................... 7

XtremIO™ virtual copy (XVC) ......................................................................................................... 8 Snapshot scheduler .................................................................................................................... 8

EMC RecoverPoint ............................................................................................................................ 8 Snapshot-based replication ........................................................................................................ 9

VMware vCenter Site Recovery Manager ........................................................................................... 9 SAP Business Suite .......................................................................................................................... 9 SAP Power Benchmark ..................................................................................................................... 9

Solution architecture ........................................................................................................................ 10 Overview ........................................................................................................................................ 10 Architecture diagram ...................................................................................................................... 11 Hardware resources ....................................................................................................................... 13 Software resources ........................................................................................................................ 13

Testing and validation ...................................................................................................................... 14 Protecting an SAP system locally .................................................................................................... 14

Test scenario ............................................................................................................................. 14 Test objectives .......................................................................................................................... 15 Test procedure .......................................................................................................................... 15 Test result ................................................................................................................................. 18

Protecting an SAP system remotely ................................................................................................ 19 Test scenarios ........................................................................................................................... 19 Failover after disaster ................................................................................................................ 21 Failback after Site A is rebuilt .................................................................................................... 23

Refreshing an SAP test landscape from production ........................................................................ 27 Test scenario ............................................................................................................................. 27 Test objective ............................................................................................................................ 27 Test procedure .......................................................................................................................... 27 Test results ................................................................................................................................ 33


4

Conclusion ....................................................................................................................................... 34 Summary ....................................................................................................................................... 34 Findings ......................................................................................................................................... 34

References ....................................................................................................................................... 35 EMC documents ............................................................................................................................. 35 VMware documents ....................................................................................................................... 35 SAP documents .............................................................................................................................. 35 Oracle documents .......................................................................................................................... 35

Appendix A ....................................................................................................................................... 36 Post SQL command to add authorizations ...................................................................................... 36


Executive summary

While ensuring business continuity for mission-critical SAP systems is critical for IT organizations, it is increasingly important for IT to become more agile to enable business innovation. Key challenges include:

• Ensuring application-consistent recovery from disruption and data corruption:

This includes immediate recovery for SAP systems, both local and over distances. Consistent recovery is critical for supporting financial transactions, including sales, order fulfillment, and customer service. Key challenges for a business-based point-in-time recovery include the ability to automate and test disaster recovery (DR) operations and operational recovery from data corruption. SAP also requires the interdependencies of databases and multiple applications across storage systems and data centers.

• Reducing the cost and increasing the availability of SAP backups:

Multi-terabyte SAP databases force many companies to clone to costly tier 1 storage to expedite backups. These clones often require coordinating incremental restore operations because of the lack of full backups.

Tape stored offsite takes time to locate and return onsite.

SAP non-production environments consume three or four times more storage than production environments and must still be protected.

SAP administrators and database administrators require visibility and management control for backups.

All of these challenges demand innovative thinking at a time when IT staffs are asked to do more with less. The amount of data is growing and many SAP databases increasingly store tens of terabytes of data, which is often duplicated in test systems and for production backups. Despite these growing demands on businesses, IT budgets and staff numbers are stagnant. Businesses are often frustrated when the majority of their IT budgets are spent just maintaining the status quo and managing the existing infrastructure, and not investing strategically in business priorities. According to a recent Forrester Research study, 72 percent of IT budgets go to routine IT maintenance and management, in contrast to just 28 percent invested in business innovation.

EMC addresses these challenges with the EMC® XtremIO™ all-flash array to simplify SAP system landscapes, while reducing the total cost of ownership and providing data protection and recovery for planned and unplanned disruptions.

Business case


6

The solution described in this paper demonstrates how SAP on XtremIO can integrate into existing data center workflows on a platform that is supercharged by flash performance, and provides reliability, resiliency, high availability, and rich data services.

This solution validates XtremIO when deployed in a storage environment for mission-critical SAP systems and mixed workloads, including:

• SAP Business Suite on SAP NetWeaver

• SAP production and non-production systems

The validated use cases include those most critical for SAP environments, including:

• SAP administrators running backup and restore operations for SAP production and non-production systems

• SAP system refresh operations for non-production systems, such as testing, development, and training

• Operational recovery from data corruption or human error

• High availability, locally or within a metro or synchronous distance

The use cases demonstrate the integration of an XtremIO all-flash storage array with EMC RecoverPoint®, and EMC Data Domain® that runs on VMware to deliver the advanced data services required to meet mission critical SAP service level agreements (SLAs).

This solution shows that XtremIO and RecoverPoint deliver:

• Simplified provisioning and SAP refreshes

• Immediate operation recovery with a 15-second recovery point objective (RPO) using native protection tools

• Consistent point-in-time backup and restore of a full SAP landscape

• DR protection in a remote data center with heterogeneous storage

• Easy and simplified SAP test landscape refresh from a production copy

Consider the other value of deploying XtremIO all-flash storage for SAP:

• Dramatic data reduction that helps to shrink storage capacity size and costs

• Maximization of effective capacity, providing linearly scalable sub-millisecond I/O operations per second capacity

• Consistent performance to meet SLAs with reliably consistent sub-millisecond response times for enterprise-class SAP landscape applications with mixed online transaction processing (OLTP) and online analytical processing (OLAP) workload together in one array

• Rapid development and testing for SAP environments, within an agile multi-workload, all-flash SAP infrastructure

• Elimination of traditional storage challenges associated with overprovisioning, tuning, performance, and scalability

Solution overview

Key results/ recommendations


• Faster application rollouts so that development and test teams can quickly deploy as many copies of SAP landscapes as needed to meet business requirements, with agile and writeable snapshots that have no impact on cost or SAP performance

This white paper describes a full data protection solution for the SAP Business Suite, with steps to deploy SAP systems in local and remote data centers with XtremIO and EMC VNX® storage, and with steps to provision and refresh a test landscape.

The scope of this white paper is to:

• Introduce the key enabling technologies

• Describe the solution architecture and design

• Describe and validate the key components and processes

• Identify the key business benefits of the solution

This white paper is for SAP BASIS administrators, VMware administrators, storage administrators, IT architects, and technical managers responsible for designing, creating, and managing SAP deployment, infrastructure, and data centers.

Technology overview

The key technology components in this solution are:

• EMC XtremIO all-flash storage

• EMC RecoverPoint

• VMware vCenter Site Recovery Manager

• SAP Business Suite

• SAP Power benchmark

The XtremIO storage array is an all-flash system, based on a scale-out architecture. The system uses EMC X-Brick® building blocks, which can be clustered together to linearly scale capacity and performance.

The XtremIO Management Server (XMS), which is a stand-alone dedicated Linux-based server, controls system operation. Each XtremIO cluster requires its own XMS host, which can be either a physical or a virtual server. The array continues operating if it is disconnected from XMS, but cannot be configured or monitored.

The XtremIO array architecture is specifically designed to deliver the full performance potential of flash, while linearly scaling all resources such as CPU, RAM, SSDs, and host ports in a balanced manner. This allows the array to achieve any desired performance level, while maintaining consistency of performance that is critical to predictable application behavior.

Purpose

Scope

Audience

Overview

EMC XtremIO


8

The XtremIO storage array provides a high level of performance that is consistent over time, system conditions, and access patterns. It is designed for high detail and true random I/O.

The cluster's performance level is not affected by its capacity utilization level, number of volumes, or aging effects. Moreover, performance is not based on a “shared cache” architecture and is not affected by the dataset size or data access pattern.

Due to its content-aware storage architecture, XtremIO provides:

• Even distribution of data blocks, inherently leading to maximum performance and minimal flash wear

• Even distribution of metadata

• No data or metadata hotspots

• Easy setup and no tuning

• Advanced storage functionality, including inline data deduplication and compression, thin provisioning, advanced data protection (XDP), snapshots, and more

XtremIO™ virtual copy (XVC)

XVC is a new branding for XtremIO snapshot technology. XVC abstracts the copy operations as an in-memory metadata operation with no impact on any back-end resources. XVC provides instant, high performance copies of any data set of any application, in nearly any quantity desired. XVC is space-efficient, with data services such as inline deduplication and compression, and with no impact on production or other copies. XtremIO Integrated Copy Data Management (iCDM) integrates with key applications by providing copies that are immediately useable by the application. This enables fast deployment and ensures that the deployed copies are fully functional.

Snapshot scheduler

You can use the scheduler for local protection use cases. Apply it to a volume, a consistency group, or a snapshot set. You can define each scheduler to run at an interval of seconds, minutes, or hours. Alternatively, you can set it to run at a specific time of a day or a week. Each scheduler has a retention policy, based on the number of copies that you want to hold or based on the age of the oldest snapshot.

RecoverPoint provides a comprehensive data protection solution for enterprise and commercial customers, with integrated continuous data protection and continuous remote replication to recover applications to any point in time.

EMC RecoverPoint


RecoverPoint 4.1 provides the following benefits:

• MetroPoint topology:

Helps organizations to achieve a new level of continuous availability with protection of three sites for DR support

Provides additional data protection for each of the VPLEX Metro sites with continuous local replication using RecoverPoint

Achieves zero RPO using VPLEX Metro with RecoverPoint any-point-in-time recovery

• Snapshots and replication provide replication control flexibility with enhanced performance for asynchronous replication under high loads, resulting in better bandwidth usage

• WAN optimization ensures replication robustness with improved resiliency when the WAN is unstable and communication quality is poor—this optimization can tolerate a maximum 2.5 X round-trip-time (RTT) delay

Snapshot-based replication

Snapshot-based replication (SBR) is a new asynchronous replication mode used in RecoverPoint version 4.1. It uses array-based snapshots and transfers the difference between these to the target. With XtremIO at the production site, there is no write splitter, and when XtremIO is at the target failover or recovery site, RecoverPoint distributes XtremIO snapshots.

VMware vCenter Site Recovery Manager is the industry leading solution to enable application availability and mobility across sites in private cloud environments. Site Recovery Manager integrates with an underlying replication technology to provide policy-based management, non-disruptive testing, and automated orchestration of recovery plans. This provides simple and reliable recovery and mobility of virtual machines between sites with minimal or no downtime.

SAP Business Suite is a bundle of business applications that provide integration of information and processes, collaboration, industry-specific functionality, and scalability. SAP Business Suite is based on the SAP NetWeaver technology platform. We used SAP ERP 6.0 in the featured test environment as an example.

For this solution, we used SAP Power Benchmark to generate a massive SAP workload on the installed SAP ERP 6.0 EHP5 system, which was built for the test scenarios. The SAP-specific workload used in the test and validation scenarios demonstrates SAP business data consistency or data loss across data centers in various scenarios.

VMware vCenter Site Recovery Manager

SAP Business Suite

SAP Power Benchmark


10

The SAP Power Benchmark toolkit performed predefined standard sales and distribution transactions against the SAP system. The toolkit includes a sell-from-stock business scenario that consists of the following transactions:

• (VA01) Create a sales order with five line items

• (VL01N) Create a delivery for the order

• (VA03) Display the customer order

• (VL02N) Change the delivery and post a goods issue

• (VA05) List 40 orders for sold-to party

• (VF01) Create an invoice for the order

Solution architecture

EMC provides full data protection of the SAP application landscape with XtremIO, RecoverPoint, VNX, and Data Domain. Table 1 shows the different data protection levels based on the business needs and infrastructure.

In this solution, we validated the scenarios in Table 1 to do the following:

• Show how the XVC enables local protection.

• Show how RecoverPoint SBR (local and remote) replicate critical SAP business data to VNX in a DR data center.

Table 1. XtremIO data protection levels

Data center coverage Data center products Enablement technology Protection level

Local XtremIO XtremIO Virtual Copy (XVC)

Logical error

XtremIO, RecoverPoint, and VNX

XVC and RecoverPoint SBR (local)

XtremIO outage

Local and Metro • Local: XtremIO and VPLEX

• Metro: XtremIO and VPLEX

XVC and VPLEX Metro Local DC outage

Local and DR • Local: XtremIO and RecoverPoint

• DR: XtremIO and RecoverPoint

XVC and RecoverPoint SBR (remote)

Local DC outage

• Local: XtremIO, RecoverPoint, and VNX

• DR: VNX and RecoverPoint

XVC and RecoverPoint SBR (local and remote)

XtremIO outage and local DC outage

Overview


Data center coverage Data center products Enablement technology Protection level

Local, Metro, and DR • Local: XtremIO, VPLEX, and RecoverPoint

• Metro: XtremIO, VPLEX, and RecoverPoint

• DR: VNX and RecoverPoint

XVC and MetroPoint Local DC outage with DR configuration lost

Local Networker and Data Domain

EMC SAP backup solution

Off-array backup

Figure 1 shows the architecture for a local data center.

Figure 1. EMC XtremIO data protection architecture in local data center

You can use XVC, a built-in local data protection feature, to create a large number of production copies at low interval points-in-time for recovery. You can use point-in-time copies for recovery or for other purposes. You can set application integration and orchestration policies to auto-manage data protection, using different SLAs. With XVC, you can protect production data from logical errors.

Architecture diagram


12

You can also add the optional RecoverPoint and existing block storage that is supported by RecoverPoint. In this solution, we used VNX at the same site as XtremIO to enhance local data protection. RecoverPoint replicates all the production data in XtremIO to VNX, either in continuous or periodic mode, which enables you to roll back to any point in time for effective local recovery from such events as database corruption. By adding the secondary storage and replication technology, it provides another layer of data protection in case the XtremIO array fails.

Figure 2 shows the architecture of local and DR data centers.

Figure 2. EMC XtremIO data protection architecture in local and DR data centers

We added the disaster recovery site into the topology to protect against production site failure. RecoverPoint replicates production data to the VNX storage in the disaster recovery site. When the primary site fails, the production data is still safe in the disaster recovery site. We also integrated RecoverPoint and VMware vCenter Site Recovery Manager (SRM) to automatically take over the failover process when the production site fails.

We recommend setting up another XtremIO array in the disaster recovery center as a replication target. This provides two advantages when VNX is used in the disaster recovery site. The first advantage is that—starting with RecoverPoint 4.1.2 and XtremIO 4.0—RecoverPoint offers native support for XtremIO, using snap-based replication, which does not require adapters to be installed. The other advantage is that the all-flash XtremIO in the disaster recovery site provides better performance and less start up time compared to hybrid storage. In this case, you can deploy different critical applications in different data centers and configure bi-directional replication to maximize the return of investment.


Consider deploying Networker and DataDomain as additional off-array backup protection. Data Domain deduplication storage systems continue to revolutionize disk backup, archiving, and disaster recovery with high-speed, inline deduplication. DataDomain can be added to either the primary site or the disaster recovery site, as an extra backup storage hardening option.

Table 2 lists the hardware resources used in the solution.

Table 2. Hardware resources

Hardware Quantity Configuration

Storage array 4 EMC XtremIO * 2

EMC VNX® 8000 * 2

RecoverPoint 4 Gen5

Data Domain 2 DD670

ESXi host 4 Four 10-core CPUs, 384 GB RAM

Ethernet switches 2 10 GbE (gigabit Ethernet)

SAN switches 2 8 Gb FC

Backbone switches

2 1 Gb slot * 1 + 10 Gb slot * 1

Table 3 lists the software resources used in this solution.

Table 3. Software resources

Software Version Description

EMC PowerPath®/VE 5.9 Multipathing software used in the virtual environment

EMC Networker module for SAP

9.0 SAP backup software

RecoverPoint 4.1.2 Replication

XtremIO 4.0.0-64 All-flash storage

VNX 05.33.000.5.051 Unified storage

VMware vSphere 5.5.0 Hypervisor

VMware vCenter Server 5.5.0 u2 vSphere management server

VMware Site Recovery Manager

5.8 Business continuity and disaster recovery software

SUSE Linux 11 SP3 Operating system for SAP system

EMC RecoverPoint 4.1.2 Replication

SAP ERP 6.0 EHP 5 Business application

Oracle database 11g R2 Database for the SAP systems

Hardware resources

Software resources


14

Testing and validation

This section provides detailed information about the following test scenarios:

• Protecting an SAP system locally

• Protecting an SAP system remotely

• Refreshing an SAP test landscape with a production snapshot

Test scenario

This test demonstrates how to use the XtremIO scheduling snapshot function to protect an SAP system locally.

For this test, we configured an XtremIO consistency group, BM1, which contained one distributed SAP ERP system spanned on multiple virtual machines. Then we created snapshots at regular short intervals using the snapshot scheduler, as shown in Figure 3. After that, we simulated an error in the SAP system and restored the entire system using one of the scheduled snapshots to recover SAP business data.

Figure 3. Snapshot scheduler used to create fixed interval snapshots over a consistency group1

1 In this figure, CI is the SAP central instance, DB is the database, and AAS is the SAP additional application server.

Protecting an SAP system locally


Test objectives

• Showcase the procedure of scheduling, retention, naming, and restoring snapshots in XtremIO

• Achieve a minimum 15 seconds RPO

Test procedure

1. Include all the storage volumes of SAP ERP system BM1 in a consistency group that contains the storage volume for the DB, CI, and AAS instance, as shown in Table 4. This means that if we restore the consistency group from one snapshot, all of the virtual machines in this group are restored at the same time.

Table 4. Volume and file system mapping

Volume File system Purpose

BM1_OS_APP /sapmnt

/usr/sap

/oracle/BM1/112_64

/oracle/client

/oracle/stage

Volumes for CI, DB, and AAS operating systems and Oracle or SAP binaries

BM1_DB_DATA1 /oracle/BM1/sapdata1 SAP data volume




BM1_DB_ArchLog /oracle/BM1/oraarch SAP archive log volume

BM1_DB_Redolog /oracle/BM1/origlogA

/oracle/BM1/origlogB

/oracle/BM1/mirrlogA

/oracle/BM1/mirrlogB

SAP redo log volume

2. Select the consistency group BM1 and create a snapshot scheduler, as shown in Figure 4. Set the snapshot frequency to every 15 seconds, and read-only as shown in Figure 5. You can also modify the retention policy and snapshot suffix name here.

Figure 4. Creating a snapshot scheduler in an XtremIO Storage Management Application (XSMA)


16

Figure 5. Scheduling a snapshot for BM1

3. Verify that the XtremIO array creates snapshots every 15 seconds in XSMA, as shown in Figure 6.

Figure 6. Snapshots taken in XSMA after scheduling

4. Generate a workload in the BM1 system, which will create sales orders in the database continuously. The VBAP table displays time stamped sales orders, as shown in Figure 7.


Figure 7. VBAP table sales order entries

5. Delete the VBAP table to simulate an error scenario in the BM1 system and note the time (10:49:32 in this example) when the problem occurred.

6. If you receive a No database table exists message, stop the workload generator, as business cannot continue after you delete the VBAP table.

7. Power off all the SAP BM1 virtual machines in the vCenter Server, including the SAP CI, the database, and SAP AAS instances. This is a prerequisite for restoring the snapshot.

8. Click Restore from Read-only Snapshot to restore consistency group BM1 from a read-only snapshot in XSMA, as shown in Figure 8.

Figure 8. Restoring from a snapshot for consistency group BM1

9. Select a snapshot of 10:49:30, from before the VBAP table was deleted, as shown in Figure 9.


18

Figure 9. Selecting a snapshot for the restore

10. Click Finish to complete the Restore operation in XSMA, as shown in Figure 10. This takes only a few seconds to complete. Power on all the SAP BM1 virtual machines in the vCenter Server, and start all the SAP applications for verification.

Figure 10. Completing the XtremIO snapshot restore

Test result

We started the BM1 system after reverting to the snapshot, which caused the BM1 system to run again with the deleted VBAP table restored. You can use the XtremIO snapshot scheduling function to save the point-in-time copies as snapshots. You can then select any of the snapshots that you want to restore and protect your SAP system from logical errors.

You can compare the timestamp of the latest sales order in the restored VBAP table (Figure 9) to the time of the snapshot we scheduled (Figure 11). A comparison shows the gap is five seconds. With the XtremIO snapshot scheduler, we achieved a 15-second RPO. You can achieve different RPO levels based on the snapshot interval value that you set.


Figure 11. VBAP table sales order entries after a snapshot Restore operation

Test scenarios

We built two sites as illustrated in Figure 12 to validate the failover and failback scenarios. We deployed a distributed SAP system BM1 on XtremIO in site A. We also configured the RecoverPoint continuous local and remote replication to replicate BM1 to two copies separately on VNX in Site A and Site B, as shown in Figure 12.

Figure 12. EMC RecoverPoint replication status

Protecting an SAP system remotely


20

For failover, we simulated the Site A outage, and validated that VMware Site Recovery Manager (SRM) can failover BM1 to VNX in Site B, and the RPO is compliant.

For failback, we restored Site A and validated that VMware SRM can failback BM1 to XtreamIO in Site A. This resumed the data protection with no data lost during the transaction.

Figure 13 shows the six different states of the two sites during the disaster recovery scenarios.

Figure 13. Six states in failover and failback processes

Table 5 describes the states during the failover and failback processes.

Table 5. Failover and failback processes

Period State Description

Failover S1 SAP instance (BM1) runs in Site A.

S2 A disaster causes Site A to fail and the entire infrastructure becomes unavailable.

S3 The IT administrator runs a Disaster Recovery operation in VMware SRM at Site B. Site B becomes the production site and BM1 becomes active on Site B.

S4 Site A is rebuilt and becomes functional. VMware SRM and the vCenter Server in Site A are back online.


Period State Description

Failback S5 The IT administrator runs a Reprotect operation in VMware SRM to reverse the original replication direction. After that, Site A becomes the data recovery site. Site A resynchronizes from Site B.

S6 Downtime maintenance is scheduled. The IT administrator triggers a planned migration. After migration, Site A becomes the production site once again. BM1 now runs in Site A, but the replication between Site A and Site B is not reestablished.

Back to S1 The IT administrator runs a Reprotect operation in the VMware SRM to establish the replication from Site A to Site B. Site B becomes the recovery site.

Failover after disaster

SAP instance BM1 ran in Site A. A disaster occurred and caused a site outage at Site A. We failed over the applications to Site B and brought BM1 back online.

Test objectives • Successfully failover the SAP instances for BM1 from Site A to Site B with an

RTO of 15 minutes.

• Validate that the recovery point actual meets the 30 minute RPO requirement.

Test procedure

1. Create a consistency group named BM1 in RecoverPoint to include the volumes of SAP instance BM1.

2. Define the group policy of the consistency group BM1. Configure RecoverPoint to be managed by the VMware SRM, and define the recovery copy as VNX in Site B, as shown in Figure 14.

Figure 14. Configuring RecoverPoint external management

3. Define the link policy of consistency group BM1. Configure the replication mode as asynchronous and the snapshot replication interval to 15 minutes (half of the desired RPO) in RecoverPoint, as shown in Figure 15.


22

Figure 15. Configuring the snapshot replication interval

4. Create a recovery plan named BM1 in the SRM that includes consistency group BM1.

5. Run the Power Benchmark to generate new sales documents in BM1.

Use transaction code SE16 to check the creation time of the last sales document entries that are displayed in the VBAP table, as shown in Figure 16.

Figure 16. Sales order entries in the VBAP table before a disaster

6. Immediately power off all ESXi servers and RecoverPoint in Site A after capturing the result that is shown in Figure 16.

7. Use the vSphere web client to log in to the vCenter Server in Site B. Navigate to the VMware SRM tab, select the recovery plan that we created in step 4, and run the Disaster Recovery operation, as shown in Figure 17.


Figure 17. Running the Disaster Recovery operation

8. When the disaster recovery action is completed, bring up SAP system BM1 and check the last available entry of the VBAP table, as shown in Figure 18.

Figure 18. Sales order entries in the VBAP table after the system is brought up in the DR site

Test results Compare the two timestamps in Figure 16 and Figure 18. The recovery point actual (RPA) is 00:08:54 (09:53:12 - 09:44:18), which meets the 30-minute RPO requirement.

Failback after Site A is rebuilt

While restoring Site A, new business data was injected to BM1 in Site B. We reversed the replication direction so that the latest business data was replicated to the XtremIO array in Site A. We performed the Reprotect operation from the vCenter Site Recovery Manager, as shown in state 5 in Table 5. After the Reprotect operation was completed, we performed a planned migration of the SAP systems from Site B to Site A.

Note: A planned downtime is required during the planned migration.


24

Test objectives • Successfully fail back the SAP BM1 instances to Site A.

• Validate that no data loss occurred during the failback.

Test procedure

1. Power on the ESXi servers and RecoverPoint in Site A.

2. Select the recovery plan BM1 in SRM in Site B, and run the Recovery operation to place the recovery plan back to a consistent state, as shown in Figure 19.

Figure 19. Running Recovery in the VMware SRM

3. Run the Reprotect operation in the VMware SRM to change the replication direction, from VNX in Site B to XtremIO in Site A, as shown in Figure 20.

Figure 20. Reversing replication direction

4. Unmount BM1 data stores in vCenter of Site A, as shown in Figure 21.


Figure 21. Unmounting the data stores

5. Run the Power Benchmark to generate new sales documents in BM1 in Site B. After the job is completed, check that the last sales order in VBAP table is 1402476018, created at 11:12:22, as shown in Figure 22.

Figure 22. Checking the last entries in BM1 in Site B

6. Shut down SAP applications properly and then shut down SAP virtual machines. Run the Planned Migration operation in VMware SRM, as shown in Figure 23.


26

Figure 23. Running the planned migration

7. Start BM1 and verify that all entries in the VBAP table exist, as shown in Figure 24.

Figure 24. Checking the last entry in BM1 in Site A

8. Run the Reprotect operation again in the VMware SRM to change the replication direction, from XtremIO in Site A to VNX in Site B.

Test results We validated that the failback process was successful with all sales documents by comparing the entries in Figure 22 and Figure 24.


Test scenario

We conducted this test to demonstrate how to refresh an SAP test instance from a production instance snapshot. To simulate this refresh procedure, we created a distributed SAP system (BM2) based on the snapshot of a distributed SAP system (BM1), as shown in Figure 25.

Figure 25. SAP PRD and test system landscape

In this test, we performed three major steps to validate this functionality:

1. Repurpose the snapshot of SAP system BM1 to build SAP test system BM2.

2. Refresh BM2 data and log volumes with BM1 snapshots.

3. Run the post steps to bring up SAP system BM2.

Test objective

• Conduct a complete SAP system refresh

• Validate data consistency after the refresh

Test procedure

1. Repurpose a snapshot of SAP system BM1 to build SAP system BM2:

a. Create consistency group BM1_DB to include database data and log volumes, as shown in Figure 26.

Refreshing an SAP test landscape from production


28

Figure 26. Volumes in consistency group BM1_DB

b. Create consistency group BM1_OS to include the BM1_OS volume, which contains operating system virtual machine disk (VMDK) files and SAP or Oracle binary files for all three virtual machines.

c. Create a snapshot of BM1_DB and BM1_OS. Rename these two snapshot sets to BM2_DB and BM2_OS, expose them to the ESXi host, and bring them up as an identical BM1 system.

d. Change the hostname of all three virtual machines of BM2, and use the SAP software provisioning manager (SWPM) to rename the SAP system from BM1 to BM2.

Note: The SAP Notes in the SAP documents section provide detailed instructions.

2. Refresh BM2 data and log volumes with BM1 snapshots:

a. Run the SAP Power Benchmark to create 300 new sales orders in the BM1 system. Record the last sales order with document number 140247899, which was created at 12:00:34, as shown in Figure 27. Verify that the BM2 system contains none of these new sales orders.


Figure 27. VBAP table entries in BM1

b. In virtual machine sapbm1db, back up the BM1 control file with this SQLPLUS command as user orabm1:

alter database backup controlfile to trace;

c. Check the latest trace file in the /oracle/BM1/saptrace/diag/rdbms/bm1/BM1/trace folder and find the BM1_ora_18351.trc file. Edit this file by replacing BM1 with BM2 in the content, and rename it as BM1_ora_18351_changed.trc.

d. Create a snapshot of consistency group BM1_DB with the name BM2_DB_refresh.

e. Shut down BM2 and remove the sapbm2db virtual machine from vCenter inventory, and unmount all data stores containing data files and log files.

f. In the XSMA, refresh the snapshot set BM2_DB from snapshot BM2_DB_refresh, which was created in step d, as shown in Figure 28.


30

Figure 28. Refreshing the snapshotset BM2_DB

g. In the vCenter Server, rescan new storage devices and VMFS volumes on the DRS cluster, add back the refreshed data stores, and sign new signatures.

h. Add virtual machine sapbm2db back to inventory and then start this virtual machine.

3. Run the post steps to bring up SAP system BM2:

a. In virtual machine sapbm2db, change the mount points from BM2 to BM1 as shown in Figure 29, and then update the authorization, as shown in Figure 30.

Figure 29. Changing the mount points from BM2 to BM1


Figure 30. Changing BM2 mount points and updating the file authorization

b. In virtual machine sapbm2db, replace BM2 with BM1 in the startup profile initBM2.ora, and then start the database BM1 with this profile, as shown in Figure 31.

Note: This step is mandatory before changing the database name to BM1. For details, refer to 15390.1 – How to Rename Database/Change DB_NAME or ORACLE_SID/Instance Name.

Figure 31. Starting database BM1 with an updated startup profile

c. Shut down the database and upload the trace file exported in step 2b.

d. Change the mount points of all the database data and log files from BM1 to BM2.

e. Recreate the Oracle database BM2 control file from the changed trace file, as shown in Figure 32.

https://support.oracle.com/epmos/faces/DocumentDisplay?id=15390.1



32

Figure 32. Changing the database control file to reflect the database name BM2

f. Run the Oracle create Oracle spfile from pfile command, and run the postscripts SAP_CLI.sql command in the BM2 database to add back the authorization of OPS$BM2ADM, OPS$ORABM2, and OPS$SAPSERVICESBM2, as shown in Figure 33.

Note: Appendix A provides the SAP_CLI.sql SQL command that we used to add authorizations for this solution.

Figure 33. Running the post service to grant user access

g. Run the following commands to change the password for database user SAPSR3:

i su – bm2adm

ii brconnect –u system/PASSWORD –f chpass –o SAPSR3 –p ‘PASSWORD’

h. Start the Oracle database BM2 and then start SAP application BM2.

i. In the BM2 system, verify the VBAP table containing the last sales order 140247899, created at 12:00:34, as shown in Figure 34.


Figure 34. VBAP table entries in BM2

Test results

After we refreshed BM2 from the BM1 snapshot, we verified that the BM2 VBAP table contains all the sales orders as in BM1, including the last sales document number 140247899, created at 12:00:34.


34

Conclusion

This paper provides information about full SAP landscape protection using the following key components:

• Snapshot scheduler—Enables local snapshot automation within XtremIO

• RecoverPoint snapshot-based replication—Enables data replication to both homogenous and heterogeneous arrays

• Data Domain—Enables the off-array local and DR data protection

This solution validates:

• Reliable SAP snapshots within XtremIO to achieve 15-seconds RPO

• Successful SAP failover and failback to VNX in the data recovery site within a 30-minute RPO

• Easy steps to refresh an SAP test landscape from a production snapshot

Summary

Findings


References

For additional information, see the following product documents on www.EMC.com or EMC Online Support (https://support.emc.com):

• EMC RecoverPoint Replication of XtremIO White Paper

• RecoverPoint Storage Replication Adapter 2.X for VMware vCenter Site Recovery Manager Release Notes

• RecoverPoint 4.1 Administrator's Guide

• RecoverPoint Deploying with XtremIO Technical Notes

For additional information, see the following product document:

• Site Recovery Manager 5.8 Administration

For additional information, see the following product documents on support.sap.com, which may require password access:

• System Rename Guide - SAP Systems Based on the Application Server ABAP of SAP NetWeaver: UNIX

• SAP Notes:

1680045 - Release Note for Software Provisioning Manager 1.0 SP 08

1619720 - System Rename for SAP Systems based on SAP NetWeaver

For additional information, see the following product document, which requires password access:

• 15390.1 – How to Rename Database/Change DB_NAME or ORACLE_SID/Instance Name

EMC documents

VMware documents

SAP documents

Oracle documents

http://www.emc.com/

https://support.emc.com/

http://pubs.vmware.com/srm-58/topic/com.vmware.ICbase/PDF/srm-admin-5-8.pdf

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

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

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

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




36

Appendix A

We used the following SAP_CLI.sql SQL command to add authorizations for this solution:

alter user system identified by PASSWORD; #PASSWORD is an example here only drop table OPS$BM1ADM.SAPUSER; drop User OPS$BM1ADM cascade; drop User OPS$ORABM1 cascade; drop User OPS$SAPSERVICEBM1 cascade; create user OPS$BM2ADM IDENTIFIED EXTERNALLY; create user OPS$ORABM2 IDENTIFIED EXTERNALLY; create user OPS$SAPSERVICEBM2 IDENTIFIED EXTERNALLY; grant CONNECT,RESOURCE,SAPDBA to OPS$BM2ADM; grant CONNECT,RESOURCE,SAPDBA to OPS$ORABM2; grant CONNECT,RESOURCE,SAPDBA to OPS$SAPSERVICEBM2; CREATE TABLE OPS$BM2ADM.SAPUSER (USERID Varchar2(255),PASSWD Varchar2(255)); CREATE public SYNONYM SAPUSER FOR OPS$BM2ADM.SAPUSER;

Post SQL command to add authorizations

emc xtremio advanced data service for sap business suite white

Documents