Active/Active cluster with three or more servers | This approach offers the following features: Active/Active Transparent Client Failover Transparent Realm Failover Universal Messaging clusters are our recommended solution for high availability and redundancy. State is replicated across all active realms. With 51% of realms required to form a functioning cluster (see the section
Quorum for an explanation of this percentage figure), this is an ideal configuration for fully automatic failover across a minimum of three realms. As a general rule of thumb, an active/active cluster can be considered in the following circumstances: You have a requirement for availability that cannot be satisfied otherwise. You understand and can implement the deployment recommendations for active/active. For more information on active/active clustering, refer to the section
Active/Active Clustering. |
Active/Active cluster with sites | This approach offers the following features: Active/Active Transparent Client Failover Semi-Transparent Realm Failover Universal Messaging Clusters with Sites provide most of the benefits of Universal Messaging Clusters but with less hardware and occasional manual intervention. This configuration is designed for two sites, such as Production and Disaster Recovery sites, containing an equal number of realms (for example, one realm on each site or two realms on each site). In such a configuration, if the communication between the sites is lost, neither site can achieve the quorum of 51% of reachable realms required for a functioning cluster. This situation can be resolved by defining one of the sites to be the so-called prime site. If the prime site contains exactly 50% of reachable realms in the cluster, the prime site is allowed to form a functioning cluster. Failover is automatic should the "non-prime" site fail, and requires manual intervention only if the prime site fails. Note: Switching the prime site MUST be a manual operation by an administrator who can confirm that the previous prime site is indeed down and not merely disconnected from the other sites. Attempts to automate this process raises the risk of "split brain" situations, in which loss of data is very likely. For more information on active/active clustering with sites, refer to the section
Active/Active Clustering with Sites. |
Active/Passive cluster with shared storage | This approach offers the following features: Active/Passive Transparent Client Failover Manual Realm Failover As an alternative to native Universal Messaging Clusters, Shared Storage configurations (see section "Shared Storage Configurations" in
About Active/Passive Clustering) can be deployed to provide disaster recovery options. This approach does not make use of Universal Messaging's built-in cluster features, but instead allows storage to be shared between multiple realms - of which only one is active at any one time. In general, we recommend the use of Universal Messaging Clusters or Universal Messaging Clusters with Sites in preference to shared storage configurations. An active/passive cluster should be considered in the following circumstances: You have an availability requirement that is already met by an active/passive Broker setup. You need higher performance than is possible with an active/active cluster. For more information on active/passive clustering, refer to the section
Active/Passive Clustering . |
Clustering Approach | Automatic client and server failover? | Vendor-specific cluster software required? | Shared storage required? | Minimum number of servers required? |
Active/Active cluster with three or more servers | Yes | No | No Uses standard (local) disk | 3 |
Active/Active cluster with sites Note: Administrator must manually set the "IsPrime" flag to the other site if the site with the "IsPrime" flag fails. | Automatic client failover. Semi-automatic server failover. | No | No Uses standard (local) disk | 2 |
Active/Passive cluster with shared storage | Yes | Yes | Yes | 2 |
Active/active | Active/passive | |
Advantages | Highest level of availability. Runs on commodity hardware with simple storage and no additional software. | Higher performance than A/A. Can re-use existing Broker A/P clustering infrastructure. |
Disadvantages | Cluster state replication will impact performance. Requires different hardware than Broker clusters. | Lower availability than A/A. Requires shared storage and potentially additional management software. |