Overview of migration, coexistence, and interoperability

The goal of migration is to reconstruct your earlier version of WebSphere® Application Server in a Version 7.0 environment. Coexistence allows you to create a mixed-version environment that is not in conflict and allows the nodes of all versions to start and run at the same time. Coexistence also facilitates rollback and allows one or the other version to run at one time. Interoperating is exchanging data between two coexisting product installations or between products on different systems.

Introduction

WebSphere Application Server Version 7.0 can coexist with Version 5.1.x and Version 6.x. Depending on the previous version of WebSphere Application Server, port conflicts might exist that must be resolved. Read Coexistence support and Configuring port settings for more information.

WebSphere Application Server Version 7.0 migration leverages the existing configuration and applications and changes them to be compatible with the WebSphere Application Server Version 7.0 environment. Existing application components and configuration settings are applied to the Version 7.0 environment during the migration process.

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

You can perform incremental migration of your WebSphere Application Server Version 5.1.x or Version 6.x configuration by running the migration tools multiple times, each time specifying a different set of instances or profiles.

Incremental migration of your WebSphere Application Server usually involves operating your 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.

A cell can contain nodes from different WebSphere Application Server versions. A WebSphere Application Server Version 7.0 mixed cell can contain nodes that support WebSphere Application Server Version 7.0, Version 6.x, Version 5.1.x. A mixed cell environment can exist in two ways:
  1. You perform incremental node migration of your existing system.
    1. You migrate the deployment manager to Version 7.0. The deployment manager has to be at the level of the highest node version. If you have nodes of the previous version, then this migration of the deployment manager creates a mixed cell at the highest version of WebSphere Application Server.
    2. Then when you migrate one node at a time to this new highest version, the cell becomes a cell at the highest version of WebSphere Application Server.
      Note: This cell cannot be at a higher version than the deployment manager.
  2. You migrate the deployment manager to Version 7.0 and then create and federate older version nodes to the new version deployment manager. This form of migration is supported for only Version 6.0.2, Version 6.1, and Version 7.0 nodes.
    1. First, you migrate the deployment manager to Version 7.0. The deployment manager has to be at the level of the highest node version.
    2. You then can federate nodes from Version 6.0.2, Version 6.1, and Version 7.0 to the new highest deployment manager version. Version 5.1.x nodes are not supported in this form of migration.
    Avoid trouble Avoid trouble: This method of incremental migration leaves your system in a mixed cell environment with nodes administered by a Version 7.0 deployment manager. Your migration planning should eventually include migrations of all nodes to the Version 7.0 level to ensure consistent administration of the nodes.gotcha

Existing functions continue to work in a mixed cell environment. You 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.

Avoid trouble Avoid trouble: gotcha: 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 you need to restart one or more processes to resolve a failure.

To circumvent the client routing problems that might arise in these cases, you 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.

gotcha
Migration involves the following main steps:
  1. Test your applications in a non-production WebSphere Application Server Version 7.0 environment, and make any changes to the applications that are necessary to ensure that they run in that environment.
  2. Migrate those applications and your configuration to Version 7.0.

    You can complete this task by using the migration tools that are included with the product.

Use the migration tools to migrate applications and configuration information to the new version as described in Migrating product configurations. Read Migrating product configurations with migration tools for more information.

Important reference articles for this migration include the following articles:
  • manageprofiles command.
  • Migrating servers from multi-broker replication domains to data replication domains
  • Comparison of multi-broker versus data replication domains
  • Migrating to Version 3 of the UDDI registry
  • Migrating a complete gateway configuration
  • Migrating from Version 5.1 embedded messaging
  • Managing WebSphere Application Server Version 5.1 JMS use of messaging resources in later versions of the product

If you neither migrate nor coexist with an earlier version of WebSphere Application Server, you are choosing to ignore the previous installation and you can run only one version at a time because of conflicting default port assignments. It is possible for both versions to run at the same time without conflict if you use non-default ports in one version. To set up coexistence withWebSphere Application Server Version 5.1.x or Version 6.x, ensure that unique ports are selected during profile creation for the Version 7.0 installation. To set up coexistence with an existing installation of Version 7.0, select the Install a new copy of the V70 Application Server product radio button during installation.

You can resolve conflicting port assignments by specifying port assignments for coexistence during profile creation, by wsadmin scripting, or by using the Servers > Application Servers > server1 > Ports administrative console page to ensure that WebSphere Application Server Version 7.0 can run with an earlier version. Read the "Wsadmin tool" article in the information center for more information on wsadmin scripting.

Coexistence processing changes the following configuration files:
  • virtualhosts.xml
  • serverindex.xml

Read Port number settings in WebSphere Application Server versions for more information.

Consider the following issues in a migration or coexistence scenario:
  • Conflicting context roots when attempting to share the same Web server.

    Follow the procedure in Migrating Web server configurations to learn how to configure a Web server for sharing between WebSphere Application Server versions.

  • A WebSphere Application Server Version 7.0 WebSphere Application Server, Network Deployment cell can contain mixed releases of Version 5.1.x or Version 6.x nodes, but there is no mixed-node management support for Version 6.0.0.x and Version 6.0.1.x.
    The Version 7.0 migration tools still migrate these nodes during deployment-manager migration, but the tools issue a warning message that the nodes cannot be managed by the Version 7.0 deployment manager. You can then perform one of the following actions based on your needs.
    • Upgrade all Version 6.0.0.x and Version 6.0.1.x nodes to at least Version 6.0.2.

      This action allows the nodes to be administered by a Version 7.0 deployment manager.

    • Migrate these nodes to Version 7.0.



Related tasks
Migrating product configurations
Migrating and coexisting application servers
Concept topic Concept topic    

Terms and conditions for information centers | Feedback

Last updatedLast updated: Feb 6, 2014 2:52:03 AM CST
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=compass&product=was-nd-iseries&topic=cmig_overview
File name: cmig_overview.html