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

Serviceguard Extension for SAP on Linux Cluster Administration
Change Management
Chapter 5210
Change Management
Serviceguard has to store information about the cluster configuration. It
especially needs to know the relocatable IP addresses and its subnets,
storage volume groups, the Logical Volumes and their mountpoints.
System Level Changes
Serviceguard Extension for SAP on Linux provides some flexibility for
hardware change management. For example if you have to maintain the
cluster node on which an SAP SCS or SAP ASCS instance is running,
this instance can temporarily be moved to the cluster node 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 Two 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 .rhosts entries of the
root user and <sid>adm on any of the nodes. Or in the case of a secure
shell setup is being used instead of remote shell access do not delete this
setup either.