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
- Migrate the deployment manager. Follow
one of the instruction sets listed in Migrating a deployment manager to complete this task.
- Make sure that the new deployment manager
is running.
- Identify the profiles involved.
- Identify an older version profile that contains cluster
members.
- 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.
- Identify all other profiles
in the same cell that contribute cluster members to any of the clusters
identified in step 3.b.
- 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.
- 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.
- Stop all the node agents and servers that are defined by the first
set of profiles that you will migrate.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.