Configuration Rules for a Mixed HP 9000 / Integrity Serviceguard Cluster, March 2007
Table Of Contents
- Executive summary
- Version history
- Introduction
- Architectural rules and typical configurations
- Specific ISV information
- HP Superdome Hybrid Servers
- Typical configuration examples
- Transition to Integrity with HP Superdome hybrid servers and mixed clusters
- Adding one Integrity server to a two-node HP 9000 cluster
- Adding two HP Integrity servers to a two-node HP 9000 cluster
- Adding one critical application and two new Integrity nodes to existing four-node HP 9000 cluster
- Mixed clusters as transition aid from HP 9000 to Integrity in a multi-tier SAP environment
- HP 9000 to Integrity transition service utilizing HP Serviceguard cluster technology
- How to implement a mixed HP 9000 / Integrity HP Serviceguard cluster
- For more information
Database applications, for instance, often store their data in an architecture-independent manner for
which it does not matter on which architecture the data was generated. It will be usable by systems of
both architectures, PA-RISC and Intel® Itanium®.
Note
If not explicitly allowed and supported by the application vendor, the
application must be of the same type (32-bit or 64-bit) on both
architectures.
Homogeneous architecture for primary and failover node
A mixed HP Serviceguard cluster consists of both HP 9000 and Integrity nodes. The application,
however, could be running only on nodes of the same architecture. Some applications would run on
HP 9000 nodes, and different applications would run on HP Integrity nodes.
This condition could apply when, for business or technical reasons, the IT department is not ready to
deploy the application on both architectures. Additionally, the application might only be available as
an Intel® Itanium® executable and unable to run on HP 9000 nodes, or the application might exist as
a PA-RISC executable only and is either not supported or unable to run using the Aries emulator.
When running an application on homogeneous nodes only, no specific impact on the application or
on the support of it is expected.
The system administrator must configure the application package so that the applications can only run
on servers of the same platform.
Heterogeneous architecture for both primary and failover nodes
In this scenario, an application can run on nodes of both architectures in a mixed HP9000 / Integrity
cluster. The following constraints must be met to deploy a specific application in a mixed HP 9000 /
Integrity cluster and allow the application to fail over between nodes of different architectures:
• The application must be supported on both platforms, either by:
– Allowing the PA-RISC version of the application to run under the Aries emulator
– Providing native executables of the application for both architectures
• The application data must be compatible between HP 9000 and Integrity systems.
• HP provides only guidelines on how to configure applications in a mixed HP 9000 / Integrity
cluster. The ISV, or the customer in the case of a self-developed application, must actually approve
and support the configuration and allow failover between nodes of both architectures.
Specific ISV information
ISV-specific information with regard to mixed HP 9000 / Integrity clusters is currently available for
Oracle, SAP, Informix, and Sybase.
Oracle 9i/10g database server
Our understanding of the current Oracle position on mixed clusters is:
• Oracle supports migration of a database from HP 9000 to Integrity. The process includes backing
up the data on the HP 9000 system, restoring it on the Integrity system, and replacing the PA-RISC
binaries with Intel® Itanium® binaries.
• Oracle does support failing over a single instance database from HP 9000 to Integrity and from
Integrity to HP 9000 cluster nodes.
13