Migrate nodes

Before you begin

Migrate application client installations

About this task

Step 14 towards the goal: Migrating cell configurations to new host machines using the command-line tool
These steps apply to cross-machine migrations only. If you are not completing a cross-machine migration of a node, see the information about migrating nodes in Migrating cells using the command-line tools. Ensure that the Version 8.5 deployment manager is running. For each node that you plan to migrate to Version 8.5, perform the following steps:
Avoid trouble Avoid trouble: For the migration to be successful, you must use the same source node name and cell name for each node that you migrate to Version 8.5 or later.gotcha

Procedure

  1. Install WebSphere® Application Server Version 8.5. Install the correct version of WebSphere Application Server Network Deployment, Base, or Express® onto each target host. For more information, see the documentation about installing an application-serving environment.
  2. Create the target node profile. Run the manageprofiles command with the appropriate parameters to create a new managed profile. For example:
    [Windows]
    version_8.5_install_root\bin\manageprofiles.bat 
    -create -profileName node1 -templatePath \opt\
    WebSphereV85\profileTemplates\managed -nodeName currentNode1Name 
    -cellName currentCellName -hostName mynode1host.company.com
    [AIX][HP-UX][Linux][Solaris]
    version_8.5_install_root/bin/manageprofiles.sh 
    -create -profileName node1 -templatePath 
    /opt/WebSphereV85/profileTemplates/managed -nodeName currentNode1Name 
    -cellName currentCellName -hostName mynode1host.company.com
  3. Use the remote migration .jar file that you created for migrating the deployment manager to make the WASPreUpgrade command available on the current node machine.
    Note: This step needs be done only if the source node and deployment manager are not on the same machine, and this step can be done only if the machine architecture is the same.
    For more information, see step 3 of this scenario, Create the remote migration .jar file.
  4. Run the WASPreUpgrade command with the -machineChange true parameter to save the current node X configuration to a migration backup directory. Choose a new directory for the backup files. For example:
    [Windows]
    <path to remote migration jar>\migration\bin\WASPreUpgrade.bat \mybackup_old_host\v70tov85node1 
    \opt\WebSphereV70 -oldProfile 70node1 -machineChange true
    [AIX][HP-UX][Linux][Solaris]
    <path to remote migration jar>/migration/bin/WASPreUpgrade.sh /mybackup_old_host/v70tov85node1 
    /opt/WebSphereV70 -oldProfile 70node1 -machineChange true
  5. Check the WASPreUpgrade console output for error and warning messages. You might find the following messages: "Failed with errors" or "Completed with warnings". Also, look in the following log files for error or warning messages:
    • myback_old_host/v70tov85node1/logs/WASPreMigrationSummary.log
    • myback_old_host/v70tov85node1/logs/WASPreUpgrade.< timestamp >.log
    • myback_old_host/v70tov85node1/logs/WASPreUpgrade.trace

    If the WASPreUpgrade command is successful, you do not need to check the log files for error or warning messages.

  6. Use the archive tool of your choice to create a compressed file of the backup directory that was created by the WASPreUpgrade command. For example:
    [AIX Solaris HP-UX Linux Windows]
    cd /mybackup_old_host
    /opt/WebSphereV70/java/bin/jar -cf v70tov85node1.jar v70tov85node1/
  7. Move the archived file to the target machine.
  8. Create a directory on the target machine and extract the archived file to the new directory. For example:
    mkdir /mybackup_new_host
    cd /mybackup_new_host
    /opt/WebSphereV85/java/bin/jar -xf v70tov85dmgr01.jar
    where mybackup_new_host is the directory from which the profile configuration files are migrated.
  9. Stop the application servers on the old node, then stop the node agent on the old node.
  10. Stop and disable the node on the old host. Ensure that you do not use the node on the old host. To disable the node, you must rename the associated serverindex.xml file as indicated in the following information:
    Old name
    $PROFILE_ROOT/config/cells/cell_name/nodes/node_X/serverindex.xml
    New name
    $PROFILE_ROOT/config/cells/cell_name/nodes/node_X/serverindex.xml_disabled
  11. Run the WASPostUpgrade command to restore the saved node X configuration into the new Version 8.5 managed profile. For example:
    [Windows]
    version_8.5_install_root\bin\WASPostUpgrade.bat \
    mybackup_new_host\v70tov85node1 -profileName v70tov85node1 
    -oldProfile 70node1 -replacePorts TRUE 
    -backupConfig TRUE -includeApps TRUE -scriptCompatibility 
    TRUE -username myuser -password mypass
    [AIX][HP-UX][Linux][Solaris]
    version_8.5_install_root/bin/WASPostUpgrade.sh /
    mybackup_new_host/v70tov85node1 -profileName v70tov85node1 
    -oldProfile 70node1 -replacePorts TRUE -backupConfig 
    TRUE -includeApps TRUE -scriptCompatibility TRUE 
    -username myuser -password mypass
    Avoid trouble Avoid trouble: The script compatibility flag on your deployment manager must be the same as the flag that you use on your clients.gotcha
  12. Check the WASPostUpgrade console output for the following messages. You might find the following messages: "Failed with errors" or "Completed with warnings". Also, look in the following log files for errors or warning messages:
    • mybackup_new_host/v70tov85node1/logs/WASPostMigrationSummary.log
    • mybackup_new_host/v70tov85node1/logs/WASPostUpgrade. <target profile>.< timestamp >.log
    • mybackup_new_host/v70tov85node1/logs/WASPostUpgrade.< target profile name >.trace
    Note: If the WASPostUpgrade command fails, you might need to restore the Version 8.5 deployment manager from the backup configuration file. If the WASPostUpgrade command processing ran the syncNode command, then the deployment manager is aware that the node X has been migrated. The node X cannot be migrated again until the deployment manager has been restored to the state before the node X migration.
  13. Check the Version 8.5 deployment manager SystemOut.log file for error or warning messages.
    Note: This topic references one or more of the application server log files. As a recommended alternative, you can configure the server to use the High Performance Extensible Logging (HPEL) log and trace infrastructure instead of using SystemOut.log , SystemErr.log, trace.log, and activity.log files on distributed and IBM® i systems. You can also use HPEL in conjunction with your native z/OS® logging facilities. If you are using HPEL, you can access all of your log and trace information using the LogViewer command-line tool from your server profile bin directory. See the information about using HPEL to troubleshoot applications for more information on using HPEL.
  14. Start the migrated Version 8.5 node X agent.
  15. Check the Version 8.5 deployment manager and node X SystemOut.log for error or warning messages.
  16. Synchronize the cell if the auto synchronization process is not enabled.
  17. Start the appropriate application servers on Version 8.5 migrated node X.
  18. Run the backupConfig command and save the Version 8.5 profile configuration to a file. For example:
    [Windows]
    version_8.5_profile_root\v70tov85node1\bin\backupConfig.bat 
    \mybackup_new_host\v70tov85node1.zip -username myuser 
    -password mypass -nostop
    [AIX][HP-UX][Linux][Solaris]
    version_8.5_profile_root/v70tov85node1/bin/backupConfig.sh 
    /mybackup_new_host/v70tov85node1.zip -username myuser 
    -password mypass -nostop
    Each time you run the backupConfig command on a specific node, use a new backup file name.
  19. Save the deployment manager configuration using the backupConfig command. On the Version 8.5 deployment manager host, change to the deployment_manager_profile_root/bin directory. Run the backupConfig command and save the Version 8.5 profile configuration to a file. For example:
    [Windows]
    version_8.5_profile_root\v70tov85dmgr01\bin\backupConfig.bat 
    \mybackup_new_host\v70tov85dmgr01backupMigratedDmgrPlusNodeX.zip 
    -username myuser -password mypass
    [AIX][HP-UX][Linux][Solaris]
    version_8.5_profile_root/v70tov85dmgr01/bin/backupConfig.sh 
    /mybackup_new_host/v70tov85dmgr01backupMigratedDmgrPlusNodeX.zip 
    -username myuser -password mypass
    Note: For each node that you migrate, backup the Version 8.5 Deployment Manager configuration to a new backup file.
  20. Repeat the previous steps for additional nodes.
Task topic    

Terms and conditions for information centers | Feedback

Last updated: April 20, 2014 10:34 PM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-nd-dist&topic=tmig_migrate_remote_commandline_step14
File name: tmig_migrate_remote_commandline_step14.html