HP Serviceguard Extension for SAP (SGeSAP) manual SGeSAP Configuration

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 -fthis 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