User's Guide
The SAP specific control file sapwas.cntl needs to arguments, which are the MODE (start/stop) and the SAP
System ID (SID). Don't omit the leading period sign in each line that calls sapwas.cntl.
Installation Step: LS500
Distribute the package setup to all failover nodes.
For example, you have to create package directories /etc/cmcluster<SID> on all backup nodes, copy
all integration files below /etc/cmcluster/<SID> from the primary host's package directory to the
backup host's package directory using rcp(1) or cmcp(1m) and similarly copy
/etc/cmcluster/sap.functions from the primary host to the same location on the backup hosts.
Installation Step: LS510
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 whole 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 on which 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.
Legacy Package Configuration 69