Managing Serviceguard Extension for SAP on Linux (IA64 Integrity and x86_64), April 2009

RUN_SCRIPT <SGCONF>/<SID>/ci.control.script
HALT_SCRIPT <SGCONF>/<SID>/ci.control.script
d01.config:
RUN_SCRIPT <SGCONF>/<SID>/d01.control.script
HALT_SCRIPT <SGCONF>/<SID>/d01.control.script
Optional Step: OS440
Serviceguard also allows the monitoring of resources and processes that belong to a Serviceguard package.
The terminology used to describe this capability is called a "Serviceguard monitoring service".
The "Serviceguard monitoring service" name is defined in the Serviceguard configuration file (xxx.config)
and the script to execute for monitoring a resource is specified in the Serviceguard control script
(xxx.control.script).
In the case of SGeSAP/LX several "Serviceguard monitoring service" scripts are available: sapms.mon,
sapdisp.mon, sapenq.mon and saplc.mon
monitors the SAP message serversapms.mon
monitors the SAP dialog instance processessapdisp.mon
monitors the SAP Standalone Enqueue Service and the Enqueue Replication Servicesapenq.mon
monitor the SAP liveCache instancesaplc.mon
Monitoring scripts periodically check the availability and responsiveness of SAP components. If the monitor
script recognizes a SAP component to be unavailable, Serviceguard will switch the package and try to restart
the package on a different cluster node.
The monitoring service name gets defined in the xxx.config file. The recommended naming for the
monitoring service is <pkgtype ><SID>mon. This is an example for the (ci) instance, SID C11 and the
ciC11.config file:
SERVICE_NAME ciC11mon
SERVICE_FAIL_FAST_ENABLED NO
SERVICE_HALT_TIMEOUT 300
NOTE: Only the Serviceguard "service" (or the "monitoring service" name: SERVICE_NAME) gets specified
in the Serviceguard configuration file (xxx.config). The script that gets executed for monitoring will be
added in the Serviceguard control script (xxx.control.script).
The monitor itself will be pause if a debug file gets created for the package: touch
${SGCONF}/<SID>/debug
The debug file can be used to allow manual SAP instance shutdowns and startups and testing without having
the SGeSAP/LX monitor switch the package to another cluster node should it detect the SAP instance is
down. If the debug file is removed the SGeSAP/LX monitor will restart its monitoring activities.
NOTE: The manual startup using common startsap/stopsap scripts may not work correctly with
Netweaver 2004s based Web Application Servers. In this case the instances need to started by directly
using the sapstart binary passing the start profile as a parameter. For example: sapstart
pf=/sapmnt/<SID>/profile/START_ <INAME><INR>_<RELOC_IP/hostname>
The service monitor will not be able to detect a stopsap command and will consider a manual instance
shutdown to be a failure. The package will then fail over the instance to another node. The existence of the
debug file can prevent that. If the debug file gets removed, the service monitor continues to run. Make sure
that the packaged SAP instance is already running when removing the debug file or an immediate failover
will occur. As long as the debug file exists locally, a package shutdown would not try to stop the SAP instance
or its database. A local restart of the package would only take care of the Serviceguard NFS portion. The
instance would not be started with the package and the monitor would be started in paused mode.
76 Step-by-Step Cluster Conversion