Migrating from a single instance to a multi-instance queue manager on Windows

To migrate a single instance queue manager, to a multi-instance queue manager, on Windows platforms, we must move the queue manager data to a shared directory, and reconfigure the queue manager on two other servers.

Before starting

We must check the prerequisites for running a multi-instance queue manager as part of this task. For a list of tested environments, see Testing statement for IBM MQ multi-instance queue manager file systems. Other environments might work; a test tool is provided with IBM MQ to assist you in qualifying other environments.

We must have three servers to run a multi-instance queue manager. One server has a shared file system to store the queue manager data and logs. The other servers run the active and standby instances of the queue manager.

About this task

We have a single-instance queue manager that we want to convert to a multi-instance queue manager. The queue manager conversion itself is straightforward, but we must do other tasks to create a fully automated production environment.

We must check the prerequisites for a multi-instance queue manager, set up the environment and check it. We must set up a monitoring and management system to detect if the multi-instance queue manager has failed and been automatically restarted. We can then find out what caused the restart, remedy it, and restart the standby. We must also modify applications, or the way applications are connected to the queue manager, so that they can resume processing after a queue manager restart.

Procedure

Check the operating system that we are going to run the queue manager on, and the file system on which the queue manager data and logs are stored on. Check that they can run a multi-instance queue manager.
1. Consult Testing statement for IBM MQ multi-instance queue manager file systems. See whether the combination of operating system and file system is tested and capable of running a multi-instance queue manager. A shared file system must provide lease-based locking to be adequate to run multi-instance queue managers. Lease-based locking is a recent feature of some shared file systems, and in some case fixes are required. The support statement provides you with the essential information.
2. Run amqmfsck to verify that the file system is configured correctly. File systems are sometimes configured with performance at a premium over data integrity. It is important to check the file system configuration. A negative report from the amqmfsck tool tells you the settings are not adequate. A positive result is an indication that the file system is adequate, but the result is not a definitive statement that the file system is adequate. It is a good indication.
3. Run the integrity checking application provided in the technote, Testing a shared file system for compatibility with IBM MQ Multi-instance Queue Managers. The checking application tests that the queue manager is restarting correctly.
Configure a user and group to be able to access a share on the networked file system from each server that is running a queue manager instance. On Windows, the security IDs (SIDs) of the mqm group can be different; see Windows domains and multi-instance queue managers.
Set up a directory for the share on the networked file system with the correct access permissions. A typical configuration is to set up a single shared directory that contains all data and log directories for all queue managers that use the shared disk; see Share named qmgrs and log directories (Version 7.0.1 onwards). For example, create a root directory on the share called MQHA that has subdirectories data and logs. Each queue manager creates its own data and log directories under data and logs. Create drive \MQHA on the shared drive. The owner is a member of mqm. mqm must have full-control authority. Create a share for drive\MQHA.
If we are using an NFS v4 file server, add the line /MQHA * rw,sync,no_wdelay,fsid=0) to etc/exports, and then start the NFS daemon: /etc/init.d/nfs start.
Copy the queue manager data and the logs to the share. We can choose to copy files manually, by following the procedure to back up the queue manager. On Windows, we can run the hamvmqm command to move the queue manager data to the share. The hamvmqm command works for queue managers created before Version 7.0.1, and not reconfigured with a datapath, or for queue managers that do not have a DataPath configuration attribute. Choose one of these methods:
- Follow the instructions in Backing up queue manager data, copying the queue manager data to the share. We must use this method if the DataPath configuration attribute is specified for this queue manager.
- Stop the queue manager, and then type the following command:
```
hamvmqm /m /dd share\data /dd share\logs
```
  where share is to be the location of the data and logs that you created in step 3.
Update the queue manager configuration information stored on the current queue manager server.
- If you moved the queue manager data and logs by running the hamvmqm command, the command has already modified the configuration information correctly for you.
- If you moved the queue manager data and logs manually, we must complete the following steps.
  1. Modify the log registry key:
```
HKEY_LOCAL_MACHINE\SOFTWARE\IBM\WebSphere MQ\Installation\MQ_INSTALLATION_NAME\Configuration\QueueManager\QMgrName\Log
"LogPath"="share\\logs\\QMgrName\\"
```
  2. Modify the Prefix registry key:
```
HKEY_LOCAL_MACHINE\SOFTWARE\IBM\WebSphere MQ\Installation\MQ_INSTALLATION_NAME\Configuration\QueueManager\QMgrName
"Prefix"="share\\data"
```
where QMgrName is the representation of the queue manager name in the existing registry key on Windows. share is share where the data and logs are moved to.
Add the queue manager configuration information to the new queue manager server.
1. Run the dspmqinf command to display the queue manager information Run the command on the server that ran the queue manager.
```
dspmqinf -o command QMgrName
```
  The command output is formatted ready to create a queue manager configuration.
  addmqinf -s QueueManager -v Name= QMgrName -v Directory= QMgrName -v Prefix=d:\var\mqm Datapath= \share\data\QMgrName
2. Create a queue manager configuration on the other server. Run the addmqinf command copied from the previous output.
Add the network address of the new server to the connection name in client and channel definitions.
1. Find all the client, sender, and requester TCPIP settings that refer to the server.
  - Client settings might be in Client Definition Tables (CCDT), in environment variables, in Java properties files, or in client code.
  - Cluster channels automatically discover the connection name of a queue manager from its cluster receiver channel. As long as the cluster receiver channel name is blank or omitted, TCPIP discovers the IP address of the server hosting the queue manager.
2. Modify the connection name for each of these connections to include the TCPIP addresses of both servers that are hosting the multi-instance queue manager. For example, change the following connection name:
```
echo DISPLAY CHANNEL(ENGLAND) CONNAME | runmqsc QM1
```
```
5724-H72 (C) Copyright IBM Corp. 1994, 2020.  ALL RIGHTS RESERVED.
Starting MQSC for queue manager QM1.
1: DISPLAY CHANNEL(ENGLAND) CONNAME
AMQ8414: Display Channel details.
CHANNEL(ENGLAND) CHLTYPE(SDR)
CONNAME(LONDON)
```
  into:
```
echo ALTER CHANNEL(ENGLAND) CHLTYPE(SDR) CONNAME('LONDON, BRISTOL') | runmqsc QM1
```
Update your monitoring and management procedures to detect the queue manager restarting.
Update client applications to be automatically reconnectable, if appropriate.
Update the start procedure for the IBM MQ applications to be started as queue manager services.
Start each instance of the queue manager, permitting them to be highly available. The first instance of the queue manager that is started becomes the active instance. Issue the command twice, once on each server.
```
strmqm -x QMgrName
```

What to do next

To get the highest availability out of multi-instance queue managers, we must design client applications to be reconnectable and server applications to be restartable; see Application recovery.

Parent topic: Migrating IBM MQ on Windows

Migrating from a single instance to a multi-instance queue manager on Windows

Before starting

About this task

Procedure

What to do next

Related information