Last but not least, I would like to quote here some documentation and white papers I found very helpful, I hope this paints a picture on how the ASCS/ERS instances work and how together with the cluster guarantee the ASCS instance availability and hence the SAP system uptime and the business continuity Ultimately once sapnode1 is back online the ERS instance will be started and will create a new lock replication table and the ASCS will be once more highly available Just to be clear for a small period of time both ASCS and ERS will be running in parallel, this is necessary as the replication table is kept on memory in the node ERS is running and only once the ASCS has completed reading and recreating the lock table the ERS node will be killed and will wait to be moved to the other node once is back online (this is part of the cluster colocation configuration) and will use the replication table to create a new table lock and resume operations, at the same time ERS will be shutdown (again also part of colocation rules) and will be shifted and brought back on sapnode1 once the host is back online Heartbeat monitor will trigger a cluster resource failover and the ASCS instance will be spun on sapnode2 together with ERS…. ERS will be brought back once sapnode2 is back online Well, the system will continue to operate as normal because ASCS availability was unaffected. Once your cluster config is completed and your ASCS/ERS instances (and rest of your system components) are operational your system will look as below, There is a number of other installation specific steps which are required but for the sake of keeping this generic I’ll leave those aside (I have included a few links at the bottom of this blog where you can check some of those)īelow is a representation of the basic requirements to kick the cluster basic configuration going including the inactive (grey) instance requirements Installation executable should point to that virtual hostįor this exercise the ASCS instance will be installed on sapnode1 using virtual hostname sapascs and the ERS instance will be installed in sapnode2 with virtual hostname sapersĪlso post installation you need to make sure you have created mount points for both ASCS and ERS in their counterpart hosts (/usr/sap//ASCSXX and /usr/sap//ERSXX) In order for the ASCS and ERS instances to be able to move from one node to the other they need to be installed on a shared filesystem and using virtual hostnames, why?… because together with the virtual IP will be added to the cluster resource group so they can all switch as one logical unit.Ī few high level tips for the installations, What is the basic architecture of a highly available central instance?Īt its leanest expression you need at least 2 nodes and a shared file system, for the purpose of this blog I’m just going to focus on the ASCS/ERS instances and the assumption is that the rest of the components are distributed on other nodesĪlso you need a cluster provider with an automatic failover mechanism, again I’m not going to focus on a particular provider and make this as generic as possible so it applies to most scenarios on its own it does not guarantee the availability of the system, it just does what is stated above, to deliver the high availability desired its capabilities need to be combined with the features of a cluster with an automatic failover mechanism, that way when (or if) the ASCS instance crashes, its brought back to a different host/node where it will use the replication table to create a new lock table so the system can resume operation well yeah… its not a magic box!… or is it?…. SAP Standard approach for making ASCS instance highly available is ERSĮRS stands for Enqueue replication server and its job is to keep an up to date replica of the lock table so if something tragic was to happen to the ASCS instance the state of the table locks is safeguarded I have read and written many blogs on SAP High Availability but people seem to struggle to understand the inner workings of the mechanism that makes the SAP central services instance highly available SAP ASCS High Availability using ERS explained
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |