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

Step-by-Step Cluster Conversion
SAP Preparation
Chapter 3102
Splitting a Central Instance
The SPOFs (Single Point of Failure) of the DVEBMGS<INSTNR> instance
will be isolated in a new instance called ABAP System Central Services
Instance ASCS<INSTNR>. This instance will replace DVEBMGS<INSTNR> for
the (ci) package type. The remaining parts of the Central Instance can
then be configured as Dialog Instance D<INSTNR_2>. The ASCS Instance
should then only be started and stopped with the cluster package startup
and halt commands instead of using manual shell operations.
NOTE The Dialog Instance D<INSTNR_2> that results from the conversion also
represents one or more Single Points of Failure for many scenarios. In
these cases, D<INSTNR_2> should also be clustered with Serviceguard
Extension for SAP on Linux. It is not even unusual to combine
ASCS<INSTNR> and D<INSTNR_2> in a single Serviceguard Extension for
SAP on Linux package. It makes sense, even though the resulting
package contains the same components like a traditional package for
DVEBMGS<INSTNR> would. Seamless failover with Replicated Enqueue
can not be achieved without splitting up DVEBMGS<INSTNR> into two
instances.
RE010 Replicated Enqueue Conversion:
Logon as root to the server on which the Central Instance
DVEBMGS<INSTNR> was installed.
Create a new mountpoint:
su - <sid>adm
mkdir /usr/sap/<SID>/ASCS<INSTNR>
RE020 Replicated Enqueue Conversion:
A volume group needs to be created for the ASCS instance. The physical
device(s) should be created as LUN(s) on shared storage. Storage
connectivity is required from all nodes of the cluster that should run the
ASCS. For the volume group, one logical volume should get configured.
For the required size, refer to the capacity consumption of
/usr/sap/<SID>/DVEBMGS<INSTNR>. This should provide a conservative
upper limit that leaves reasonable headroom.
Mount the new logical volume to the mountpoint created in RE010.