User's Guide

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