|
| 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.
| |
| |
| |
|
Product categories: Software, Application Servers, Distributed Application & Web Servers, WebSphere Application Server, System Management/Repository Operating system(s): AIX, HPUX, Linux, Multi-Platform, Solaris, Windows Software version: 3.5, 4.0 Software edition: Advanced, Base, Single Server, Standard Reference #: 1052670 IBM Group: Software Group Modified date: 2005-01-07
(C) Copyright IBM Corporation 2000, 2004. All Rights Reserved.
|