A traditional ActiveDR deployment involves the configuration of a replication link between two or more FlashArray systems at different sites to ensure seamless failover for disaster recovery scenarios. In this architecture, a SAP HANA instance is kept offline at the target site in standby for failover in the event of a disruption in the SAP HANA instance on the primary site. This configuration guarantees minimal downtime and fast recovery time objectives and recovery point objectives for the target system, ensuring business continuity during disruptions.
SAP HANA System Replication and ActiveDR
SAP HANA offers a built-in software replication solution known as HANA system replication. SAP HANA System replication is set up so that a secondary system is configured as an exact copy of the active primary system, with the same number of active hosts in each system. Unlike ActiveDR, this replication occurs at the database layer, not the storage layer. System replication replicates the logical state of the database on a configured (synchronous, asynchronous, etc.) basis.
SAP HANA system replication can be used alongside ActiveDR to create a comprehensive disaster recovery strategy by adding a third replication site. While system replication is running, the secondary system is configured identically to the primary system and is on standby until a failover takes place. ActiveDR can be used to replicate either the primary or secondary site at the storage level for an additional layer of protection.
In disaster scenarios, administrators will have two failover sites, one using SAP HANA system replication and another using storage replication, which allows them to prioritize the data most important to their current operations. This flexibility enables businesses to tailor their recovery strategies based on their current needs and the criticality of various business functions. In the event of a primary system failure, the secondary SAP HANA system can take over operations, but if the secondary site also encounters an issue, ActiveDR replication at a tertiary site provides an additional layer of protection.
This dual-layered approach improves resilience and ensures critical data remains accessible and secure while maintaining high availability and comprehensive disaster recovery capabilities.
For more information about SAP HANA system replication, see SAP HANA System Replication.
Considerations for Networking, Failover Logic, and Recovery Workflows
When designing an ActiveDR deployment for SAP HANA, it's important to consider restrictions and response workflows for various situations. This section describes three key areas to consider.
While ActiveDR functions at nearly any distance, making latency a minimal issue, it is important to consider bandwidth and network redundancy to ensure high availability. Data needs to be protected and available, and any bottlenecks, whether bandwidth or network failure-related, could impact the system. It's ideal to eliminate single points of failure via redundancy to minimize the risk of downtime.
Failover logic should prioritize recovery for the most critical site first. An effective failover strategy will ensure the system attempts recovery from the closest or least-impacted site before escalating to the next. If using SAP HANA system replication in addition to ActiveDR, automatic failover can be configured, but it could present issues with data inconsistencies or performance impacts. Administrators should consider establishing clear failover priorities to streamline the process during a disaster scenario.
It's critical to align the recovery point objectives and recovery time objectives with business needs. To do this, recovery workflows should include testing, validation, documentation, and automation. An effective failback process should be carefully planned and automated where possible with clear guidelines to prevent data inconsistencies and interruptions to business continuity. Creating a disaster recovery playbook eliminates questions and keeps everyone aligned in emergency situations.
Scale-up vs. Scale-out Deployment Types
SAP HANA offers two deployment architectures for scaling a system: scale-up and scale-out.. Scale-up means increasing the size of one physical machine by increasing the amount of RAM available for processing. Scale-out means combining multiple independent computers into one system to overcome the hardware limitations of a single physical server and to distribute the load between multiple servers.
ActiveDR integrates with these scaling methods to provide options for replication and data protection with minimal performance impact for an additional layer of security in disaster scenarios. However, ActiveDR works differently depending on the scaling configuration:
-
In scale-up architectures, ActiveDR replicates both the data and log volumes from a single host to a secondary site.
-
In scale-out architectures, ActiveDR replicates the data and log volumes for all worker hosts that are part of the SAP HANA scale-out deployment.
Test and Development Workflows Using ActiveDR
For testing, development and quality assurance cases, ActiveDR offers unique functionality ideal for teams consistently testing application workflows.
Secondary testing environments can easily be enabled without impacting primary site operations. To do this, administrators might temporarily suspend replication and spin up a secondary testing environment for a variety of use cases including workload validation, development, and software testing. This doesn't incur additional infrastructure costs, making it ideal for organizations with robust testing, development, and quality assurance workflows.
Once testing is completed, administrators can resume replication from a specific point of suspension, ensuring no impact to the primary site's operations or business continuity.