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

Two ABAP DI's and one ABAP SCS and one DB

Using the terminology of the previous example, the next configuration scenario consists of one ABAP Central

instance (= ABAP CI), one ABAP Dialog instance (ABAP DI), one ABAP SAP Central Services (ABAP SCS)

and one Database instance (=DB). So compared to the previous example one instance (ABAP SCS) will be

added. This instance is identified by the name "ASCS02". By adding the ABAP SCS, the naming conventions

of the SAP components in this scenario have changed. The original ABAP Central Instance (CI) became an

ABAP Dialog Instance as the Message Server and the Enqueue Server are now running within the ASCS

and not within the ABAP CI. To add an SAP ASCS instance to an existing configuration only one new file

system is required and that is /usr/sap/C11/ASCS02.

The 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/D01/

/usr/sap/C11/ASCS02/ <--- new

/usr/sap/C11/SYS/exe/run

/sapmnt/C11/

/home/C11/adm

DB Instance

The file systems for the database have not changed and are now not listed any more.

Two ABAP DI's, one ABAP SCS, one JAVA CI, one JAVA SCS, and one DB

Compared with the previous scenario JAVA components will now be added. The JAVA SCS instance is

identified by the name "SCS03", the JAVA CI instance is identified by JC04. The JAVA CI naming convention

remains since the SDM services are part of the JAVA CI as described above. So to add these instances to

an existing configuration two new file system are required: /usr/sap/C11/SCS03 and

/usr/sap/C11/JC04.