Managing Serviceguard Extension for SAP Version B.05.10, December 2012

test_return 52
}
The SAP specific control file sapwas.cntl needs two arguments—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 a separate sapnfs package is used Serviceguard can only perform a clean SAP
instance package halt operation if the sapnfs package is still up and running or all SAP binaries
and the SAP profile directory have a local copy created with sapcpe. This also applies to
cmhaltcl -f operations. When creating and applying any SGeSAP packages, it increases the
tolerance of cmhaltcl –f command against the lack of local copies if the existing sapnfs
package is reapplied afterwards.
Later, if you perform a forceful shutdown of the entire cluster with cmhaltcl -f command, this
package is stopped as the last one. This ensures that global directories are available until all SAP
components in the cluster are completely shutdown.
Similarly, while halting the packages manually, the sapnfs package must be halted last. If new
packages are created later which rely on sapnfs, you must delete and reapply sapnfs package
after the package creation, to maintain its position in the shutdown order.
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
92 Step-by-Step Cluster Conversion