HP Serviceguard Extension for SAP (SGeSAP) manual Splitting an Abap Central Instance

is not delivering installation routines that install Replicated Enqueue configurations for these releases, so the manual conversion steps become necessary. The 4.6D kernel does require some kernel executables of the 6.40 kernel to be added.

If the SAP installation was done for Netweaver 2004 Java-only, Netweaver 2004s, or a newer release as documented in section 'SAP Installation Considerations', only the second part 'Creation of Replication Instance' is required. The split of the Central Instance is then already effective and a [A]SCS instance was created during installation.

In this case it is sufficient to ensure that the [A]SCS startup profile does not use local Restart for the enqueue process and that the instance profile contains recommended replication parameter settings, eg:

enque/server/internal_replication = true enque/server/replication = true enque/server/threadcount = 1 enque/enrep/keepalive_count = 0 enque/process_location = local enque/table_size = 4096 ipc/shm_psize_34 = 0

Using Replicated Enqueue heavily changes the SAP instance landscape and increases the resource demand: Two additional SAP instances will be generated during the splitting procedure. There is a requirement for at least one additional unique SAP System ID. Unique means, that the ID is not in use by any other SAP instance of the cluster. There is also a requirement for one or two additional shared LUNs on the SAN and one or two additional virtual IP addresses for each subnet. The LUNs need to have the size that is required for a SAP Instance directory of the targeted kernel release.

Splitting an ABAP Central Instance

The SPOFs 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 SGeSAP. It is not even unusual to combine ASCS<INSTNR> andD<INSTNR_2> in a single SGeSAP 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.

Logon as root to the server on which the Central Instance DVEBMGS<INSTNR> was installed.

Replicated Enqueue Conversion: RE010

Create a new mountpoint:

su - <sid>adm

mkdir /usr/sap/<SID>/ASCS<INSTNR>

Replicated Enqueue Conversion: RE020

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.

Replicated Enqueue Conversion: RE030

Create instance subdirectories in the mounted logical volume.

SAP Preparation 39