Create a multi-instance queue manager using journal mirroring and NetServer on IBM i
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 starting
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.
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.
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.
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.
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:
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.
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.
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.
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.
Use NetServer to place the queue manager data on a Windows server.
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.