Managing Serviceguard Extension for SAP Version A.06.00 for Linux, December 2012

If you have more than one system, place /usr/sap/put on separate volume groups created on
shared drives. The directory must not be added to any package. This ensures that they are
independent from any SAP SAP Netweaver system and you can mount them on any host by hand
if needed.
All files ystems mounted below /export are part of NFS cross-mounting via the automount
programm. The automount program uses virtual IP addresses to access the NFS directories via the
path that comes without the /export prefix. Three components must be configured for NFS toolkit:
• The NFS server consisting of a virtual hostname, storage volumes and mount points in the
/export directory
• The NFS server export table consisting of a list of NFS exported file systems, export options
and NFS client access control. Note: The specification of the fsid export option is key as it
ensures that the device minor number is retained during the failover to an adoptive node.
• The automount configuration on each adoptive node, consisting of a list of NFS client mount
points
This ensures that the directories are quickly available after a switchover. The cross-mounting allows
coexistence of NFS server and NFS client processes on nodes within the cluster.
Special attention needs to be given to the diagnostic agent (DA) instance directory if a related
dialog instance (both using the same virtual hostname) is planned to be clustered. Such DA instances
need to move with the related dialog instances. Therefore, their instance directory has to be part
of the package. It is recommended that the DA instance filesystem resides on the volume group of
the dialog instance (not on a volume group common to all DA instances).
However, such a setup does not care for the SYS directory of the DA SID. The DA installation does
not create links underneath SYS as the standard Netweaver installation does, but just creates this
directory into the local filesystem. To keep a central and consistent copy of this SYS directory within
the cluster, it is recommend to create a similar setup manually (SYS containing links into /sapmnt
and /sapmnt itself mounted to an exported directory) for the diagnostic agents. For more details
on preparation steps, see Chapter 5, “Clustering SAP using SGeSAP packages” (page 42). If each
cluster node has local dialog instances installed and therefore the DA SYS directory on each node,
that /sapmnt approach won’t be necessary.
Option 2: SGeSAP NFS idle standby cluster
This option has a simple setup, but is limited in flexibility. It is recommended to follow option 1 for
most of the cases. A cluster can be configured using option 2, if it fulfills all of the following
prerequisites:
• Only one SGeSAP package is configured in the cluster. Underlying database technology is
a single-instance Oracle RDBMS. The package combines failover services for the database
and all required NFS services and SAP central components (ABAP CI, SCS, ASCS). Application
Server Instances are not installed on cluster nodes. Replicated Enqueue is not used.
• Additional SAP software is not installed on the cluster nodes.
The use of a NFS toolkit service can be configured to export file systems to external Application
Servers that manually mount them. A dedicated NFS package is not possible. Dedicated NFS
requires option 1.
Common directories that are kept local
For information on common directories that are kept local, see Table 4 (page 31)
Local database client software needs to be stored locally on each node. Details can be found in
the database sections below.
Part of the content of the local group of directories must be synchronized manually between all the
nodes in the cluster.
34 SAP cluster storage layout planning