Migrating a queue manager in a high-availability configuration

Follow standard procedures to migrate a queue manager that is part of a high-availability configuration. (On platforms other than z/OS®.)

High-availability configurations of queue managers can increase the availability of IBM® MQ applications. If a queue manager, or server fails, it is restarted automatically on another server. You can arrange for IBM MQ MQI client applications to automatically reconnect to the queue manager. Server applications can be configured to start when the queue manager starts.

Distributed[IBMi]High-availability configurations are implemented either by using a high-availability cluster solution or by using multi-instance queue managers. Red Hat Cluster Suite or Microsoft Cluster Service (MSCS) are examples of high-availability cluster solutions.

[z/OS]On z/OS there are several alternative techniques to increase queue manager availability; see Availability. Migration considerations on z/OS depend on the availability techniques that are employed, and are not described in this topic. The term high-availability configuration refers only to queue managers in configurations on platforms other than z/OS.

The overall principles involved in queue manager migration in a high availability configuration are the same, whether you are migrating a multi-instance queue manager or a high-availability cluster. In either case, the principles are as follows:

  1. You must not restart a queue manager at a lower command level than the one it was previously running.
  2. You cannot upgrade the code an active queue manager is running.
  3. You cannot back up an active queue manager.

Overall steps to migrate a queue manager in a multi-instance queue manager configuration

The following terms are relevant:
active queue manager instance
A queue manager instance that has been started permitting standby instances, and is running.
standby queue manager instance
A queue manager instance that has been started permitting standby instances, and is in standby. It is ready to take over from the active instance automatically.

Base your migration procedure on the following steps.

  1. Before you start the migration process, create a different queue manager on a server on which you have installed the upgrade. Test the upgrade by performing whatever verification checks that your organization requires.
  2. If you have a pool of servers that you pick from when starting a queue manager instance, upgrade IBM MQ on the servers that are in the pool and are neither active or acting as a standby.
  3. Stop the standby queue manager instance. Make sure that you have no system management procedure running that restarts the instance automatically.
  4. If you do not have a pool of servers, upgrade IBM MQ on the server that was running the standby instance.
  5. Decide whether downtime or recoverability is more important in the migration:
    Follow these steps if recoverability is more important, and you must take a backup:
    1. Stop the active queue manager instance, without switching to any standby.
    2. Back up the queue manager.
    3. Start a queue manager instance, permitting standbys, on one of the upgraded servers.
    4. If you have a pool of upgraded servers, start another one, permitting standbys.
    If availability is more important, follow this procedure; you do not take a backup.
    1. Start a queue manager instance as a standby on one of the upgraded servers.
    2. Stop the active queue manager instance, switching to the standby.
    3. If you have a pool of upgraded servers, start another one, permitting standbys.
  6. Upgrade the IBM MQ code on the server that was the active queue manager instance, and start it as the standby instance if you have not already started a standby.

Overall steps to migrate a queue manager in a high-availability cluster

The following terms are relevant:
active server
The running server or active queue manager instance
passive server
A server that is ready to take over from the active server automatically.
inactive server
A server that is not prepared to take over automatically. The server might have been removed from the cluster, or taken offline in some way.

Base your migration procedure on the following steps. The details depend on the specific commands in the cluster concerned.

  1. Before you start the migration process, create a different queue manager on a server on which you have installed the upgrade. Test the upgrade by performing whatever verification checks that your organization requires.
  2. If you have four servers available, you can form two cluster pairs.

    With two pairs, the queue manager can continue to run in a cluster-pair at the old command level. When you are ready, you can transfer the queue manager to the pair of servers at the new command level.

  3. Remove a passive server from the cluster. Make sure that the cluster cannot automatically restart the server. The server is made inactive.
  4. If a high-availability cluster is using a common location for IBM MQ code, you must create a second location for the upgraded code.
  5. Install, or upgrade, IBM MQ code using the server that is not now running the queue manager.
  6. Verify the upgrade by creating a different queue manager on the server, and performing whatever verification checks that your organization requires.
  7. If more than half the servers remain in the cluster, remove a server, upgrade IBM MQ, and verify the upgrade. Each server is made inactive as part of the process. Continue until half the servers are upgraded.
  8. If your active server is part of a remaining cluster, deactivate the passive servers so that the cluster cannot reactivate them automatically.
  9. Decide whether downtime or recoverability is more important in the migration:
    Follow these steps if recoverability is more important:
    1. Stop the queue manager and remove the server from the cluster.
    2. Back up the queue manager.
    Or this step, if downtime is more important:
    1. Add the migrated servers back into the cluster, as passive servers. Then switch the remaining server in the high-availability server cluster over to one of the passive servers. The switch causes the running queue manager to stop, restarts it on one of the passive servers.
  10. Upgrade any remaining high-availability servers, and add them back into the cluster.