Types of Disaster Tolerant Clusters

To protect against multiple points of failure, a cluster must be geographically dispersed: nodes can be put in different rooms, on different floors of a building, or even in separate buildings or separate cities. The distance between the nodes is dependent on the types of disaster from which you need protection, and on the technology used to replicate data.

Local Cluster

A local cluster has all nodes located in a single data center and is not disaster tolerant. Because most high-availability clusters are local clusters, this type is included in the discussion as a baseline for comparison with other cluster architectures.

Figure 1-3 Local Cluster

Campus Clusters

A campus cluster has alternate nodes located in different data centers. These data centers can be separate rooms in a building, adjacent buildings, or even buildings separated by some distance. The word "campus" implies that the organization housing the cluster owns or leases the land and buildings such that no outside permission is needed to dig trenches, lay cable, or reroute power circuits. Campus clusters are designed so that no single building failure will cause the cluster to fail.

Campus clusters are connected using a high speed cable that guarantees network access between the nodes as long as all guidelines for disaster tolerant architecture are followed. The distance between nodes in a campus cluster is limited by the data replication technology.

Figure 1-4 Campus Cluster

Architecture requirements for campus clusters usually consist of:

Redundant disks using data replication. An example of this is HP's MirrorDisk/UX, which replicates data to two disks of any type.




	NOTE: While it is possible to configure physical data replication through products such as HP's XP Series disk arrays with Continuous Access XP or Symmetrix EMC SRDF, it is still necessary to provide for high availability at the local level through RAID or mirroring.

Redundant network cables installed using different routes. This protects the cluster from a single accident severing both network cables at once.
Power for each data center supplied from different power circuits. Some may even want to lease redundant power from different substations. This protects the cluster from a single power failure due to shorts or accidents that cuts power to all nodes in the cluster.
A campus cluster with four nodes must use dual cluster locks to provide a tie-breaker in case heartbeat is lost among the nodes. As an alternative, the campus cluster can use arbitrators if it follows the same rules as the metropolitan cluster designs (described in Chapters 3 and 4). However, the conventional four-node campus cluster shown in Chapter 2 uses dual lock disks.

Campus clusters are implemented use standard MC/ServiceGuard with FibreChannel mass storage.

Metropolitan Cluster

A metropolitan cluster is a cluster that has alternate nodes located in different parts of a city or in adjacent cities. Putting nodes further apart increases the likelihood that alternate nodes will be available for failover in the event of a disaster. Metropolitan clusters are very similar to campus clusters with the exception that metropolitan clusters often require right-of-way from local governments or utilities to lay network and data replication cable. This can complicate the design and implementation.

Metropolitan clusters also require a different kind of tie-breaker system for ensuring that split-brain situations do not arise. Typically, metropolitan clusters use an arbitrator site containing additional cluster nodes instead of the cluster lock disk.

The architectural requirements are the same as for a campus cluster, with the additional constraint of the third data center. And as with a campus cluster, the distance separating the nodes in a metropolitan cluster is limited by the data replication and network technology available. Metropolitan cluster architecture is implemented through two HP products:

MetroCluster with Continuous Access XP (described in Chapter 3)
MetroCluster with EMC SRDF (described in Chapter 4)

Figure 1-5 Metropolitan Cluster

A key difference between campus and metropolitan clusters is the data replication technology used. The campus cluster uses FibreChannel and MirrorDisk/UX, which limits the distances between data centers. Metropolitan clusters use data replication based on the capabilities of the HP SureStore E Disk Array XP series or the EMC Symmetrix array, which allow greater distances.

Continental Cluster

A continental cluster provides alternate clusters that are separated by large distances so that wide area networking is used between them. Continental cluster architecture is implemented via the ContinentalClusters product, described fully in Chapter 5. The design is implemented with two distinct ServiceGuard clusters located in different geographic areas. In this architecture, each cluster maintains its own quorum, so an arbitrator data center is not used. ContinentalClusters is architected to use any WAN connection via a TCP/IP protocol; however, due to data replication needs, high speed connections such as T1 or T3/E3 leased lines or switched lines may be required.

Figure 1-6 Continental Cluster

The key issues concerning a WAN cluster are:

Inter-cluster connections for ContinentalClusters are TCP/IP based connections.
The physical connection is one or more leased lines managed by a common carrier. Common carriers cannot guarantee the same reliability that a dedicated physical cable can. The distance can introduce a time lag for data replication, which creates an issue with data currency. This could increase the cost by requiring higher speed WAN connections to improve data replication performance and reduce latency.
Tools such as Transaction Processing Monitors or database replication tools that work across a WAN are needed to make sure the data replication maintains data consistency.
Operational issues, such as working with different staff with different processes, and conducting failover rehearsals, are made more difficult the further apart the nodes in the cluster are.

Continental Cluster With Cascading Failover

Another way of setting up your continental cluster is the use of cascading failover, an option available for users of the EMC Symmetrix. Cascading failover means that applications are configured to fail over on nodes within two data centers in either cluster. They fail over to a cluster if the entire alternate cluster is down. For example, bi-directional failover allows a cluster to be both a recovery cluster and a primary cluster for different packages. Data replication also follows the cascading model. Data is replicated from the primary disk array to the secondary disk array in the MetroCluster, then data is replicated to the third disk array in the ServiceGuard recovery cluster.

A continental cluster with cascading failover uses four data centers distributed between a metropolitan cluster, which serves as a primary cluster, and a standard cluster, which serves as a recovery cluster. The configuration uses three EMC Symmetrix frames, two of which are part of the metropolitan cluster and the other attached to the recovery cluster.

The data centers are distributed as follows:

Primary Symmetrix—on the site that holds the primary copy of the data, located in the primary cluster.
Secondary Symmetrix—on the site that holds a remote mirror copy of the data, located in the primary cluster.
Arbitrator—a separate site that contains the arbitrator nodes, located in the primary cluster.
Recovery Symmetrix—on a site that holds a remote mirror copy of the data, located in the recovery cluster.

Figure 1-7 “Cascading Failover Data Center Distribution” illustrates data centers, clusters, nodes and Symmetrix frames ina cascading failover configuration. Refer to Chapter 8 for details on setting up data replication for this type of cluster.

Figure 1-7 Cascading Failover Data Center Distribution

Types of Disaster Tolerant Clusters

Technical documentation

» Table of Contents

» Glossary

» Index

Local Cluster

Campus Clusters

Metropolitan Cluster

Continental Cluster

Continental Cluster With Cascading Failover