Migrating a WebSphere MQ broker network

The procedure that you must follow to migrate a WebSphere MQ broker that is part of a multi-broker network is basically the same as that needed to migrate a single broker.

Before you start the migration, you must consider:

Refer to Planning for migration for more information.

The following sequence of figures illustrates the migration of a network of three brokers. The actions taken to migrate the network assumes that the three brokers are migrated one at a time, and that all three are to be grouped in a single collective in the WebSphere Message Broker broker domain.

The WebSphere MQ broker network that is to be migrated has three brokers, the root (NEWYORK) and two children (LONDON and TOKYO).

A <ph conref='edvent.dita#edvent/mqs'></ph> broker network with three brokers, the root (NEWYORK) and two children (LONDON and TOKYO).
These brokers do not have to be migrated in any particular order. This example shows the migration being done in the following order:
  1. LONDON
  2. NEWYORK
  3. TOKYO

The migration is completed in a number of separate steps. Each step is best taken when network traffic is low (for example, at weekends). The whole migration is planned in three stages:

Stage 1: migration of the LONDON broker

The steps that you need to take to migrating a single broker within a network are exactly the same as those that you need to take to migrate a standalone WebSphere MQ broker. See Migrating WebSphere MQ brokers.

  1. Quiesce all client applications at both the LONDON and NEWYORK brokers. This ensures that no publications are missed by any subscribers while the topology is being changed.
  2. Quiesce all other brokers in the network (in this example, the TOKYO broker). This guarantees that no publications are delivered while the topology is being changed.
After the migration of the LONDON broker you have a mixed network, consisting of two WebSphere MQ brokers (NEWYORK and TOKYO) and one WebSphere Message Broker broker:

A mixed broker network with three brokers (two <ph conref='edvent.dita#edvent/mqs'></ph> brokers (NEWYORK and TOKYO) and one <ph conref='edvent.dita#edvent/mqsi'></ph> broker)

The connection between the LONDON and NEWYORK brokers is a WebSphere MQ connection. The workbench only recognizes WebSphere Message Broker brokers, and therefore only LONDON has been defined to it. A WebSphere Message Broker connection cannot be created at this stage.

This mixed network is in a perfectly valid state. It can remain in this state until you are ready to do the next stage of the migration.

Stage 2: migration of the NEWYORK broker

Follow the step-by-step procedure for migrating a single broker for broker NEWYORK. This is described in Migrating WebSphere MQ brokers.

  1. Quiesce all client applications at all brokers to which NEWYORK is a neighbor; in this network, LONDON and TOKYO. This ensures that no publications are missed by any subscribers while the topology is being changed.
  2. Quiesce all the brokers in the network. This guarantees that no publications are delivered while the topology is being changed.
The network now contains two WebSphere Message Broker brokers (LONDON and NEWYORK), and one WebSphere MQ broker (TOKYO):

