|
Problem |
When installing a fix pack, or when migrating a version of
WebSphere® Application Server, it is important to keep all of the nodes in
the WebSphere Application Server repository at the same level. |
|
Cause |
WebSphere Application Server can, and often does, change
the schema of their repository database from version to version, even from
fix pack to fix pack. As a result, we do not recommend running WebSphere
nodes of different versions in the same repository.
For example, WebSphere Application Server V4.0.2 (Fix Pack 2) introduced
a schema change. As a result, when nodes running WebSphere Application
Server V4.0.1 and V4.0.2 are in the same repository, the V4.0.1 nodes do
not start. |
|
Solution |
In cases where the repository is shared by more than one
node, the solution involves temporarily, or permanently, configuring
multiple WebSphere nodes:
Separate repository configuration:
A suggested best practice is to configure multiple WebSphere Application
Server configurations, each with their own repository. This eliminates the
repository as a single point of failure, but increases the complexity of
administering WebSphere Application Server and deploying applications.
In this scenario, you install WebSphere Application Server into a new
directory, following directions for coexistence in the Release Notes.
Notes:
- Create a new repository on each system when you
install.
- Keep in mind that you will probably want to manually
configure the plug-in on your local or remote Web server to perform
failover.
Temporarily separate repository:
Temporarily create a second repository, then migrate from the old
repository to the new repository, one node at a time.
In this scenario, you create a second repository that uses the new version
of code to be installed. Once the repository is created, one node at a
time:
- Use XMLConfig -export to save the current configuration.
- Stop WebSphere Application Server processes.
- Change the configuration to point to new repository.
- Install the fix pack, following all directions in readme for
upgrade.
- Start WebSphere Application Server.
- Alter XMLConfig's output file to reference and configuration changes
(for example, new repository), then perform XMLConfig -import to
restore the configuration in the repository.
- After the last node is moved to the new repository and verified,
delete the old repository.
Notes:
- WebSphere Application Server V3.5 XMLConfig
-export has EJB-specific limitations.
- When doing a complete reinstall, do not select the option
to create a default server, because XMLConfig -import restores
the default server that was already configured.
Co-existence
Leave the current multi-node configuration up, while installing a new
multi-node configuration on the same systems using directions in the
Release Notes for coexistence:
- Install new version of WebSphere Application Server to different
directory on each node.
- Configure it to use different ports, as per the coexistence
documentation.
- Test using a separate instance of Web server.
- When all nodes of the new configuration are working correctly (in
test) on the production systems, change the Web server configurations to
point to ports for the new configuration.
- Shutdown the old configuration.
Notes:
- This configuration provides the ability to maintain
current load and throughput.
- This configuration provides a failover back to the
original configuration using all nodes.
- This is the most complex form of multi-node
migration.
|
|
|
|
|
|
|