Verifying the multi-instance queue manager on Linux

Use the sample programs amqsghac, amqsphac and amqsmhac to verify a multi-instance queue manager configuration. This topic provides an example configuration to verify a multi-instance queue manager configuration on Linux® Red Hat Enterprise 5.

The high availability sample programs use automatic client reconnection. When the connected queue manager fails, the client attempts to reconnect to a queue manager in the same queue manager group. The description of the samples, High availability sample programs, demonstrates client reconnection using a single instance queue manager for simplicity. You can use the same samples with multi-instance queue managers to verify a multi-instance queue manager configuration.

The example uses the multi-instance configuration described in Create a multi-instance queue manager on Linux. Use the configuration to verify that the multi-instance queue manager switches over to the standby instance. Stop the queue manager with the endmqm command and use the -s, switchover, option. The client programs reconnect to the new queue manager instance and continue to work with the new instance after a slight delay.

In the example, the client is running on a Windows 7 Service Pack 1 system. The system is hosting two VMware Linux servers that are running the multi-instance queue manager.

Verifying failover using IBM MQ Explorer

Before using the sample applications to verify failover, run the IBM® MQ Explorer on each server. Add both queue manager instances to each explorer using the Add Remote Queue Manager > Connect directly to a multi-instance queue manager wizard. Ensure that both instances are running, permitting standby. Close the window running the VMware image with the active instance, virtually powering off the server, or stop the active instance, allowing switchover to standby instance.
Note: If you power off the server, make sure that it is not the one hosting /MQHA !
Note: The Allow switchover to a standby instance option might not be available on the Stop Queue Manager dialog. The option is missing because the queue manager is running as a single instance queue manager. You must have started it without the Permit a standby instance option. If your request to stop the queue manager is rejected, look at the Details window, it is possibly because there is no standby instance running.

Verifying failover using the sample programs

Choose a server to be to run the active instance
You might have chosen one of the servers to host the MQHA directory or file system. If you plan to test failover by closing the VMware window running the active server, make sure that it is not the one hosting MQHA !
On the server running the active queue manager instance
Note: Running the SVRCONN channel with the MCAUSER set to mqm, is a convenience to reduce the number of configuration steps in the example. If another user ID is chosen, and your system is set up differently to the one used in the example, you might experience access permission problems. Do not use mqm as a MCAUSER on an exposed system; it is likely to compromise security greatly.
  1. Modify ipaddr1 and ipaddr2 and save the following commands in /MQHA/hasamples.tst.
    
    DEFINE QLOCAL(SOURCE) REPLACE
    DEFINE QLOCAL(TARGET) REPLACE
    DEFINE CHANNEL(CHANNEL1) CHLTYPE(SVRCONN)  TRPTYPE(TCP) +
    MCAUSER('mqm') REPLACE
    DEFINE CHANNEL(CHANNEL1) CHLTYPE(CLNTCONN) TRPTYPE(TCP) +
    CONNAME(' ipaddr1 (1414), ipaddr2
    (1414)') QMNAME(QM1) REPLACE
    START  CHANNEL(CHANNEL1)
    DEFINE LISTENER(LISTENER.TCP) TRPTYPE(TCP) CONTROL(QMGR)
    DISPLAY LISTENER(LISTENER.TCP) CONTROL
    START  LISTENER(LISTENER.TCP)
    DISPLAY LSSTATUS(LISTENER.TCP) STATUS
    
  2. Open a terminal window with the path /MQHA and run the command:
    
    runmqsc -m QM1 < hasamples.tst
    
  3. Verify that the listener is running and has queue manager control, either by inspecting the output of the runmqsc command.
    
    LISTENER(LISTENER.TCP)CONTROL(QMGR)
    LISTENER(LISTENER.TCP)STATUS(RUNNING)
    
    Or, using the IBM MQ Explorer that the TCPIP listener is running and has Control = Queue Manager.
On the client
  1. Copy the client connection table AMQCLCHL.TAB from /MQHA/qmgrs/QM1.000/@ipcc on the server to C:\ on the client.
  2. Open a command prompt with the path C:\ and set the environment variable MQCHLLIB to point to the client channel definition table (CCDT)
    
    SET MQCHLLIB=C:\
    
  3. At the command prompt type the commands:
    
    start amqsghac TARGET QM1
    start amqsmhac -s SOURCE -t TARGET -m QM1
    start amqsphac SOURCE QM1
    
On the server running the active queue manager instance
  1. Either:
    • Close the window running the VMware image with the active server instance.
    • Using the IBM MQ Explorer, stop the active queue manager instance, allowing switchover to the standby instance and instructing reconnectable clients to reconnect.
  2. The three clients eventually detect the connection is broken, and then reconnect. In this configuration, if you close the server window, it is taking about seven minutes for all three connections to be reestablished. Some connections are reestablished well before others.

Results


N:\>amqsphac SOURCE QM1
Sample AMQSPHAC start
target queue is SOURCE
message <Message 1>
message <Message 2>
message <Message 3>
message <Message 4>
message <Message 5>
17:05:25 : EVENT : Connection Reconnecting (Delay: 0ms)
17:05:47 : EVENT : Connection Reconnecting (Delay: 0ms)
17:05:52 : EVENT : Connection Reconnected
message <Message 6>
message <Message 7>
message <Message 8>
message <Message 9>

N:\>amqsmhac -s SOURCE -t TARGET -m QM1
Sample AMQSMHA0 start

17:05:25 : EVENT : Connection Reconnecting (Delay: 97ms)
17:05:48 : EVENT : Connection Reconnecting (Delay: 0ms)
17:05:53 : EVENT : Connection Reconnected

N:\>amqsghac TARGET QM1
Sample AMQSGHAC start
message <Message 1>
message <Message 2>
message <Message 3>
message <Message 4>
message <Message 5>
17:05:25 : EVENT : Connection Reconnecting (Delay: 156ms)
17:05:47 : EVENT : Connection Reconnecting (Delay: 0ms)
17:05:52 : EVENT : Connection Reconnected
message <Message 6>
message <Message 7>
message <Message 8>
message <Message 9>