A mixed broker network with three brokers (one <ph conref='edvent.dita#edvent/mqs'></ph> broker (TOKYO) and two <ph conref='edvent.dita#edvent/mqsi'></ph> brokers (LONDON and NEWYORK)

The LONDON and NEWYORK brokers are still connected by a WebSphere MQ connection. They can remain connected in this way for as long as necessary. However, to develop applications that use the functions provided by WebSphere Message Broker you must join the two WebSphere Message Broker brokers together using the workbench.

The connection can be upgraded to a WebSphere Message Broker connection by first removing the original WebSphere MQ connection between LONDON and NEWYORK.

To remove this connection, issue the WebSphere Message Broker command mqsiclearmqpubsub at both brokers:
mqsiclearmqpubsub NEWYORK -n LONDON
mqsiclearmqpubsub LONDON -n NEWYORK
The network now looks like this:

Three brokers; <ph conref='edvent.dita#edvent/mqs'></ph> broker (TOKYO) is connected to the <ph conref='edvent.dita#edvent/mqsi'></ph> broker (NEWYORK); <ph conref='edvent.dita#edvent/mqsi'></ph> broker (LONDON) has no connection to either of the other two brokers.

Now use the workbench to define the relationship between the two brokers, LONDON and NEWYORK. Both brokers are already defined, but the collective to which they are to be assigned is not. You can define this collective from the Topology view, and assign the two brokers to it. All brokers in a collective are assumed to be connected, so you do not have to make those connections using the workbench.

The new topology can now be deployed. The connection between LONDON and NEWYORK is now implemented using WebSphere Message Broker functions. The network is now:

Three brokers; <ph conref='edvent.dita#edvent/mqs'></ph> broker (TOKYO) is connected to the <ph conref='edvent.dita#edvent/mqsi'></ph> broker (NEWYORK); <ph conref='edvent.dita#edvent/mqsi'></ph> brokers (LONDON and NEWYORK) are joined by a <ph conref='edvent.dita#edvent/mqsi'></ph> interbroker connection.

The two brokers, LONDON and NEWYORK, are no longer in a parent-child relationship but are neighbors within a collective. The topology of the WebSphere Message Broker network is not based on a hierarchical structure as was the WebSphere MQ network.

Now that LONDON and NEWYORK form a collective, there is no root node left in the WebSphere MQ network. NEWYORK is the gateway between the WebSphere MQ broker (TOKYO) and the WebSphere Message Broker collective of brokers.

Stage 3: migration of the TOKYO broker

The final WebSphere MQ broker, TOKYO, is now ready to be migrated. Follow the procedure described in Migrating WebSphere MQ brokers.

The network is now:

There are three <ph conref='edvent.dita#edvent/mqsi'></ph> brokers (LONDON, NEWYORK, and TOKYO); brokers LONDON and NEWYORK are joined by a <ph conref='edvent.dita#edvent/mqsi'></ph> interbroker connection, and brokers NEWYORK and TOKYO are joined by a <ph conref='edvent.dita#edvent/mqs'></ph> connection.
The WebSphere MQ connection between TOKYO and NEWYORK can now be broken. This is done by using the following commands:
mqsiclearmqpubsub NEWYORK -n TOKYO
mqsiclearmqpubsub TOKYO -n NEWYORK

Now use the workbench to add the TOKYO broker to the WebSphere Message Broker network, and to the collective. The operation of a collective requires that all brokers have direct physical connections with each other (via WebSphere MQ).

Before the topology of the new WebSphere Message Broker network can be deployed, a WebSphere MQ connection between LONDON and TOKYO is required. A series of WebSphere MQ commands must be invoked to define the channels and transmission queues that support two-way traffic.

When you have completed the migration of all the brokers in the collective, you have removed the single point of failure at the NEWYORK broker. Subscribers on the LONDON broker can receive publications from the TOKYO broker even when the NEWYORK broker is not running.

Before migration, traffic between brokers was always routed through NEWYORK, the root node, which was therefore the single point of failure.

For further details of connecting brokers to each other, see Configuring the broker domain. For more general information about distributed WebSphere MQ networks, refer to WebSphere MQ Intercommunication.

When all migration and associated tasks have been completed, the network comprises a single collective, containing three WebSphere Message Broker brokers connected as equals.

This is the migrated <ph conref='edvent.dita#edvent/mqs'></ph> network; three <ph conref='edvent.dita#edvent/mqsi'></ph> brokers (LONDON, NEWYORK, and TOKYO) fully interconnected to form a collective.

A network of migrated brokers

The following diagram shows a mixed network of WebSphere Message Broker and WebSphere MQ brokers. Brokers NEWYORK, LONDON, and TOKYO have been migrated to form a WebSphere Message Broker collective. All the other brokers remain as WebSphere MQ brokers.

This is shows the migrated <ph conref='edvent.dita#edvent/mqs'></ph> network ( three <ph conref='edvent.dita#edvent/mqsi'></ph> brokers (LONDON, NEWYORK, and TOKYO) fully interconnected to form a collective) as part of a larger <ph conref='edvent.dita#edvent/mqs'></ph> network.