Universal Messaging 10.1 | Concepts | Performance, Scalability and Resilience | Clustered Server Concepts | Clusters: An Overview
 
Clusters: An Overview
A Universal Messaging Cluster is a collection of Universal Messaging Realms (servers) that contain common messaging resources such as channels/topics or queues. Each clustered resource exists in every Realm within the cluster. Whenever the state of a clustered resource changes, the state change is updated on all realms in the cluster.
Clustering also offers a convenient way to replicate content between servers and ultimately offers a way to split large numbers of clients over different servers in different physical locations.
Note: Clustering and Realm Federation are mutually exclusive. If a realm is a member of a cluster, you cannot use the realm for federation. Similarly, if a realm is part of a federation, the realm cannot be used for clustering.
Universal Messaging provides built-in support for clustering in the form of Universal Messaging Clusters and Universal Messaging Clusters with Sites. Universal Messaging clients can also use the same clustering functionality to communicate with individual, non-clustered Universal Messaging realms in Shared Storage (see Shared Storage Configurations) server configurations.
Universal Messaging clusters provide support for business contingency and disaster recovery natively or in conjunction with existing BCP enterprise solutions.
From a client perspective a cluster offers resilience and high availability. Universal Messaging clients automatically move from realm to realm in a cluster as required or when specific realms within the cluster become unavailable to the client for any reason. The state of all client operations is maintained so a client moving will resume whatever operation they were previously carrying out.
The following diagram represents a typical three-realm cluster distributed across three physical locations:
Tip: Since the underlying purpose of a cluster is to provide resilience and high availability, we advise against running all the servers in a cluster on a single physical or virtual machine in a production environment.
Clustered Resources
A Universal Messaging realm server is a container for a number of messaging resources that can be clustered:
*Universal Messaging Channels
*JMS Topics
*Universal Messaging Queues
*JMS Queues
*DataGroups
*Access Control Lists
*Resource Attributes including Type, Capacity, TTL
*Client Transactions on Universal Messaging Resources
Within the context of a cluster, a single instance of a channel, topic or queue can exist on every node within the cluster. When this is the case all attributes associated with the resource are also propagated amongst every realm within the cluster. The resource in question can be written to or read from any realm within the cluster.
The basic premise for a Universal Messaging cluster is that it provides a transparent entry point to a collection of realms that share the same resources and are, in effect, a mirror image of each other.
A Universal Messaging cluster achieves this by the implementation of some basic concepts described below:
* Masters & Slaves
*Quorum
*Master Election
*Message Passing
* Outages & Recovery
* Clustered Resources
Configuration Option 1: Universal Messaging Clusters
This approach offers the following features:
*Active/Active
*Transparent Client Failover
*Transparent Realm Failover
*Provides Load Balancing and Connection Scalability
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.
Configuration Option 2: Universal Messaging Clusters with Sites
This approach offers the following features:
*Active/Active
*Transparent Client Failover
*Semi-Transparent Realm Failover
*Provides Load Balancing and Connection Scalability
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. For details of clusters with sites, see the section Clusters with Sites.
Configuration Option 3: Shared Storage Configurations
This approach offers the following features:
*Active/Passive
*Transparent Client Failover
*Manual Realm Failover
*No Load Balancing Features
As an alternative to native Universal Messaging Clusters, Shared Storage (see Shared Storage Configurations) configurations 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.

Copyright © 2013-2017 | Software AG, Darmstadt, Germany and/or Software AG USA, Inc., Reston, VA, USA, and/or its subsidiaries and/or its affiliates and/or their licensors.
Innovation Release