Designing Disaster Tolerant High Availability Clusters, 10th Edition, March 2003 (B7660-90013)

Building a Continental Cluster
Designing a Disaster Tolerant Architecture for use with ContinentalClusters
Chapter 5 197
Both of these templates can be purchased separately with the product
MetroCluster/CA or MetroCluster/SRDF.
Details on configuring the special ContinentalClusters control scripts are
in Chapters 6 and 7. Some additional notes are provided below.
Highly Available Wide Area Networking
Disaster tolerant networking for ContinentalClusters is directly tied to
the data replication method. In addition to the reliability of the
redundant lines connecting the remote nodes, you also need to consider
what bandwidth you need to support the data replication method you
have chosen. A continental cluster that handles a high number of write
transactions per minute will not only require a highly available network,
but also one with a large amount of bandwidth. Details on highly
available networking can be found in Chapter 1, in the section titled
“Disaster Tolerant Architecture Guidelines.” White papers describing
specific implementations are also available from http://docs.hp.com.
Data Center Processes
ContinentalClusters provides the cmrecovercl command that fails over
all applications on the primary cluster that are protected by
ContinentalClusters. However, application failover also requires
well-defined processes for the two sites. These processes and procedures
should be written down and made available at both sites.
Some considerations for site management are as follows:
• Who notifies whom for the various events: configuration changes,
alerts, alarms?
• What communication methods should be used? Email? Phone?
Beeper? Multiple methods?
• Who has authority to perform what sort of configuration
modifications? Can the administrator at one site log in to the nodes
on the remote site? If so, what permissions would be set?
• How often is a practice failover done?
• Is there a documented test plan?
• What is the process for tracking changes made to the primary
cluster?