Accelerating recovery during restarts for SAP HANA using AWS Elastic Disaster Recovery

Update (12/12/2022): Depending on your specific RTO and RPO requirements, we recommend evaluating the use of Elastic Disaster Recovery along with database native replication methods, such as SAP HANA System Replication (HSR) for SAP HANA.

Disasters due to natural calamities, application failures, human errors, or ransomware cause not only downtime for business applications, but also data loss and revenue impact. To mitigate the impacts of these scenarios, disaster recovery (DR) planning is critical for organizations running mission-critical and business-critical applications, such as SAP.

An SAP HANA environment can suffer outages due to either planned restarts and reboots or unplanned crashes. In these scenarios, even when a DR environment is set up to make sure of business continuity, the delay in replicating the changes to the target system can grow considerably. This is because no data replication occurs until after the disks are re-read from the source SAP HANA system. In this scenario, the DR environment may be out of sync with the source system for several hours depending on the size of the SAP HANA database. If a disaster were to occur, you could suffer large data loss resulting in higher RPO (Recovery Point Objective).

AWS Elastic Disaster Recovery enables organizations to quickly and easily implement a new DR plan or migrate an existing one onto AWS. The source servers can be based on AWS, existing physical or virtual data centers, private clouds, or other public clouds. Elastic Disaster Recovery enables customers to use AWS as an elastic recovery site without needing to invest in on-premises DR infrastructure that lies idle until needed. It also gives you the flexibility to pay on an hourly basis instead of committing to a long-term contract or a set number of servers as is the case with on-premises or data center recovery solutions. Elastic Disaster Recovery is fully supported as a DR solution for SAP applications and databases, and it helps you recover all of your SAP applications and databases that run on supported Windows and Linux operating system versions.

In this post, we first demonstrate how to use Elastic Disaster Recovery to set up a DR environment for an SAP HANA database. We then demonstrate how applying the ‘no rescan after reboot’ feature in Elastic Disaster Recovery to SAP HANA accelerates recovery during system restarts and minimizes replication lag. This minimizes the duration that the DR environment may be out of sync with the source system and helps you meet your lower RPO objectives.

Solution overview

We use the AWS Launch Wizard to deploy an SAP HANA database on a single Amazon Elastic Compute Cloud (Amazon EC2) instance in a single-node, scale-up architecture. We use an AWS CloudFormation template to provision an Amazon Virtual Private Cloud (Amazon VPC) that consists of private subnet(s) in a minimum of two Availability Zones (AZs). The HANA database is deployed on a supported Suse Linux for SAP 12 SP3 EC2 instance in a private subnet with outbound internet access.

We deploy an Elastic Disaster Recovery agent on the source HANA database EC2 instance in the us-west-2 Region to connect to Elastic Disaster Recovery in the us-east-1 target Region. With this setup, I continuously replicate block storage volumes from the source SAP HANA database into a low-cost staging area in the target DR AWS Region. In the case of a disaster, you can launch the replicated HANA database via the Elastic Disaster Recovery console to a fully provisioned state in minutes.

Replication lag is the delay between the changes that occur on the source and the replication of those changes to the target. If the source machine on which the HANA database is deployed had a spike of write operations, or if it was rebooted recently, then the disks are re-read after this. Until it’s finished, the replication lag will grow. I demonstrate how a reboot of the underlying Linux server on which the SAP HANA database is deployed no longer triggers a rescan in Elastic Disaster Recovery once the source server is restarted. This results in minimizing replication lag and accelerating recovery during restarts for SAP HANA using Elastic Disaster Recovery.

The following diagram describes the setup of SAP HANA for multi-Region DR using Elastic Disaster Recovery:

Figure 1: SAP HANA multi-region DR using Elastic Disaster Recovery

Prerequisites

The following prerequisites are required for this post:

1. In the source Region (us-west-2), navigate to the AWS CloudFormation console and create a stack by launching the aws-vpcsetup-v1.yml CloudFormation template. This template sets up a VPC consisting of public and private subnets in a minimum of two AZs. It also provisions an AWS Identity and Access Management (IAM) user required to set up the Elastic Disaster Recovery replication agent. The private subnets have outbound internet access via a NAT Gateway. The template takes no parameters. After the successful launch of the template, select Stacks on the left panel. Then select the aws-vpcsetup-v1.yml template, and select the Outputs tab:

a. Note the identifiers for the VPC (vpc1), public subnet (vpc1_sn1_A1), private subnets (vpc1_sn1_A2 and vpc1_sn1_B2), and the security group (SG_BASTION). You must install the SAP HANA software with the Launch Wizard in the Setup section.

b. Note the values for the DRSUserAccessKeyId and DRSUserSecretAccessKey. You must install the Elastic Disaster Recovery replication agent in the Setup section.

