Queue manager coexistence
Queue managers, with different names, can coexist on any server as long as they use the same IBM MQ installation. On z/OS®, UNIX, Linux , and Windows, different queue managers can coexist on the same server and be associated with different installations.
Single installation queue manager coexistence on all platforms
Single installation queue manager coexistence is useful in development and production environments. In development environments, we can set up different queue manager configurations to support different development activities. We can also work with multiple queue manager configurations on a single server, connected by channels, as if deployed on a network.
In production environments configuring multiple queue manager on a single server is less common. It has no performance or functional advantage over a single queue manager configuration. Sometimes, you must deploy multiple queue managers on server. It might be essential to meet the requirements of a particular software stack, governance, administration, or as a consequence of the consolidation of servers.
Queue manager coexistence in a multi-installation
On UNIX, Linux, and Windows, multi-installation 1 queue manager coexistence became available in Version 7.1.
Multi-installation queue manager coexistence has always been supported on z/OS.
With multi-installation queue manager coexistence on the same server, we can run queue managers at different commands levels on the same server. We can also run multiple queue managers at the same command level, but associate them with different installations.
Multi-installation adds more flexibility to the coexistence of queue managers using a single installation. Any of the reasons behind running multiple queue managers, such as supporting different software stacks, might require different versions of IBM MQ.
The biggest benefit of multi-installation identified by early users, is in upgrading from one version of IBM MQ to another. Multi-installation makes upgrading less risky, less costly, and is more flexible in meeting the migration needs of applications running on a server.
The key to migration flexibility is being able to install a new version alongside an existing installation; see Figure 1, which is extracted from Migrating on UNIX and Linux: side-by side or Migrating on Windows: side-by-side.
When the installation is complete, and verified, migrate queue managers and applications to the new installation; see Figure 2. When migration is complete, uninstall the old installation.
Think of multi-installation as being the basis for a range of migration strategies. At one end is single-stage, in which we only have one installation on a server at a time. At the other end is multi-stage migration, in which you continue to run multiple installations at the same time. In the middle is side-by-side migration. Each of the three strategies is explained in the following tasks:
- Migrating on UNIX and Linux: single-stage or Migrating on Windows: single stage
- Migrating on UNIX and Linux: side-by side or Migrating on Windows: side-by-side
- Migrating on UNIX and Linux: multi-stage or or Migrating on Windows: multi-stage
Migration of queue managers to a new fix level
Another similar use of multi-installation is to support the migration of queue managers to a new fix level; see Figure 3. You maintain two installations, one of which has the latest fix pack applied, and the other has the previous maintenance levels. When we have moved all queue managers to the latest fix pack level, we can replace the previous fix pack with the next fix pack to be released. The configuration allows you to stage the migrating applications and queue managers to the latest fix pack level. We can switch the primary installation designation to the latest fix pack level.
