Roadmap: Migrating and coexisting application servers
Migrating involves collecting the configuration information from a previous release of a WebSphere Application Server and merging it into a configuration for a new release. Coexisting involves running a new release of a WAS and an earlier release simultaneously on the same machine.
Review...
- Overview of migration, coexistence, and interoperability
- Migration considerations
- Knowledge Collection: Migration planning for WAS
The migration tools basically save the existing WebSphere configurations and user applications in a backup directory and then process the contents of this backup directory to migrate the configurations and the applications from previous WAS releases to the latest release.
If we have a previous version of WAS, we must decide whether to migrate the configuration and applications of the previous version to the new version.
Migration does not uninstall the previous version.
- For stand-alone application server migrations and for deployment-manager migrations in which we do not choose to disable the previous deployment manager during migration, the earlier release is still functional.
- For federated-node migrations and for deployment-manager migrations in which we do choose to disable the previous deployment manager during migration, the earlier release is disabled after migration completes successfully. We can re-enable the earlier version using the migrationDisablementReversal.jacl script.
If we run two different versions of the application server at the same time, the two versions are coexisting. For example, if v7.0 and 8.5 application servers are running on the same machine, they are coexisting.
To support coexistence, we must either use the -setPorts and -resolvePortConflicts options when we migrate a profile or we must resolve port conflicts manually so that the two releases do not attempt to use the same ports. Any ports bound when the first profile starts will prevent the second profile from starting because the port is in use. No port changes are required if only one release of the profile is active at any given time.
For help in troubleshooting problems when migrating, read Troubleshoot migration.
For information on migrating to v9.0, read Migrate product configurations. For more information on coexistence among releases, read Run coexisting application servers.
Tasks
- Update product prerequisites and corequisites to supported versions.
Refer to the IBM WAS supported hardware, software, and APIs site for current requirements.
- Install the v9.0 product.
After installing WAS v9.0, we might want to build a complete WAS ND cell configuration and verify that it works correctly before we attempt to migrate an existing cell or node. This process ensures that the system has all of the necessary prerequisites and supports the new level of WAS.
Read the Install and configure the application serving environment article.
- Migrate the WAS v7.0 or later product configuration to v9.0.
We have the choice between migrating the configuration automatically using the migration tools or manually.
- Use the migration tools to automatically migrate the configuration.
Read Use the migration tools for more information.
The following two WAS ND migration scenarios are possible:
- Automated migration with all-node upgrade
In this scenario, we use the migration tools to migrate the deployment manager as well as all of its federated nodes.
There are the following advantages and considerations with this approach:
- Advantages
- Copies the old configuration automatically, including all resource definitions, virtual host definitions, security settings, cluster definitions, and so forth.
- Recreates the same exact v7.0 or later configuration in v9.0, including the node definitions, server definitions, and deployed applications by default.
- We can enable support for script compatibility.
- Considerations
- Have a good idea of how long it will take to migrate the configuration before beginning.
- Migrate within a maintenance window.
- Automated migration with mixed-node utilization
This scenario involves the following activities:
- Use the migration tools to migrate the deployment manager only.
- Add v9.0 nodes.
- Move the applications to v9.0 as they are tested on v9.0.
- Remove v7.0 or later nodes from the cell when they are no longer needed.
There are the following advantages and considerations with this approach:
- Advantages
- Copies the old configuration automatically, including all resource definitions, virtual host definitions, security settings, cluster definitions, and so forth.
- Recreates the same exact v7.0 or later configuration in v9.0, including the node definitions, server definitions, and deployed applications by default.
- We can have a mixed-node configuration.
- We can enable support for script compatibility.
- We can move applications iteratively.
- Considerations
- We should have a good idea of how long it will take to migrate the configuration before beginning.
- We should migrate within a maintenance window.
- Manually migrate the configuration.
Migrate the configuration manually involves the following activities:
- Start with a clean slate and build up a new environment for v9.0.
- Move the applications to v9.0 as they are tested on v9.0.
- Remove a v7.0 or later cell when it is no longer needed.
Consider the following points related to manually migrating the configuration:
- Advantages
- We can reuse the scripts for maintenance, replication, and disaster recovery.
- We can refactor the topology.
- Considerations
- A complete set of administration scripts is a significant investment.
- We must address script incompatibilities and changes before migrating.
- We cannot have a mixed-node configuration.
- Migrate web server plug-ins
- Optional: Set up multiple versions of WAS to coexist.
No runtime conflicts can exist for multiple instances and versions of WAS if they are going to run at the same time on the same machine. Potential conflicts can occur with your port assignments. Read Port number settings for more information.
- Set up the system to run multiple installations together
- Create more than one v9.0 profile on the same machine
Related:
Overview of migration, coexistence, and interoperability Migration considerations Port number settings Knowledge Collection: Migration planning for WAS Migration Toolkit on WASdev.