Before you begin the process of migrating to WebSphere Application
Server V6.1, there are some considerations of which you need to be
aware.
- After you have installed WebSphere
Application Server V6.1, you might want to build a complete deployment
cell configuration and make sure that it works properly before you attempt
to migrate an existing cell or node.
This ensures that your system has
all of the necessary prerequisites and supports the new level of WebSphere
Application Server.
- High availability manager and
core group functionality are included in WebSphere Application Server Version
6.0 and later. See Core group migration considerations for core
group configuration and topology considerations that might impact your migration
from V5.x or 6.0.x to V6.1.
- Before you migrate to JDK 5 (introduced in WebSphere
Application Server V6.1) from JDK 1.4 (introduced in V5.1) or
JDK 1.3 (supported in V5.0.x) , review your applications for necessary
changes based on the Sun Microsystems Java specification.
See API and specification migration.
- When migrating a cell with multiple
nodes, the applications must remain at lowest JDK level until all nodes are
migrated.
- The Web server plug-in configuration
file (plugin-cfg.xml) generated after successful migration
from V5.x to V6.x is topology centric—that is, it includes all
the applications within a cell. You cannot manage this cell-wide plug-in configuration
file from the administrative console until you have manually configured it.
See Migrating Web server configurations.
- The migration articles assume that WebSphere Application Server Version
6.1 is being installed in an environment where it must coexist with prior
levels of WebSphere Application Server. Consider the following items while
planning to enable coexistence:
- Update prerequisites to the levels required by WebSphere Application Server
V6.1.
Prior levels of WebSphere Application Server will continue
to run at the higher prerequisite levels.
- Review the ports that have been defined to ensure that the WebSphere Application
Server V6.1 installation does not conflict.
In particular, note
that the default daemon port definition for both versions is the same when
installing to coexist with WebSphere Application Server V5.x or 6.0.x.
See Port number settings in WebSphere Application Server versions for default port information.
See Coexisting.
- Consider the following if you
are planning to have any mixed-release cells:
- You can upgrade a portion of the nodes in a cell to WebSphere Application
Server V6.1 while leaving others at the older release level. This means
that, for a period of time, you might be administering servers that are at
the current release and servers that are running the newer release in the
same cell.
Note that in this mixed-release environment,
there might be some restrictions on what you can do with servers at the older
release level. For details, see Creating application servers.
There might also be restrictions on creating clusters and cluster members.
For details, see Creating clusters.
- A WebSphere Application Server V6.1 deployment cell can contain
mixed releases of V5.x or 6.0.x nodes, but there is no mixed-node management
support for V6.0.0.x and V6.0.1.x. The V6.1 migration
tools still migrate these nodes during deployment-manager migration, but they
issue a warning message that the nodes cannot be managed by the V6.1
deployment manager. You can then do one of the following based on your needs.
- Upgrade all V6.0.0.x and V6.0.1.x nodes to at least Version
6.0.2. This will allow them to be administered by a V6.1 deployment
manager.
- Immediately migrate these nodes to V6.1.
- During migration, V6.1
cluster information is distributed throughout the cell. V6.0.x nodes
that are not at V6.0.2.11 or later fail to read this information and
the cluster function might fail. Therefore, upgrade all V6.0.x nodes
that will be contained in or interoperating with a V6.1 cell to Version
6.0.2.11 or later before migrating your deployment managers to V6.1.
- WebSphere Application Server V6.1 migration converts HTTP transports
to channel-framework Web container transport chains.For
more information on WebSphere Application Server V6.1 transport support,
see the following articles:
- The default profile location
was changed in WebSphere Application Server V6.0.x. The old file path $WAS_HOME/profiles/<profile>/<node>/installedApps/<ear>/<war> is
now $WAS_HOME/profiles/<profile>.
To
avoid configuration problems, use servlet APIs to control the file location
instead of using the default location.
- When migrating a deployment manager,
the WebSphere Application Server V6.1 cell name must match the Version
5.x or 6.0.x cell name.
If you create a profile with a new cell name, the
migration will fail.
- When migrating a federated node,
the WebSphere Application Server V6.1 cell name and node name must
match their respective V5.x or 6.0.x names.
- If you create a profile that does not meet the migration requirements
(such as naming requirements), you can remove the old profile and create a
new one rather than uninstalling and reinstalling the WebSphere Application
Server V6.1 product.
- If you migrate a node to WebSphere
Application Server V6.1 then discover that you need to revert back
to V5.x or 6.0.x, see Rolling back your environment.
- If you have
a Web services gateway running on a WebSphere Application Server V5.x
or 6.0.x application server that is part of a Network Deployment cell and
you want to migrate the cell from a V5.x or 6.0.x to a V6.1
deployment manager, first preserve the gateway configuration as described
in Coexisting with previous gateway versions.
- The migration tools create a migration backup directory containing a backup
copy of the configuration from the previous version. Here are some guidelines
that might help you to determine the amount of file-system space that this
directory might require.
- If you are migrating from V5.x, the space available
for this directory should be at least the size of the previous version's configuration
directory and applications.
- If you are migrating from V6.0.x, the space available for this
directory should be at least the size of the previous profile's configuration
directory and applications.
- The amount of storage that your system requires during migration to Version
6.1 depends on your environment as well as on which migration tool you are
using.
- WASPreUpgrade storage requirements
- Location: Backup directory specified as a parameter of the WASPreUpgrade command
- Amount: For a rough estimate of your storage requirements when
using this command, add the following amounts.
- Size of the following items for the old profile or
instance that you are migrating:
- If trace is enabled, which is the default, up to 200 MB (depending on
the size and complexity of your configuration)
For more information about this command, see WASPreUpgrade command.
- WASPostUpgrade storage requirements
- Location: New configuration relative to the new profile_root directory
- Amount: For a rough estimate of your storage requirements when
using this command, add the following amounts.
- Size of the following items for the old profile or
instance that you are migrating:
- If trace is enabled, which is the default, up to 200 MB (depending on
the size and complexity of your configuration)
For more information about this command, see WASPostUpgrade command.
- Before you migrate a Cloudscape database, ensure that any application
servers hosting applications that are using the Cloudscape database are shut
down. Otherwise, the Cloudscape migration will fail.
- After you use the migration tools to migrate to WebSphere Application
Server V6.1, you might need to do some things that are not done automatically
by the migration tools.
- Examine any Lightweight Third Party Authentication
(LTPA) security settings that you might have used in WebSphere Application
Server V5.x or 6.0.x, and make sure that V6.1 security is set
appropriately.
See Lightweight Third Party Authentication.
- Check the WASPostUpgrade.log file in the logs directory
for details about any JSP objects that the migration tools did not migrate.
If
V6.1 does not support a level for which JSP objects are configured,
the migration tools recognize the objects in the output and log them.
- Verify the results of the automatic Cloudscape database migration, and
manually migrate any Cloudscape databases that are not automatically migrated
by the tools.
See Migrating Cloudscape databases.