Migrating V3.5.x and V.4.0.x to Network Deployment
You can migrate V3.5.x or V4.0.x of WebSphere Application Server to WebSphere Application Server Network Deployment, V5.x.
Overview
Migrating WebSphere Application Server Advanced Edition to WebSphere Application Server Network Deployment requires migrating all nodes in the collection to WebSphere Application Server. When migrating a model or server group from an earlier version to a V5 cluster, first migrate the model or server group node to a V5 base WebSphere Application Server node, which also migrates applications that are on the previous version node. Migrated applications are in the installableapps folder in the install_root of the base WebSphere Application Server node.
Install the Network Deployment product and then follow the instructions in this task to migrate the model or server group configuration to the deployment manager. Migration creates the appropriate number of V5 clusters. To install a migrated application on a cluster, you copy the EAR file from the installableapps folder of the base V5 WebSphere Application Server node.
Overview
Your current configuration from a previously installed version contains one or more node configurations, one for each node in the repository. You have a choice of where to install the Network Deployment product. You can install it either:
- On one of the nodes where you are installing and migrating applications to WebSphere Application Server.
This choice maps the single domain with multiple nodes to a single V5 cell with the same number of nodes. Network Deployment is on one of the nodes. This placement provides a configuration that is equivalent to the previously installed version.
- On an additional machine that does not have WebSphere Application Server.
This choice maps the single domain with multiple nodes to a single V5 cell with the same number of nodes, but with Network Deployment on an additional node.
You can vary the order in which you migrate these nodes. This task describes the most direct method.
After federating an Application Server node into a deployment manager cell, you cannot use the migration tools on the Application Server node. To use these tools again, remove the node from the cell, use the tools, and add the node to the cell again. You can, however, use the migration tools on a Network Deployment node after base Application Server nodes have been added. Use the -nodeName parameter on the WASPostUpgrade command to specify the Deployment Manager node.
You can also perform a silent migration to Network Deployment during a silent installation.
- Perform a typical or custom WebSphere Application Server installation on all nodes in the repository. The installation procedure is described in the information center for the base WebSphere Application Server product.
- Migrate each Application Server node to the base WebSphere Application Server product, as described in the WebSphere Application Server information center.You must migrate each node that you intend to add to the Network Deployment configuration.
- Install the Network Deployment product.
- When installing Network Deployment on a WebSphere Application Server node that you migrated:
- If the previous version is still installed and running, select the migration option during the installation.
- If the previous version is no longer installed, perform a manual migration against the WASPreUpgrade backup directory on this or another migrated node. Issue the WASPostUpgrade backupDirectory command from the bin directory of the install_root.
- When installing Network Deployment on a machine that did not have an earlier version of WebSphere Application Server, perform a manual migration against the WASPreUpgrade backup directory on another node that you migrated from the previous domain. Issue the WASPostUpgrade backupDirectory command from the bin directory of the install_root.
You can also install the Network Deployment product silently, and migrate an earlier version configuration silently. You must supply values for silent migration options when you tailor the options response file:
- Direct the installation program to migrate a previous installation by specifying the -W previousVersionDetectedBean.previousVersionDetected="true" parameter.
- Identify the specific version to migrate.Use one of the following values to identify the specific version to migrate:
- For WebSphere Application Server Advanced Edition, Versions 3.5.x and 4.0.x, use one of the following parameters:
- -W previousVersionPanelBean.selectedVersionEdition="AE"
- -W previousVersionPanelBean.selectedVersionEdition="advanced"
- For WebSphere Application Server Advanced Single Server Edition, Version 4.0.x, use the -W previousVersionPanelBean.selectedVersionEdition="AEs" parameter.
- For WebSphere Application Server Standard Edition, V3.x, use the -W previousVersionPanelBean.selectedVersionEdition="standard" parameter.
- Specify the location where the previous version is installed in the -W previousVersionPanelBean.selectedVersionInstallLocation="/opt/WebSphere/AppServer" parameter.
- Specify the path to the configuration file.
- For WebSphere Application Server Advanced Edition, Versions 3.x and 4.0.x, use the -W previousVersionPanelBean.selectedVersionConfigFile="/opt/WebSphere/AppServer/config/admin.config" parameter.
- For WebSphere Application Server Advanced Single Server Edition, Version 4.0.x, use the -W previousVersionPanelBean.selectedVersionConfigFile="/opt/WebSphere/AppServer/config/server-cfg.xml" parameter.
- For WebSphere Application Server Standard Edition, V3.x, use the -W previousVersionPanelBean.selectedVersionConfigFile="/opt/WebSphere/AppServer/config/server-cfg.xml" parameter.
- Specify the version number of the previous version, such as "4.0", "4.0.1", or "3.5", in the -W previousVersionPanelBean.previousVersionSelected="4.0" parameter.
- Indicate that you are selecting the version you have identified with the -W previousVersionPanelBean.migrationSelected="true" parameter.
- Specify the backup directory where WASPreUpgrade is to store information from the previous version with the -W migrationInformationPanelBean.migrationBackupDir="/tmp/migrationbackup" parameter.
- Specify the directory for storing migration logs with the -W migrationInformationPanelBean.migrationLogfileDir="/tmp/migrationlogs" parameter.
- Enter a node name, host name, and cell name for the new Version 5 installation. The node name is used for administration must be unique within the group of nodes that comprise the cell. The host name is the DNS name or IP address for this computer. The cell name is a logical name for the group of nodes.
- Use the -W nodeNameBean.nodeName="nodenameManager" parameter to specify a unique node name. You can use the short host name of the machine as the node name portion of the name and append Manager to it to compose the name.
- Use the -W nodeNameBean.cellName="nodenameNetwork" parameter to specify the cell name. You can use the host name as the node name portion of the name and append Network to it to compose the name.
- Use the -W nodeNameBean.hostName="hostNameOrIPAddress" parameter to specify the host name for the machine, which can be the fully qualified network name, the short name, or the IP address.
You can also configure the options response file for coexistence with an earlier version by specifying non-conflicting port assignments in the file.
- Start the deployment manager on the Network Deployment node. On the system that has Network Deployment installed, start the deployment manager in either of these ways:
- Click Programs > WebSphere Application Server > Deployment Manager from the Start menu on a Windows platform.
- Issue the startManager command from the bin directory of the install_root.
- Use the deployment manager administrative console to add each WebSphere Application Server node to the cell.The following procedure supports adding migrated nodes to a deployment manager cell, whether the nodes are cloned, stand-alone, or a combination of the two.
After federating an Application Server node into the Network Deployment cell, the configuration repository for the cell contains the master copy of the node configuration. From that point on, the deployment manager maintains the permanent configuration for the node. Changes you make with the deployment manager administrative console directly update the configuration files stored on the deployment manager node.
- Use the Network Deployment administrative console to add each node to the Network Deployment cell.
- Install any clustered applications on the appropriate cluster, using either the administrative console or the wsadmin command. Use the EAR file that the migration tools create when migrating the earlier version to the V5 base WebSphere Application Server. You can find the EAR file in the installableApps directory that is in the base product install_root.
The deployment manager automatically propagates enterprise applications to appserver nodes in the cluster.
- Use First Steps to perform the installation verification test (IVT).
What to do next
Occasionally, for example after rebooting an Application Server machine, restart the nodeagent server on the Application Server node, by running the startNode command from the bin directory of the Application Server install_root. To keep your Application Server nodes running, without having to access the bin directory of each one, use the operating system to monitor and restart the nodeagent process on each Application Server node. (You can also set up the dmgr server as a managed process on the deployment manager node.) Adding a node automatically issues the startNode command for the node.
Return to Migrating configuration data to continue.
Migrating
Configuration mapping during migration
Migration tools
Migrating configuration data
Migrating Network Deployment, V5.0.0 or V5.0.1 with embedded messaging to V5.1
Migrating V3.5.x or V4.0.x of WebSphere Application Server to V5.x
Migrating V3.5.x or V4.0.x of WebSphere Application Server to a remote V5.1 machine
Migrating V5.0.x of WebSphere Application Server to V5.1
Migrating V5.0.x of WebSphere Application Server to a remote V5.1 machine
Migrating from an operating system that is no longer supported
Starting clusters
Stopping clusters
Example: Creating a cluster using wsadmin
addNode command
removeNode command
serverStatus command
startNode command
startServer command
stopNode command
stopServer command
startManager command
stopManager command