Failover of services to a cloud operated environment in case of a primary site disaster can be more cost effective than managing and operating a dedicated traditional disaster recovery site. With VMware Cloud on AWS customers can experience a secondary site with a vSphere operating environment which is operationally consistent with an on-premise VMware datacenter. In order to maintain low RPO during a disaster recovery (DR) event data replication technologies are considered from the primary to the DR site. This can be achieved via various methods including storage replication or database (log) replication. In this blog we demonstrate the functionality of failing over a SAP S/4HANA system to VMware Cloud on AWS using SAP HANA System Replication. VMware Cloud for AWS is not yet certified for SAP HANA – this blog introduces a functional proof-of-concept.
SAP HANA System Replication is a high availability and disaster recovery solution where SAP HANA replicates all data from a primary to a secondary SAP HANA system. Once HANA system replication is enabled, a snapshot of data is initially sent from the primary to secondary after which all logged changes in the primary system are replicated continuously to the secondary in the form of redo log files. The secondary is on standby until a takeover takes place.
The following diagram shows the logical architecture of an SAP S/4HANA disaster recovery solution between an on-premise VMware based datacenter and VMware Cloud on AWS.
SAP HANA System Replication has different modes for replication: synchronous (secondary system sends acknowledgement back to primary as soon as data is received and persisted to disk); and asynchronous (primary does not wait for an acknowledgment from secondary). The choice depends on network latency between the systems – asynchronous is recommended for data centers more than 100 km apart which is the case in this demonstration.
SAP provides guidance and tools to check system replication performance at the SAP HANA system level between two sites – see here. The SAP method to check log shipping time was tested with the above architecture to compare log shipping time to local log write time for the synchronous use case. The KPI Avg. log buffer shipping time showed significant longer buffer shipping time compared to Avg. local log buffer write time (as expected). This confirmed use of asynchronous replication mode in this example.
A demo of the proof-of-concept is available here. The demo shows:
- Enabling HANA system replication on the primary system via SAP HANA Studio.
- Initial transfer of the data from the primary system on-premise to the secondary system on VMware Cloud on AWS after which system replication is up and operational
- Manual takeover of the secondary system on VMware Cloud on AWS.
Customers currently using SAP HANA System Replication for their disaster recovery solutions can leverage the same technology and skill sets with VMware Cloud on AWS as their disaster recovery site. VMware Cloud on AWS provides a secondary site that is operationally consistent with a customer’s on-premise VMware data center. In a future blog we will show how VMware Site Recovery Manager with VMware Cloud on AWS can provide DR as a service for SAP HANA systems.
