Introduction

The only significant difference between traditional clustering and campus clustering is that of distance. In campus clustering, the nodes of a cluster configuration can be up to several kilometers apart. This increases the likelihood that, in the case of a catastrophe such as a fire or earthquake, at least one server and its storage will survive.

Sun Cluster software currently supports exactly two nodes in a campus cluster configuration. However, both two- and three-room configurations are supported. A room can be thought of as a functionally independent hardware grouping (such as a node and its attendant storage, or a quorum device physically separated from any nodes) that has been separated from other rooms to increase the likelihood of failover and redundancy in case of accident or failure. The definition of a room therefore depends on the type of failures to be safeguarded against, as indicated by Table E-1.

Since all campus clusters are two-node clusters, each campus cluster must have a quorum disk. In two-room configurations, the quorum disk occupies the same room as one node (see "Example Two-Room Configuration"). In the case of a three-room configuration, the third room is used for the quorum disk ("Example Three-Room Configuration").

In a two-room configuration, the quorum disk should be located in the room that is more likely to survive an accident or catastrophe in the event that all cluster transport and disk connectivity is lost between rooms. (If only cluster transport is lost, the node sharing a room with the quorum disk will not necessarily be the room that reserves the quorum disk first.) For more information about quorum and quorum devices, see the Sun Cluster 3.0 12/01 Concepts.

The advantage to a three-room cluster is that, if any one of the three rooms is lost, automatic failover should typically be possible; whereas with a two-room cluster, if an entire room is lost, automatic failover is possible only if the surviving room contains the quorum disk. Only a three-room configuration guarantees system availability in the event of complete loss of an entire room (in the absence of any other failures).

As with non-campus configurations, data integrity will be compromised if there are other unrecovered I/O failures present when a room is destroyed, and the most up-to-date submirror was in the destroyed room.

In a campus cluster configuration, each of the two rooms used for nodes should have an equal number of shared disks. (In a two-room configuration, one room can have a separate quorum disk, so the two rooms need not have the same number of total disks.) Mirroring of the shared disks must always be done between rooms, rather than within rooms. In other words, both submirrors of a two-way mirror should never be in the same room. Mirroring is required for all campus cluster configurations, since RAID-5 alone does not lend itself to providing data redundancy across rooms.

If you use Solstice DiskSuite as your volume manager for shared device groups, pay special consideration to the distribution of replicas. In two-room configurations, all disksets should be configured with an additional replica in the room that houses the cluster quorum disk. Further, all Solstice DiskSuite device groups should be configured to use the node in the quorum disk room as their default primary room. In three-room configurations, the third room should not only house the quorum disk, but also include at least one extra disk configured into each of the disksets. Each diskset should include a third-room disk with an extra Solstice DiskSuite replica per diskset. Quorum disks can be used as metadb replicas in a metaset. Sun Cluster software does not currently support using the third room for data storage.

Sun Cluster software supports campus cluster configurations with rooms up to 10km apart.