ActiveDR Disaster Recovery Workflows for SAP HANA

SAP

Audience
Public
Product
FlashBlade
FlashArray
FlashStack
FlashBlade > Purity//FB
FlashArray > Purity//FA
Technology Integrations
SAP
Source Type
Documentation

For disaster recovery, there are a few options for testing failovers and workflows for real scenarios. Here's how to perform each one.

Non-disruptive Failover Testing

Non-disruptive failover with ActiveDR allows for any one of the disaster recovery/target sites to bring a pod online without changes being replicated back to the production/primary pod. During a non-disruptive test, the databases in the primary pod remain online and continue to replicate transactions to the FlashArray at the secondary site. This ensures uninterrupted production operations while enabling failover testing and allowing the target database to be used for testing and development purposes once the disaster recovery testing is complete.

Note: When using this process, the primary site will still queue changes, which will be applied to the target site once the process is undone automatically, with no manual intervention required.

During this process, while the target pod is promoted, ActiveDR will maintain replication from the source pod in the background, continuing to stream new content to the target array. The target FlashArray system will store the replicated content in a separate accounting bucket using metadata and pointers for space efficiency. The replicated content will not be shown in the target pod while the pod is in a promoted state.

When failover testing is complete, simply demote the target pod. Demoting a target pod will cause any test data written into that pod to be discarded from the pod. The content that was replicated from the source will then be attributed to the target pod.

To perform a non-disruptive failover, the state of the environment must be as follows:

  • There are two FlashArray storage platforms with an ActiveDR replica link.

  • There are two separate SAP HANA systems running the same version. These can be either scale-up or scale-out hosts.

  • There is a demoted remote pod on a separate array in the same active pod replica link.

Performing the Failover

A non-disruptive failover consists of the following steps:

  1. Promote the ActiveDR pod on the target array.

  2. Connect the log and data volumes to the target systems.

  3. Mount them to the relevant SAP HANA volume locations.

A failback after a non-disruptive failover only requires that the pod be demoted on the target system. Replication will automatically resume from the source pod to the target.

To complete the non-disruptive failover and failback between two arrays and different SAP HANA host systems:

  1. In the Storage section on the production/primary array, click the Pods tab, and then observe the state of the Pod Replica Links in a specific pod's details, which will show as promoted.

    Figure 1. Displaying the state of the production/primary array pod
  2. In the Storage section on the target/disaster recovery array, click the Pods tab, and then observe the state of the Pod Replica Links, which will show as demoted.

    Figure 2. Displaying the state of the target/disaster recovery array pod
  3. When ready to perform the failover, navigate to the specific pod in Pods under Storage on the target/disaster recovery array, click the ellipsis, and then select Promote.

    Figure 3. Promoting the target/disaster recovery array pod
  4. In the dialogue box, click Promote.

    Figure 4. The dialogue box to confirm promotion
  5. When the pod has been promoted, it will have a status of promoted.

    Figure 5. The promoted pod on the target/disaster recovery array
  6. On the array to be failed over to connect the data and log volumes to the target systems. attach the pod's volumes to a specific host. This can be done on the Hosts tab for a specific host. (If not already connected during the initial implementation).

    Figure 6. Attaching the pod's volumes to a host
  7. Once complete, mount the data and log file systems on the HANA server (scale-up) and then start the instance. To learn more, read SAP HANA Host Failover with ActiveCluster and ActiveDR.

Once the secondary site is operational, monitor the status of the SAP HANA database to ensure there are no issues with data loss or integrity. Ensure that business applications can connect and remain operational with the secondary site online. If there are no issues, resume replication from the primary site by demoting the target array pod.

Resuming Replication to DR site
  1. Stop the running SAP HANA database at the DR site

    /usr/sap/hostctrl/exe/sapcontrol -nr <instance number> -function StopSystem HDB
  2. Unmount the SAP HANA volumes

    umount /hana/data; umount/hana/log
  3. In the secondary site's Everpure array user interface, navigate to the specific pod in Pods under the Storage tab and then select the POD used during the testing. Select the ellipsis next to the pod name, and then select Demote.

    Figure 7. Demoting the pod on the secondary array
  4. Check the status of the pod on the primary array, where it will show as replicating.

    Figure 8. Pod at the primary site's status showing as replicating

Unplanned Failover (Disaster Recovery Scenario)

