Managing Serviceguard Extension for SAP Version B.05.10, September 2010

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, 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. Starting with SAP Application Server 6.40,
the SPOFs of the Central Instance can be isolated in a separate Instance that is then called the
ABAP System Central Service Instance (ASCS). The installer for SAP Application Server allows
to install ASCS automatically. This installation procedure also creates 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 package contains a SCS instance. In any case, these packages provide 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, SAP MAXDB
RDBMS, and IBM DB2 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.
Mutual Failover Scenarios Using the Two Package Concept 13