+

Search Tips | Advanced Search

Overview of combining IBM i clustering capabilities with IBM MQ clustering

Running IBM MQ on IBM i, and exploiting the IBM i clustering capabilities can provide a more comprehensive High Availability solution, than using only IBM MQ clustering.

To have this capability, set up:
  1. Clusters on the IBM i machine; see IBM i clusters
  2. An independent auxiliary storage pool (IASP), into which you move the queue manager; see Independent auxiliary storage pools (IASPs)
  3. A cluster resource group (CRG); see Device cluster resource groups, in which you define the:


IBM i clusters

An IBM i cluster is a collection of instances, that is IBM i computers or partitions, that are logically linked together.

The purpose of this grouping is to allow for each instance to be backed up, eliminating a single point of failure and increasing application and data resiliency. With a cluster created, the various cluster resource group (CRG) types can be configured to manage applications, data, and devices in the cluster.

See Create a cluster and the Create Cluster (CRTCLU) command for further information.


Independent auxiliary storage pools (IASPs)

An IASP is a type of user ASP that serves as an extension of single-level storage. It is a piece of storage that, due to its independence from the system storage, can be easily manipulated without having to IPL the system.

An IASP can be easily switched to another operating system instance or replicated to a target IASP on another operating system instance. Two methods can be used to switch an IASP between instances:

  • The first method requires all the computers in the cluster, and the switchable disk tower containing the IASP, to be connected using a High Speed Link (HSL) loop.
  • The second method requires the operating system instances to be partitions on the same IBM i computer where input/output processors (IOPs) can be switched between partitions. No special hardware is needed to be able to replicate an IASP. The replication is performed using TCP/IP over the network.

See the Configure Device ASP (CFGDEVASP) command for more information.


Device cluster resource groups

There are several types of cluster resource groups (CRGs). For more information about the different types of CRGs available, see Cluster resource group.

This topic concentrates on a device CRG. A device CRG:

  • Describes and manages device resources such as independent auxiliary storage pools (IASPs).
  • Defines the recovery domain of the cluster nodes
  • Assigns a device, and
  • Assigns the exit program that will handle cluster events.

The recovery domain denotes which cluster node will be considered as the primary node. The rest of the nodes are considered to be backups. The backup nodes are also ordered in the recovery domain, specifying which node is the first backup, the second backup, and so on, depending on how many nodes there are in the recovery domain.

In the event of a primary node failure, the exit program is run on all nodes in the recovery domain. The exit program running on the first backup can then make the necessary initializations to make this node the new primary node.

See Create device CRGs and the Create Cluster Resource Group (CRTCRG) command for more information.


Device CRG exit program

The operating system cluster resource service calls a device CRG exit program when an event occurs in one of the nodes the recovery domain defines; for example, a failover or switchover event.

A failover event occurs when the primary node of the cluster fails and the CRGs are switched with all the resources they manage, and a switchover event occurs when a specific CRG is manually switched from the primary node to the backup node.

Either way, the exit program is in charge of initializing and starting all the programs that were running on the previous primary node, which converts the first backup node into the new primary node.

For example, with IBM MQ, the exit program should be in charge of starting the IBM MQ subsystem (QMQM), and queue managers. Queue managers should be configured to automatically start listeners and services, such as trigger monitors.

A sample exit program, AMQSCRG4, is available on IBM i from IBM MQ Version 9.1.


Switchable IASP configuration

IBM MQ can be set up to take advantage of the clustering capabilities of IBM i. To do this:
  1. Create an IBM i cluster between the data center systems
  2. Move the queue manager to an IASP.

    Moving, or removing, a queue manager to, or from, an independent auxiliary storage pool contains some sample code to help you carry out this operation.

  3. We need to create a CRG defining the recovery domain, the IASP, and the exit program.

    Configure a device cluster resource group contains some sample code to help you carry out this operation.

Parent topic: Multi-instance queue managers on IBM i


Related concepts

Last updated: 2020-10-04