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
Note
If Informix is used in a SAP environment with SGeSAP, it is still restricted to
fail-over between homogeneous nodes in a mixed cluster.
• SAP integrated with SGeSAP starting with version B.03.11
Please check with the application vendor if you are unsure about the status of your specific
application.
The examples in this section just give an overview of possible scenarios. The “How to implement a
mixed HP 9000 / Integrity Serviceguard cluster” section gives a more detailed overview of the steps
involved in implementing a mixed cluster.
Transition to Integrity with HP Superdome hybrid servers and mixed
clusters
This example shows a scenario in which individual nPars within HP Superdome servers are gradually
upgraded to the Integrity architecture. This example takes advantage of hybrid Superdome servers
and Oracle supporting heterogeneous fail-over of 9i/10g single instance database systems between
HP 9000 and Integrity cluster nodes.
Original 4 node HP 9000 nPar Supderdome cluster
In this example, the customer starts out with a 4 node cluster spanning 2 Superdome servers each
configured with 2 nPars. Each of these nodes hosts one application (Serviceguard package) during
normal operation and is sized generously enough to serve one additional application during a failure
scenario.
Two of the applications are available for HP9000 and Integrity servers and allow failover between
those two architectures:
• Oracle 9iR2 single instance database server (OraDB) on nPar 0 of Superdome 0, cluster node A
• NFS server (NFS) on node B on nPar 0 of Superdome 1, cluster node B
The other two applications don’t allow failover between nodes of different architecture and are
pl
anned to transition to Integrity servers at a later time:
• Legacy application 1 (App1) on nPar 1 of Superdome 0, cluster node C
• Legacy application 2 (App2) on npar 1 of Superdome 1, cluster node D
16