SAP High availability
High availability (HA) keeps an SAP system running despite the failure of individual components. Because SAP runs mission-critical operations, HA design, especially for the single points of failure, is essential in any production landscape.
SAP high availability protects the components whose loss stops everything: the database, through clustering or HANA System Replication, and the central services, through a clustered ASCS with an Enqueue Replication Server so locks survive failover. Application servers are already redundant behind load balancing. HA covers a failure within a site; disaster recovery covers losing the site.
- Watch out: Protecting app servers but not central services/database.
The single points of failure
In an SAP system, the components whose loss would stop everything are the database and the central services (message and enqueue services, ASCS). HA design focuses on making these redundant, since ordinary application-server instances are already horizontally redundant.
HA building blocks
- Clustered central services (ASCS/ERS): with an enqueue replication server so locks survive a failover.
- Database HA: clustering or replication (e.g. HANA System Replication).
- Multiple application servers: load-balanced, so one failing is tolerated.
- Redundant infrastructure: network, storage, power.
Enqueue replication
A subtlety unique to SAP: the enqueue (lock) service must fail over without losing locks, or in-flight transactions break. The Enqueue Replication Server (ERS) exists precisely to preserve locks across a central-services failover.
HA vs DR
HA handles component failure within a site (keeping the system up); disaster recovery handles loss of a whole site. A complete strategy needs both.
Common pitfalls
- Protecting app servers but not central services/database.
- Ignoring enqueue replication, losing locks on failover.
- Never testing failover until a real outage.