WebSphere Enterprise Service Bus, Version 6.2.0 Operating Systems: AIX, HP-UX, i5/OS, Linux, Solaris, Windows


Migrating non-clustered managed nodes using the migration wizard

Migrate non-clustered managed nodes from an older version to a newer version of WebSphere® ESB using the migration wizard.

Before you begin

Note: The migration wizard cannot run in a non-graphical environment. Examples of non-graphical environments include the i5/OS® platform or telnet sessions. If you want to run migration in a non-graphical environment, use the WBIPreUpgrade and WBIPostUpgrade commands.
Note: The migration wizard supports only WebSphere ESB profiles. If you have WebSphere Application Server profiles, you must use the migration commands.
Make sure that the following conditions are met before you start the migration process: Make sure that you have completed the following tasks before you start the migration process:

About this task

After you migrate an older version deployment manager to a newer version of WebSphere ESB, the newer version deployment manager runs in compatibility mode by default, where it can manage both older and newer versions of WebSphere ESB. For example, after migration, a version 6.2 deployment manager can manage both version 6.1.x and version 6.2 nodes. The managed nodes of the previous version 6.1.x deployment manager are now running as version 6.1.x managed nodes in the version 6.2 deployment manager.

Over time, migrate eachversion 6.1.x WebSphere ESB managed node (server managed by a version 6.2 deployment manager) to a version 6.2 managed node. After migrating all theversion 6.1.x managed nodes, use the convertScriptCompatibility script to change the deployment manager from supporting compatibility of version 6.1.x administration scripts to supporting compatibility of only version 6.1.x and version 6.2 administration scripts. See the convertScriptCompatibility command.
Note: When following the directions at this link to use the convertScriptCompatibility command, use the WBIPostUpgrade command rather than the WASPostUpgrade command.

For help in troubleshooting problems when migrating, see Troubleshooting version-to-version migration.

