Start of change

Migrating a high availability domain

Before you start

This task is part of the following larger task: See the larger task to understand the context of this task and what you must do before you start this task.

This topic describes general considerations for migrating a high availability domain. Refer to the product specific migration topics for detailed migration instructions.

High availability is the requirement for a system to be running all, or a very high proportion of, the time. Providing a high availability environment involves having multiple brokers so that some brokers can be used for backup purposes. The entire production domain might be duplicated so that the backup system can be switched on in the event of a problem.

Migration presents a problem in providing a high availability environment because there is a window of time between the stopping of the previous version of the product and the installation and starting of WebSphere Business Integration Message Broker Version 6.0. A solution is to install and configure WebSphere Business Integration Message Broker Version 6.0 while the previous version of the product is running in parallel, and then switch to using WebSphere Business Integration Message Broker Version 6.0. You can install WebSphere Business Integration Message Broker Version 6.0 on either the same systems that are running the previous version of the product, or on a different set of systems.

The following sections of this topic provide a general framework for how you might want to migrate your high availability domain. You might need to adjust these instructions to suit your specific circumstances. Refer to the product specific migration topics for detailed migration instructions.

Preparing to migrate a high availability domain

To achieve high availability migration, your environment must be configured correctly. Complete the following tasks:
  1. Ensure that the production domain that is to be migrated is configured for high availability. You must have at least three brokers supporting the executing applications, so that when broker 1 is being migrated, brokers 2 and 3 can provide backup support for each other. This is a standard setup for a high availability domain at all times, and is not specific to migration.
  2. Ensure that the test domain is identical to the production domain. This means that you can identify any problems during the migration of the test domain and resolve them before you migrate the production domain.

Migrating the test domain

The purpose of migrating the test domain before migrating the production domain is to identify any problems that might arise during migration. For example, if problems arise you might need to restore some migrated resources to the level that you backed up before you started the migration, and any post-migration changes to these resources would be lost. Testing the migration allows you to fix problems like this and develop a strategy for dealing with further problems.

To migrate the test domain, complete the following tasks. Refer to the product specific migration topics for detailed migration instructions.

  1. Back up your resources from the previous version of the product.
  2. Install WebSphere Business Integration Message Broker Version 6.0, and create a Configuration Manager and a broker, on as many systems as is required to mirror the production domain.
  3. Test the migration of your resources to WebSphere Business Integration Message Broker Version 6.0:
    1. In message flow and message set development, one developer is often responsible for a given area of functionality. Move one of these functional areas to Version 6.0 one by one, by migrating the Message Brokers Toolkit and the resources used by the developer responsible for that area.
    2. Test that the migrated resources work as required, [HOW DO YOU TEST THIS? IN STEPS 3 AND 4 YOU DO IT BY DEPLOYING. IS THIS JUST A VISUAL INSPECTION?] and resolve any problems.
    3. Repeat steps a and b for the remaining functional areas.

    Migrating the functional areas one by one means that existing development can continue on the previous version of the product.

    Except for user-defined extensions, you do not need to perform any tasks to migrate your resources to Version 6.0. However, after you start using your resources with Message Brokers Toolkit Version 6.0, there are restrictions to using the same resources again with in Message Brokers Toolkit Version 5.0 or Version 5.1. See Conditions for using migrated resources with previous versions of the Message Brokers Toolkit for more information.

  4. Associate the brokers from the previous version of the product to the Version 6.0 Configuration Manager. Complete the following steps:
    1. Associate a broker from the previous version of the product to the Version 6.0 Configuration Manager.
    2. Test that your resources still work as required by deploying your migrated resources using this broker [SHOULD YOU DEPLOY ALL RESOURCES, OR ONLY ONES ASSOCIATED WITH THAT BROKER?], and resolve any problems.
    3. Repeat steps a and b for the remaining brokers from the previous version of the product.

    Moving the brokers one at a time means that only small changes are made at each stage. If problems occur, other brokers that have not been migrated yet can process requests while the migration problems as resolved. If required, the brokers can be moved back to their original Configuration Manager.

  5. Migrate the brokers from the previous version of the product to WebSphere Business Integration Message Broker Version 6.0. Complete the following steps:
    1. Migrate a broker from the previous version of the product to WebSphere Business Integration Message Broker Version 6.0.
    2. Test that your resources still work as required by deploying your migrated resources using this broker [SHOULD YOU DEPLOY ALL RESOURCES, OR ONLY ONES ASSOCIATED WITH THAT BROKER?], and resolve any problems.
    3. Repeat steps a and b for the remaining brokers from the previous version of the product.

Migrating the production domain

To migrate the production domain, complete the following tasks. Refer to the product specific migration topics for detailed migration instructions.
  1. Back up your resources from the previous version of the product.
  2. Configure an administration system with the Version 6.0 Message Brokers Toolkit. This allows you to administer the new Version 6.0 components.
  3. Migrate your resources, taking into account any problems you identified when you tested the migration of your resources earlier.
  4. Create a Version 6.0 Configuration Manager, and connect the Message Brokers Toolkit to this Configuration Manager.
  5. Associate the brokers from the previous version of the product to the Version 6.0 Configuration Manager. Complete the following steps:
    1. Associate a broker from the previous version of the product to the Version 6.0 Configuration Manager.
    2. Test that your resources still work as required by deploying your migrated resources using this broker [SHOULD YOU DEPLOY ALL RESOURCES, OR ONLY ONES ASSOCIATED WITH THAT BROKER?], and resolve any problems.
    3. Repeat steps a and b for the remaining brokers from the previous version of the product.

    Moving the brokers one at a time means that only small changes are made at each stage. If problems occur, other brokers that have not been migrated yet can process requests while the migration problems as resolved. If required, the brokers can be moved back to their original Configuration Manager.

  6. Migrate the brokers from the previous version of the product to WebSphere Business Integration Message Broker Version 6.0. Complete the following steps:
    1. Migrate a broker from the previous version of the product to WebSphere Business Integration Message Broker Version 6.0.
    2. Test that your resources still work as required by deploying your migrated resources using this broker [SHOULD YOU DEPLOY ALL RESOURCES, OR ONLY ONES ASSOCIATED WITH THAT BROKER?], and resolve any problems.
    3. Repeat steps a and b for the remaining brokers from the previous version of the product.


End of change