HP Serviceguard Extension for SAP (SGeSAP) manual

identified as SPOFs in the system. Other SAP services can potentially be installed redundantly within additional Application Server instances, sometimes called Dialog Instances.

As its naming convention may suggest, DVEBMGS, there are more services available within the Central Instance than just those that cause the SPOFs. An undesirable result of this is, that a Central Instance is a complex software with a high resource demand. Shutdown and startup of Central Instances is slower and more error-prone than they could be. Starting with SAP Application Server 6.40 it is possible to isolate the SPOFs of the Central Instance in a separate Instance that is then called the ABAP System Central Service Instance, in short ASCS. The installer for SAP Application Server allows to install ASCS automatically. This installation procedure will then also create a standard Dialog Instance that is called DVEBMGS for compatibility reasons. This kind of DVEBMGS instance provides no Enqueue Service and no Message Service and is not a Central Instance anymore.

A package that uses the sgesap/sapinstance module can be set up to cluster the SCS and/or ASCS (or Central Instance) of a single SAP application.

The SGeSAP legacy ci package contains either a full DVEBMGS instance or a ASCS instance. The SGeSAP legacy jci packge contains a SCS instance. In any case, these packages provides failover capabilities to SAP Enqueue Services and SAP Message Services.

SAP application servers also require a database service, which usually defines the second software SPOF. SGeSAP bundles cluster capabilities for single-instance ORACLE RDBMS and SAP MAXDB RDBMS database services. The module sgesap/dbinstance (and similarly the legacy package type db) clusters any of these databases. The module unifies the configuration, so that database package administration for all database vendors is treated identically. sgesap/dbinstance can be used with any type of SAP application, independent of whether it is ABAP-based or JAVA-based or both. In case they are available, the module will take advantage of database tools that are shipped with certain SAP applications.

A SGeSAP legacy jdb package contains a database instance for SAP JAVA applications. A SGeSAP legacy db package contains a database instance for an ABAP application or a combined ABAP and JAVA application.

NOTE: It is not allowed to specify a single SGeSAP package with two database instances in it. An environment with db and jdb requires at least two packages to be defined.

If you are planning a simple three-tier SAP layout in a two node cluster, use the SGeSAP mutual failover model. This approach distinguishes two SGeSAP packages, one for the database SPOF and the other for the SAP SPOFs as defined above. In small and medium size environments, the database package gets combined with HA NFS server functionality to provide all filesystems that are required by the software in both packages. During normal operation, the two packages are running on different nodes of the cluster.

NOTE:

•Module-based SGeSAP database packages cannot be combined with a legacy based NFS toolkit to create a single package.

•The major advantage of this approach is, that the failed SAP package will never cause a costly failover of the underlying database since it is separated in a different package.

•It is not a requirement to do so, but it can help to reduce the complexity of a cluster setup, if SCS and ASCS are combined in a single package. Under these circumstances, it needs to be considered that the failure of one of the two instances will also cause failover for the other instance. This might be tolerable in those cases in which SAP replication instances are configured (see below).

The process of failover results in downtime that typically lasts a few minutes, depending on the work in progress when the failover takes place. A main portion of downtime is needed for the recovery of a database. The total recovery time of a failed database can not be predicted reliably.

By tuning the Serviceguard heartbeat on a dedicated heartbeat LAN, it is possible to achieve failover times in the range of about a minute or two for a ci package that contains a lightweight [A]SCS instance without database.

NOTE: sgesap/sapinstance packages can identify the state of a corresponding sgesap/dbinstance package in the same cluster without the requirement of explicitly configuring Serviceguard package

Mutual Failover Scenarios Using the Two Package Concept 13