High Availability Explained – v1.1

There are numerous blogs about SAP running High Availability but none of them seem to focus on explaining how the basics work.

What are the Basics?
To explain this in simple terms we should start from a standard Standalone SAP system. A standard system has 3 basic components, each of them is critical for the system to work:

1. ASCS -> stands for ABAP SAP Central Service and it’s made of two parts, the Message Server and the Enqueue Server. The Message Server acts as communication channel between the application servers and handle the load distribution, the Enqueue Server controls the lock mechanism.

2. AS ->  Applications servers.  In the old days you had a Central instance which included the ASCS component, now the ASCS component has been removed and stands on its own, hence the first application server is called the PAS (Primary Application Server) and the ones after that are called AAS’s (Additional Application Servers) but in practice there is very little difference in between them.

3. Database -> The database is simply the database, your primary persistence and where you store your data.

Your traditional standalone system looks something like this:



So, what do you have to do to make your system highly available?… very simple, you have to give each of these components redundancy, covering all the single points of failure.

How do you achieve that?
Well, for the basic HA system you need at least two hosts (or nodes) to fit the required components, also ideally they will be located in separate data centers.

ASCS -> For the central services the recommended procedure is to use ERS (Enqueue replication server).  ASCS and ERS are installed on a shared disk in both hosts. Enqueue server will keep the lock table and ERS will keep a replicated copy of the lock table. A third party cluster software will provide an automatic failover mechanism for the ASCS instance. Now that the jibber-jabber is out of the way, what this means is that you have an ASCS and an ERS on each host so if at any moment an issue was to hit one of the nodes it would automatically failover to the other one keeping the system alive.

AS -> From the application server point of view the key is the numbers of them; at a basic level you need at least 2 application servers (PAS and AAS) using load balancing. If an issue hit one of the nodes all users connected to that node wold be kicked out but users will be able to logon again as the other AS will be up and running.

Database -> DB wise the norm is to have at least 2 databases where one is set to be the primary database, serving the system and the second one is a standby database which is supplied with a constant feed of logs from the primary database (this is called log shipping). On top of that you need a cluster software and an automated fail-over mechanism. This means that the cluster will be pointing to the primary database, if that node becomes unavailable the failover mechanism will kick in and the standby database will become the primary database effectively keeping the system running.

Once finished your new HA system should look something like this,



Now, What is a HA-Cluster?
At the most basic level a standard HA-Cluster in an Active-Passive configuration has 2 nodes, one is the primary node and the other one is the standby node. That simply means that the primary node is actively serving the system while the standby node is waiting to jump-in in case of a failure.

How does it work?
The cluster get set with a virtual IP (and hostname via DNS), these are the details to be used on the SAP profiles to call that particular component. The Cluster will assign that virtual IP to the active node and use a heartbeat monitor to confirm the availability of the components, if the primary node stops responding it will trigger the automatic failover mechanism that will call the standby node to step-up to become the primary node and will assign the virtual IP to it restoring the component availability. Once the failed node is fixed it will come online as a standby node.

A High Availability database will look something like this:

You can read more about this subject on High Availability – Frequently Asked Questions  by Eyal Katz

So? is that it?…
Yes, and no….

Yes, you have a HA system now!! … if there is a problem your system will be able to withstand the loss of one of its components or even an entire host.

No, you need to make sure everything that talks to this system is using load balancing. I cannot stress this enough, if the rest of the landscape and third parties are pointing at a fix host you will end up out of business… so, it’s very important to make sure that all the RFC’s, JCO’s and GUI’s are set to take full benefit of load balancing.

Hope this was a good overview of a basic HA system.


PS: This is a very basic case scenario, if you use ICM or the SAP Gateway you want to make sure you use an SAP webdispatcher and a standalone SAP Gateway to load balance those requests too.


PPS: HA differs drastically depending what OS and Database you run your landscape on, also there are several tools available for virtualised environments.