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


Migrating cluster members using the migration wizard

Migrate cluster members 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.
Note: These instructions are part of the larger procedure to migrate all the servers in your cluster. Follow the instructions in Migrating a cluster or Migrating a cluster with minimal down time before performing the steps described here.
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 a version 6.0.2.x 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.0.2.x and version 6.2 nodes. In other words, version 6.0.2.x managed nodes can run with the version 6.2 deployment manager. Over time, you can migrate each version 6.0.2.x WebSphere ESB managed node (server managed by a version 6.2 deployment manager) to a version 6.2 managed node. After migrating all version 6.0.2.x managed nodes, you use the convertScriptCompatibility script to convert their configurations from a mode that supports compatibility of version 6.0.2.x administration scripts to a mode that is fully in a configuration version 6.2 model. 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.
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. Repeat steps 1-6 for each cluster member you wish to migrate.
  10. 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

The cluster member profiles are now migrated.

What to do next

Complete the cluster migration by completing steps 6-9 in Migrating a cluster or steps 7-12 in Migrating a cluster with minimal down time.

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_mnclust_wiz.html
Copyright IBM Corporation 2005, 2010. All Rights Reserved.
This information center is powered by Eclipse technology (http://www.eclipse.org).