Home

 

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 Set up WebSphere MQ for MSCS clustering.

2. Use the haregtyp utility program to register WebSphere MQ as an MSCS resource type on all of the cluster nodes. See WebSphere MQ MSCS support utility programs for additional information.

3. If you have not yet created the queue manager, see Creating a queue manager for use with MSCS.

4. 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.

5. Stop the queue manager, if it is running, using either a command prompt or the WebSphere MQ Explorer.

6. 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. Each group can contain multiple 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.

   We can use one drive to store both the logs and queue files, or we 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. If the IBM WebSphere MQ MSCS resource type is not listed then run the haregtyp.exe command described in WebSphere MQ MSCS support utility programs to register it. When you refresh the Cluster Administrator application, the IBM WebSphere MQ MSCS resource type will be listed.

   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; for better isolation

   • Possible owners; set both nodes

   • Dependencies; add the drive and IP address for this queue manager.
     Warning: Failure to add these dependencies means that WebSphere MQ attempts to write the queue manager status to the wrong cluster disk during failovers. Because many processes might be attempting to write to this disk simultaneously, some WebSphere MQ processes could be blocked from running.

   • 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); we 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); we 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 we 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. Right-click the Queues tree node, then select New->Local Queue..., and give the queue a name.

    2. Click Finish. The queue is created, and displayed in the content view.

    3. Right-click the queue, then select Put Test Message.... The Put Test Message panel is displayed.

    4. Type some message text, then click Put Test Message, and close the panel.

    5. Right-click the queue, then select Browse Messages.... The Message Browser panel is displayed.

    6. Ensure your message is on the queue, then click Close . The Message Browser panel closes.

    7. Right-click the queue, then select Clear Messages.... The messages on the queue are cleared.

    8. Right-click the queue, then select Delete.... A confirmation panel is displayed, click OK. The queue is deleted.

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.) We can also right-click and select Initiate Failure; the action (local restart or failover) depends on the current state and the configuration settings.

 

Parent topic:

Supporting the Microsoft Cluster Service (MSCS)

fa14240_

 

Home