HP Serviceguard Extension for SAP (SGeSAP) Cmmakepkg -m sgesap/sapinstance -m ... /sap.config

SGeSAP functionality. It will be more convenient to do this once the SAP installation has taken place. The following steps are performed as root user to prepare the cluster for the SAP installation.

Preparation steps MS12xx should be followed to create module-based packages. Preparation steps LS12xx should be followed to create legacy packages.

Preparation Step: MS1200

Create a tentative Serviceguard package configuration for one or more SAP instances.

The first thing required is a SGeSAP configuration file that can be used to define the SAP Serviceguard failover package. It is usually created with the following command:

cmmakepkg -m sgesap/sapinstance [-m ...] >/sap.config

For a database package, the module sgesap/dbinstance can be specified.

NOTE: SGeSAP modules can be referred to by using SGeSAP legacy package types. Covered package

types include: ci, scs and ascs, rep and arep.

Specification examples for SGeSAP modules:

cmmakepkg -m sgesap/db -m sgesap/ci

creates a single package configuration file for database and SAP instance(s) (one package concept)

cmmakepkg -m sgesap/db

cmmakepkg -m sgesap/ci

separates database and SAP instances into two package configuration files (two package concept)

cmmakepkg -m sgesap/scs

cmmakepkg -m sgesap/ers

separates System Central Service and Enqueue Replication into two packages

cmmakepkg -m sgesap/scs -m sgesap/ers

would immediately issue an error message, because System Central Services and Enqueue Replication cannot share the same package.

Preparation Step: MS1210

The created configuration file needs to be edited.

Refer to the Managing Serviceguard user's guide for general information about the generic file content. A minimum configuration will do for the purpose of supporting the SAP installation. At least the following parameters should be edited: package_name, node_name, ip_address and monitored_subnet.

The package_name can be chosen freely. It is often a good approach to stick to the naming convention that combines the name of the SAP Instance type and the SAP System ID. Examples: dbciC11, scsC11. Specify node_name entries for all hosts on which the package should be able to run. There is a section that defines a virtual IP address array. All virtual IP addresses specified here will become associated to the SAP and database instances that are going to be installed. Specify at least one virtual IP. Specify subnets to be monitored in the monitored_subnet section.

The only SAP specific parameters that needs to be set is the planned SAP system id sap_system.

Preparation Step: MS1220

Create a debug file on the system on which the installation takes place.

The debug file allows manual SAP instance shutdown and startup operations during installation.

touch /var/adm/cmcluster/debug_<package_name>

It does not matter, if the system is meant to be run in a multi-tier fashion that separates the database from the ASCS instance by running them on different cluster nodes during normal operation. For convenience, all installation steps should be done on a single machine. Due to the virtualization, it is easy to separate the instances later on.

Preparation Step: MS1230

The configuration file needs to be applied and the packages started.

36 Step-by-Step Cluster Conversion