Universal Messaging 10.5 | Administration Guide | Universal Messaging Enterprise Manager | Cluster Administration | Case Study: Migrating Between Single-Node and Multi-Node Active/Active Cluster
 
Case Study: Migrating Between Single-Node and Multi-Node Active/Active Cluster
This case study examines the following scenarios:
*Migrating from a single node setup to a multi-node active/active cluster.
*Migrating from an active/active cluster to a single-node setup ("declustering").
Migrating from a single-node setup to a multi-node active/active setup is a procedure that requires various manual steps. A "live" migration from a single node to a cluster is not currently supported. The current migration procedure enables you to migrate all the non-cluster-wide resources to cluster-wide resources.
The steps outlined below describe behaviours of realms and their local stores (channels and queues) before and after clustering/ declustering.
Before you start, check through the description in the section Creating Clusters for general information about creating a cluster.
Preparation
1. Currently, migrating from a single-node setup to a multi-node active/active setup is a procedure that requires various manual steps. It is therefore recommended to have proper downtime for this cluster setup and not migrate from a LIVE node.
2. Stop all publishers, so that no new events arrive. Also ensure that all channels and queues are completely drained, i.e. that there are no pending events, by waiting until the subscribers consume all pending messages.
This step is needed as currently, Universal Messaging doesn't support live migration. By stopping publishers and consuming all events we are ensuring no event loss will be experienced. Our current migration allows the migration of all non-cluster wide resources into cluster-wide ones, and vice-versa, but does not take care of the system dynamics, such as transactions and in-flight events from a durable object. Durable subscriber objects will not be re-created after the migration, so client applications need to take care of this.
3. When all channels and queues are completely drained, stop all subscribers.
4. If you are working with a virtual machine (VM), create a snapshot of the existing virtual machine, in case you need to revert to this snapshot at a later stage.
5. Update the Universal Messaging license file with "clustering" capability (if applicable).
6. Ensure that the other Universal Messaging nodes that you will be working with in the clustered environment are at a software level that is identical with your existing node. If possible, update your existing node to the latest released fix level issued by Software AG, and ensure that the same fix level is installed on the other nodes.
Migrating from Single-Node to Multi-Node Active/Active Cluster
Here there are two possible scenarios:
*The cluster does not already exist, so you must create a new cluster containing your node and other nodes.
*The cluster exists already, so you will add your single node to the existing cluster.
Scenario 1: Create a new cluster and add your node to it
If the cluster does not already exist, then follow these steps to create the cluster and add the single node to the cluster:
1. Create a new cluster, as described in Creating Clusters.
2. Add your single node and the other required nodes to the cluster.
3. After you have specified all of the nodes to be added to the cluster, choose the option to convert local stores to cluster stores.
If you choose not to migrate the local stores, then they will not be available in the cluster and will continue to act as stand-alone local stores for their respective realms.
4. Verify successful migration by the following steps:
a. Ensure that all nodes joined the cluster, i.e. are in Master or Slave state.
b. Ensure that all connection factories are enabled with the new URL for the Universal Messaging realm cluster.
c. Ensure that JMS / webMethods Messaging triggers (durable subscribers) are enabled by selecting the "Cluster Wide" checkbox on the durable subscription in the Enterprise Manager. If this is not already the case, you will need to delete the non-clustered durable subscribers, then manually synchronize documents using the Software AG Designer.
d. Update the realm URL in all affected Universal Messaging clients (webMethods Integration Server, My webMethods Server, etc.) to point to the new Universal Messaging cluster URL. Enable Universal Messaging client connections (webMethods Integration Server, My webMethods Server, etc.) and enable publishers / subscribers.
e. Start the publishers and subscribers.
Scenario 2: Add your node to an existing cluster
If the cluster already exists, then follow these steps to add the single node to the cluster:
1. Add your realm from the list of available realms to the list of existing cluster members.
2. Ensure that all connection factories are extended with the Universal Messaging realm URL of the newly added node.
3. Update the realm URL in all affected Universal Messaging clients (webMethods Integration Server, My webMethods Server, etc.) to point to the new Universal Messaging cluster URL.
4. Start publishers and subscribers.
Declustering a Single Node from an Active/Active Cluster
Here there are two possible scenarios:
*Deleting the cluster and allowing the individual nodes to continue as non-clustered nodes;
*Removing a single node from a cluster, while allowing the cluster to continue operating with the other cluster nodes.
Scenario 1: Delete the cluster
Follow these steps to delete the cluster and allow the individual nodes to continue as non-clustered nodes:
1. Delete the cluster, as described in Deleting a Cluster.
You can choose whether you want to copy the cluster stores into local stores on the declustered nodes.
2. Ensure that all connection factories are enabled with the Universal Messaging realm URL.
3. Integration Server: Ensure that the "Cluster-Wide" settings for the JMS / webMethods Native Message triggers ( DS ) are disabled. Documents need to be synchronized from Software AG Designer so all durable objects are re-created. Ensure they have the "Cluster-Wide" option deselected.
4. Update the realm URL in the Universal Messaging clients (webMethods Integration Server, My webMethods Server, etc.) to point to the Universal Messaging realm URL.
5. Enable the Universal Messaging client connections.
6. Start the publishers and subscribers.
Scenario 2: Remove a single node from a cluster
Follow these steps to remove a single node from a cluster, while retaining the rest of the cluster:
1. Remove the realm from the list of cluster members, as described in Adding and Removing Cluster Members.
You can choose whether you want to copy the cluster stores into local stores on the declustered node.
2. Connection factories:
*For the declustered node: Modify all connection factories so that they refer to only the realm URL of the newly declustered node.
*For the remaining nodes in the cluster: Modify all connection factories so that the realm URL of the declustered node is removed.
3. Client URLs:
*For the declustered node: Update the realm URL in the Universal Messaging clients (webMethods Integration Server, My webMethods Server, etc.) by providing only the Universal Messaging URL of the newly declustered node.
*For the remaining nodes in the cluster: Update the realm URL in the Universal Messaging clients (webMethods Integration Server, My webMethods Server, etc.) by removing the Universal Messaging URL of the newly declustered node.
4. Start the publishers and subscribers.
Rollback strategy
For a rollback strategy if any severe issues occur during clustering/declustering that cannot be resolved, below are some options:
*Delete the cluster and migrate to local nodes.
*In the worst case, if there are still any potential issue with the local node after deleting the cluster, then roll back to the virtual machine snapshot.