Managing Serviceguard Extension for SAP Version B.05.10, December 2012

database runs. The changed volume group configuration has to be redistributed to all cluster nodes
afterwards via vgexport(1m) and vgimport(1m).
It is a good practice to keep a list of all directories that were identified in chapter “Designing
SGeSAP Cluster Scenarios” (page 8) to be common directories that are kept local on each node.
As a rule of thumb, files that get changed in these directories need to be manually copied to all
other cluster nodes afterwards. There might be exceptions. For example, /home/<SID>adm does
not need to be the same on all of the hosts. In clusters that do not use CFS, it is possible to locally
install additional Dialog Instances on hosts of the cluster, although it will not be part of any package.
SAP startup scripts in the home directory are only needed on this dedicated host. You do not need
to distribute them to other hosts.
If remote shell access is used, never delete the mutual .rhosts entries of <sid>adm on any of
the nodes. Never delete the secure shell setup in case it is specified for SGeSAP.
Entries in /etc/hosts, /etc/services, /etc/passwd or /etc/group should be kept
unified across all nodes.
If you use an ORACLE database, be aware that the listener configuration file of SQL*Net V2 is
kept in a local copy as /etc/listener.ora also by default.
Files in the following directories and all subdirectories are typically shared:
/usr/sap/<SID>/DVEBMGS<INR>
/export/usr/sap/trans (except for stand-alone J2EE)
/export/sapmnt/<SID>
/oracle/<SID> or /export/sapdb
Chapter “Designing SGeSAP Cluster Scenarios” (page 8) can be referenced for a full list. These
directories are only available on a host if the package they belong to is running on it. They are
empty on all other nodes. Serviceguard switches the directory content to a node with the package.
All directories below /export have an equivalent directory whose fully qualified path comes
without this prefix. These directories are managed by the automounter. NFS file systems get mounted
automatically as needed. Servers outside of the cluster that have External Dialog Instances installed
are set up in a similar way. Refer to /etc/auto.direct for a full list of automounter file systems
of SGeSAP.
It enhances the security of the installation if the directories below /export are exported without
root permissions. The root user cannot modify these directories or their contents. With standard
permissions set, the root user cannot even see the files. If changes need to be done as root, the
equivalent directory below /export on the host the package runs on can be used as access point.
If the system is badly configured, it might be possible that the system hangs if a logon is attempted
as <sid>adm user. The reason for this is, that /usr/sap/<SID>/SYS/exe is part of the path
of <sid>adm. Without local binaries, this directory links to /sapmnt/<SID>, which is handled
by the automounter. The automounter cannot contact the host belonging to the relocatable address
that is configured because the package is down—the system hangs. To avoid this, always keep
local copies of the executables.
NOTE: If the database package with HA NFS services is halted, you cannot log in as <sid>adm
unless you keep a local copy of the SAP binaries using sapcpe.
To allow proper troubleshooting, there is a verbose package startup log in the package directory.
It should be checked first in case of trouble. The level of information can be adjusted by changing
the parameter LOGLEVEL in the sap.config file. If problems with package startup remain, a
general debug mode can be activated by creating a file:
touch /var/adm/cmcluster/debug — debug mode for all modular SGeSAP package.
touch /var/adm/cmcluster/debug_<packagename> — debug mode for the SGeSAP
modules of package <packagename>.
touch /etc/cmcluster/debug — debug mode for all legacy SGeSAP packages.
24 SGeSAP Cluster Administration