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

Use cmapplyconf(1m) to add the newly configured package(s) to the cluster.
NOTE: If you plan to use a sapnfs package as central NFS service, specify this package in the
last position of the cmapplyconf command. Later, if you force a shutdown of the entire cluster
with cmhaltcl -f, this package is the last one stopped. This prevents global directories from
disappearing before all SAP components in the cluster have completed their shutdown.
Verify that the setup works correctly to this point. All operating system resources should be able
to switch between the hosts. To do this, you can temporarily create debug files
/etc/cmcluster/<SID>/debug. This prevents SAP-specific package startup operations to
be executed for each node where this file gets created. SAP-specific package operations would
not succeed at this point of the integration. At this point of the integration, the package control
log of the shutdown procedures will contain error messages, because the existence of a debug
file does not prevent all of the instance shutdown attempts that come as part of the package
operation. For example, database shutdowns are never skipped by the package logic. This is to
prevent that careless testing causes unexpected database crashes. Such crashes might require
undesirable database recovery efforts. Do not forget to remove all debug files after the tests.
SGeSAP Configuration
This section deals with the configuration of the SAP specifics of the Serviceguard packages. In
chapter 1, various sample scenarios and design considerations that apply to common setups
were introduced. The mapping of this design to SGeSAP is done in a SAP specific configuration
file called sap.config. The file is structured into four main sections that serve different purposes:
Section 1: Specification of the Packaged SAP Components
Section 2: Configuration of Application Server Handling
Section 3: Optional Parameters and Customizable Functions
Section 4: Global Defaults
Specification of the Packaged SAP Components
For each type of potentially mission-critical SAP software components there exists a set of
configuration parameters in section 1 of the sap.config file. The information delivered here
will be specified exactly once and it will configure all packaged components of a <SID> within
the cluster. This is a central place of configuration, even if the intention is to divide the components
into several different packages. The mapping of components to packages will be done
automatically. There is one subsection per package type:
• db: a database utilized SAP ABAP or SAP add-in installations. Do not combine a database
with a liveCache in a single package.
• ci: a SAP Instance that has SPOF services defined. This might be a Central Instance with
integrated Enqueue and Message Service (DVEBMGS). It might also be a standalone Enqueue
and Message Service as part of a separate ABAP System Central Service instance (ASCS). A
Replicated Enqueue setup can be implemented by configuring at least one additional package
of type RE in combination with this CI.
• arep: an ASCS Replicated Enqueue instance.
• rep: an SCS Replicated Enqueue instance.
• d: one or more virtualized SAP ABAP Application Instances that are considered
mission-critical due to special use cases.
• jdb: a database exclusively utilized by J2EE engines that are not part of Application Server
Instances. Do not combine a database with a liveCache in a single package.
82 Step-by-Step Cluster Conversion