- After
you install WebSphere Application Server Version 7.0, you might want to
build a complete WebSphere Application Server, Network Deployment cell
configuration and verify that it works correctly before you attempt
to migrate an existing cell or node.
This process ensures that
your system has all of the necessary prerequisites and supports the
new level of WebSphere Application Server.
- Before you perform the migration, evaluate the items deprecated
in WebSphere Application Server Version 7.0.
For more information,
read the "Deprecated and removed features" article in the information
center.
- High-availability
manager (HAM) and core-group functionality are included in WebSphere Application Server Version 6.0 and
later.
Read the "Core group migration considerations" article in
the information center for core-group configuration and topology considerations
that might impact your migration from Version 5.1.x or Version 6.x
to Version 7.0.
Note: The
migration tools add all servers to the default core group during migration
from Version 5.1.x. In most cases, however, the recommended number
of servers in a core group should not exceed 50. You receive a warning
message when the migration tools add a server that exceeds the recommended
upper limit.
- Before you migrate to Java™ Standard
Edition (SE) Development Kit (JDK) 6 from JDK 5 or JDK 1.4 , review
your applications for necessary changes based on the Sun Microsystems Java specification.
Read Migrating API and specifications for more information.
- WebSphere Application Server profiles
from previous releases that are configured to use the i5/OS® Java Developer Kit Java Virtual
Machine (JVM), also known as the "classic" JVM, generally exhibit
better application performance when they are migrated to a WebSphere Application Server Version 7.0 profile that is configured
to use the IBM® Java SE 6 32 bit JVM (which is the default
for WebSphere Application Server Version 7.0). This is due to
the reduced size of Java reference
objects (4 byte versus 8 byte ) and the smaller Java heap
storage requirements.
However, large applications might require
a larger Java heap than the maximum heap
size allowed by the IBM Java SE 6 32 bit JVM and might
not run efficiently or at all. In addition, if the source profile
has explicit settings for the initial Java heap
size or Java maximum heap size in the application
server's genericJvmArguments that are larger then the allowed maximum Java heap size of the IBM Java
SE 6 32 bit JVM (2.5 G), the target profile's application server will
not start. You can resolve these types of Java heap
related problems using one of the following two methods:
- Use the administrative console to alter or remove the explicit Java heap settings (-Xms or -Xmx java arguments)
from the genericJvmArguments of the source application server before
migration or of the target application server after migration, and
continue to use the IBM Java SE 6 32 bit JVM.
- Use the enableJvm script to change the JVM configuration of the
target profile to use either the classic i5/OS Java Developer Kit 6.0 JVM or the IBM Java
SE 6 64 bit JVM. Neither of these 64-bit JVMs limit the maximum heap
size.
- When
migrating a cell with multiple nodes, the applications must remain
at the lowest JDK level until all nodes are migrated.
- The
Web server plug-in configuration file, plugin-cfg.xml,
that is generated after successful migration from Version 5.1.x to Version 7.0 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.
Read Migrating Web server configurations for more information.
- The migration articles in this information center assume that WebSphere Application Server Version 7.0 is being installed
in an environment where it must coexist with prior levels of WebSphere Application Server.
Consider the
following items when planning to enable coexistence:
Read Running multiple application server versions for
more information.
- Consider
the following information 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 Version 7.0 while leaving others
at the previous release level. This means that, for a period of time,
you might be administering servers that are at the previous release
level and servers that are running the newer release in the same cell.
In
this mixed-release environment, some restrictions on what you can
do with servers at the previous release level might exist. For details,
read the "Creating application servers" article in the information
center.
- 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; however, no
mixed-node management support exists 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;
however, these 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.
- Upgrade all Version 6.0.0.x and Version 6.0.1.x nodes to at least
Version 6.0.2. This allows them to be administered by a Version 7.0 deployment manager.
- Migrate these nodes to Version 7.0.
- During
migration, Version 7.0 cluster
information is distributed throughout the cell. Version 6.0.x nodes
that are not at Version 6.0.2.11 or later fail to read this information
and the cluster function might fail. Therefore, upgrade all Version
6.0.x nodes that will be contained in or interoperating with a Version 7.0 cell to Version 6.0.2.11
or later before migrating your deployment managers to Version 7.0.
- WebSphere Application Server Version 7.0 migration converts
HTTP transports to channel-framework Web container transport chains.
For
more information on
WebSphere Application Server Version 7.0 transport support,
read the following articles in the information center:
- Configuring transport chains
- HTTP transport channel settings
- Transport chains
- The
default profile location was changed in WebSphere Application Server Version 6.0.x.
The previous file path app_server_root/profiles/<profile>/<node>/installedApps/<ear>/<war> was
changed to app_server_root/profiles/<profile>.
To
avoid configuration errors, use servlet APIs to control the file location
instead of using the default location.
- The
following restrictions apply to a deployment manager migration:
- The Version 7.0 cell
name must match the cell name in the Version 5.1.x or Version 6.x
configuration.
If you create a profile with a new cell name, the
migration will fail.
- Either one or the other of the following options must be true:
- The Version 7.0 deployment
manager node name must be the same as the Version 5.1.x or Version
6.x deployment manager node name.
- The Version 7.0 deployment
manager node name must be different from every node name in the Version
5.1.x or Version 6.x configuration.
Otherwise, the migration fails with the following message:MIGR0488E: The deployment manager node name in the new configuration ({0})
cannot be the same as a nodeagent node in the old configuration.
- When
migrating a federated node, the WebSphere Application Server Version 7.0 cell name and node
name must match their respective Version 5.1.x or Version 6.x names.
- If you create a profile that does not meet the migration requirements
such as naming requirements, you can remove the previous profile and
create a new one rather than uninstalling and reinstalling the WebSphere Application Server Version 7.0 product.
- If
you migrate a node to WebSphere Application Server Version 7.0 and then discover
that you need to revert back to Version 5.1.x or Version 6.x, read Rolling back environments.
- If
you have a Web services gateway running on a WebSphere Application Server Version 5.1.x
or Version 6.x application server that is part of a WebSphere Application Server, Network Deployment cell and you
want to migrate the cell from a Version 5.1.x or Version 6.x to a Version 7.0 deployment manager,
you must first preserve the gateway configuration as described in
the "Coexisting with previous gateway versions" article in the information
center.
- The migration tools create a migration backup directory containing
a backup copy of the configuration from the previous version. The
following guidelines might help you to determine the amount of file-system
space that this directory might require:
- If you are migrating from Version 5.1.x, the
space available for this directory must be at least the size of the
configuration directory and applications from the previous version.
- If you are migrating from Version 6.x, the space available for
this directory must be at least the size of the configuration directory
and applications from the previous profile.
- If you use the migration tools to create more than one Version
7.0 target profile on the same host or installation instance and you
use the default port settings, there is a chance that the target profiles
will share the same ports for some of the new Version 7.0 port definitions.
This will cause startup problems if both of the migrated profiles
are used.
If you are migrating two or more profiles that reside
on the same host or installation instance, perform the following actions
for each additional target profile:
- Before using the migration tools, use the Profile Management tool
or manageprofiles command to create the target
profile and make sure that you select unique ports rather than using
the default ports.
- When you use the migration tools, select the target profile rather
than letting the tools create it.
- The amount of storage that your system requires during migration
to Version 7.0 depends on
your environment as well as on the migration tool that you are using.
- WASPreUpgrade storage requirements
- Location: Backup directory specified as a parameter of
the WASPreUpgrade command
- Amount: For an estimate of your storage requirements when
using this command, add the following amounts.
- Size of the following items for the previous
profile or instance that you are migrating:
- profile_root/installableApps directory
- profile_root/installedApps directory
- profile_root/config directory
- profile_root/properties directory
- Shared libraries referenced in the libraries.xml configuration
files
- Resource adapter archive (RAR) files referenced in the resources.xml configuration
files
- 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, read WASPreUpgrade command.
- WASPostUpgrade storage requirements
- For an estimate of your storage requirements when using this command,
add the following amounts.
For more information about this command, read WASPostUpgrade command.
- The IPC_CONNECTOR_ADDRESS port is new for Version 7.0.
Table 1. IPC_CONNECTOR_ADDRESS port values. The
following table lists the default values for this port.
Port type |
Value |
Application server |
9633 |
Administrative agent |
9630 |
Job manager |
9631 |
Secure proxy server |
9633 |
Administrative subsystem |
9634 |
IPC_CONNECTOR_ADDRESS port conflicts might exist after
running the migration jobs. Reconfigure the conflicting ports.
- If you use isolated data repositories—specifically, nonshared
data repositories such as transaction logs for SIB and IBM Cloudscape
or Apache Derby databases—and you migrate from a previous release,
your existing databases and transaction logs are saved when the WASPreUpgrade
tool is run. Any database changes that you make after the WASPreUpgrade
tool is run will not be reflected in the migrated environment.
- If you have mission-critical information that is stored in these
local data repositories, you should safely shut down all servers that
interact with those repositories before attempting migration. Those
servers should remain offline until the migration has been successfully
completed or rolled back.
- If you make multiple attempts at migration, either because of
unexpected rollback or to apply fixes, rerun the WASPreUpgrade tool
so that any changes to your isolated data repositories are reflected
in the migrated environment.
After the migration is complete or you have rolled back to the
previous version, you can restart the servers that interact with these
isolated data repositories.
- Before you migrate an Apache Derby database, ensure that any application
servers hosting applications that are using the Apache Derby database
are closed. Otherwise, the Apache Derby migration fails.
- You
should be aware of the following rules related to migrating security
domains:
- If you migrate a deployment manager that has a security domain
with a cell-level scope, the migration tools take the following actions:
- If you migrate a federated node that has a security domain with
a cell-level scope, the migration tools take the following actions:
- Migration creates a domain in the new configuration called PassThroughToGlobalSecurity if
it does not already exist.
- Migration adds a server-level mapping to the PassThroughToGlobalSecurity
domain for all non-clustered servers in the old node's configuration.
Read the "Security domains in a mixed-version environment"
section of the "Multiple security domains" article in the information
center.
- During migration, some of your application metadata might be reset
to the default and cause the application to function differently from
what you expect.
If you installed an application in your old environment
with Use Metadata From Binaries set to true and during that
installation or a future update of the application you made a change
to the application's metadata (such as JNDI resource references or
database entries for example), the change might be lost when you migrate.
When Use
Metadata From Binaries is set to true, the administrative code
only updates the metadata in the binary EAR file. This option is not
supported in a mixed cell; therefore, it is automatically turned to
false as part of migration. When this happens, the expanded metadata
in the configuration directories take precedence over the values in
the binary EAR file. This causes the values from the original EAR
file installation to take precedence over any updates that you might
have made.
Perform one of the following actions to resolve this
issue:
- Before migrating, update your applications in the old environment
and set Use Metadata From Binaries to false. Ensure that the
applications are functioning correctly with this new setting, and
then run the migration.
- After migrating, update your applications and correct the metadata
as required to allow the applications to function appropriately.
- After you use the migration tools to migrate to WebSphere Application Server Version 7.0, you might need to
perform some actions 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 Version 5.1.x
or Version 6.x, and verify that Version 7.0 security is set appropriately.
Read
the "Lightweight Third Party Authentication" article in the information
center for more information.
- Check the WASPostUpgrade.log file in the logs directory
for details about any JavaServer Pages (JSP) objects that the migration
tools did not migrate.
If Version 7.0 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 Apache Derby database migration,
and manually migrate any Apache Derby databases that are not automatically
migrated by the tools.
Read Migrating IBM Cloudscape or Apache Derby databases for
more information.
- WebSphere Application Server Version 7.0 does not include
the WebSphere Connect JDBC driver for SQL Server.
The WebSphereConnectJDBCDriverConversion tool is provided to convert
data sources from the WebSphere Connect JDBC driver
to the DataDirect Connect JDBC driver or the Microsoft® SQL
Server 2005 JDBC driver.
Read Migrating from the WebSphere Connect JDBC driver for
more information.
- During
cell migrations to Version 7.0,
the Version 6.0.x server user ID is not migrated or mapped to the Version 7.0 Primary administrative
user name field as shown in the administrative console at Security >
Global security > user_account_repository >
Configure. The server user identity value is transferred, and
the proper user ID from the Version 6.0.x cell is migrated along with
a password.
The primary administrative user name is required when
defining Lightweight Directory Access Protocol (LDAP) as the security
repository in Version 7.0.
The Primary administrative user
name field and server user identity value are used by the product
when you use administrative scripts (wsadmin) to update the configuration.
Version 6.0.x and earlier versions of the product store a valid username-and-password
pair in the authenticating registry inside the local product configuration
files. Beginning with Version 6.1, an administrative user ID can be
set but the authentication information is not stored in the local
product configuration files (thereby improving security).
If
you migrate from an older release of the product to Version 6.1 or
later, the old model is still used in order to maintain backward compatibility
and to allow the mixed cell to function properly. When you are ready
to upgrade to the new model, which requires that all nodes in the
cell be at Version 6.1.x or later, you can perform the following actions:
- Input a Primary administrative user name that represents a valid
user identity in the authentication authority (user registry).
- Change the server user identity value from Server identity
that is stored in the repository to Automatically generated
server identity.
If you are still using a mixed cell in Version 7.0 that contains Version
5.x or Version 6.0.x nodes, you must continue to use the old model
or the older nodes will not be able to communicate with the new nodes.
You should not make any changes to the security settings in the mixed
cell. If editing the user registry becomes necessary in a mixed cell
that is not ready to be upgraded to the new model, however, select
a valid user identity in the authentication authority (user registry)
and put that value into the Primary administrative user name field
but do not change the value of the server user identity. On
all platforms, it is important to select a user ID that is valid for
the scripting tools (wsadmin).