SAP S/4HANA migration (Lift/shift) from On-Prem – Public cloud(Demo Video)

In this blog/video I would like to show how easy it is to migrate your mission-critical or your crown jewel S/4HANA distributed system to a public cloud using Cloud Block Store on AWS. What is Cloud Block Store? Cloud Block Store, is based on Purity software running natively on AWS. Powered by Purity software, Cloud […]

sap

In this blog/video I would like to show how easy it is to migrate your mission-critical or your crown jewel S/4HANA distributed system to a public cloud using Cloud Block Store on AWS.

What is Cloud Block Store? Cloud Block Store, is based on Purity software running natively on AWS. Powered by Purity software, Cloud Block Store enables mission-critical applications to run on the cloud seamlessly – while also making cloud storage more powerful for web-scale applications. It drives true hybrid operations with consistent data services, resiliency, and APIs, and bi-directional mobility and seamless management and orchestration. You gain the ultimate agility: faster application development and the ability to free applications from specific infrastructure.

In order to show this migration, I have built two S/4HANA systems. One on the on-premises FlashArray and another one on Cloud Block Store in AWS. The demo involves using FlashArray data services (asynchronous replication) from an on-premises SAP HANA database running on a Pure Storage FlashArray//XR2 host in our lab, to Cloud Block Store in AWS. Once the database volume is replicated, we can bring up an SAP HANA instance and S4HANA application running on an Amazon EC2 instance.

These are a series of blogs concentrating on Migration of S/4HANA applications. Here I have used Asynchronous replication. In the next blog, I will show a different methodology of migrating the S/4HANA system to AWS.

These are distributed systems with the same SID. Both are S/4HANA systems are S/4HANA 1610 on SAP HANA 2.0 SP3 version. On AWS the S/4HANA distributed system is using EFS file system for sap home or /sapmnt, whereas in on-premises the sap home or /sapmnt is using NFS v3. This is the only difference between these two systems but the rest in every other possible way they are completely identical.

Operating system: SUSE Linux 12 sp3 for SAP applications

Sap home file system(/sapmnt): EFS on AWS and NFS on On-prem system

SAP HANA version: SAP HANA 2.0 sp3

S/4HANA version: S/4HANA 1610

Schema name: SAPABAP1

SAP HANA Data and Log volumes: XFS File system(Data volume is replicated to Cloud Block Store/AWS)

It is very important to make sure the schema name remains the same for both the on-prem S/4HANA system and S/4HANA system in AWS. Here is the status of the S/HANA system.

The following steps are performed on the on-premises S/HANA system:

  1. The Cloud Block Store on AWS is connected to the on-premises FlashArray as an asynchronous-replication target.
  2. We have a protection group for this on-premises SAP HANA’s data volume. This protection group is configured to replicate to Cloud Block Store.
  3. Now we take an application-consistent snapshot of the on-premises SAP HANA system. We put SAP HANA in create snapshot mode (Back up mode) and then we freeze the data volume’s file system to an application-consistent snapshot. Then we unfreeze the file system and close the SAP HANA backup mode. Please refer to my other blog which explains the whole process in detail for backing up an SAP HANA 2.0 multi-tenant system. Backup of SAP HANA 2.0 MDC with Single Tenant on Pure Storage ->Part-1
  4. This asynchronously replicates the latest data to the Cloud Block Store. Let us now begin the recovery process for the SAP HANA instance on AWS.

The following steps are performed on AWS:

  1. Now use the latest snapshot which was replicated from the on-premises FlashArray. We apply this latest snapshot on to the SAP HANA data volume.
  2. After we apply the snapshot, we start the recovery process for the SAP HANA instance on EC2. Remember this is an SAP HANA 2.0 Multi-tenant system. This means we need to first recover the System database and then the tenant database. Please refer to my other blog which explains the whole process in detail for the recovery of an SAP HANA 2.0 multi-tenant system. Recovery of SAP HANA 2.0 MDC on Pure Storage using snapshots->Part-2
  3. Once the recovery is completed, we can use the HANA system we need to start the S/4HANA application.

The complete demo is shown in this video: https://www.youtube.com/watch?v=5QHsRxgiDTg&feature=youtu.be