Migrate nodes
Migrate application client installations
Step 10 towards the goal: Migrate cells using the command-line tools
Use the migration tools to migrate the previous versions of the nodes in the configuration to v8.5. Perform the following procedure for each node to migrate to v8.5.
Avoid trouble: We must use the same source node name and cell name for each node that you migrate to v8.5. gotcha
- Ensure that the v8.5 deployment manager is running.
- Create the target node profile. Run the manageprofiles command with the appropriate parameters to create a new managed profile. For example:
(dist)
/opt/WebSphereV85/manageprofiles.sh -create -profileName node1 -templatePath /opt/WebSphereV85/profileTemplates/managed -nodeName currentNode1Name -cellName currentCellName -hostName mynode1host.company.com
(iseries)/QIBM/ProdData/WebSphere/AppServer/V85/ND/bin/manageprofiles -create -profileName currentNode1Name -templatePath /QIBM/ProdData/WebSphere/AppServer /V85/ND/profileTemplates/managed -nodeName currentNode1Name -cellName currentCellName -hostName mynode1host.company.com
- Run the WASPreUpgrade command to save the current node X configuration information to a migration backup directory. Choose a new directory for the backup files. For example:
(dist)
/opt/WebSphereV85/bin/WASPreUpgrade.sh /mybackup/v70tov85node1 /opt/WebSphereV70 -oldProfile 70node1
(iseries)/QIBM/ProdData/WebSphere/AppServer/V85/ND/bin/WASPreUpgrade /mybackup/ v70tov85node1 /QIBM/UserData/WebSphere/AppServer/V70/ND/profiles/currentNode1Name
- If the WASPreUpgrade command completed with Success, then checking the logs for errors or warnings is not necessary.
- Check the WASPreUpgrade console output for the following messages: Failed with errors or Completed with warnings.
- Look in the following logs for warnings or errors:
- migration_backup_dir/logs/WASPreUpgrade.old_profile.timestamp.log
- migration_backup_dir/logs/WASPreUpgrade.trace
- Stop the node agent. If we have Version 7.0 or above nodes running during a migration to v8.5, stop the node agent on the node that is being migrated. If we do not stop the node agent, you might encounter corruption problems.
- Run the WASPostUpgrade command to restore the saved node X configuration into the new v8.5 managed profile. For example:
(dist)
/opt/WebSphereV85/bin/WASPostUpgrade.sh /mybackup/v70tov85node1 -profileName v70tov85node1 -oldProfile 70node1 -replacePorts TRUE -backupConfig TRUE -scriptCompatibility TRUE -username myuser -password mypass
(iseries)/QIBM/ProdData/WebSphere/AppServer/V85/ND/bin/WASPostUpgrade /mybackup/ v70tov85node1 -profileName currentNode1Name -replacePorts TRUE -backupConfig TRUE -scriptCompatibility TRUE -username myuser -password mypassThe script compatibility flag on the deployment manager must be the same as the flag that you use on the nodes.gotcha
- If the command completed with Success, then checking the logs for errors or warnings is not necessary.
- Check the WASPostUpgrade console output for the messages Failed with errors or Completed with warnings.
- Look in the following logs for errors or warnings:
- migration_backup_dir/logs/WASPostUpgrade.target_profile.timestamp.log
- migration_backup_dir/logs/WASPostUpgrade.target_profile.trace
If the WASPostUpgrade command fails, we might have to restore the v8.5 deployment manager from the backupConfig file. If the WASPostUpgrade processing ran the syncNode command, the deployment manager is aware that the node X was migrated. The node X cannot be migrated again until the deployment manager is restored to the state before the node X migration.
- Check the v8.5 deployment manager SystemOut.log file for warnings or errors.
This topic references one or more of the application server log files. As a recommended alternative, we 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. We can also use HPEL in conjunction with the native z/OS logging facilities. If we are using HPEL, we can access all of the log and trace information using the LogViewer command-line tool from the server profile bin directory. See the information about using HPEL to troubleshoot applications for more information on using HPEL.
- Start the migrated v8.5 node X agent.
- Check the v8.5 deployment manager and node X SystemOut.log file for warnings or errors.
- Synchronize the cell.
- Stop all the application servers on the v8.5 migrated node X.
- Start the appropriate application servers on the v8.5 migrated node X.
- Save the v8.5 profile configuration to a file by running the backupConfig command with the appropriate parameters. For example:
(dist)/opt/WebSphereV85/profiles/v70tov85node1/bin/backupConfig.sh /mybackupdir/ v70tov85node1.zip -username myuser -password mypass -nostop
(iseries)
/QIBM/UserData/WebSphere/AppServer/V85/profiles/v70tov85node1/bin/backupConfig /mybackupdir/v70tov85node1.zip -username myuser -password mypass -nostop
Each time that you run the backupConfig command, use a new backup file name.
- Save the deployment manager configuration to a file by running the backupConfig command with the appropriate parameters. Before you run the command, change to the deployment_manager_profile_root/bin directory on the v8.5 deployment manager host.
For each node migrated, back up the v8.5 deployment manager configuration to a new backup file. For example:
(dist)/opt/WebSphereV85/profiles/v70tov85dmgr01/bin/backupConfig.sh /mybackupdir/ v70tov85dmgr01backupMigratedDmgrPlusNodeX.zip -username myuser -password mypass
(iseries)/QIBM/UserData/WebSphere/AppServer/V85/profiles/currentDmgrName/bin/ backupConfig.sh /mybackupdir/v70tov85dmgr01backupMigratedDmgrPlusNodeX.zip -username myuser -password mypassIf we are migrating a node to a different host, refer to the information about migrating nodes in Migrate cell configurations to new host machines using the command-line tool.
Subtopics
Related tasks
Migrate cell configurations to new host machines using the command-line tool