+

Search Tips   |   Advanced Search

Overview of migration, coexistence, and interoperability


Common migration terminology


Basic migration concepts

Migration is the process of moving the configuration from an older release to a new release, such that the new configuration behaves as closely as possible to the old configuration. The main unit for a migration is the profile, which is migrated in 3 basic steps:

  1. Take a snapshot of the source profile from the old installation.

  2. Create a compatible target profile in the new installation.

  3. Merge the data from the snapshot into the target profile.

Migrating a cell, which contains the deployment manager and federated nodes, requires special attention. Because the deployment manager controls the configuration in the cell, each node must be synchronized with the new deployment manager as it is migrated.


Migration strategies


Migration tools

The tools used to migrate the product configuration are run from the new installation at the target release. If possible, update the new installation to the latest available fix pack before beginning our migration. The WASv9.0 migration tools support migration only from v7.0 or later and do not support migrating within the same release, for example from v9.0 to v9.0. To replicate the configuration across machines of the same version or release, see the information about property-based configuration or use the wsadmin scripting exportWasprofile command in the ConfigArchiveOperations command group for the AdminTask object.

Migration uses the following main command-line tools:

The Configuration Migration Tool (migration wizard), is a GUI tool that guides you through running the command-line tools. The tool detects the source profile and offers the option to "Clone the source profile".

The configuration migration tools deploy the applications as they existed in the source profile onto the target profile. Before migrating the configuration, test the applications in a non-production WAS v9.0 environment. Then, make any changes to the applications necessary to ensure they run in that environment. To identify any required changes, we can scan the applications using the Migration Toolkit for Application Binaries.

We can run the WASMigrationAppInstaller command as many times as necessary to install any applications not installed by the WASPostUpgrade command.

For remote migrations, we can use the createRemoteMigrJar command to create a .jar file that enables us to run the WASPreUpgrade command on a system that does not have WAS installed.

Use the migration tools to migrate applications and configuration information to the new version. See Migrate product configurations.


Mixed-cell environments

Only standard migrations support mixed-cell environments. Clone migrations do not support mixed-cell environments.

A cell can contain nodes from different WAS versions. A WAS v9.0 mixed cell can contain nodes that support WAS v9.0 and v7.0 or later. In a mixed-cell environment, if a member of a cell is older than v7.0, the tools cannot migrate the deployment manager. The administrator must either migrate the nodes to at least Version 7.0 or remove them from the cell.

A mixed cell environment can exist in two ways:

  1. We perform incremental node migration of our existing system.

    1. We migrate the deployment manager to v9.0. The deployment manager has to be at the level of the highest node version. If we have nodes of the previous version, then this migration of the deployment manager creates a mixed cell at the highest version of WAS.

    2. Then when we migrate one node at a time to this new highest version, the cell becomes a cell at the highest version of WAS.

      This cell cannot be at a higher version than the deployment manager.

  2. We migrate the deployment manager to v9.0 and then federate older version nodes to the new version deployment manager. This form of migration is supported for only v7.0 or later nodes.

    1. First, we migrate the deployment manager to v9.0. The deployment manager has to be at the level of the highest node version.
    2. We then can federate nodes from v7.0 or later to the new highest deployment manager version.

    This method of incremental migration leaves the system in a mixed cell environment with nodes administered by a v9.0 deployment manager. Migration planning should eventually include migrations of all nodes to the v9.0 level to ensure consistent administration of the nodes.

Existing functions continue to work in a mixed-cell environment. We should be able to perform reasonable operations, such as run existing applications, perform management operations, such as addNode, create mixed cluster, configure the system, call Mbeans, and deploy applications. New function support in a mixed cell environment can be decided on a case by case basis - based on function, priority and available resources.

When running in a mixed-cell environment, clients might suddenly encounter a situation where the port information about the cluster members of the target cluster has become stale. This situation most commonly occurs when all of the cluster members have dynamic ports and are restarted during a time period when no requests are being sent. The client process in this state will eventually attempt to route to the node agent to receive the new port data for the cluster members, and then use that new port data to route back to the members of the cluster.

If any issues occur that prevent the client from communicating with the node agent, or that prevent the new port data being propagated between the cluster members and the node agent, request failures might occur on the client. In some cases, these failures are temporary. In other cases we need to restart one or more processes to resolve a failure.

To circumvent the client routing problems that might arise in these cases, we can configure static ports on the cluster members. With static ports, the port data does not change as a client process gets information about the cluster members. Even if the cluster members are restarted, or there are communication or data propagation issues between processes, the port data the client holds is still valid. This circumvention does not necessarily solve the underlying communication or data propagation issues, but removes the symptoms of unexpected or uneven client routing decisions.

We can run earlier versions of WAS at the same time without conflict if we use non-default ports in one version.


Potential migration issues

Consider the following issues in a migration or coexistence scenario:


Other information

WAS v9.0 can coexist with v7.0 or later. Depending on the previous version of WAS, port conflicts might exist that must be resolved. See:

WAS migration leverages the existing configuration and applications and changes them to be compatible with the WAS v9.0 environment. Existing application components and configuration settings are applied to the v9.0 environment during the migration process.

If we use an earlier version of WAS, the system administrator might have fine-tuned various application and server settings for the environment. It is important to have a strategy for migrating these settings with maximum efficiency.

We can perform incremental migration of our WAS v7.0 or later configuration by running the migration tools multiple times, each time specifying a different set of profiles. Incremental migration of our WAS usually involves operating the system in a mixed-cell release environment. Migration in this environment involves node migrations at various times and as such, may result in mixed cells running for extended periods of time until migration is complete.


Subtopics