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
Table 4.
HP 9000 systems with HP-UX 11i
v2UD2
HP Integrity systems with HP-UX 11i
v2UD2
PA 32-bit application Supported Supported with Aries
PA 64-bit application Supported Supported with Aries
Intel® Itanium® 32-bit application N/A Supported
Intel® Itanium® 64-bit application N/A Supported
Even though HP Integrity systems support all four types of applications at the same time, specific
applications will either be all 32-bit or all 64-bit. The mix is between PA-RISC and Intel® Itanium®
and not between 32-bit and 64-bit.
When preparing an application for a mixed HP 9000 / Integrity cluster with the ability to fail over
between nodes of a different architecture, the application executables must be available in a form that
runs on both architectures. Providing only Intel® Itanium® executables would not be sufficient, as
Table 4 shows. Two options are available:
• Native executables for both architectures are available for a specific version of the application—
either from an ISV or self-developed.
• The application is available as PA-RISC version only and runs natively on HP 9000 nodes and
through the Aries binary emulator on Integrity nodes.
Note
Although HP fully supports the use of the Aries emulator for running PA-RISC
executables on an HP Integrity system, some ISVs might require the use of
executables that have been compiled directly for a given architecture.
These ISVs will not support the use of a PA-RISC executable running with
the Aries emulator on an HP Integrity system.
Native PA-RISC and Intel® Itanium® executables
HP has been working with many ISVs and individual customers over the last couple of years to help
them transition their applications to Intel® Itanium®. As a result of this effort, many individual
applications and those of major ISVs are available as native Intel® Itanium® versions on HP Integrity
servers.
If a particular application is available natively for both architectures, HP recommends taking
advantage of the two sets of native executables and configuring the cluster in a way that the
appropriate set is used on each node. To do this, you can either:
• Store the applications executables locally on each node of the cluster and only have the application
data on shared volumes. In this way, you can ensure that PA-RISC executables reside on HP 9000
nodes and Intel® Itanium® executables reside on Integrity server nodes. Also, having one set of
executables locally available on each node increases the overall availability in the event one set is
inadvertently corrupted by human error. On the other hand, if there is more than just one server of
each architecture in the cluster, the versions of the executables must be kept in sync manually.
• Store both sets of executables, along with the applications data on shared volumes, and add logic
to the applications startup scripts for choosing the appropriate executable, depending on the system
on which it is started. Although this procedure might impose additional administration effort while
11