Universal Messaging 10.11 | Concepts | Clustered Server Concepts | Active/Active Clustering | Working with an Active/Active Cluster | Setting Up a High Availability (HA) Failover Cluster
 
Setting Up a High Availability (HA) Failover Cluster
Universal Messaging servers can be clustered together to form part of a single logical High Availability (HA) server.
Server Configuration
As an example, let us look at the steps involved in creating a simple 2-node cluster:
*Realm1 running on host1.mycompany.com
*Realm2 running on host2.mycompany.com
Firstly, use the Enterprise Manager tool to create a cluster (see Clusters: An Overview) with Realm1 and Realm2.
Next, create cluster channels and cluster queues, which ensures these objects exist in both realm servers.
Client Configuration
The next step is to set up your clients so that they are configured to swap between Realm1 and Realm2 in case of failures.
When you initialise a client session with a Universal Messaging server, you provide an array of RNAME URLs (see Communication Protocols and RNAMEs) as the argument to the nSessionAttributes object. This ensures that if you lose the connection to a particular Universal Messaging realm, the session will be automatically reconnected to the next realm in the RNAME array.
Using the configuration above where cluster channels exists on each realm, disconnected clients will automatically continue publishing/subscribing to the channel or queue on the newly connected realm.
For example, to use the two realms described above for failover you could use the following as your RNAME value using a comma separated list of individual RNAME URLs:

RNAME=nhp://host1.mycompany.com:80,nsp://host2.mycompany.com:9000
In this example, note the optional use of different protocols and ports in the specified RNAME URLs.
Failover/HA Scenarios
If all subscribers and publishers are configured in this way, then failover is provided in each of the following scenarios:
Scenario I: Subscriber loses connection to a Realm
If a subscriber is consuming data from the /sales channel on Realm1 and loses its connection it will automatically attempt to connect to its additional RNAME URLs (in this case nsp://host2.mycompany:9000) and resume consuming from where it left off.
Scenario II: Publisher loses connection to a Realm
If a publisher loses a connection to its Realm, it will automatically reconnect to the alternative realm and continue publishing there.
Scenario III: Publisher and Subscriber are connected to different Realms
As the above channels on Realm1 and Realm2 are cluster channels, events published to a channels named, say, /sales on either Realm will be passed to the /sales channel on the other realm. As long as subscribers are consuming from the /sales channel on one of the realms they will receive all events. Thus full guaranteed delivery is provided even if the publisher is publishing to Realm1 and subscribers are consuming from Realm2.
For more information on HA configuration options please contact the support team who will be happy to outline the pros and cons of the various HA configurations available.