Converting 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 you begin
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.
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,
you 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 we 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.
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.
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:
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.
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.
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.
On ALPHA:
WRKMQMJRN MQMNAME(QM1)
On BETA:
WRKMQMJRN MQMNAME(QM1)
Start the queue manager instances on ALPHA and BETA.
Start the first instance on ALPHA, making it the active instance. Enabling switching over to a
standby instance.
STRMQM MQMNAME(QM1) STANDBY(*YES)
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.
Start the high availability sample programs.
On ALPHA, end the queue manager requesting switch over:
ENDMQM MQMNAME(QM1) OPTION(*IMMED) ALSWITCH(*YES)
Check that the instance of QM1 on BETA is active.
Restart QM1 on ALPHA
STRMQM MQMNAME(QM1) STANDBY(*YES)
Look at alternative high availability configurations:
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.