Procedure
  1. Log on as the root user on a Linux® or UNIX® system, or as a member of the Administrator group on a Windows® system.
  2. Stop the version 6.1.x or version 6.0.2.x server if it is running on the node to be migrated. Use the stopServer command from the profile_dir/bin directory for the profile of the affected server, or stop the server from the profile's First steps console.

    For more information about the stopServer command see the stopServer command. Use the following syntax:

    • For Linux operating systemFor UNIX operating system On Linux and UNIX platforms: profile_root/bin/stopServer.sh server_name
    • For Windows operating system On Windows platforms: profile_root\bin\stopServer.bat server_name
    If security is enabled, use one of the following commands instead. The user name provided must be a member of the operator or administrator role.
    • For Linux operating systemFor UNIX operating system On Linux and UNIX platforms: profile_root/bin/stopServer.sh server_name -username user_ID -password password
    • For Windows operating system On Windows platforms: profile_root\bin\stopServer.bat server_name -username user_ID -password password

    On the Windows operating system, even if security is enabled, the -username and -password parameters do not have to be specified if the server is running as a Windows service. In this case, the parameters are automatically passed into the script that the Windows service uses to shut down the system.

    Note: Before you start the migration process, you must stop the server from which you are migrating. It is not necessary to have that server running in order to migrate its configuration. The migration tools can retrieve all of the configuration data while the server is stopped.
  3. Stop the node agent of the node to be migrated. Issue one of the following commands to stop the nodeagent process, depending on platform (where profile_root represents the installation directory of the federated node):
    • For Linux operating systemFor UNIX operating system On Linux and UNIX platforms: profile_root/bin/stopNode.sh
    • For Windows operating system On Windows platforms: profile_root\bin\stopNode.bat
    If security is enabled, use one of the following commands instead:
    • For Linux operating systemFor UNIX operating system On Linux and UNIX platforms: profile_root/bin/stopNode.sh -username user_ID -password password
    • For Windows operating system On Windows platforms: profile_root\bin\stopNode.bat -username user_ID -password password
  4. Identify, in advance, the pre-existing information required for the migration, as listed below:
    Installation root directory
    See WBIPreUpgrade command-line utility for a description of the currentWebSphereDirectory parameter.
    Migration backup directory name
    See WBIPreUpgrade command-line utility for a description of the backupDirectory parameter.
    Administrative security user name (required if adminstrative security is configured)
    See WBIPostUpgrade command-line utility for a description of the -username parameter.
    Administrative security password (required if adminstrative security is configured)
    See WBIPostUpgrade command-line utility for a description of the -password parameter.
    Source profile name
    See WBIPostUpgrade command-line utility for a description of the -oldProfile parameter.
    Target profile name
    See WBIPostUpgrade command-line utility for a description of the -profileName parameter.
    Port value assignments (optional)
    See WBIPostUpgrade command-line utility for a description of the -replacePorts and -portBlock parameters.
    Note: This applies only if you are migrating from version 6.0.2.x toversion 6.2.
  5. Ensure that the version 6.2 deployment manager is up and running.
  6. Invoke the migration wizard.
    Invoke the migration wizard in one of the following ways:
    • From the WebSphere ESB First Steps console, select Migration wizard.
    • Run one of the following scripts (depending upon your operating system) stored in the install_dir/bin directory:
      • For Linux operating systemFor UNIX operating system On Linux and UNIX platforms: wbi_migration.sh
      • For Windows operating system On Windows platforms: wbi_migration.bat
      Note: You can optionally change the default trace setting (*=all=enabled:com.ibm.ws.migration.common.*=all=disabled) when invoking the migration wizard. The default trace setting enables tracing on only certain classes, but you can change the default to either enable full tracing or disable all tracing.
      • To enable full tracing, run one of the following scripts to invoke the migration wizard, depending on your operating system:
        • For Linux operating systemFor UNIX operating system On Linux and UNIX platforms: wbi_migration.sh -W -migrationPanel.traceString="*=all=enabled"
        • For Windows operating system On Windows platforms: wbi_migration.bat -W -migrationPanel.traceString="*=all=enabled"
      • To disable all tracing, run one of the following scripts to invoke the migration wizard, depending on your operating system:
        • For Linux operating systemFor UNIX operating system On Linux and UNIX platforms: wbi_migration.sh -W -migrationPanel.traceString="*=all=disabled"
        • For Windows operating system On Windows platforms: wbi_migration.bat -W -migrationPanel.traceString="*=all=disabled"

    The migration wizard copies the configuration and applications from the version 6.0.x or 6.1.x managed node to the version 6.2 managed node. After migrating all of the data, the wizard federates the version 6.2 managed node into the deployment manager cell.

  7. Follow the prompts for the migration wizard as described in Running the migration wizard.
  8. If you are migrating from version 6.0.2 to version 6.2.x you need to create the common database.

    For information, see Creating the common database and configuring the recovery subsystem when migrating from version 6.0.2 to version 6.2.x.

  9. Stop (if they are not stopped already) the server and node agent. If the server has not already been stopped, stop the server as described in step 2. If the node agent has not already been stopped, stop the node agent as described in step 3.
  10. Restart the node agent. To start a node agent, run the command profile_root\bin\startNode (where profile_root represents the installation directory of the managed node).
    • For Linux operating systemFor UNIX operating system On Linux and UNIX platforms: profile_root/bin/startNode.sh
    • For Windows operating system On Windows platforms: profile_root\bin\startNode.bat
  11. Start the server or servers running on this node. Start each server using the startServer command, the administrative console, or the profile's First steps console. For more information see Starting an application server.
  12. Repeat steps 1-11 for each additional managed node you wish to migrate.
  13. If you chose the compatibility option (which is the default), and if all of your nodes are completely migrated to WebSphere ESB version 6.2, run the convertScriptCompatibility script to remove compatibility from the version 6.2 deployment manager.
    Note: This applies only if you are migrating from version 6.0.2.x.
    Issue the convertScriptCompatibility command from the bin directory.
    • For UNIX operating systemFor Linux operating system install_root/bin/convertScriptCompatibility.sh
    • For Windows operating system install_root\bin\convertScriptCompatibility.bat

    See the convertScriptCompatibility command.

Results

Your non-clustered managed nodes are now migrated.

What to do next

Verify that the migration has been successful.

task Task topic

Terms of use | Feedback


Timestamp icon Last updated: 21 June 2010


http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic//com.ibm.websphere.wesb620.doc/doc/tmig_vtv_mn_wiz.html
Copyright IBM Corporation 2005, 2010. All Rights Reserved.
This information center is powered by Eclipse technology (http://www.eclipse.org).