Migrating an MSCS configuration on Windows
Migrate queue managers in a Microsoft Cluster Service (MSCS) configuration one node at a time, following these instructions.
About this task
These steps are required for a rolling upgrade with a minimum amount of downtime. We must always upgrade an offline node with no online IBM MQ resources. In an Active/Passive configuration, if the node is Passive, we must ensure it cannot be switched to Active during the upgrade process.
The example, Migrating a four-node MSCS cluster from an earlier version of the product to the latest version, shows this procedure applied to a four-node cluster.
Procedure
- Modify the possible owners of the IBM MQ resource to encompass only the Active node or nodes. With no owners assigned to Passive nodes, the IBM MQ resource that is being migrated cannot be activated.
- Ensure that the group containing the IBM MQ resource is currently on one of the nodes defined as a possible owner. The group must include any applications connecting to the queue manager resource.
- Stop the cluster service on the node being migrated. The MSCS cache is cleared of any IBM MQ DLLs that have been registered.
- Migrate the selected node by following the standard instructions in Migrating a queue manager to a later version on Windows. Apply the required maintenance level.
- Start the cluster service on the selected node.
- On the next node to be migrated, ensure that the IBM MQ resources are offline.
- Remove this node from the list of possible owners. For clusters with more than two nodes, see the Additional considerations later in this topic.
- Move the group containing the IBM MQ resource to one of the possible owners and bring it online.
- Repeat steps 3-8 as necessary for any remaining nodes.
Migrating a four-node MSCS cluster from an earlier version of the product to the latest version
The example in Table 1 illustrates the steps involved in migrating a four-node MSCS cluster.In the example IBM MQ resources include queue managers, applications, and dependant MSCS resources, such as an IP address defined an as MSCS resource. In each step, the changes are italicized.
- Step 1
- Select the node to migrate and prepare it for upgrading from an earlier version of the product to the latest version.
- Select node 1 to be migrated and convert it into a Passive node with no running IBM MQ resources.
- Modify the possible owners of the group containing the IBM MQ resources, to encompass only the required online nodes. Failover does not attempt to switch IBM MQ resources to the node that is not a possible owner. It is safe to migrate that node.
- Move the group containing the IBM MQ resource to one of the nodes that is a possible owner, and bring it online.
- Stop the cluster service on the node being migrated. Stopping the service clears the MSCS cache of any IBM MQ libraries that have been registered for MSCS. The node goes offline.
- Step 2
- Migrate IBM MQ from an earlier version of the product to the latest version
- Step 3
- Start the cluster service on the selected node. The node becomes online, but it is not a possible owner, so no work is switched to it.
- Step 4
- Repeat steps 1 - 3 for node 2. Nodes 1 and 2 are now online, and you have migrated them to the latest version. They are still doing no work, as they are not possible owners of any of the IBM MQ resource groups.
- Step 5
- Migrate the cluster from running an earlier version of the product to the latest version. The number of migrated nodes is now greater or equal to the number of unmigrated nodes.
- Change the set of possible owners from 3,4 to 1,2.
- Move the IBM MQ resource groups from nodes 3 and 4 to nodes 1 and 2 and bring online.
- From this point onward, the list of possible owners must include migrated nodes only. The IBM MQ resource must never failover to a node running a back level version of the product.
Note: If we must revert IBM MQ to an earlier version, the IBM MQ resources must be removed from MSCS control, before performing an uninstallation of IBM MQ
- Step 6
- Migrate node 3 to the latest version.
- Follow steps 1 - 3 for node 3.
- Add node 3 to the list of possible owners.
- Move the QMC resource group back from node 1 to node 3 and bring online again.
- Step 7
- Repeat step 6 for node 4.
Steps 0 1 2 3 4 5 6 7 Node 1 State Online Offline Offline Online Online Online Online Online Version Earlier version Earlier version Latest version Latest version Latest version Latest version Latest version Latest version Groups QMA QMC, QMA QMA QMA Node 2 State Online Online Online Online Online Online Online Online Version Earlier version Earlier version Earlier version Earlier version Latest version Latest version Latest version Latest version Groups QMB QMB QMB QMB QMD, QMB QMD, QMB QMB Node 3 State Online Online Online Online Online Online Online Online Version Earlier version Earlier version Earlier version Earlier version Earlier version Earlier version Latest version Latest version Groups QMC QMC, QMA QMC, QMA QMC, QMA QMC, QMA QMC QMC Node 4 State Online Online Online Online Online Online Online Online Version Earlier version Earlier version Earlier version Earlier version Earlier version Earlier version Earlier version Latest version Groups QMD QMD QMD QMD QMD, QMB QMD Possible Owners 1,2,3,4 2,3,4 2,3,4 2,3,4 3,4 1,2 1,2,3 1,2,3,4 Task Update 1 Update 2 Transfer Update 3 Update 4
What to do next
Additional considerations in an MSCS setup with more than 2 nodes: A cluster might contain enough nodes for you to form a group of migrated queue managers and a group of unmigrated nodes. Switch to the migrated group when it contains half the number of queue managers. Before you have reached the half way point, the unmigrated group are possible owners. When you reach the half way point, switch the possible owners to the migrated group.
Related tasks
Related information