Looking for a High Availability Solution? Consider Multi-Instance Queue Managers!![]() ![]() WebSphere MQ V7.0.1 introduced multi-instance queue managers (qmgrs). To use this feature, you will need a shared file system on networked storage. The storage must be accessed by a network file system protocol that is Posix-compliant and supports lease-based locking. Network File System version 4 (NFS v4) satisfies this requirement. Note: earlier versions of NFS do NOT satisfy this requirement and must not be used with multi-instance queue managers. For more information about requirements and supported platforms for WebSphere multi-instance qmgrs, see Testing and support statement for WebSphere MQ multi-instance queue managers. When you create a multi-instance queue manager, the queue manager data and logs are stored on shared network storage. You can then run the queue manager from either of the servers. Each of the servers reference the same queue manager data and logs; there is only one queue manager, and it is active on only one server at a time. A multi-instance queue manager restarts automatically on a standby server, providing a high availability solution when coupled with client and channel reconnection. The server that is not running the active instance of the queue manager runs as a standby instance, ready to take over from the active instance automatically if the active server fails. The standby instance will have the execution controller process amqzxma0 checking the file locks and when those locks are released by the active instance the standby qmgr will start. Multi-instance qmgrs are started with the –x option of the strmqm command. For example: strmqm –x QMGR1 starts an instance of a multi-instance queue manager on the local server, permitting it to be highly available. If an instance of the queue manager is not already running elsewhere, the queue manager starts and the instance becomes active. The –x parameter can also be used with the dspmq command to show the qmgr status of multi-instance qmgr that will include details for which node has the active instance and which node is running as a standby: QMNA To end the active QMGR and have the backup qmgr become active, use the –s option for the endmqm command. For example: endmqm –s QMG1 will end the queue manager on the current server and switch over to a standby queue manager instance after shutting down. The commands checks that there is a standby instance running before ending the active instance, but it does not wait for the standby instance to start before ending. Using the endmqm –s command to switch to the inactive instance of the queue manager will result in the current connections to the queue manager being broken. If configured, reconnectable clients start trying to reconnect and can establish connection when the standby instance of the queue manager becomes active. Resources:
|