Managing Serviceguard Extension for SAP on Linux (IA64 Integrity and x86_64), February 2008

Step-by-Step Cluster Conversion
SAP Preparation
Chapter 388
Specify NODE_NAME entries for all hosts on which the package should be
able to run.
Specify the created control scripts that were created earlier on as run
and halt scripts:
RUN_SCRIPT $SGCONF/<SID>/<pkg_name>.control.script
HALT_SCRIPT $SGCONF/<SID>/<pkg_name>.control.script
Specify subnets to be monitored in the SUBNET section.
In the ${SGCONF}/<SID>/<pkg_name>.control.script file(s), 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. Edit the array and create at least one
virtual IP:
IP[0]=xxx.xxx.xxx.xxx
Distribute the edited package templates to all cluster nodes with a
remote command such as ftp, rcp or cmcp.
Only if the SAP components are meant to be able to run on different
nodes, several packages have to be created using different virtual IPs.
NW04S440 Preparation Step:
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. Basically all the required file systems for
this package get mounted, the virtual IP address is enabled and the SAP
instance now can be started or stopped manually.
touch ${SGCONF}/<SID>/debug
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.