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

The Standalone Enqueue Service has the ability to mirror its memory content to an Enqueue Replication
Service instance, which must be running on a remote node in the cluster. Both Standalone Enqueue Service
and Enqueue Replication Service are configured as Serviceguard packages. In case of a failure of the node
running the Standalone Enqueue Service, the package configured for the Standalone Enqueue Service
switches over to the node running the Enqueue Replication package. The Standalone Enqueue Service
reclaims the locking data stored by the Enqueue Replication Service in shared memory.
Clustering Stand-Alone J2EE Components
Some SAP applications just contain standalone J2EE components and do not come with an ABAP context.
An example is a SAP Enterprise Portal installation.
Beginning with SAP Web Application Server 6.40, these components can be treated a fashion similar to
ABAP installations.
A one-package setup for pure JAVA environments implements a (dbjciSID) package.
The (jci) package type is always dedicated to a JAVA System Central Service (SCS) Instance. It uses
standalone Enqueue and Message Server implementations similar to the ones delivered with ABAP kernels.
Highly Available (HA) NFS
Distributed SAP environments require the Network File System (NFS) to be highly available. Serviceguard
Extension for SAP on Linux packages can be combined with the Serviceguard NFS toolkit for Linux to achieve
this functionality. Typically, the Serviceguard Extension for SAP on Linux database package also provides
Highly Available NFS functionality.
Serviceguard Extension for SAP on Linux cluster hosts can usually act as Highly Available NFS servers and
as NFS clients that access these server's file systems. A cross-mounting approach is taken to achieve this.
The logical volumes that contain the NFS file systems are mounted below a specific directory, usually called
/export. They are accessed via a different path by the NFS clients that is linked to a location below
/import which is monitored by an automounter instance that provides the linkage between corresponding
/export and /import directories.
This setup allows NFS servers in a Serviceguard cluster to be failed over to NFS client hosts without getting
into trouble with busy mount points for the disk devices. It also avoids adding static mounts to Highly Available
NFS file systems, which also cause problems if the NFS server is not running during reboot time.
NOTE: Database data files need to be treated differently to avoid measurable performance impacts and
data inconsistencies.
Dialog Instance Clusters as Simple Tool for Adaptive Enterprises
Databases and Central Instances are Single Points of Failure. ABAP Dialog Instances can be installed in a
redundant fashion. In theory, this allows to avoid additional SPOFs in Dialog Instances. This doesn't mean
that it is impossible to configure the systems including SPOFs on Dialog Instances. A simple example for the
need of a SAP Application Server package is to protect dedicated batch servers against hardware failures.
SAP ABAP Dialog Instances use package type (d). This reflects the SAP abbreviation for Dialog Services.
Dialog Instance packages differ from other packages in that there might be several of them for one SAP
SID. Therefore the naming convention is slightly altered and the unique Instance Number of the Application
Server is added. A Dialog Instance package for Instance Number 01 of SAP System SID would be called
(d01<SID>).
As with any other SAP component, Dialog Instances can now freely be added to packages that also protect
other parts of the setup. It is suggested to only apply the Dialog Instance naming convention if there are no
mission-critical core components in the package. In other words, adding a Dialog Server to a (dbciSID)
package should not change the package name.
20 Understanding Serviceguard Extension for SAP on Linux