Put a queue manager under MSCS control

The tasks involved in placing a queue manager under MSCS control, including prerequisite tasks.


Before you put a queue manager under MSCS control

Before you put a queue manager under MSCS control, perform the following tasks:
  1. Ensure that IBM MQ and its MSCS Support are installed on both machines in the cluster and that the software on each computer is identical, as described in Set up IBM MQ for MSCS clustering.
  2. Use the haregtyp utility program to register IBM MQ as an MSCS resource type on all the cluster nodes. See Support for MSCS utility programs for additional information.
  3. If we have not yet created the queue manager, see Create a queue manager for use with MSCS.
  4. If we have created the queue manager, or it already exists, ensure that we 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 IBM MQ Explorer.
  6. Test MSCS operation of the shared drives before going on to either of the following Windows procedures in this topic.


Windows Server 2012

To place a queue manager under MSCS control on Windows Server 2012, use the following procedure:
  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 Failover Cluster Management tool.
  3. Right-click Failover Cluster Management > Connect Cluster ... to open a connection to the cluster.
  4. In contrast to the group scheme used in the MSCS Cluster Administrator on previous versions of Windows, the Failover Cluster Management tool uses the concept of services and applications. A configured service or application contains all the resources necessary for one application to be clustered. We can configure a queue manager under MSCS as follows:
    1. Right-click on the cluster and select Configure Role to start the configuration wizard.
    2. Select Other Server on the "Select Service or Application" panel.
    3. Select an appropriate IP address as a client access point.

      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.

    4. Assign a storage device for exclusive use by the queue manager. This device needs to be created as a resource instance before it can be assigned.

      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 we are using; refer to your SCSI adapter instructions. There might already be groups and resources for each of the shared drives. If so, we do not need to create the resource instance for each drive. 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.

    5. Select the MQSeries MSCS resource on the "Select Resource Type" panel.
    6. Complete the remaining steps in the wizard.

  5. Before bringing the resource online, the MQSeries MSCS resource needs additional configuration:
    1. Select the newly defined service which contains a resource called 'New MQSeries MSCS'.
    2. Right-click Properties on the MQ resource.
    3. Configure the resource:

      • Name ; choose a name that makes it easy to identify which queue manager it is for.
      • 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 IBM 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 IBM 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 in MSCS.
        • 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 in MSCS. Note: The looksAlive poll interval is set to default value of 5000 ms. The isAlive poll interval is set to default value of 60000 ms. These defaults can only be modified after the resource definition has been completed. For further details see looksAlive and isAlive polling on MSCS.

    4. Optionally, set a preferred node (but note the comments in Use preferred nodes in MSCS )
    5. The Failover Policy 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.

  6. Test the queue manager by bringing it online in the MSCS Cluster Administrator and subjecting it to a test workload. If we are experimenting with a test queue manager, use the IBM 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 that 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.

  7. Test that the queue manager can be taken offline and back online using the MSCS Cluster Administrator.
  8. 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 we 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.


Windows Server 2008

To place a queue manager under MSCS control on Windows Server 2008, use the following procedure:
  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 Failover Cluster Management tool.
  3. Right-click Failover Cluster Management > Manage a Cluster ... to open a connection to the cluster.
  4. In contrast to the group scheme used in the MSCS Cluster Administrator on previous versions of Windows, the Failover Cluster Management tool uses the concept of services and applications. A configured service or application contains all the resources necessary for one application to be clustered. We can configure a queue manager under MSCS as follows:
    1. Right-click Services and Applications > Configure a Service or Application ... to start the configuration wizard.
    2. Select Other Server on the Select Service or Application panel.
    3. Select an appropriate IP address as a client access point.

      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.

    4. Assign a storage device for exclusive use by the queue manager. This device needs to be created as a resource instance before it can be assigned.

      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 we are using; refer to your SCSI adapter instructions. There might already be groups and resources for each of the shared drives. If so, we do not need to create the resource instance for each drive. 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.

    5. Select the MQSeries MSCS resource on the Select Resource Type panel.
    6. Complete the remaining steps in the wizard.

  5. Before bringing the resource online, the MQSeries MSCS resource needs additional configuration:
    1. Select the newly defined service which contains a resource called 'New MQSeries MSCS'.
    2. Right-click Properties on the MQ resource.
    3. Configure the resource:

      • Name ; choose a name that makes it easy to identify which queue manager it is for.
      • 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 IBM 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 IBM 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 in MSCS.
        • 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 in MSCS. Note: The looksAlive poll interval is set to default value of 5000 ms. The isAlive poll interval is set to default value of 60000 ms. These defaults can only be modified after the resource definition has been completed. For further details see looksAlive and isAlive polling on MSCS.

    4. Optionally, set a preferred node (but note the comments in Use preferred nodes in MSCS )
    5. The Failover Policy 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.

  6. Test the queue manager by bringing it online in the MSCS Cluster Administrator and subjecting it to a test workload. If we are experimenting with a test queue manager, use the IBM 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 that 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.

  7. Test that the queue manager can be taken offline and back online using the MSCS Cluster Administrator.
  8. 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 we 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.


Windows 2003

To place a queue manager under MSCS control on Windows 2003, use the following procedure:
  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 Use 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 we are using; refer to your SCSI adapter instructions. There might already be groups and resources for each of the shared drives. If so, we do not need to create the resource instance for each drive. 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 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 ; 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 IBM 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 IBM 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 in MSCS.
      • 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 in MSCS. Note: The looksAlive poll interval is set to default value of 5000 ms. The isAlive poll interval is set to default value of 30000 ms. These defaults can only be modified after the resource definition has been completed. For further details see looksAlive and isAlive polling on MSCS.

  8. Optionally, set a preferred node (but note the comments in Use preferred nodes in MSCS )
  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 we are experimenting with a test queue manager, use the IBM 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 that 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 we 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)