In the event of an unplanned failover, the secondary site must be brought online.

  1. Navigate to the Protection tab in the disaster recovery array's Everpure user interface to view the status of all arrays. The status will show as unhealthy.

    Figure 9. Status showing unhealthy
  2. In the Storage section on the disaster recovery array, click the Pods tab, and then observe the state of the Pod Replica Links in a specific pod's details, which will show as demoted.

  3. Navigate to the specific pod in Pods under Storage on the disaster recovery array, click the ellipsis, and then select Promote.

    Figure 10. Promoting the pod on the disaster recovery array
  4. In the dialogue box that opens, click Promote.

    Figure 11. Confirming promotion of the pod
  5. When the pod has been promoted, it will have a status of promoted.

    Figure 12. The promoted pod on the disaster recovery array
  6. Connect the log and data volumes to the target system(s) (If not already done during the original implementation). Mount the file systems on the HANA server (scale-up).

    Figure 13. Attaching the pod's volumes to a host
  7. Start SAP HANA database

Failback after Disaster Recovery

After verifying that the primary FlashArray has fully recovered and is operational, storage replication can be brought back online to replicate data from the secondary FlashArray back to the primary FlashArray.

  1. Stop the primary site's SAP HANA system.

    /usr/sap/hostctrl/exe/sapcontrol -nr <instance number> -function StopSystem HDB
  2. Wait until the instances have stopped on each system by using the following command:

    /usr/sap/hostctrl/exe/sapcontrol -nr <instance number> -function GetProcessList
  3. Unmount the HANA data and log volumes on the HANA server

    umount <path to volume>
                         
  4. On the primary site's Everpure user interface, select Storage in the navigation pane, and then select the Pods tab.

  5. Click the ellipsis for the original source pod, and then select Demote.

    Figure 14. Demoting the primary site's pod
  6. From the Demote dialog, select the Skip Quiesce option and then click Demote. This will make the original source pod volumes read-only and will reverse the direction of replication.

    Figure 15. Confirming the pod's demotion
  7. Move the SAP instance back to the Primary Site.

  8. Monitor the Status field in the Pod Replica Links group until the Status field changes from "baselining" to "replicating."

  9. Stop the secondary site's SAP HANA system.

  10. Verify the HANA instance has halted.

  11. On the primary site's Everpure user interface, select Storage in the navigation pane, and then select the Pods tab.

  12. Navigate to the primary site's pod, click the ellipsis, and then select Promote.

    Figure 16. Promoting the primary site's pod
  13. From the Promote dialogue, select Promote. The primary site's pod is promoted and put into a read/write state.

    Figure 17. Confirming the pod's promotion

With the primary site's pod promoted and in a read/write state, the volumes can be attached to the primary site's SAP HANA database. The following steps highlight how to do this:

  1. If necessary, adjust the applications' database connection settings to point back to the primary SAP HANA system's IP address or hostname.

  2. Perform connectivity tests to confirm that applications can access the database without issues.

  3. Verify that business applications can connect to the SAP HANA database without issues.

  4. On the secondary site's Everpure user interface, select Storage in the navigation pane, and then select the Pods tab.

  5. Click the ellipsis for the original target pod, and then select Demote.

  6. From the Demote dialog, select the Quiesce option and then click Demote. This will make the original target pod volumes read-only and will reverse the direction of replication from the primary site to the secondary site.

    Figure 18. Confirming the pod's demotion

ActiveDR and SAP HANA System Replication

To use ActiveDR alongside SAP HANA system replication, the following must be in place:

  • The same SAP HANA version deployed on multiple sites with sites configured for failover

  • FlashArray configured at a site for storage replication

System replication is ideal for customers who need high availability for business operations and who want swift recovery from planned maintenance, faults, and disasters. Besides the standard setup, in which a primary system ships all the data to the secondary system, a multitier or a multitarget system replication can be configured, which replicates data changes to more than one failover system.

To create a stronger disaster recovery posture, ActiveDR can be used alongside system replication. The ActiveDR site can be configured to replicate any of the secondary sites configured for system replication, even in a multitarget system. Because the ActiveDR site will be using storage replication instead of system replication, the data backed up to the different sites is protected in a multi-layer disaster recovery strategy.

The ActiveDR deployment is flexible and can be utilized by administrators to replicate the primary SAP HANA system or any of the secondary sites as desired. In failover scenarios, administrators will have two options for recovery available as restore points: a high availability site in one region between the availability zones and another using ActiveDR that helps in recovering the system from catastrophic regional failures.

Figure 19. Flowchart showing the steps for implementing ActiveDR alongside system replication

To configure a site for ActiveDR alongside system replication, follow the steps in Deployment and Disaster Recovery Configuration to configure pods for replicating the SAP HANA sites.