Putting a queue manager under MSCS control

Before you put a queue manager under MSCS control:

1. Ensure that WebSphere MQ and its MSCS Support is installed on both machines in the cluster and that the software on each computer is identical, as described in Setting up WebSphere MQ for MSCS clustering.
2. If you have not yet created the queue manager, see Creating a queue manager for use with MSCS.
3. If you have created the queue manager, or it already exists, ensure that you have carried out the procedure in Moving a queue manager to MSCS storage.
4. Stop the queue manager, if it is running, using either a command prompt or the WebSphere MQ Explorer.
5. Test MSCS operation of the shared drives before going on to the procedure below.

To place a queue manager under MSCS control:

1. Log in to the cluster node computer hosting the queue manager, or log in to a remote workstation as a user with cluster administration permissions, and connect to the cluster node hosting the queue manager.
2. Start the MSCS Cluster Administrator.
3. Open a connection to the cluster.
4. Create an MSCS group to be used to contain the resources for the queue manager. Name the group in such a way that it is obvious which queue manager it relates to. For example, you might decide to call the group QM1-Group. Each group can contain one or more queue managers, as described in Using multiple queue managers with MSCS.

   Use the group for all the remaining steps.

5. Create a resource instance for each of the SCSI logical drives that the queue manager uses.

   You can use one drive to store both the logs and queue files, or you can split them up across drives. In either case, if each queue manager has its own shared disk, ensure that all drives used by this queue manager are exclusive to this queue manager, that is, that nothing else relies on the drives. Also ensure that you create a resource instance for every drive that the queue manager uses.

   The resource type for a drive depends on the SCSI support you are using; refer to your SCSI adapter instructions. There might already be groups and resources for each of the shared drives. If so, you do not need to create the resource instance for each drive. Just move it from its current group to the one created for the queue manager.

   For each drive resource, set possible owners to both nodes. Set dependent resources to none.

6. Create a resource instance for the IP address.

   Create an IP address resource (resource type IP Address). This address should be an unused IP address to be used by clients and other queue managers to connect to the virtual queue manager. This IP address is not the normal (static) address of either node; it is an additional address that floats between them. Although MSCS handles the routing of this address, it does not verify that the address can be reached.

7. Create a resource instance for the queue manager.

   Create a resource of type IBM WebSphere MQ MSCS; the wizard prompts you for various items, including the following:

   • Name; choose a name that makes it easy to identify which queue manager it is for.
   • Add to group; use the group that you created
   • Run in a separate Resource Monitor; isolation is better if you do
   • Possible owners; set both nodes
   • Dependencies; add the drive and IP address for this queue manager
   • Parameters; as follows:
     • QueueManagerName (required); the name of the queue manager that this resource is to control. This queue manager must exist on the local computer.
     • PostOnlineCommand (optional); you can specify a program to run whenever the queue manager resource changes its state from offline to online. For more details see PostOnlineCommand and PreOfflineCommand.
     • PreOfflineCommand (optional); you can specify a program to run whenever the queue manager resource changes its state from online to offline. For more details see PostOnlineCommand and PreOfflineCommand.
8. Optionally, set a preferred node (but note the comments in Using preferred nodes).
9. The Failover Policy (as defined in the properties for the group) is set by default to sensible values, but you can tune the thresholds and periods that control Resource Failover and Group Failover to match the loads placed on the queue manager.
10. Test the queue manager by bringing it online in the MSCS Cluster Administrator and subjecting it to a test workload. If you are experimenting with a test queue manager, use the WebSphere MQ Explorer. For example:
    1. Expand the folder with the name of the queue manager.
    2. Select one of the queues, or, to create a test one, right-click the queues folder, select New->Local, and give the queue a name.
    3. Right-click the queue in the results pane, and use Put test message to put several test messages.
    4. Double-click the queue to display the test messages.
    5. Right-click the queue and select Tasks->Clear messages.
    6. If you created a test queue in (b), right-click the queue and select Delete.
11. Test that the queue manager can be taken offline and back online using the MSCS Cluster Administrator.
12. Simulate a failover.

    In the MSCS Cluster Administrator, right-click the group containing the queue manager and select Move Group. This can take some minutes to do. (If at other times you just want to move a queue manager to another node quickly, follow the procedure in Moving a queue manager to MSCS storage.) You can also right-click and select Initiate Failure; the action (local restart or failover) depends on the current state and the configuration settings.