If you have an existing WebSphere Application Server Version 5.x
or 6.0.x Network Deployment configuration with a significant number of large
applications and you must meet a specific maintenance window for migration,
you might have some difficulty if you use the standard migration scenario.
In this case, you might want to copy the resources in the configuration tree
from a Version 5.x or 6.0.x deployment manager configuration to a Version
6.1 profile but defer adding applications to the Version 6.1 profile so that
you can continue managing the environment using the Version 5.x or 6.0.x deployment
manager.
Before you begin
Tip: To avoid possible connection-timeout problems, modify
the connection-timeout value before running the
WASPostUpgrade command
to migrate the federated nodes in a cell containing many small applications,
a few large applications, or one very large application. If you use a SOAP
connector, for example, perform the following actions:
- Go to the following location in the Version 6.1 directory for the profile
to which you are migrating your federated node:
profile_root/properties
- Open the soap.client.props file in that directory
and find the value for the com.ibm.SOAP.requestTimeout property. This is the
timeout value in seconds. The default value is 180 seconds.
- Change the value of com.ibm.SOAP.requestTimeout to make it large enough
to migrate your configuration. For example, the following entry would give
you a timeout value of a half of an hour:
com.ibm.SOAP.requestTimeout=1800
Note: Select
the smallest timeout value that will meet your needs. Be prepared to wait
for at least three times the timeout that you select—once to download files
to the backup directory, once to upload the migrated files to the deployment
manager, and once to synchronize the deployment manager with the migrated
node agent.
- Go to the following location in the backup directory that was created
by the WASPreUpgrade command:
backupDirectory/profiles/profile_name/properties
- Open the soap.client.props file in that directory
and find the value for the com.ibm.SOAP.requestTimeout property.
- Change the value of com.ibm.SOAP.requestTimeout to the same value that
you used in the Version 6.1 file.
See Overview of migration, coexistence, and interoperability and Premigration considerations.
About this task
You can use this strategy to satisfy your specific maintenance-window
requirement by building the full WebSphere Application Server Version 6.1
Network Deployment configuration in the background while the existing topology
is still running and being managed.
For help in troubleshooting problems
when migrating, see Troubleshooting migration.
Procedure
- Make sure that the WebSphere Application Server Version 5.x or
6.0.x deployment manager is running and managing the existing environment,
and make sure that no Version 6.1 deployment manager is running.
This
is important in order to prevent two different deployment managers from trying
to manage the same environment.
- Start the Qshell environment so that you can
run WebSphere Application Server scripts.
Enter the following
command on a command line:
STRQSH
- Run the WASPreUpgrade command.
Use the following parameters:
app_server_root/bin/WASPreUpgrade
backup_directory_name
old_profile_root
where
For a full explanation of the WASPreUpgrade command
and its parameters, see WASPreUpgrade command.
- Run the WASPostUpgrade command.
Use the following parameters:
app_server_root/bin/WASPostUpgrade
backup_directory_name
-profileName 61ND_profile_name
-includeApps script
-keepDmgrEnabled true
where
- app_server_root is the location where
Version 6.1 is installed
- backup_directory_name (required parameter)
is the fully qualified path to the integrated file system directory that the WASPreUpgrade migration
tool previously used to save the Version 5.x or 6.0.x deployment manager configuration
- 61ND_profile_name (required parameter)
is the name of the Version 6.1 deployment manager profile to which the script
migrates your configuration
For a full explanation of the WASPostUpgrade command
and its parameters, see WASPostUpgrade command.
At
this point, you can exit the maintenance window and still manage the environment
using the WebSphere Application Server Version 5.x or 6.0.x deployment manager.
- Customize the administration files.
- Go to the migration backup directory location that contains
the generated administration files.
- Combine and tailor the administration files as needed.
This might include grouping applications together in some administration
files or specifying the installedApplications directory
using the installed.ear.destination parameter .
- Start the Qshell environment so that you can
run WebSphere Application Server scripts.
Enter the following
command on a command line:
STRQSH
- Run the wsadmin command to install the
applications.
After all applications have been installed, you are ready to start
using the WebSphere Application Server Version 6.1 deployment manager.
- Stop the WebSphere Application Server Version 5.x or 6.0.x deployment
manager.
This is important in order to prevent two different
deployment managers from trying to manage the same environment.
You
can do this in a number of ways. One easy way is to rename the serverindex.xml file
in the node directory of the Version 5.x or 6.0.x deployment manager to something
else.
- Start the WebSphere Application Server Version 6.1 deployment manager.
- Start the Qshell environment so that you can run WebSphere Application
Server scripts.
Enter the following command on a command line:
STRQSH
- If the QWAS61 subsystem has not been started, start the default
profile.
Enter the following command on a command line:
STRSBS QWAS61/QWAS61
- Start the Version 6.1 deployment manager using the startManager script.
Use the following parameters:
app_server_root/bin/startManager
-profileName 61ND_profile_name
where
- app_server_root is
the location where Version 6.1 is installed
- 61ND_profile_name is the name of the
Version 6.1 deployment manager profile
Results
At this point, the WebSphere Application Server Version 6.1 deployment
manager should be running and the normal application synchronization should
occur.
You can follow either of the following procedures:
- Migrate the entire cell before installing the applications.
- Perform the following actions:
- Install the applications, and leave the cell in a mixed state.
- When you are ready, modify the connection-timeout values (as described
in the tip at the beginning of this article) before running the WASPostUpgrade command
to migrate the federated nodes.