2. Download the SAP HANA software from the SAP software center and upload it to an Amazon Simple Storage Service (Amazon S3) To do this, follow the instructions in the Make SAP HANA software available for Launch Wizard to deploy a HANA database section of the Launch Wizard documentation. The S3 bucket must have the prefix ‘launchwizard’. In this case, I downloaded the SAP HANA Platform Edition 2.0 as a zip file. I then uploaded the zip file to a folder ‘hana2sp6’ as shown in the following. Note the Amazon S3 URL of this folder to be used to install the SAP HANA software using the Launch Wizard in the next section.

Figure 2: S3 bucket folder that contains the uploaded zip file for the SAP HANA 2 Platform edition database

3. SAP HANA must run on a supported operating system version. For a complete list of supported operating system versions, see Operating systems. In this case, I’m using an AWS Marketplace subscription for the SUSE Linux Enterprise Server for SAP Applications 12 SP3 operating system to run the SAP HANA 2 Platform edition database.
4. Follow the steps here to configure IAM roles and create an IAM user that Launch Wizard uses to deploy SAP systems on AWS.
5. In the target Region (us-east-1) of your AWS account, navigate to the AWS CloudFormation console and create a stack by launching the aws-vpcsetup-v1.yml You will use the VPC and public subnet from this template in the default settings for your replication settings for Elastic Disaster Recovery.

Setup

1. Navigate to the Launch Wizard console in the us-west-2 Region and install the SAP HANA database.

a. Select SAP from the left panel and select Create deployment. Follow the instructions here to deploy the SAP HANA database with the Launch Wizard. I highly recommend reviewing this AWS video tutorial as a reference for using the Launch Wizard for SAP deployments. In this case, I followed the steps for a single instance deployment of the SAP HANA database with the Launch Wizard using the following configurations:

i. On the Define infrastructure step of the Launch Wizard, under Configuration details in the Infrastructure – SAP landscape tab, provide the VPC and private subnets from the template deployed in Step1a of the prerequisites section.

ii. On the Define infrastructure step of the Launch Wizard, under Security groups in the Infrastructure – SAP landscape tab, select Choose from existing security groups and select the security group from Step 1a of the prerequisites section.

iii. On the Configure application settings step of the Launch Wizard, under S3 location for HANA media, enter the Amazon S3 URL from Step 2 of the prerequisites section.

iv. On the Configure deployment mode step of the Launch Wizard, select Single instance deployment and provide details of the SUSE Linux Enterprise Server for SAP Applications 12 SP3 AMI from the AWS Marketplace subscription. In this case, under Instance sizing, I selected an r5.16xlarge instance.

2. Navigate to the Elastic Disaster Recovery console in the us-east-1 Region. Set up the configuration that your source SAP HANA server will take on by default in Elastic Disaster Recovery once the Elastic Disaster Recovery replication agent is installed.

a. Select Set default replication settings. Under Replication server configuration select vpc1_sn_A1 as the Staging area subnet and select m5.xlarge as the Replication server instance type.

b. Select Next and use the default options for Amazon Elastic Block Store (EBS) volume type, EBS encryption, and Security groups under the Volume and security groups

c. Select Next and use the default options under the Data routing and throttling tab as well as the Point in time (PIT) policy

d. Select Next and then Create default to save your default replication configuration.

3. Navigate to the Amazon EC2 console in the us-west-2 Region to install the replication agent on the SAP HANA database server. The Launch Wizard in Step 1 of this section also installs the AWS Systems Manager agent on the SAP HANA database server. Select the SAP HANA database instance on the Amazon EC2 console. Select Connect and then on the Connect to instance tab, select Session Manager. Then select Connect to login to the SAP HANA database server.

a. Download the Elastic Disaster Recovery agent installer: wget -O ./aws-replication-installer-init.py https://aws-elastic-disaster-recovery-us-west-2.s3.amazonaws.com/latest/linux/aws-replication-installer-init.py

b. Run the Elastic Disaster Recovery agent installer: sudo python3 aws-replication-installer-init.py

c. When prompted by the agent installation process, enter the following information. After responding to the prompts, you should see that the installation was successful:

i. AWS Region Name: us-west-2.

ii. AWS Access Key ID: Enter the value of the DRSUserAccessKeyId from step 1b of the prerequisites section.

iii. AWS Secret Access Key: Enter the value from the DRSUserSecretAccessKey from step 1b of the prerequisites section.

iv. When prompted to Choose the disks you want to replicate, hit the Enter key to select all.

4. Navigate back to the Elastic Disaster Recovery console in the us-east-1 Region. Select Source servers on the left panel. You should now be able to select the SAP HANA source server to review the initial sync process. The initial sync is comprised of several tasks. At any time, you may return here to monitor the data replication progress. Once the initial sync is complete, the Data replication status will be shown as Healthy.

