Create a multi-instance queue manager

Create a multi-instance queue manager, creating the queue manager on one server, and configuring IBM® MQ on another server. Multi-instance queue managers share queue manager data and logs.

Most of the effort involved in creating a multi-instance queue manager is the task of setting up the shared queue manager data and log files. You must create shared directories on network storage, and make the directories available to other servers using network shares. These tasks need to be performed by someone with administrative authority, such as root on UNIX and Linux® systems. The steps are as follows:
  1. Create the shares for the data and log files.
  2. Create the queue manager on one server.
  3. Run the command dspmqinf on the first server to collect the queue manager configuration data and copy it into the clipboard.
  4. Run the command addmqinf with the copied data to create the queue manager configuration on the second server.
You do not run crtmqm to create the queue manager again on the second server.

File access control

You need to take care that the user and group mqm on all other servers have permission to access the shares.

On UNIX and Linux, you need to make the uid and gid of mqm the same on all the systems. You might need to edit /etc/passwd on each system to set a common uid and gid for mqm, and then reboot your system.

On Microsoft Windows, the user ID that is running the queue manager processes must have full control permission to the directories containing the queue manager data and log files. You can configure the permission in two ways:
  1. Create a queue manager with a global group as the alternative security principal. Authorize the global group to have full control access to the directories containing queue manager data and log files; see Secure shared queue manager data and log directories and files on Windows. Make the user ID that is running the queue manager a member of the global group. You cannot make a local user a member of a global group, so the queue manager processes must run under a domain user ID. The domain user ID must be a member of the local group mqm. The task, Create a multi-instance queue manager on domain workstations or servers, demonstrates how to set up a multi-instance queue manager using files secured in this way.
  2. Create a queue manager on the domain controller, so that the local mqm group has domain scope, domain local. Secure the file share with the domain local mqm, and run queue manager processes on all instances of a queue manager under the same domain local mqm group. The task, Create a multi-instance queue manager on domain controllers, demonstrates how to set up a multi-instance queue manager using files secured in this way.

Configuration information

Configure as many queue manager instances as you need by modifying the IBM MQ queue manager configuration information about each server. Each server must have the same version of IBM MQ installed at a compatible fix level. The commands, dspmqinf and addmqinf assist you to configure the additional queue manager instances. Alternatively, you can edit the mqs.ini and qm.ini files directly. The topics, Create a multi-instance queue manager on Linux, Create a multi-instance queue manager on domain workstations or servers, and Create a multi-instance queue manager on domain controllers are examples showing how to configure a multi-instance queue manager.

On Windows, UNIX and Linux systems, you can share a single mqs.ini file by placing it on the network share and setting the AMQ_MQS_INI_LOCATION environment variable to point to it.

Restrictions

  1. Configure multiple instances of the same queue manager only on servers having the same operating system, architecture and endianness. For example, both machines must be either 32-bit or 64-bit.
  2. All IBM MQ installations must be at release level 7.0.1 or higher.
  3. Typically, active and standby installations are maintained at the same maintenance level. Consult the maintenance instructions for each upgrade to check whether you must upgrade all installations together.

    Note that the maintenance levels for the active and passive queue managers must be identical.

  4. Share queue manager data and logs only between queue managers that are configured with the same IBM MQ user, group, and access control mechanism. [IBMi]For example, the network share set up on a Linux server could contain separate queue manager data and logs for UNIX and Linux queue managers, but could not contain the queue manager data used by IBM i.

    [IBMi]You can create multiple shares on the same networked storage for IBM i and other UNIX systems as long as the shares are different. You can give different shares different owners. The restriction is a consequence of the different names used for the IBM MQ users and groups between UNIX and IBM i. The fact that the user and group can have the same uid and gid does not relax the restriction.

  5. On UNIX and Linux systems, configure the shared file system on networked storage with a hard, interruptible, mount rather than a soft mount. A hard interruptible mount forces the queue manager to hang until it is interrupted by a system call. Soft mounts do not guarantee data consistency after a server failure.
  6. The shared log and data directories cannot be stored on a FAT, or an NFSv3 file system. For multi-instance queue managers on Windows, the networked storage must be accessed by the Common Internet File System (CIFS) protocol used by Windows networks.
  7. [z/OS] z/OS® does not support multi-instance queue managers. Use queue sharing groups.

    Reconnectable clients do work with z/OS queue managers.