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

The SAP installer should now start. Follow the instructions of the JAVA Central Instance installation process.
JAVA dialog instances get installed in the same fashion.
Afterwards, the virtualized installation for SAP J2EE Engine 6.40 should have completed, but the cluster still
needs to be configured. The instances are now able to run on the installation host, provided the corresponding
Serviceguard packages got started up front. It is not yet possible to move instances to other nodes, monitor
the instances or trigger automated failovers. Do not shut down the Serviceguard packages while the instances
are running. It is possible to continue installing content for the SAP J2EE Engine, before the cluster conversion
as described in the sections below gets performed.
Generic SAP Installation
Netweaver 2004s introduced High Availability installation options. Similar options were used for Netweaver
2004SR1 JAVA-only installations. All SAP components that are based on pre-Netweaver 2004s technology
get installed in a standard fashion. No special case applies due to the fact that the system is going to be
clustered afterwards. The required file systems should already be set up as documented in Chapter 2 Planning
a File System Layout for SAP in a Serviceguard Cluster Environment to prevent avoidable conversion activities
in a later stage.
If the SAP application is not installed yet, consult the appropriate SAP Installation Guides and perform the
installation according to the guidance given there.
Creating a Standalone Enqueue Service and a Enqueue Replication Service
This section describes how a SAP ABAP Central Instance DVEBMGS<INSTNR>can be converted to use the
Enqueue Replication feature for seamless failover of the Enqueue Service. The whole section can be skipped
if Enqueue Replication is not going to be used for the ABAP stack. It can also be skipped in case Replicated
Enqueue is already installed. The manual conversion steps can be done for SAP applications that are based
on ABAP kernel 4.6D, 6.20, 6.40 or 7.0. These kernels are supported on Serviceguard Extension for SAP
on Linux with Replicated Enqueue. As SAP does not deliver installation routines that install Replicated Enqueue
configurations for these releases, a manual conversion becomes necessary.
If the SAP installation was done for Netweaver 2004 JAVA-only or Netweaver 2004s 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 ASCS instance was created during installation.
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 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.
Replicated Enqueue Conversion: RE010
Logon as root to the server on which the Central Instance DVEBMGS<INSTNR> was installed.
Create a new mountpoint:
SAP Preparation 57