Managing Serviceguard Extension for SAP Version B.05.10, December 2012

Configuration Restrictions
• 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.
• Module-based SGeSAP database packages cannot be combined with a legacy based NFS
toolkit to create a single 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).
• 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 dependencies. The information is for example used to
delay SAP instance package startups while the database is starting in a separate package,
but not yet ready to accept connections.
• Module-based SGeSAP packages cannot be combined with a legacy based NFS toolkit to
create a single package.
Mutual Failover Scenarios Using the Two Package Concept
Most SAP applications rely on two central software services that define the major software Single
Point of Failure (SPOF) for SAP environments: the SAP Enqueue Service and the SAP Message
Service. These services are traditionally combined and run as part of a unique SAP Instance that
is referred to as JAVA System Central Service Instance (SCS) for SAP JAVA applications or ABAP
System Central Service Instance (ASCS) for SAP ABAP applications. If an SAP application has both
JAVA and ABAP components, it is possible to have both—an SCS and an ASCS instance—for one
SAP application. In this case, both instances are SPOFs that require clustering.
In pure ABAP environments, the term Central Instance (ci) is still in use for a software entity that
combines further SAP application services with these SPOFs in a single instance. As any other SAP
instance, a Central Instance has an Instance Name. Traditionally it is called DVEBMGS. Each letter
represents a service that is delivered by the instance. The "E" and the "M" stand for the Enqueue
and Message Service that were 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, more services are available within the Central
Instance than just those that cause the SPOFs. An undesirable result is a Central Instance is a
complex software with a high resource demand. Shutdown and startup of Central Instances is
slower and more error-prone. Starting with SAP Application Server 6.40, the SPOFs of the Central
Instance can be isolated in a separate Instance called the ABAP System Central Service Instance
(ASCS). The installer for SAP Application Server allows ASCS to install automatically. This installation
procedure also creates a standard Dialog Instance called DVEBMGS for compatibility reasons.
This 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 package contains a SCS instance. These packages provide failover capabilities
to SAP Enqueue Services and SAP Message Services.
SAP application servers also require a database service that usually defines the second software
SPOF. SGeSAP bundles cluster capabilities for single-instance ORACLE RDBMS, SAP MaxDB
RDBMS, Sybase ASE RDBMS , and IBM DB2 database services. The module sgesap/dbinstance
10 Designing SGeSAP Cluster Scenarios