Multi-instance queue managers on IBM i

Multi-instance queue managers improve availability by automatically switching to a standby server if the active server fails. The active and standby servers are multiple instances of the same queue manager; they share the same queue manager data. If the active instance fails you need to transfer its journal to the standby that takes over so that the queue manager can rebuild its queues.

Configure the IBM i systems we are running multi-instance queue managers on so that, if the active queue manager instance fails, the journal it is using is available to the standby instance that takes over. We can design your own configuration and administration tasks to make the journal from the active instance available to the instance that takes over. If we do not want to lose messages, your design must ensure the standby journal is consistent with the active journal at the point of failure. We can adapt your design from one of the two configurations that are described with examples in subsequent topics that do maintain consistency.

  1. Mirror the journal from the system that is running the active queue manager instance to the systems that are running standby instances.
  2. Place the journal in an Independent Auxiliary Storage Pool (IASP) that is transferable from the system running the active instance to a standby instance.

The first solution requires no additional hardware or software as it uses basic ASPs. The second solution requires switchable IASPs which need IBM i clustering support that is available as a separately priced IBM i License Product 5761-SS1 Option 41.

  • Reliability and availability on IBM i
    Multi-instance queue managers aim to improve the availability of applications. Technological and physical constraints mean we need different solutions to meet the demands of disaster recovery, backing up queue managers and continuous operation.
  • Components of a high availability solution on IBM i
    Construct a high availability solution using multi-instance queue managers by providing robust networked storage for queue manager data, journal replication or robust IASP storage for queue manager journals, and using reconnectable clients, of applications configured as restartable queue manager services.
  • Failover performance on IBM i
    The time it takes to detect a queue manager instance has failed, and then to resume processing on a standby can vary between tens of seconds to fifteen minutes or more depending on the configuration. Performance needs to be a major consideration in designing and testing a high availability solution.
  • 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.
  • Mirrored journal configuration for ASP on IBM i
    Configure a robust multi-instance queue manager using synchronous replication between mirrored journals.
  • Switched independent ASP journal configuration on IBM i
    You do not need to replicate an independent ASP journal to create a multi-instance queue manager configuration. You do need to automate a means to transfer the independent ASP from the active queue manager to the standby queue manager. There are alternative high availability solutions possible using an independent ASP, not all of which require using a multi-instance queue manager.
  • Delete a multi-instance queue manager on IBM i
    Before you delete a multi-instance queue manager, stop remote journaling, and remove queue manager instances.
  • Backing up a multi-instance queue manager on IBM i
    The procedure shows you how to back up queue manager objects on the local server and the queue manager data on the network file server. Adapt the example to back up data for other queue managers.
  • Commands to set up multi-instance queue managers
    IBM MQ has commands to simplify configuring journal replication, adding new queue manager instances, and configuring queue managers to use independent ASP.

Parent topic: Availability, backup, recovery, and restart on IBM i