Skip to content

Latest commit

 

History

History
41 lines (26 loc) · 4.44 KB

alternative_implementations.md

File metadata and controls

41 lines (26 loc) · 4.44 KB

Alternative Implementations

This section describes alternative implementations of SAP HANA System. These are not seen to be part of this Reference Architecture and are described only for informational purpose.

SAP HANA Host Auto-Failover (in single Availability Zone)

As discussed in AD1: High Availability Concept there are two options how to implement SAP HANA High Availability. This Reference Architecture is based on SAP HANA Synchronous System Replication option. This section is discussing SAP HANA Host Auto-Failover (HAF) option which is not used in this Reference Architecture.

SAP HANA Host Auto-Failover is native function of SAP HANA System and is in detail described in SAP HANA Host Auto-Failover Whitepaper.

SAP HANA Host Auto-Failover High Availability option is based on adding one or more dedicated standby hosts, that are passively waiting for failure of one or more of the active hosts. When such failure will happen, SAP HANA instance running on this standby host will takeover the data files and log files of failed host, thus replacing the failed host in its function.

This option is having both advantages and disadvantages when compared to SAP HANA Synchronous System Replication option.

Advantages:

  • Lower Costs - SAP HANA Host Auto-Failover is adding 1-3 extra hosts dedicated for High Availability (n+m approach), while SAP HANA System Replication needs same number of hosts on both sides (n+n approach)
  • Native Feature - SAP HANA Host Auto-Failover is native function of SAP HANA System - no external cluster software is required (therefore no additional knowledge is required)

Disadvantages:

  • Single Failure Protection - One standby host is able to protect only against failure of one active host, maximum three standby hosts can be deployed (with cost implications)
  • No Availability Zone Support - SAP HANA Host Auto-Failover architecture is unable to support multiple Availability Zones as all active hosts must be available simultaneously
  • High Takeover Times - Since standby host cannot predict which of active hosts will fail, no pre-loading was implemented - therefore, takeover times can easily take dozens of minutes for very large systems
  • No Support for Active/Active - since SAP HANA Host Auto-Failover does not have secondary system, thus there is no Active/Active capability (see Administration Guide: Active/Active (Read Enabled) for additional information)
  • No Support for Secondary Time Travel - since SAP HANA Host Auto-Failover does not have secondary system, thus there is no Secondary Time Travel capability (see Administration Guide: Secondary Time Travel for additional information)
  • No Support for Near Zero Downtime Upgrades - since SAP HANA Host Auto-Failover does not have secondary system, thus there is no Near Zero Downtime Upgrades capability (see Administration Guide: Use SAP HANA System Replication for Near Zero Downtime Upgrades
  • Not Supported by all IaaS Cloud Vendors - as explained in Administration Guide: Multiple-Host System Concepts SAP HANA Host Auto-Failover must to be deployed either using Shared File Systems (like NFS) or based on Storage Connector API, therefore, not all IaaS Cloud Vendors are supporting this High Availability option

Additional Information: