Universal Messaging 9.10 | Universal Messaging 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:
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 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, 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 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 an even number of realms across two Sites (such as Production and DR). Failover is automatic should the "Non-Prime" Site fail, and requires manual intervention only if the Prime Site fails.
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-2019 | 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.