Convert a single instance queue manager to a multi-instance queue manager using NetServer and journal mirroring on IBM i

Convert a single instance queue manager to a multi-instance queue manager. Move the queue manager data to a network share connected by NetServer. Mirror the queue manager journal to a second IBM i server using remote journaling.

Before starting

The task requires three IBM i servers. The existing IBM MQ installation, on the server ALPHA in the example, must be at least at Version 7.0.1.1. ALPHA is running a queue manager called QM1 in the example.
Install IBM MQ on the second IBM i server, BETA in the example.
The third server is an IBM i server, connected by NetServer to ALPHA and BETA. It is used to share the queue manager data. It does not have to have an IBM MQ installation. It is useful to install IBM MQ on the server as a temporary step, to set up the queue manager directories and permissions.
Make sure that the QMQM user profile has the same password on all three servers.
Install IBM i NetServer; see i5/OS NetServer.

About this task

Perform the following steps to convert a single instance queue manager to the multi-instance queue manager shown in Figure 1. The single instance queue manager is deleted in the task, and then re-created, storing the queue manager data on the network share connected by NetServer. This procedure is more reliable than moving the queue manager directories and files to the network share using the CPY command.

Create connections from ALPHA and BETA to the directory share on GAMMA that is to store the queue manager data. The task also sets up the necessary permissions, user profiles and passwords.
Add Relational Database Entries (RDBE) to the IBM i systems that are going to run queue manager instances. The RDBE entries are used to connect to the IBM i systems used for remote journaling.
Save the queue manager logs and definitions, stop the queue manager, and delete it.
Re-create the queue manager, storing the queue manager data on the network share on GAMMA.
Add the second instance of the queue manager to the other server.
Create remote journals on both the IBM i servers for both queue manager instances. Each queue manager writes to the local journal. The local journal is replicated to the remote journal. The command, ADDMQMJRN simplifies adding the journals and the connections.
Start the queue manager, permitting a standby instance.

Note:

In step 4 of the task, you delete the single instance queue manager, QM1. Deleting the queue manager deletes all the persistent messages on queues. For this reason, complete processing all the messages stored by the queue manager, before converting the queue manager. If processing all the messages is not possible, back up the queue manager library before step 4. Restore the queue manager library after step 5.

Note:

In step 5 of the task, you re-create QM1. Although the queue manager has the same name, it has a different queue manager identifier. Queue manager clustering uses the queue manager identifier. To delete and re-create a queue manager in a cluster, we must first remove the queue manager from the cluster; see Removing a queue manager from a cluster: Alternative method or Removing a queue manager from a cluster. When you have re-created the queue manager, add it to the cluster. Although it has the same name as before, it appears to be a new queue manager to the other queue managers in the cluster.

Procedure

Do the task, Create a network share for queue manager data using NetServer on IBM i.
As a result, ALPHA and BETA have a share, /QNTC/GAMMA/WMQ, that points to /QIBM/UserData/mqm/qmgrs on GAMMA. The user profiles QMQM and QMQMADM have the necessary permissions, and QMQM has matching passwords on all three systems.
Add Relational Database Entries (RDBE) to the IBM i systems that are going to host queue manager instances.
1. On ALPHA create the connection to BETA.
```
 
ADDRDBDIRE RDB(BETA) RMTLOCNAME(BETA *IP) RMTAUTMTH(*USRIDPWD)
```
2. On BETA create the connections to ALPHA.
```
 
ADDRDBDIRE RDB(ALPHA) RMTLOCNAME(ALPHA *IP) RMTAUTMTH(*USRIDPWD)
```

Create the scripts that re-create the queue manager objects.

QSAVEQMGR LCLQMGRNAM(QM1) FILENAME('*CURLIB/QMQSC(QM1)')
OUTPUT(*REPLACE) MAKEAUTH(*YES) AUTHFN('*CURLIB/QMAUT(QM1)')

Stop the queue manager and delete it.

ENDMQM MQMNAME(QM1) OPTION(*IMMED) ENDCCTJOB(*YES) RCDMQMIMG(*YES) TIMEOUT(15)
DLTMQM MQMNAME(QM1)

