Managing HP Serviceguard Extension for SAP for Linux, December 2013

tables TBTCO,TBTCS,.... In case a batch job is ready to run, the application server name will be
used to start it. Therefore, when using the relocatable name to build the Application Server name
for the instance, you do not need to change batch jobs that are tied to it after a switchover. This
is true even if the hostname, that is also stored in the above tables, differs.
Plan to use saplogon to application server groups instead of saptemu/sapgui to individual
application servers. When logging on to an application server group with two or more application
servers, the SAP user does not need a different login procedure if one of the application servers
of the group fails. Also, using login groups, provides workload balancing between application
servers, too.
Within the CCMS you can define operation modes for SAP instances. An operation mode defines
a resource configuration. It can be used to determine which instances are started and stopped and
how the individual services are allocated for each instance in the configuration. An instance
definition for a particular operation mode has the number and types of Work processes as well
as Start and Instance Profiles. When defining an instance for an operation mode, you need to
enter the hostname and the system number of the application server. By using relocatable names
to fill in the hostname field, the instance will be working under control of the CCMS after a failover
without a change.
NOTE: If an instance is running on the standby node in normal operation and is stopped during
the switchover, only configure the update service on a node for Application Services running on
the same node. As a result, the remaining servers, running on different nodes, are not affected by
the outage of the update server. However, if the update server is configured to be responsible for
application servers running on different nodes, any failure of the update server leads to subsequent
outages at these nodes. Configure the update server on a clustered instance. Using local update
servers must only be considered, if performance issues require it.
3.4 Ongoing verification of package failover capabilities
The SGeSAP functionality includes SAP specific verifications that test the node-local operating
environment configurations. These checks detect the incorrect local settings that might prevent a
successful SAP failover. The routines are executed as part of cmcheckconf(1) and
cmapplyconf(1) commands run on SGeSAP package configurations. The cmcheckconf -P
<pkg_config_file> command can be scheduled at regular intervals to verify the failover
capabilities of already running SGeSAP packages. These tests are executed on the current node
as well as on all reachable, configured failover nodes of the SGeSAP package. The resulting logs
will be merged.
A cmcheckconf(1) run command performs a complete test only if an SGeSAP package is up
and running. In this case all file systems are accessible, and allows a complete verification. If the
SGeSAP package is halted, only a subset of the checks can be performed.
NOTE: Successful execution of cmcheckconf(1) command does not guarantee a successful
failover. The currently available functionality cannot replace any regular failover test mechanism.
These checks complement existing tests and are useful to detect issues timely.
If required, the execution of SGeSAP cluster verification as part of the cmcheckconf(1) and
cmapplyconf(1) command routines can be deactivated. The existence of a file called ${SGRUN}/
debug_sapverify skips SGeSAP cluster verification for all packages on that cluster node. The
existence of a file ${SGRUN}/debug_sapverify_<packagename> skips verification only for
a single package on that cluster node. Generic and SGeSAP clustering specific check routines
which are not related to SAP requirements towards local operating environment configurations are
not deactivated and are executed as part of both cmcheckconf(1) and cmapplyconf(1)
commands.
The deploysappkgs(1) command is used during initial cluster creation. It is also called after
system level or SAP application configuration change operations to verify if any of the performed
3.4 Ongoing verification of package failover capabilities 31