Creating a multi-instance queue manager using journal mirroring and NetServer

Create a multi-instance queue manager to run on two IBM® i servers. The queue manager data is stored on a third IBM i server using NetServer. The queue manager journal is mirrored between the two servers using remote journaling. The ADDMQMJRN command is used to simplify creating the remote journals.

Before you begin

The task requires three IBM i servers. Install IBM MQ on two of them, ALPHA and BETA in the example. IBM MQ must be at least at version 7.0.1.1.
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 create the configuration shown in Figure 1. The queue manager data is connected using IBM i NetServer.

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.
Create the queue manager QM1 on the IBM i server, ALPHA.
Add the queue manager control information for QM1 on the other IBM i server, BETA.
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.

Procedure

Do the task, Creating a network share for queue manager data using NetServer.

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 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.
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 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

Shows synchronous replication between local and remote journals on host ALPHA and BETA with queue manager data stored using NetServer. — Figure 1. Mirrored journal configuration

What to do next

Verify that the active and standby instances switch over automatically. You can run the sample high availability sample programs to test the switch over; see High availability sample programs. The sample programs are 'C' clients. You 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.