Migrating a Version 5.x managed node to a Version 6.0.x managed node

Use the migration tools to migrate WebSphere Application Server Version 5.x managed nodes to Version 6.0.x managed nodes.

Before you begin

Migrating a Version 5.x managed node to a Version 6.0.x managed node requires that you first migrate the Version 5.x deployment manager node to a Version 6.0.x deployment manager node. Migrating Network Deployment Version 5.x to Version 6.0.x is described in Migrating from Network Deployment Version 5.x to a Version 6.0.x deployment manager.

Before starting the migration of a managed node from Version 5.x to Version 6.0.x, you must create a Version 6.0.x profile for either a standalone application server or a managed node. If you create a Version 6.0.x managed node profile, do not federate the node before migration. The migration tools federate the Version 6.0.x node during migration.

The migration procedure is the same for either type of Version 6.0.x profile, but he end result can vary slightly. Each standalone application server has a server1 application server process. A Version 5.x managed node might not have a server1 process. This article describes migrating to a Version 6.0.x managed node that has not been federated.

About this task

After migrating a Version 5.x deployment manager to a Version 6.0.x deployment manager, the Version 6.0.x deployment manager runs in compatibility mode by default, where it can manage both Version 5.x and Version 6.0.x nodes. The managed nodes of the Version 5.x deployment manager are now running as Version 5.x managed nodes in the Version 6.0.x deployment manager.

V6 cell with mixed version nodes

Over time, migrate each Version 5.x managed node in the Version 6.0.x cell to a Version 6.0.x managed node. After migrating all Version 5.x managed nodes, use the convertScriptCompatibility script to change the deployment manager from a node that supports backward compatibility of Version 5.x administration scripts to a node that supports only Version 6.0.x.

Procedure

  1. Perform a typical or custom Version 6.0.x installation.
  2. Migrate the Version 5.x deployment manager node to Version 6.0.x as described in Migrating from Network Deployment Version 5.x to a Version 6.0.x deployment manager.
  3. Collect the following information about your Version 5.x installation before you begin this procedure. The Migration wizard prompts you for the following information during the migration:
    • Installation root directory

      See WASPreUpgrade command for a description of the currentWebSphereDirectory parameter.

    • Replace port values for virtual hosts and Web containers?

      Specifying “true” causes any ports of matching VirtualHosts to first be removed from the new configuration before adding the new values.

      Specifying “false” for this parameter will just add new port values.

      See WASPostUpgrade command for a description of the replacePorts parameter.

    • Backup directory name

      See WASPreUpgrade command for a description of the backupDirectory parameter.

    • Target profile name.

      See WASPostUpgrade command for a description of the profileName parameter.

  4. Use the Version 6.0.x Profile creation wizard to create a managed node, but do not federate the node.
    The Version 6.0.x node must have the same node name as the Version 5.x node.
    Note: You can migrate a Version 5.x node without stopping it, but it is not necessary for it to be running for you to migrate its configuration. The migration tools can retrieve all the configuration data while the node is either running or stopped. You must stop the Version 5.x node before you can start the Version 6.0.x node that you are installing, however, so it makes sense to stop it now.
  5. Use the Migration wizard to migrate the Version 5.x managed node to the Version 6.0.x managed node profile as described in Migrating a Version 5.x application server to a Version 6.0.x standalone application server with the Migration wizard.
    The Migration wizard copies the configuration and applications from the Version 5.x managed node to the Version 6.0.x managed node. After migrating all of the data, the Migration wizard federates the Version 6.0.x managed node into the deployment manager cell.
    Note: When migrating managed nodes from Versions 5.0 through 5.1.0 to Version 6.0.x, there is a custom property of which you should be aware: com.ibm.websphere.ObjectIDVersionCompatibility. It might be possible to gain performance benefits after the entire cell is migrated to Version 6.0.x.
  6. Migrate as many Version 5.x managed nodes as you intend to migrate by using the following procedure.
    1. Determine the node name of the Version 5.x managed node.
    2. Use the Profile creation wizard to create a Version 6.0.x managed node, but do not federate the node.
    3. Use the Migration wizard to migrate the Version 5.x managed node to the Version 6.0.x managed node.
    Note: For migration to be successful, you must use the same node names and cell names for each node from Version 5.x to Version 6.0.x.
  7. If you chose the compatibility option (which is the default), and if all of your nodes are completely migrated to Version 6.0.x, run the convertScriptCompatibility script to remove backward compatibility from the Version 6.0.x deployment manager.
    1. Issue the convertScriptCompatibility command from the bin directory.
      • [Linux] ./app_server_root/bin/convertScriptCompatibility.sh
      • [Windows] app_server_root\bin\convertScriptCompatibility.bat

What to do next

Occasionally (after rebooting an application server machine for example), you must restart the nodeagent server on the application server node by running the startNode command from the profile_name/bin directory. 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.

Note: When a deployment manager is migrated, the applications in the cell are reinstalled. Even though the name is unchanged, the application is different from the version that was deployed on the previous release. When the federated nodes synchronize with the migrated deployment manager, therefore, they detect the new application and download it. After the application has been downloaded (synchronized), the node agent uses the new application rather than the old application. If the application is running on any active servers, the application will appear to restart as the old application is stopped and uninstalled and the new application is installed and started.



In this information ...


IBM Redbooks, demos, education, and more

(Index)

Use IBM Suggests to retrieve related content from ibm.com and beyond, identified for your convenience.

This feature requires Internet access.

Task topic    

Terms of Use | Feedback

Last updated: Sep 20, 2010 9:00:59 PM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=vela&product=was-nd-dist&topic=tins_increment
File name: tins_increment.html