The Sun Cluster Geographic Edition software enables a group of clusters to be managed and viewed as a single, large system. This chapter presents a high-level overview of the Sun Cluster Geographic Edition architecture, which you can use in preparation for installing, configuring, and administering Sun Cluster Geographic Edition software.
This chapter contains the following topics:
The Sun Cluster Geographic Edition software provides tools for managing geographically separated clusters. The Sun Cluster Geographic Edition product also provides highly available services within a cluster by utilizing Sun Cluster resource management features.
The following software components form a Sun Cluster Geographic Edition cluster:
SolarisTM 9 or 10 software
Sun Cluster software
Sun Cluster Geographic Edition software
Application Data Service Agents
Data replication software
Either Solaris Volume Manager or Veritas Volume Manager
The following figure illustrates how components of the Sun Cluster Geographic Edition software interrelate.
You can install and remove the Sun Cluster Geographic Edition software independently of the underlying Sun Cluster installation. The installation and the uninstallation processes do not require an additional node reboot or cluster downtime.
The Sun Cluster hardware configuration is the basis for a Sun Cluster Geographic Edition cluster.
The following additional hardware components form a Sun Cluster Geographic Edition cluster:
Sun Cluster hardware installations, with attached data storage
Internet connections for inter-cluster management communication between the Sun Cluster installations
Internet connections for inter-cluster heartbeats
Connections for data replication
Connections for custom heartbeats
The Sun Cluster Geographic Edition hardware environment supports the following topologies:
N+1, where multiple clusters that are located at multiple sites are communicating with a single backup cluster
Cluster pair, where both clusters are online and providing services
Figure 3–3 illustrates a high-level view of the Sun Cluster Geographic Edition hardware architecture.
The Sun Cluster Geographic Edition software does not limit the distance between partner clusters. Partner clusters require data replication connections to support the protection groups that are hosted by the partnership. Partner clusters must be compatibly configured to support data replication between the clusters.
The Sun Cluster Geographic Edition software supports replication from a single-node cluster to a single-node cluster, from a multinode cluster to a single-node cluster, and from a multinode cluster to a multinode cluster.
While you can use a single-node cluster at both the primary and backup sites, a single-node cluster offers no internal redundancy. To ensure no single point of failure, you must have a minimum of two nodes in a cluster at the primary site. Use a single-node cluster at the secondary site as a cost effective backup solution if the secondary site is used only for backup purposes. Do not use single-node cluster to run mission critical applications.
Primary clusters and secondary clusters can have any configuration that is supported by the Sun Cluster product if the data replication characteristics of these clusters are compatible. The level of compatibility varies with each data replication product.
The following requirements determine the data replication connection:
The distance between the partner clusters
The amount of data that is being replicated
Data replication configuration parameters
The Sun Cluster Geographic Edition product enables you to balance between data consistency and the cost of the connection, where data consistency is the acceptable amount of data loss.
The following figure illustrates a data replication configuration from a two-node cluster to a single-node cluster.
The following figure illustrates a data replication configuration from a two-node cluster to a two-node cluster.
A partnership establishes communication and a heartbeat between clusters. One cluster can participate in several partnerships. A protection group establishes data replication between partner clusters. You can configure several protection groups for a partnership, with each protection group replicating different data between the partner clusters.
The following figure illustrates a geographically distributed topology that demonstrates intercluster relationships.
The Sun Cluster Geographic Edition software enables you to configure multiple partnerships for a cluster with heartbeats between partner clusters. For example, the Geneva-London-Rome-Berlin topology contains a central cluster in Geneva that forms three separate partnerships with clusters in London, Rome, and Berlin. The partnerships require two-way Internet connections between the following cluster pairs: London and Geneva, Rome and Geneva, and Berlin and Geneva. These partnerships enable the cluster in Geneva to detect failures of the clusters in London, Berlin, and Rome by exchanging heartbeats.
Each partnership has a protection group so that the primary clusters in London, Rome, and Berlin can replicate data to the cluster in Geneva as a secondary cluster.
The following figure illustrates a geographically distributed topology that demonstrates intercluster relationships.
The Paris-New York topology has two clusters that form a partnership with two protection groups. Each cluster is the primary cluster for one protection group, and the secondary cluster for the other protection group. The partnership requires a two-way Internet connection between the two clusters for intercluster management and heartbeats. The two clusters must have a data replication link to support data replication for two protection groups.
In the Geneva-London-Rome-Berlin topology, the cluster in Geneva could become the primary cluster for any of the three protection groups. However, the cluster in Geneva must have adequate provisioning to run all the services that are offered by the application resource groups.
For example, if the cluster in Rome is shut down for maintenance, the cluster in Geneva could be the new primary cluster by using a controlled switchover for the Rome-Geneva protection group. As the new primary cluster for the Rome-Geneva protection group, the cluster in Geneva would host the services that are provided by the application resource groups of the Rome-Geneva protection group. The cluster in Geneva would simultaneously serve as the secondary cluster for the clusters in London and Berlin.
Similarly, in the Paris-New York topology, either cluster could take over as the primary cluster to both protection groups if the partner cluster were unexpectedly lost.