Managing Serviceguard Extension for SAP on Linux (IA64 Integrity and x86_64), April 2009

the access to the storage devices on the first cluster node; activating the access to the storage devices on
the second node, mounting the file systems will cause the startup of the application to fail.
NOTE: In prior SGeSAP/LX documentation this category was called "Instance specific."
Configuration Scenarios
In the following sections the file systems used for several different SAP configuration scenarios will be
analyzed. Other combinations of scenarios are possible.
• One ABAP CI and one DB
• One ABAP CI, one ABAP DI, and one DB
• Two ABAP DI's and one ABAP SCS and one DB
• Two ABAP DI's, one ABAP SCS, one JAVA CI, one JAVA SCS, and one DB
• Two ABAP DI's, one ABAP SCS, one JAVA CI, one JAVA SCS, one JAVA REP, and one DB
One ABAP CI and one DB
The first configuration scenario is the classical SAP configuration with one SAP Central instance (CI) and
with one Database instance (DB). The name<SID> (SAP System ID) is contained in the name of some of the
paths as well as the type of SAP instance. The CI in this case can be identified by the following name
"DVEBMGS00". The <SID> used in these examples is C11.
For this scenario the typical SAP and database file system mount points to be analyzed in a cluster environment
are:
SAP Instance
/usr/sap/tmp/
/usr/sap/trans/
/usr/sap/C11/DVEBMGS00/
/usr/sap/C11/SYS/exe/run
/sapmnt/C11/
/home/c11adm
DB Instance
One of the following two databases could be used:
MaxDB:
/etc/opt/sdb
/sapdb/C11
/sapdb/data
/sapdb/programs
/var/spool/sql
Oracle:
$ORACLE_HOME
/oracle/client
/oracle/oraInventory
/oracle/stage
/oracle/C11/saparch
/oracle/C11/sapreorg
/oracle/C11/sapdata1
...
34 Planning a File System Layout for SAP in a Serviceguard/LX Cluster Environment