1 MARCO TEÓRICO
1.8. ESTUDIO ECONÓMICO FINANCIERO
This section provides information about the test cases and the results.
Test Case 1: Controlled switch-over
The setup for the first test case, involving a controlled switch-over, was done using the following steps:
1. Verify the status of the active node. Refer 6.6.2, “Verifying the status on the node” on page 138. Start any components on the active node as required. 2. Verify the status of the standby node. Refer 6.6.2, “Verifying the status on the
node” on page 138. Start any components on the standby node as required. 3. Ensure that the message flow is running.
Table 6-6 describes the test case.
Table 6-6 Test case 1
Component WebSphere Message Broker Multi-Instance Brokers
Test Case Controlled switch-over from the active to the standby node
Description This test case tests the controlled switch-over from the active node to the standby node using the endmqm command with the -s option.
We expect the standby queue manager and broker to become active and to continue consuming the 100000 messages published by the CICS program without loss of messages.
Table 6-7 describes the steps executed in the test case and the results.
Table 6-7 Test steps
Step Description Pass/
Fail
1 Invoke the CICS program to publish messages to the NEWS.POLITICS topic on z/OS queue manager MQH1.
See Appendix A, “QPUB Transaction” on page 227 for details of the CICS program and how to invoke it.
Results:
The messages are published to the NEWS.POLITICS topic on z/OS queue manager MQH1 and go to the MI_INPUT queue on queue manager NFSMQK.
Pass
2 Monitor the output queue MI_OUTPUT on the active node through MQ Explorer. After approximately 15000 messages have been processed perform a controlled switch from the active node to the standby node by issuing the endmq -s command on the active node.
If you are monitoring the queue depth in MQ Explorer you lose connection to the active node instance of the queue manager on Node1 as it stops and switches control to the standby instance on Node2. After Node2 becomes active you must re-connect to the queue manager instance on Node2 to check the queue depth of the output queue. Results:
$ endmqm -s NFSMQK
Waiting for queue manager 'NFSMQK' to end.
Quiesce request accepted. The queue manager will stop when all outstanding work is complete, permitting switch-over to a standby instance.
$
This shows that the queue manager on Node1 is about to stop and has handed control to the standby instance on Node2.
3 Verify the status of the active node. Refer 6.6.2, “Verifying the status on the node” on page 138.
The queue manager stops on Node1 and Node2 becomes the active node. Results:
$ dspmq -x
QMNAME(NFSMQK) STATUS(Running as standby) INSTANCE(p5502p8) MODE(Active)
INSTANCE(p5501p5) MODE(Standby) $ dspmq -x
QMNAME(NFSMQK) STATUS(Running as standby) INSTANCE(p5502p8) MODE(Active)
INSTANCE(p5501p5) MODE(Standby) $ dspmq -x
QMNAME(NFSMQK) STATUS(Running as standby) INSTANCE(p5502p8) MODE(Active)
INSTANCE(p5501p5) MODE(Standby) $ dspmq -x
QMNAME(NFSMQK) STATUS(Running as standby) INSTANCE(p5502p8) MODE(Active) INSTANCE(p5501p5) MODE(Standby) $ dspmq -x QMNAME(NFSMQK) STATUS(Running) INSTANCE(p5501p5) MODE(Active) $ mqsilist
BIP1295I: Broker 'NFSWMB' is a multi-instance broker running in active mode on multi-instance queue manager 'NFSMQK'.
BIP8071I: Successful command completion.
When the switch-over was complete the queue manager on Node2 (p5501p5) became active and the broker on Node2 became the active instance.
Pass
4 Connect to the newly active queue manager instance in MQ Explorer on Node2 and monitor the queue depths until all 100000 messages appear on the MI_OUTPUT queue. Results:
All 100000 messages were processed and written to MI_OUTPUT.
Pass
Overall Test Status
We managed to successfully switch control of the application from Node1 to Node2 without loss of messages. There was a brief interruption during the cut-over period, but this had no impact in this scenario as the publish subscribe configuration meant that our messages were persisted until the queue manager switch over was complete and the Node2 instance of the queue manager was able to retrieve the messages.
Pass
Step Description Pass/
Test Case 2: Automatic failover after killing the MQ processes
The setup for the test involved the following steps:1. Verify the status of the active node. Refer 6.6.2, “Verifying the status on the node” on page 138. Start any components on the active node as required. 2. Verify the status of the standby node. Refer 6.6.2, “Verifying the status on the
node” on page 138. Start any components on the standby node as required. 3. Ensure that the message flow is running.
Table 6-8 describes the test case.
Table 6-8 Test case 2
Component WebSphere Message Broker Multi-Instance Brokers
Test Case Automatic failover from the active to the standby node after killing the WebSphere MQ processes.
Description This test case tests the automatic failover from the active node to the standby node during message processing, when we kill all of the WebSphere MQ processes on the active node using kill -9.
We expect the standby queue manager and broker to become active and to continue consuming the 100000 messages published by the CICS program without loss of messages.
Table 6-9 describes the steps executed in the test case and the results.
Table 6-9 Test steps with kill -9
Step Description Pass/
Fail
1 Invoke the CICS program to publish messages to the NEWS.POLITICS topic on z/OS queue manager MQH1.
See Appendix A, “QPUB Transaction” on page 227 for details of the CICS program and how to invoke it.
Results:
The messages are published to the NEWS.POLITICS topic on z/OS queue manager MQH1 and go to the MI_INPUT queue on queue manager NFSMQK.
Pass
2 Monitor the output queue MI_OUTPUT on the active node through MQ Explorer. After approximately 15000 messages have been processed perform a failover from the active node to the standby node by issuing the following command on the active node: kill -9 `ps -ef | grep amq | grep -v grep | awk '{print $2}'`
kill -9 `ps -ef | grep runmqlsr | grep -v grep | awk '{print $2}'`
The first command kills the queue manager processes and second command kills the listener.
Results:
The queue manager on Node1 is stopped and the standby instance on Node2 started automatically. The broker instance on active node stops and on Node2 becomes active broker instance.
Pass
3 Verify the status of the active node. Refer 6.6.2, “Verifying the status on the node” on page 138.
The queue manager on Node2 becomes the active node. Results:
$ dspmq -x
QMNAME(NFSMQK) STATUS(Running) INSTANCE(p5501p5) MODE(Active)
$ mqsilist
BIP1295I: Broker 'NFSWMB' is a multi-instance broker running in active mode on multi-instance queue manager 'NFSMQK'.
BIP8071I: Successful command completion.
Pass
4 Connect to the newly active queue manager instance in MQ Explorer on Node2 and monitor the queue depths until all 100000 messages appear on the MI_OUTPUT queue. Results:
Test case 3: automatic failover at active server shut down
The setup for the test involved the following steps:1. Verify the status of the active node. Refer 6.6.2, “Verifying the status on the node” on page 138. Start any components on the active node as required. 2. Verify the status of the standby node. Refer 6.6.2, “Verifying the status on the
node” on page 138. Start any components on the standby node as required. 3. Ensure that the message flow is running.
Table 6-10 describes the test case.
Table 6-10 Test case 3
Overall Test Status
The failover of queue manager instance and broker instance by using command kill -9 works correct, the application switches processing from Node1 to Node2 without loss of messages. There was a brief interruption during the cut-over period.
Pass
Step Description Pass/
Fail
Component WebSphere Message Broker Multi-Instance Brokers
Test Case Automatic failover from the active to the standby node
Description This test case tests automatic failover from the active node to the standby node during message processing when a shutdown and restart is performed on the active server using shutdown -rF.
We expect the standby queue manager and broker to become active and to continue consuming the 100000 messages published by the CICS program without loss of messages.
Table 6-11 describes the steps executed in the test case and the results.
Table 6-11 Test steps with shutdown -rF
Step Description Pass/
Fail
1 Invoke the CICS program to publish messages to the NEWS.POLITICS topic on z/OS queue manager MQH1.
See Appendix A, “QPUB Transaction” on page 227 for details of the CICS program and how to invoke it.
Results:
The messages are published to the NEWS.POLITICS topic on z/OS queue manager MQH1 and go to the MI_INPUT queue on queue manager NFSMQK.
Pass
2 Monitor the output queue MI_OUTPUT on the active node through MQ Explorer. After approximately 15000 messages have been processed perform a failover of the active node with the shutdown -rf command.
Results:
The queue manager standby instance on Node2 started automatically. The broker instance on Node2 became active.
Pass
3 Verify the status of the active node. Refer 6.6.2, “Verifying the status on the node” on page 138.
The queue manager on Node2 becomes the active node. Results:
$ dspmq -x
QMNAME(NFSMQK) STATUS(Running) INSTANCE(p5501p5) MODE(Active)
$ mqsilist
BIP1295I: Broker 'NFSWMB' is a multi-instance broker running in active mode on multi-instance queue manager 'NFSMQK'.
BIP8071I: Successful command completion.
Pass
4 Connect to the newly active queue manager instance in MQ Explorer on Node2 and monitor the queue depths until all 100000 messages appear on the MI_OUTPUT queue. Results:
All 100000 messages were processed and written to MI_OUTPUT.
Pass
Overall Test Status
The failover of queue manager instance and broker instance when we shutdown and restart the active server works correctly. The message processing restarted on node2 without loss of messages. The time of interruption during the cut-over period was minimal.
6.7 Summary
In this scenario we were able to demonstrate successfully the use of WebSphere MQ and WebSphere Message Broker multi-instance features to provide a high availability solution.
Our testing showed that the controlled switch-over can be used to change the active instance to allow maintenance of the active node. In addition we looked at two failover scenarios and verified the automatic switch-over from the active node to the standby node in the event of a failure.
The multi-instance features performed well and provided an effective high availability solution.