HP Serviceguard Extension for SAP (SGeSAP) manual Upgrading SAP Software, Mixed Clusters

NOTE: If an instance is running on the standby node in normal operation and is stopped during the switchover

Only configure the update service on a node for Application Services running on the same node. As a result, the remaining servers, running on different nodes, are not affected by the outage of the update server. However, if the update server is configured to be responsible for application servers running on different nodes, any failure of the update server leads to subsequent outages at these nodes. Configure the update server on a clustered instance. Using local update servers should only be considered, if performance issues require it.

Upgrading SAP Software

Upgrading the version of the clustered SAP application does not necessarily require changes to SGeSAP. Usually SGeSAP detects the release of the application that is packaged automatically and treats it as appropriate. Make sure that you have a valid SGeSAP version in place by issuing the command:

On HP-UX 11i v2 or higher type:

swlist -l bundle T2357BA T2803BA

On HP-UX 11i type:

swlist -l bundle B7885BA T2803BA

Review the release notes of the SGeSAP version that gets reported and make sure that the target SAP application release is supported with the SGeSAP version that is already installed. If this is not the case, you should first get an update for the HP Serviceguard Extension for SAP installed and activated before continuing.

For a safe upgrade, SGeSAP can be switched off like is described in the section below.

Perform failover tests for all potential failure scenarios before putting the system in production.

If the setup has a mixed cluster of PA-RISC and IPF nodes, then he will have two sets of SAP central executables. In this case it is required to make sure that after successful upgrade on one platform, the second kernel directory gets upgraded manually. Both kernel directories need to have the same kernel revision and patch level.

Sometimes, upgrades come with additional configuration options. ASCS and Replicated Enqueue is possible beginning with ABAP kernel 4.6. SCS instances are introduced with J2EE engine 6.40. Refer to Chapter Three on how to configure packages for the additional components.

Mixed Clusters

Platform changes from HP 9000 hardware to Integrity systems are complex and require a significant investment. Changing the hardware for a multi-node cluster at once is an expensive undertaking. It is possible to perform this change step by step, replacing only one server at once with SGeSAP. During this transition phase, the cluster will technically have a mixed layout. However, from SAPs perspective it's still a homogeneous HP-UX system.

Most of SAPs business transactions are still written in ABAP, SAPs own programming language. All programs are stored as source code in the database and translated at the first time of execution if not already delivered in a translated form. At this first time of execution, the translated code is also stored in the database for next time use. This table is usually sized to hold the code for one platform. If you deploy application servers of different platforms within a single SAP system, this table needs to be sized appropriately to avoid unnecessary translations.

A mixed cluster containing both HP 9000 and Integrity HP-UX nodes must fulfill the following prerequisites:

•The system needs to be based on single-instance ORACLE database technology.

•All cluster nodes are installed with HP-UX 11i v2 (ud2) or higher.

•Serviceguard 11.16 or Serviceguard 11.17 is required

•The bundles of the HP Serviceguard Storage Management Suite are not allowed in SAP mixed clusters

•The cluster setup must follow the storage layout option 1 of chapter 2 (NFS-based)

140 SGeSAP Cluster Administration