What if you could use SAP HANA system replication beyond high availability and disaster recovery scenarios?
High availability and disaster recovery planning is foundational to good architectures and vital to supporting service level agreements (SLAs) defined by business requirements. Most organizations will have a business continuity plan in place. SAP HANA system replication provides a well prepared and preloaded secondary copy to support fast failover in the event of a failure at the primary or a planned event like regular maintenance. The ability to have a fast failover to a standby or immediate take-over to a secondary SAP HANA instance allows for client applications to resume work with little interruption.
SAP HANA system replication is the ability to copy and continuously synchronize a SAP HANA database to another SAP HANA instance. The secondary can be in the same data center or another data center. SAP HANA system replication (starting with SAP HANA 2.0 SPS 03) can replicate from the SAP HANA primary instance to multiple secondary targets. The locations for the secondary targets can be in the same or another or multiple data centers, across town and across the globe.
SAP HANA system replication is traditionally deployed to support high availability and disaster recovery plans and supports a fast take-over to a secondary SAP HANA instance in the event the primary in unavailable due to a planned or unplanned event.
New in SAP HANA 2.0 SPS 04, SAP HANA system replication’s multi-target replication ability supports read access on the secondary tier with the SAP HANA, active/active read-enabled option. Idle resources at the secondary tier put in place to support business continuity can be made productive for pure read operations without impacting SLAs.
This ability to support multiple locations with copies of production data available for pure reads opens new architectures to solve business requirements. Let’s walk through a couple of use cases to illustrate this.
Global Reporting with SAP HANA, active/active read-enabled option
Let’s look at a simple example. A global electronics manufacturer has operations in Asia, Europe, Africa, and the North America. The primary or leading SAP HANA instance in this scenario is in Europe. With SAP HANA system replication multi-target replication capability and SAP HANA, active/active read-enabled option, data centers in Asia, Africa and the North America could support secondary instances of SAP HANA, containing a copy of the primary’s data. And these instances would be read-accessible. Any changes at the primary would be replicated to the instances in secondary tier. Each of the targets in this example have a direct replication connection from the primary, as illustrated in Diagram 1.
Diagram 1: Global Reporting with SAP HANA, active/active read-enabled option
The primary or leading SAP HANA in Europe is available for reads and writes. The SAP HANA instances in the secondary tier are available for pure read access only. Read-only reporting, ad-hoc queries and new read applications can be off-loaded from the primary to the secondaries that were previously geared for disaster recovery purposes only. Off-loading read workloads increases available capacity at the primary, potentially improves performance by isolating competing workloads, and increases the ROI of the previously idle stand-by instances. The ability to use the stand-by instances in the secondary tier puts disaster recovery assets to productive use and supports regional reporting needs.
SAP HANA active/active read-enabled routing of implicit connections (hint-based routing) supports one SAP HANA instance and explicit connections can be used for every SAP HANA instance in the secondary tier.
Follow the Sun Architecture
Who says the primary SAP HANA instance must be in one location? We are accustomed to the idea of “follow the sun” with technical support teams on critical matters. Why not consider this for operational matters as well?
Let’s expand on the global reporting scenario and revisit the global electronics manufacturer with operations in Asia, Europe, Africa, and the North America. The primary role in the SAP HANA system replication topology can be reassigned to another SAP HANA instance with the replication connections re-established to the secondary tier instances (multi-targets). Instead of the primary or leading SAP HANA instance always in Europe, over a 24 hours period, the location of the leading SAP HANA instance could change based on business requirements.
Below, Diagram 2 shows that the leading SAP HANA instance is based in Asia. The SAP HANA instances in Europe, Africa and the North America are in the secondary tier and read accessible with the SAP HANA active/active read-enabled option.
Diagram 2 – Leading SAP HANA instance in Asia
As the work day comes to an end in Asia, role of “Primary” or “Leading” can be assigned to the Europe SAP HANA instance. In diagram 3, the leading SAP HANA instance would be in Europe, the SAP HANA instances in Asia, Africa, and the North America would be in the secondary tier and accessible for pure reads.
Diagram 3 – Leading SAP HANA instance in Germany
As you would expect for this example, as the work day comes to an end in Europe, the role of “Primary” or “Leading” can be assigned to the SAP HANA instance in the North America. In diagram 4, the leading SAP HANA instance would be in the North America, and the SAP HANA instances in Asia, Africa, and Europe would be in the secondary tier and accessible for pure reads.
Diagram 4 – Leading SAP HANA instance in the North America
Just like the scenario for global reporting, in the “Follow the Sun” architecture, implicit connections (hint-based routing) route to one SAP HANA instance while all SAP HANA instances in the secondary tier can support explicit connections.
More than likely and for performance reasons, the SAP HANA instance that will support hint-based statement routing would be co-located in the same or near-by data center for high availability.
The introduction of multi-target support for SAP HANA active/active read-enabled opens many new architecture possibilities. I look forward to hearing about yours!
For more information on implicit and explicit connections, see here.
Interested in how to set up SAP HANA system replication and the SAP HANA active/active read-enabled option? Check out this SAP HANA Technical Academy video.
To learn more about What’s New in SAP HANA 2.0 SPS 04: Mission Critical Data Center Operations please attend or watch the replay of the April 10th Webinar. It is part of the Live Virtual Expert series
More sessions to come after Sapphire.
Webinar recordings and presentation materials will be available in the SAP HANA iFG Community.
Click HERE if you are already a member of the SAP HANA iFG Community. If not, please register @ www.SAPHANACommunity.com
High availability and disaster recovery planning is foundational to good architectures and vital to supporting service level agreements (SLAs) defined by business requirements. Most organizations will have a business continuity plan in place. SAP HANA system replication provides a well prepared and preloaded secondary copy to support fast failover in the event of a failure at the primary or a planned event like regular maintenance. The ability to have a fast failover to a standby or immediate take-over to a secondary SAP HANA instance allows for client applications to resume work with little interruption.
SAP HANA system replication is the ability to copy and continuously synchronize a SAP HANA database to another SAP HANA instance. The secondary can be in the same data center or another data center. SAP HANA system replication (starting with SAP HANA 2.0 SPS 03) can replicate from the SAP HANA primary instance to multiple secondary targets. The locations for the secondary targets can be in the same or another or multiple data centers, across town and across the globe.
SAP HANA system replication is traditionally deployed to support high availability and disaster recovery plans and supports a fast take-over to a secondary SAP HANA instance in the event the primary in unavailable due to a planned or unplanned event.
New in SAP HANA 2.0 SPS 04, SAP HANA system replication’s multi-target replication ability supports read access on the secondary tier with the SAP HANA, active/active read-enabled option. Idle resources at the secondary tier put in place to support business continuity can be made productive for pure read operations without impacting SLAs.
This ability to support multiple locations with copies of production data available for pure reads opens new architectures to solve business requirements. Let’s walk through a couple of use cases to illustrate this.
Global Reporting with SAP HANA, active/active read-enabled option
Let’s look at a simple example. A global electronics manufacturer has operations in Asia, Europe, Africa, and the North America. The primary or leading SAP HANA instance in this scenario is in Europe. With SAP HANA system replication multi-target replication capability and SAP HANA, active/active read-enabled option, data centers in Asia, Africa and the North America could support secondary instances of SAP HANA, containing a copy of the primary’s data. And these instances would be read-accessible. Any changes at the primary would be replicated to the instances in secondary tier. Each of the targets in this example have a direct replication connection from the primary, as illustrated in Diagram 1.
Diagram 1: Global Reporting with SAP HANA, active/active read-enabled option
The primary or leading SAP HANA in Europe is available for reads and writes. The SAP HANA instances in the secondary tier are available for pure read access only. Read-only reporting, ad-hoc queries and new read applications can be off-loaded from the primary to the secondaries that were previously geared for disaster recovery purposes only. Off-loading read workloads increases available capacity at the primary, potentially improves performance by isolating competing workloads, and increases the ROI of the previously idle stand-by instances. The ability to use the stand-by instances in the secondary tier puts disaster recovery assets to productive use and supports regional reporting needs.
SAP HANA active/active read-enabled routing of implicit connections (hint-based routing) supports one SAP HANA instance and explicit connections can be used for every SAP HANA instance in the secondary tier.
Follow the Sun Architecture
Who says the primary SAP HANA instance must be in one location? We are accustomed to the idea of “follow the sun” with technical support teams on critical matters. Why not consider this for operational matters as well?
Let’s expand on the global reporting scenario and revisit the global electronics manufacturer with operations in Asia, Europe, Africa, and the North America. The primary role in the SAP HANA system replication topology can be reassigned to another SAP HANA instance with the replication connections re-established to the secondary tier instances (multi-targets). Instead of the primary or leading SAP HANA instance always in Europe, over a 24 hours period, the location of the leading SAP HANA instance could change based on business requirements.
Below, Diagram 2 shows that the leading SAP HANA instance is based in Asia. The SAP HANA instances in Europe, Africa and the North America are in the secondary tier and read accessible with the SAP HANA active/active read-enabled option.
Diagram 2 – Leading SAP HANA instance in Asia
As the work day comes to an end in Asia, role of “Primary” or “Leading” can be assigned to the Europe SAP HANA instance. In diagram 3, the leading SAP HANA instance would be in Europe, the SAP HANA instances in Asia, Africa, and the North America would be in the secondary tier and accessible for pure reads.
Diagram 3 – Leading SAP HANA instance in Germany
As you would expect for this example, as the work day comes to an end in Europe, the role of “Primary” or “Leading” can be assigned to the SAP HANA instance in the North America. In diagram 4, the leading SAP HANA instance would be in the North America, and the SAP HANA instances in Asia, Africa, and Europe would be in the secondary tier and accessible for pure reads.
Diagram 4 – Leading SAP HANA instance in the North America
Just like the scenario for global reporting, in the “Follow the Sun” architecture, implicit connections (hint-based routing) route to one SAP HANA instance while all SAP HANA instances in the secondary tier can support explicit connections.
More than likely and for performance reasons, the SAP HANA instance that will support hint-based statement routing would be co-located in the same or near-by data center for high availability.
The introduction of multi-target support for SAP HANA active/active read-enabled opens many new architecture possibilities. I look forward to hearing about yours!
For more information on implicit and explicit connections, see here.
Interested in how to set up SAP HANA system replication and the SAP HANA active/active read-enabled option? Check out this SAP HANA Technical Academy video.
To learn more about What’s New in SAP HANA 2.0 SPS 04: Mission Critical Data Center Operations please attend or watch the replay of the April 10th Webinar. It is part of the Live Virtual Expert series
- April 5th – What’s New in HANA 2.0 SPS04 Overview
- April 8th – What’s New in HANA 2.0 SPS04: Administration and Monitoring
- April 10th – What’s New in HANA 2.0 SPS04: Mission Critical Data Center Operations
- April 17th – What’s New in HANA 2.0 SPS04: HANA Data Tiering Options
More sessions to come after Sapphire.
Webinar recordings and presentation materials will be available in the SAP HANA iFG Community.
Click HERE if you are already a member of the SAP HANA iFG Community. If not, please register @ www.SAPHANACommunity.com
- SAP Managed Tags:
11 Comments
