SAP HANA supports disaster tolerance solutions on the basis of replication using the hard disk I/O subsystem. The disaster tolerance solution is based on replication mechanisms of the hard disk I/O subsystem. All the data that is written to the persistence (data volume and log volume) by the primary SAP HANA system is replicated to a second location (secondary). The SAP HANA instance of the second location is not active (cold standby).
The mirroring is offered at the storage system level. It is offered together with the appliance as a special offering by our partners. The hardware partner defines how this concept is finally realized with their operation possibilities.
Generally, write requests are replicated to the hard disk I/O subsystem synchronously. When there are long distances between locations, the latency times for writing the redo log may increase. This means that the synchronous replication can be used up to certain distances only. The maximum distance depends on the performance requirements of the SAP HANA system, the respective solution of the hardware partner, and the network configuration in the customer environment.
Some hardware partners support an asynchronous transfer of the write requests, while the consistency of the data and transactions within the SAP HANA database is ensured. During a takeover in this case, the changes that were made last may be lost. In some application scenarios, this loss can be accepted, but in other cases, it cannot.
For example, in an SAP HANA data mart solution, data is replicated from a source system to the SAP HANA database using SAP Landscape Transformation (SLT). If the SAP HANA database loses the data that was inserted last due to a failover, SLT does not transfer the missing data again. As a result, the data has to be reloaded to the tables of the SAP HANA database. In this environment, only a synchronous replication between the primary SAP HANA system and the secondary SAP HANA system is useful.
Solutions with asynchronous replication can be used for longer distances between the locations because the latency times are not significantly affected when writing the redo log.
You can expect an impact on performance for data changing operations as soon as the synchronous mirroring is activated. The impact depends heavily on various external factors like distance, connection between data centers, and so on. The synchronous writing of the log with the concluding COMMITs is crucial.
In an emergency situation, the primary data center is no longer available and you must initiate a process for the takeover. So far, many customers have requested a manual process here, but an automated process can also be implemented. This take-over process then ends the mirroring officially, mounts the disks to the already installed SAP HANA software and instances, and starts the secondary database side of the cluster. If the host names and instance names on both sides of the cluster are identical, no further steps with HDBRENAME are necessary.
Supported Storage Solutions
The hardware and storage solution vendors support SAP HANA Storage Replication, therefor no further certification of these storage replication solutions from SAP is required for use with SAP HANA.
All existing storage replication solution certifications for SAP HANA appliances continue their validity. These solutions are mentioned in SAP Note1755396 - Released disaster tolerance solutions for SAP HANA with disk replication.
All newer solutions are supported directly by corresponding hardware vendors or storage partners.
Using Secondary Servers for Non-Production Systems
With SAP HANA storage replication, you can use the servers on the secondary system for non-production SAP HANA systems.
Depending on the hardware solution, you can use the servers of the secondary system for other SAP HANA systems (such as test systems) until the takeover. During a takeover, other running systems are switched off, the replication between the locations is interrupted, the mount points of the replicate are made available for the secondary servers, and the SAP HANA system is started. When using servers of the secondary system for other SAP HANA systems, these do not use the hard disk storage system that contains the replicate of the primary system.
You can run a development or QA instance of the three-tier installation on this secondary cluster hardware, simply to use it until the takeover is executed. The take-over then stops these development or QA instances and mounts the production disks to the hosts. It requires an additional set of disks for the development and QA instance.
The same applies to asynchronous mirroring solutions for distant data centers (> 100 km). Some hardware partners have concepts available to offer this asynchronous storage replication. For more information, see SAP Note: 1755396.
