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


Migrating cluster members using the command-line tools

Migrate cluster members from an older version to a newer version of WebSphere® ESB with the command-line tools.

Before you begin

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.
Note: When you migrate using the command-line tools, you can migrate either a WebSphere ESB profile or a WebSphere Application Server profile.
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 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:
    Note: On i5/OS® platforms, you must run the scripts under QSHELL. To start a QSHELL session, open a CL command prompt and type QSH.
    • For i5/OS operating system On i5/OS platforms: profile_root/bin/stopServer server_name
    • 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 i5/OS operating system On i5/OS platforms: profile_root/bin/stopServer server_name -username user_ID -password password
    • 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: Stop the server before beginning the migrating process. By default, all servers on the node are stopped before the migration completes.
  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 i5/OS operating system On i5/OS platforms: profile_root/bin/stopNode
    • 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 i5/OS operating system On i5/OS platforms: profile_root/bin/stopNode -username user_ID -password password
    • 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
    Note: You must stop the old node before you start migration process. It is not necessary to have the server running to migrate its configuration. The migration tools can retrieve all the configuration data while the server is stopped.
  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. Run the WBIPreUpgrade command, specifying the migration backup directory name and the existing WebSphere ESB directory name. The WBIPreUpgrade tool saves the configuration files of your existing profiles to the backup directory you specify.
  7. Run the WBIPostUpgrade command, specifying the migration backup directory. The WBIPostUpgrade tool restores the backed up configuration in the backup directory into the new WebSphere ESB Deployment Manager profile.
    Important: Use the -createTargetProfile parameter when invoking WBIPostUpgrade. This option creates a matching required new target profile for migration. For more information about target profiles, refer to Target profile considerations.
    For i5/OS operating system Note: If you are migrating on an i5/OS platform, the target profile name must match the profile name of the source profile being migrated.
  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-7 (with the possible exception of step 6).
    Note: You need to perform step 6 (running WBIPreUpgrade) again only you are migrating from version 6.1.x, or if you are migrating from version 6.0.2.x and the version 6.0.2.x system has been reconfigured since the first time you ran WBIPreUpgrade. If you skip step 7 because you are migrating additional managed profiles in the same WebSphere ESB installation, then you may also be able to skip step 1.
  10. For Linux operating systemFor UNIX operating systemFor Windows operating system 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: Perform this step only if you are migrating from version 6.0.2.x.
    Note: This step does is not applicable to i5/OS platforms.
    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_cl.html
Copyright IBM Corporation 2005, 2010. All Rights Reserved.
This information center is powered by Eclipse technology (http://www.eclipse.org).