WebSphere Enterprise Service Bus, Version 6.2.0 Operating Systems: AIX, HP-UX, i5/OS, Linux, Solaris, Windows


Migrating a cluster with minimal down time

To migrate a cluster while minimizing down time, first migrate approximately half of the profiles contributing to the cluster, then migrate the other half. Perform the extra steps required for cluster migration after you have migrated the first set of profiles.

Before you begin

You must have an existing cell containing at least one cluster running on an older version of WebSphere® ESB (for example, version 6.0.x or 6.1.x) that you wish to migrate to a newer version (for example, version 6.2). In addition, you must have installed the new version of WebSphere ESB.
Important: In a cluster, version 6.0.x or 6.1.x members and version 6.2 members must never run at the same time. All version 6.0.x or 6.1.x cluster members must be stopped before you start the first version 6.2 cluster member. Also, once you start a version 6.2 cluster member, do not start any version 6.0.2.x cluster members in that cluster.

About this task

Following these steps will ensure that you retain cluster functionality on the new version of WebSphere ESB with minimal downtime.
Restriction: The following procedure is supported only if you are migrating from version 6.1.x to version 6.2. If you are migrating from version 6.0.2.x, and you want to minimize downtime while migrating a cluster, you must migrate to version 6.1.x first, then migrate to version 6.2.
Procedure
  1. Migrate the deployment manager. Follow one of the instruction sets listed in Migrating a deployment manager to complete this task.
  2. Make sure that the new deployment manager is running.
  3. Identify the profiles involved.
    1. Identify an older version profile that contains cluster members.
    2. Identify which other clusters this profile contributes to; that is, if the profile defines servers that are members of any other clusters, identify those clusters.
    3. Identify all other profiles in the same cell that contribute cluster members to any of the clusters identified in step 3.b.
    4. Identify all the node agents and process servers defined by any of the profiles identified in step 3.c.
    All of the profiles identified in step 3.c, and all of the corresponding node agents and servers identified in step 3.d will be involved in the migration.
  4. Define two groups of profiles out of the full set of profiles identified in step 3. Divide the profiles into roughly half (If the total number of profiles is an odd number, one group will consist of one more in number than the other group). You will migrate one set of servers while the other set is still running, thus reducing the amount of time when all servers in the cluster are stopped.
  5. Stop all the node agents and servers that are defined by the first set of profiles that you will migrate.
  6. Migrate each profile in the first set, one at a time, but do not start any new node agents or servers. Follow one of the instruction sets listed in either Migrating cluster members using the migration wizard or Migrating cluster members using the command-line tools.
  7. Stop the remaining node agents and servers; that is, those defined by the second set of profiles. This action starts the period of time when cluster services will be unavailable.
  8. On the system that hosts the WebSphere ESB version 6.2 deployment manager profile, navigate to the install_dir/util directory. This directory contains the WBIProfileUpgrade script, WBIProfileUpgrade.ant.
  9. Run the WBIProfileUpgrade script for each cluster defined in the profiles that have been migrated so far. (That is, run WBIProfileUpgrade for each cluster defined in step 3.) For instructions on running WBIProfileUpgrade, see WBIProfileUpgrade script.
  10. Start all the new (migrated) node agents and servers; that is, the node agents and servers corresponding to the profiles that have been migrated so far.
  11. Migrate each profile in the second set of profiles As with the first set, to migrate, follow one of the instruction sets listed in either Migrating cluster members using the migration wizard or Migrating cluster members using the command-line tools. This time, you can start the migrated node agents and servers as you proceed to migrate each managed node.

Results

The cluster is now migrated to the new version of WebSphere ESB.

What to do next

Verify that the migration has been successful.

task Task topic

Terms of use | Feedback


Timestamp icon Last updated: 21 June 2010


http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic//com.ibm.websphere.wesb620.doc/doc/tmig_vtv_migclust_min.html
Copyright IBM Corporation 2005, 2010. All Rights Reserved.
This information center is powered by Eclipse technology (http://www.eclipse.org).