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 command-line tools

Migrate non-clustered managed nodes from an older version to a newer version of WebSphere® ESB with the command-line tools.

Before you begin

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:
  • Your system meets all the hardware and software requirements for the new version of WebSphere ESB.
  • You have installed the new version of WebSphere ESB side-by-side the previous version on the same system.
  • A federated profile, created with the older WebSphere ESB version resides on the same system.
  • Sufficient disk space is available for the migrated profile and its backup. See Premigration considerations for WebSphere ESB for disk space requirements.
  • The deployment manager that manages the managed node that you intend to migrate has already been migrated to the newer version of WebSphere ESB, and is running.
    Note: Migrating a WebSphere ESB version 6.0.x or 6.1.x managed node to a version 6.2 managed node requires that you first migrate the version 6.0.x or 6.1.x deployment manager to a version 6.2 deployment manager. See Migrating a deployment manager for instructions. Complete the migration of the deployment manager before you proceed with the instructions in this topic.
Make sure that you have completed the following tasks before you start the migration process:
  • Back up the databases that support version 6.0.x or 6.1.x WebSphere ESB components.

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 using one of the following procedures, depending on your operating system.
    • For i5/OS operating system On i5/OS® platforms: Log on with an i5/OS user profile that has *SECOFR user class or *ALLOBJ special authority.
    • For Linux operating systemFor UNIX operating system On Linux® and UNIX® platforms: Log on as the root user.
    • For Windows operating system On Windows® platforms: Log on as a member of the Administrator group.
  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. 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 i5/OS operating system On i5/OS platforms: profile_root/bin/startNode
    • 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.
    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.
  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 one of the convertScriptCompatibility commands from the bin directory, depending on your operating system:
    • For i5/OS operating system On i5/OS platforms: install_root/bin/convertScriptCompatibility
    • For Linux operating systemFor UNIX operating system On Linux/UNIX platforms: install_root/bin/convertScriptCompatibility.sh
    • For Windows operating system On Windows platforms: 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_cl.html
Copyright IBM Corporation 2005, 2010. All Rights Reserved.
This information center is powered by Eclipse technology (http://www.eclipse.org).