Create the queue manager QM1 on ALPHA, saving the queue manager data on GAMMA.
```
CRTMQM MQMNAME(QM1) UDLMSGQ(SYSTEM.DEAD.LETTER.QUEUE)
MQMDIRP(' /QNTC/GAMMA/WMQ ')
```
The path, /QNTC/GAMMA/WMQ , uses NetServer to create the queue manager data in /QIBM/UserData/mqm/qmgrs.
Re-create the queue manager objects for QM1 from the saved definitions.
```
STRMQMMQSC SRCMBR(QM1) SRCFILE(*CURLIB/QMQSC) MQMNAME(QM1)
```
Apply the authorizations from the saved information.
1. Compile the saved authorization program.
```
CRTCLPGM PGM(*CURLIB/QM1) SRCFILE(*CURLIB/QMAUT)
SRCMBR(QM1) REPLACE(*YES)
```
2. Run the program to apply the authorizations.
```
CALL PGM(*CURLIB/QM1)
```
3. Refresh the security information for QM1.
```
RFRMQMAUT MQMNAME(QM1)
```
Run ADDMQMJRN on ALPHA. The command adds a remote journal on BETA for QM1.
```
ADDMQMJRN MQMNAME(QM1) RMTJRNRDB(BETA)
```
QM1 creates journal entries in its local journal on ALPHA when the active instance of QM1 is on ALPHA. The local journal on ALPHA is replicated to the remote journal on BETA.
Use the command, DSPF, to inspect the IBM MQ configuration data created by CRTMQM for QM1 on ALPHA.
The information is needed in the next step.
In this example, the following configuration is created in /QIBM/UserData/mqm/mqs.ini on ALPHA for QM1:
```
Name=QM1
Prefix=/QIBM/UserData/mqm
Library=QMQM1
Directory=QM1
DataPath= /QNTC/GAMMA/WMQ /QM1
```
Create a queue manager instance of QM1 on BETA using the ADDMQMINF command. Run the following command on BETA to modify the queue manager control information in /QIBM/UserData/mqm/mqs.ini on BETA.
```
ADDMQMINF MQMNAME(QM1)
PREFIX('/QIBM/UserData/mqm')
MQMDIR(QM1)
MQMLIB(QMQM1)
DATAPATH(' /QNTC/GAMMA/WMQ /QM1 ')
```
Tip: Copy and paste the configuration information. The queue manager stanza is the same on ALPHA and BETA.
Run ADDMQMJRN on BETA. The command adds a local journal on BETA and a remote journal on ALPHA for QM1.
```
ADDMQMJRN MQMNAME(QM1) RMTJRNRDB(ALPHA)
```
QM1 creates journal entries in its local journal on BETA when the active instance of QM1 is on BETA. The local journal on BETA is replicated to the remote journal on ALPHA.
Note: As an alternative, you might want to set up remote journaling from BETA to ALPHA using asynchronous journaling. Use this command to set up asynchronous journaling from BETA to ALPHA, instead of the command in step 7.
```
 ADDMQMJRN MQMNAME (QM1) RMTJRNRDB (ALPHA) RMTJRNDLV (*ASYNC)
```
If the server or journaling on ALPHA is the source of the failure, BETA starts without waiting for new journal entries to be replicated to ALPHA.
Switch the replication mode to *SYNC, using the CHGMQMJRN command, when ALPHA is online again.

Use the information in Mirrored journal configuration for ASP on IBM i to decide whether to mirror the journals synchronously, asynchronously, or a mixture of both. The default is to replicate synchronously, with a 60 second wait period for a response from the remote journal.
Verify that the journals on ALPHA and BETA are enabled and the status of remote journal replication is *ACTIVE.
1. On ALPHA:
```
WRKMQMJRN MQMNAME(QM1)
```
2. On BETA:
```
WRKMQMJRN MQMNAME(QM1)
```
Start the queue manager instances on ALPHA and BETA.
1. Start the first instance on ALPHA, making it the active instance. Enabling switching over to a standby instance.
```
STRMQM MQMNAME(QM1) STANDBY(*YES)
```
2. Start the second instance on BETA, making it the standby instance.
```
STRMQM MQMNAME(QM1) STANDBY(*YES)
```

Results

Use WRKMQM to check queue manager status:

The status of the queue manager instance on ALPHA should be *ACTIVE.
The status of the queue manager instance on BETA should be *STANDBY.

Example

Figure 1. Mirrored journal configuration

What to do next

Verify that the active and standby instances switch over automatically. We can run the sample high availability sample programs to test the switch over; see High availability sample programs. The sample programs are 'C' clients. We can run them from a Windows or Unix platform.
1. Start the high availability sample programs.
2. On ALPHA, end the queue manager requesting switch over:
```
ENDMQM MQMNAME(QM1) OPTION(*IMMED) ALSWITCH(*YES)
```
3. Check that the instance of QM1 on BETA is active.
4. Restart QM1 on ALPHA
```
STRMQM MQMNAME(QM1) STANDBY(*YES)
```
Look at alternative high availability configurations:
1. Use NetServer to place the queue manager data on a Windows server.
2. Instead of using remote journaling to mirror the queue manager journal, store the journal on an independent ASP. Use IBM i clustering to transfer the independent ASP from ALPHA to BETA.

Parent topic: Mirrored journal configuration for ASP on IBM i