Managing Serviceguard Extension for SAP Version B.05.10, September 2010

To update (edit) a SGeSAP toolkit package configuration:
• From the View Window on the right hand side of the Serviceguard Manager Main page,
right click on a package icon to bring up the Operations Menu, then click Edit a Package
to bring up the first in a series of screens where you can make edits to package properties.
• A package can also be edited by clicking the Packages tab on the Serviceguard Manager
Main page to bring up the Packages screen, then click on the package you want to update
in the Package Name column to bring up the Package Properties screen. Click Edit This
Package in the upper left-hand corner of the Package Properties screen to bring up the first
in a series of screens where you can make edits to package properties.
Change Management
Serviceguard keeps information about the cluster configuration. It especially needs to know the
relocatable IP addresses and its subnets, your Volume Groups, the Logical Volumes and their
mountpoints. Check with your HP consultant for information about the way Serviceguard is
configured to suite your SAP system. If you change this configuration, you may have to change
and reapply the cluster configuration accordingly.
System Level Changes
SGeSAP provides some flexibility for hardware change management. If you have to maintain
the server on which an (A)SCS instance is running, this instance can temporarily be moved to
the host that runs its Replicated Enqueue without interrupting ongoing work. Some users might
experience a short delay in the response time for their ongoing transaction. No downtime is
required for the maintenance action.
If you add new hardware and SAP software needs access to it to work properly, make sure to
allow this access from any host of the cluster by appropriately planning the hardware connectivity.
E.g. it is possible to increase database disk space by adding a new shared LUN from a SAN device
as physical volume to the shared volume groups on the primary host on which a 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 2 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. E.g. /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 the root user and
<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 by default, too.
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 2 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.
Change Management 177