5. After completion of the initial sync process and synching from the Elastic Disaster Recovery console in the us-east-1 Region, select Source servers on the left panel. Select the SAP HANA source server, and select Launch settings.

a. In the General launch settings tab, select Edit. Set Instance type right sizing to ‘None’ and then save the settings.

b. In the EC2 launch template tab, select Edit and modify the Amazon EC2 launch template:

i. For the Template version description provide a description for “saphanalaunchtemplate”.

ii. In the Instance Type tab, select Manually select instance type and select r5.4xlarge.

iii. Under the Network settings tab in the Subnet section, select the ‘vpc1_sn_A2’ private subnet and in the Firewall section, select Select existing security group, and then select the ‘SG_BASTION’ security group.

iv. Scroll down and select Create template version.

v. Select the link to the template version that you just created in the Success notification box, select Actions and select Set Default Version. Select ” saphanalaunchtemplate as the Template version, and select the Set as default version button.

Test and run

This section covers how to validate recovery, and validate accelerated recovery after restart.

Validate recovery

Perform a failover of the SAP HANA database server in us-west-2 to a target server in us-east-1 using Elastic Disaster Recovery:

1. Navigate to the Elastic Disaster Recovery console in the us-east-1 Region. Select Source servers on the left panel. Select the SAP HANA source server (imdbmaster) and select Initiate recovery job. Then Initiate Drill from the top right panel.

2. On the Select a point in time page, for Points in time select Use most recent data. Scroll down and select Initiate drill.

3. Select Recovery job history from the left panel of the Elastic Disaster Recovery console to monitor the job log and make sure that your launch is successful.

Figure 3: Job log for the failover in Elastic Disaster Recovery showing details of the recovery process for the SAP HANA database server

4. Select Source servers on the left panel, and select your SAP HANA source (imdbmaster) to see the final status of your recovery.

Figure 4: Recovery dashboard in Elastic Disaster Recovery showing the recovery status for the SAP HANA server

Validate accelerated recovery after restart

Let’s now perform a restart of the SUSE Linux server on which the SAP HANA database is deployed and test Elastic Disaster Recovery replication to the target Region:

1. Navigate to the Amazon EC2 console in the us-west-2 Region. Select the Amazon EC2 instance (SAP HANA Master) for the SAP HANA server. Select Connect, and then on the Connect to instance tab, select Session Manager. Select Connect to log in to the SAP HANA server. Enter sudo shutdown -r 0 to restart the server.

2. Navigate to the Elastic Disaster Recovery console in the us-east-1 Region. Select Source servers on the left panel. Select the SAP HANA source server (imdbmaster) and you will see that the source server status under Ready for recovery is changed from Ready to Initial sync. From the Recovery dashboard tab, scroll down to the Data Replication status panel to monitor the replication lag that highlights the delay between the changes that occur on the source and the replication of those changes by Elastic Disaster Recovery to the target.

3. Note that in this case of a server restart the disks aren’t being re-read since you don’t see the appearance of a Rescan progress bar and the replication lag is minimal. (For example, two minutes as shown in this case.)

Figure 5: Data replication status for the SAP HANA server after a server restart showing a replication lag and replication in progress

4. Moreover, you can see that the replication lag doesn’t grow, since replication automatically starts from where it left off before restart. You can see that the replication progress changes to healthy within minutes for our 1.94 TB database and the server status under Ready for recovery is changed back from Initial to Ready.

Figure 6: Data replication status for the SAP HANA server after a server restart showing replication completed successfully

Cleaning up

To avoid recurring charges, and to clean up your account after trying the solution outlined in this post, perform the following:

1. Follow these steps to terminate the Amazon EC2 instance running the source SAP HANA server in the us-west-2 Region and the target SAP HANA server in the us-east-1 Region.
2. Delete the cloudformation stack for the aws-vpcsetup-v1 template in each of the us-west-2 and us-east-1 Regions.

Conclusion

Elastic Disaster Recovery is fully supported as a DR solution for SAP HANA. It helps you recover all of your SAP applications and databases that run on supported Windows and Linux operating system versions.

However, even when a DR environment is set up to support business continuity, the delay in the changes to be replicated to the target system can grow considerably. This is the case with planned or unplanned restarts during an outage since no data replication occurs until after the disks are re-read from the source SAP HANA system. In this scenario, the DR environment may be out of sync with the source system for several hours depending on the size of the SAP HANA database. A disaster during this time can cause large data loss resulting in higher RPO (Recovery Point Objective).

In this post, we first demonstrated how to use Elastic Disaster Recovery to setup and test a DR environment for an SAP HANA database. We then demonstrated accelerated recovery of your SAP HANA database using Elastic Disaster Recovery. This minimizes replication lag and reduces the duration that your DR environment may be out of sync with the source system. This helps you meet your lower RPO objectives for your SAP HANA environment in the event of a disaster.