VERITAS Cluster Server for SAP

VERITAS Cluster Server (also known as VCS) is a High-availability cluster software, for Unix, Linux and Microsoft Windows computer systems, created by VERITAS Software. It provides application cluster capabilities to systems running other applications, including databases, network file sharing, and electronic commerce websites.

High availability clusters (HAC) improve application availability by failing them over or switching them over in a group of systemsas opposed to High Performance Clusters, which improve application performance by running them on multiple systems simultaneously.

Most VERITAS Cluster Server implementations attempt to build availability into a cluster, eliminating single points of failure by making use of redundant components like multiple network cards, storage area networks in addition to the use of VCS.

Central Instance (CI):

The Central Instance is mostly used in classic R/3 configurations. The Central Instance contains the Enqueue and Message service, and therefore is a Single Point of Failure (SPOF) by design. (The need for a CI will completely go away in future SAP versions)

SAP Central Services Instance (SCS)

The SAP Central Services Instance contains the critical SAP Enqueue Service (responsible for maintaining the SAP transaction locks) and is a SPOF.

Enqueue Replication Instance (ERS, REP)

The Enqueue Replication Instance is a counterpart to the SAP Central Services Instance (SCS), and is necessary to implement the Enqueue / Enqueue Replication mechanism (highly recommended by SAP). Both Enqueue instances protect the SAP transaction locks by replicating them in a lossless synchronous fashion from the Enqueue to the Enqueue Replication instance.

Dialog (Application Server) Instances

The Dialog instance is responsible for the direct communication with the accessing client (SAPGUI or HTTP[S] connection via a standard web browser). It is in the middle tier in the SAP 3-Tier architecture between the presentation and database layer. It is not a SPOF, but is often included in VCS cluster configurations in order make use of the existing cluster hardware which is underutilized by just running small footprint SAP instances like SCS or ERS.

NFS (Network File System) Service

The NFS is necessary to share access to central file systems. The NFS service is a SPOF in a SAP architecture as access to a few central file systems is necessary for starting SAP instances on other cluster nodes or on application servers outside the cluster. Veritas Storage Foundation Cluster File System (CFS) can also be used to allow parallel access to data across all members of a cluster. Because the file system can be mounted on all nodes in a cluster, the time normally required to mount a file system in the event of a failover is eliminated. This can have a dramatic effect on improving failover times.

Database Instance

The database layer is the third tier of the SAP 3-Tier architecture. It is protected by the respective VCS Database Agent (i.e., an Oracle database would be clustered with its specific Oracle database agent.).

SAP HA solutions can be enhanced with disaster recovery (DR) functionality via the respective HA/DR offering. The difference to a standard Veritas Cluster Server DR configuration is located in the network address resolution area. SAP instances already require a forward (virtualhostA -> 10.1.1.1) and reverse (10.1.1.1 -> virtualhostA) name resolution of the virtual hostname in the startup phase. We addressed this with a VCS UNIX DNS Agent update (The VCS Windows LANMAN Agent contained this capability already).

In case of a Enqueue Server failure, VERITAS Cluster Server will failover the service group to the node running the corresponding Enqueue Replication Server. The replica table of the Enqueue lock information is used to establish a new (primary) Enqueue table containing all the previous entries.After the successful lock table takeover, the Enqueue Replication Server will fault on this node (initiated by SAP). VERITAS Cluster Server recognizes this failure and initiates a failover to a remaining node to create SAP Enqueue redundancy again. The Enqueue Replication Server will receive the complete Enqueue table from the Enqueue Server (SCS) and later Enqueue lock updates in a synchronous fashion. The same sequence will start all over again if the Enqueue Server fails again.