Managing Serviceguard Extension for SAP on Linux (IA64 Integrity and x86_64), April 2009

be restarted triggered by a failover. A sample configuration in Figure 1-5 shows node1 with a failure, which
causes the package containing the database and central instance to fail over to node2. A Quality Assurance
System and additional Dialog Instances get shut down, before the database and Central Instance are
restarted.
NOTE: A J2EE Engine might also be part of the Central Instance. The JAVA instance will then automatically
be moved with the package.
Some Web Application Server installations automatically install more than just a Central Instance at a time.
E.g. a SAP Exchange Infrastructure 3.0 installation creates a DVEBMGS instance as well as a System Central
Service (SCS) instance using different Instance Numbers. This SCS instance is technically identical with an
ASCS instance, but it delivers its services to the J2EE Engines instead of the ABAP Engines of the Web
Application Server.
NOTE: JAVA SCS Instances are clustered with the package type (jci), ABAP SCS instances are clustered
with the package type (ci). The naming reflects that the SCS Instance delivers the critical Central Instance
Services for the JAVA portion of the Web Application Server.
A one-package installation for the SAP Exchange Infrastructure would need to include three mission-critical
components: the database, the Central Instance for ABAP and the SCS Instance for JAVA. The package
would now be called (dbcijciSID). It is allowed to create (cijciSID) packages that just fail over SAP
software excluding the database which might be secured with different means. It is also possible to split a
DVEBMGS instance into an ASCS and a Dialog Instance. This process is described later in this document.
As a result, a single SAP System may have a SCS and an ASCS Instance at the same time. SAP Web
Application Server 7.0 provides installation options that provide this combination of SCS and ASCS out of
the box.
About SAP Client/Server Architecture
Depending on the configuration of the overall SAP system, SAP can support either a two- or three-tier
client/server architecture. The number of tiers depend on how many physical machines are running the
software layers; Presentation, (SAP) Application and Database.
Table 1-1 About the Two and Three Tier Layers
DescriptionLayer
Consists of a front end, for users to connect to the SAP system.
Typically front end is a tool called SAPGUI or a web browser .
Presentation
Runs the typically CPU intensive applications components, such
as the SAP DVEBMGS, the Enqueue server , the Message server,
and the Dialog processes to name a few.
To increase processing power in a scaled-out approach, several
physical servers can be added to the SAP system, each running
parts of the Application Layer software components. In the case
of Dialog instances, multiple instances can be configured, running
with the same SAP SID, but with a different SAP instance numbers.
(SAP) Application
Manages all database transactions. There can only be one
database instance for each SAP system.
Database
16 Understanding Serviceguard Extension for SAP on Linux