You configure WebSphere MQ for clustering by making the queue manager the unit of failover to MSCS. You define a queue manager as a resource to MSCS, which can then monitor it, and transferred it to another computer in the cluster if there is a problem.
To set your system up for this, you start by installing WebSphere MQ on each computer in the cluster. WebSphere MQ for Windows, V5.3 Quick Beginnings tells you how to do this.
The queue managers themselves need to exist only on the computer on which you create them. In the event of a failover, the MSCS initiates the queue managers on the other computer. The queue managers, however, must have their log and data files on a cluster shared disk, and not on a local drive. If you have a queue manager already installed on a local drive, you can migrate it using a tool provided with WebSphere MQ; see Moving a queue manager to MSCS storage. If you want to create new queue managers for use with MSCS, see Creating a queue manager for use with MSCS.
After installation and migration, use the MSCS Cluster Administrator to make MSCS aware of your queue managers; see Putting a queue manager under MSCS control.
If you decide to remove a queue manager from MSCS control, use the procedure described in Removing a queue manager from MSCS control.
When an application switches from one node to the other it must behave in the same way regardless of node. The best way of ensuring this is to make the environments identical. If you can, set up a cluster with identical hardware, operating system software, product software, and configuration on each computer. In particular, ensure that all the required software installed on the two computers is identical in terms of versions, levels, CSDs, SupportPacs, paths and exits (as described WebSphere MQ for Windows, V5.3 Quick Beginnings), and that there is a common namespace (security environment) as described in MSCS security.
Start by making sure you have identical software installations on each computer in the cluster, as described in WebSphere MQ for Windows, V5.3 Quick Beginnings.
For successful MSCS security, follow these guidelines:
Remember that an account local to one computer does not exist on the other one. Even if you create an account with the same name on the other computer, its security identifier (SID) is different, so, when your application is moved to the other node, the permissions do not exist on that node.
During a failover or move, WebSphere MQ MSCS support ensures that all files that contain queue manager objects have equivalent permissions on the destination node. Explicitly, the code checks that the Administrators and mqm groups, and the SYSTEM account, have full control, and that if Everyone had read access on the old node, that permission is added on the destination node.
You can use a domain account to run your WebSphere MQ Service. Make sure that it exists in the local mqm group on each computer in the cluster.
If you are running more than one queue manager on a computer, you can choose one of the following setups:
There are two modes in which you might run a cluster system with WebSphere MQ:
In Active/Passive mode, computer A has the running application on it, and computer B is backup, only being used when MSCS detects a problem.
You can use this mode with only one shared disk, but, if any application causes a failover, all the applications must be transferred as a group (because only one computer can access the shared disk at a time).
You can configure MSCS with A as the preferred computer. Then, when computer A has been repaired or replaced and is working properly again, MSCS detects this and automatically switches the application back to computer A.
If you run more than one queue manager, consider having a separate shared disk for each. Then put each queue manager in a separate group in MSCS. In this way, any queue manager can failover to the other computer without affecting the other queue managers.
In Active/Active mode, computers A and B both have running applications, and the groups on each computer are set to use the other computer as backup. If a failure is detected on computer A, MSCS transfers the state data to computer B, and reinitiates the application there. computer B then runs its own application and A's.
For this setup you need at least two shared disks. You can configure MSCS with A as the preferred computer for A's applications, and B as the preferred computer for B's applications. After failover and repair, each application automatically ends up back on its own computer.
For WebSphere MQ this means that you could, for example, run two queue managers, one on each of A and B, with each exploiting the full power of its own computer. After a failure on computer A, both queue managers would run on computer B. This would mean sharing the power of the one computer, with a reduced ability to process large quantities of data at speed. However, your critical applications would still be available while you find and repair the fault on A.