Chapter 3 Sun Cluster Geographic Edition Architecture

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.

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.

Sun Cluster Geographic Edition Hardware Environment

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:

Data Replication Configuration

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.

Figure 3–2 Data Replication 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.

Figure 3–3 Data Replication From a Two-Node Cluster to a Two-Node
Cluster

Geographically Distributed Cluster Topology

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.

Figure 3–4 Geographically Distributed Topology

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.