SAP HANA contains a feature called System Replication: it replicates all data to a secondary SAP HANA system, and the data is then constantly pre-loaded into Memory on the secondary system to minimize recovery time objective (RTO). More information on SAP HANA System Replication see here.

While System Replication is running, the secondary system, which is configured identically to the primary, is on standby until a takeover takes place. The secondary server can normally not be used for anything else.

Cost-optimized.png

In this cost-optimized scenario, SAP lets you run, for example, a non-productive instance of SAP HANA Quality Assurance System (QAS) in parallel to the system replication of the production system on node 2. The replication does not go to memory (as in a performance optimized scenario). Instead it goes to disk and the memory is free for another SAP HANA database. In case of a takeover, the non-productive system needs to be stopped before the secondary production replica of this SAP HANA on node 2 is started from disk.

How the failover between 2 HANA instances in the cost-optimized scenario is automated leveraging SUSE HA technology is explained in this new Whitepaper.

More information about our best preactise guides can be found SAP on SUSE on on suse.com

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply