Migrating Compute Grid or Feature Pack for Modern Batch using the command-line tools

You can use the command-line tools to migrate a cell from a previous version of WebSphere® Extended Deployment Compute Grid to Version 8.5.

1. Back up current deployment manager and node configuration
   In case of failure during the migration, save the current deployment manager and node configuration to a file that you can use later for recovery purposes. To save the configuration, run the backupConfig command on the deployment manager and all existing nodes.
   1. Change to the deployment_manager_profile_root/bin directory.
   2. Run the backupConfig command with the appropriate parameters and save the current profile configuration to a file.
      For example:

      

      /opt/WebSphereV70/profiles/Dmgr01/bin/backupConfig.sh /mybackupdir/Dmgr01backupBeforeV85migration.zip 
      -username myuser -password mypass -nostop

   3. For each node in the configuration, change to the node_profile_root/bin directory.
   4. Run the backupConfig command with the appropriate parameters, and save the current profile configuration to a file.
      For example:

      

      /opt/WebSphereV70/profiles/node1/bin/backupConfig.sh /mybackupdir/
      node1backupBeforeV85migration.zip -username myuser -password mypass -nostop

2. Install WebSphere Application Server Version 8.5
   1. Install WebSphere Application Server Version 8.5 onto each target host in a new directory.
      For more information, see the documentation about installing an application-serving environment.
3. Prepare cells for migration to WebSphere Application Server Version 8.5
   1. On the Deployment Manager node, change to the deployment_manager_profile_root/bin directory.
   2. Run the addCGSystemAppVariables.py script with the appropriate parameters.
      For example:

      

      /opt/WebSphereV70/profiles/Dmgr01/bin/wsadmin.sh -lang jython -conntype NONE -f /opt/WebSphereV85/bin/addCGSystemAppVariables.py -level wcg 

      The value for the -level parameter depends on the product from which you are migrating.

      Source product	-level parameter value
      Compute Grid Version 6.1	wcg
      Compute Grid Version 8.0	wcg8
      WebSphere Application Server Version 8.0	was8
      Feature Pack for Modern Batch	fep

      The default value is wcg.
   3. Synchronize all nodes.
   4. Restart all servers.
4. Create the target deployment manager profile
   The target deployment manager profile is a new deployment manager profile that will be the target of the migration.
   Avoid trouble: The Version 8.5 profile nodeName and cellName must match the previous Version 7.0 or later nodeName and cellName. If the Version 8.5 deployment manager cellName or nodeName are different, the migration will fail.
   1. Run the manageprofiles command with the appropriate parameters to create a deployment manager profile
      For example:

      

      /opt/WebSphereV85/bin/manageprofiles.sh -create -profileName Dmgr01 
      -templatePath /opt/WebSphereV85/profileTemplates/management -serverType 
      DEPLOYMENT_MANAGER -nodeName currentDmgrNodeName -cellName currentCellName 
      -hostName mydmgrhost.company.com

5. Save the current deployment manager configuration to the migration backup directory
   To save the current deployment manager configuration, run the WASPreUpgrade command from the new deployment manager profile bin directory. The WASPreUpgrade command does not make any changes to the Version 7.0 or later configuration.

   If you are migrating from Version 8.0 to Version 8.5 and your profile is a deployment manager, Version 8.0 profile is stopped when WASPreUpgrade runs. The deployment manager is started before WASPreUpgrade completes only if you provide -keepDmgrEnabled true on the command line or specify the corresponding option in the Migration wizard.

   1. Run the WASPreUpgrade command to save the current deployment manager configuration information to a migration backup directory.
      For example:

      

      /opt/WebSphereV85/bin/WASPreUpgrade.sh /mybackup/Dmgr01 /opt/WebSphereV70 -oldProfile Dmgr01

   2. Review warnings or errors in the console output and WASPreUpgrade logs.
      After the WASPreUpgrade command is complete, check the console output for Failed with errors or Completed with warnings messages. Then, check the WASPreUpgrade.old_Profile.timestamp.log and WASPreUpgrade.trace log files for any warnings or errors. If there are errors, fix the errors and run the WASPreUpgrade command again. Check whether the warnings affect any other migration or runtime activities on Version 8.5.

      If the command completed successfully, it is not necessary to check the logs for errors or warnings.

6. Back up the current deployment manager compute grid configuration
   To save the current deployment manager compute grid configuration to the compute grid migration backup directory, run the migrateConfigTo85 command with the --backup parameter. The --backup parameter does not change the existing configuration.
   1. Run the migrateConfigTo85.py script.
      For example:

      /opt/WebSphereV70/profiles/Dmgr01/bin/wsadmin.sh -conntype NONE -lang jython  
      -username myuser-password mypass -f /opt/WebSphereV85/bin/migrateConfigTo85.py 
      --backup -nameOfProfile Dmgr01 -configBackupDir /opt/WSMigration/CGBackup01

   2. Review warnings or errors in the console output.
      After the migrateConfigTo85 command is complete, check the console output for Failed with errors or Completed with warnings messages. If there are errors, fix the errors and run the migrateConfigTo85 command again. Check whether the warnings affect any other migration or runtime activities on Version 8.5.

      If the command completed successfully, it is not necessary to check the logs for errors or warnings.

7. Restore the previous deployment manager configuration
   To restore the previous deployment manager configuration that you saved in the migration backup directory, run the WASPostUpgrade command from the new deployment manager profile bin directory. If you use the options that are shown in the following example, all the ports will be carried forward, the old deployment manager will be shut down and disabled, and all applications will be installed.
   1. Run the WASPostUpgrade command to restore the saved deployment manager configuration into the new Version 8.5 deployment manager profile.
      For example:

      

      /opt/WebSphereV85/bin/WASPostUpgrade.sh /mybackup/Dmgr01 -profileName 
      Dmgr01 -oldProfile 70dmgr01 -replacePorts TRUE -backupConfig TRUE 
      -includeApps TRUE -scriptCompatibility TRUE -keepDmgrEnabled FALSE 
      -username myuser -password mypass

      When creating profiles, only one profile per installation is considered the default.

      The WASPostUpgrade command migrates the default profile for the source and the target installations if the -oldProfile or the -profileName parameters are not specified.

      The default profiles can be identified by looking in the profileRegistry.xml file in the WAS_HOME/properties directory. The source profileRegistry.xml is copied to the migration backup directory as part of the WASPreUpgrade command.

      Avoid trouble:

      • Always specify the -oldProfile and -profileName parameters when you run the WASPostUpgrade command.
      • The script compatibility flag on your deployment manager must be the same as the flag that you use on your nodes. Save the value of the script compatibility flag for later use.
   2. Review warnings or errors in the console output and WASPostUpgrade logs.
      After the WASPostUpgrade command is complete, check the console output for Failed with errors or Completed with warnings messages. Then, check the migration_backup_dir/logs/WASPostUpgrade.target_profile_name.timestamp.log and migration_backup_dir/logs/WASPostUpgrade.target_profile_name.trace log files for any warnings or errors. If there are errors, fix the errors and run the WASPostUpgrade command again. Check whether the warnings affect any other migration or runtime activities on Version 8.5.

      If the command completed successfully, it is not necessary to check the logs for errors or warnings.

8. Update existing system applications and data.
   To update existing system applications and data into the new deployment manager, run the migrateConfigTo85 command with the --wasmigrate parameter.
   1. Run the migrateConfigTo85.py script.
      For example:

      /opt/WebSphereV85/profiles/Dmgr01/bin/wsadmin.sh -conntype NONE -lang jython 
      -f /opt/WebSphereV85/bin/migrateConfigTo85.py --wasmigrate -oldWASHome 
      /opt/WebSphereV70 -newWASHome /opt/WebSphereV85/ -nameOfProfile Dmgr01 
      -cellName currentCellName -configBackupDir c:/opt/WSMigration/CGBackup01 -level wcg8

   2. Review warnings or errors in the console output.
      After the migrateConfigTo85 command is complete, check the console output for Failed with errors or Completed with warnings messages. If there are errors, fix the errors and run the migrateConfigTo85 command again. Check whether the warnings affect any other migration or runtime activities on Version 8.5.

      If the command completed successfully, it is not necessary to check the logs for errors or warnings.

9. Back up the Version 8.5 migrated deployment manager configuration.
   To save the Version 8.5 migrated deployment manager configuration to a file, run the backupConfig command on the Version 8.5 deployment manager.

   Avoid trouble: This is an important step in the cell migration plan. If there are any node migration failures, you can restore the cell configuration to the point before the failure, apply remedial actions, and attempt the node migration again.
   1. Change to the deployment_manager_profile_root/bin directory.
   2. Run the backupConfig command with the appropriate parameters and save the Version 8.5 profile configuration to a file.
      For example:

      

      /opt/WebSphereV85/profiles/Dmgr01/bin/backupConfig.sh /mybackupdir/
      Dmgr01backupMigratedDmgrOnly.zip -username myuser -password mypass

10. Stop existing Compute Grid or Feature Pack nodes.
    1. Stop the node agent on every node that contains a scheduler or an endpoint server.
       This ensures that the node does not synchronize incomplete data when the migrated deployment manager is started. See stopNode command.
11. Start the Version 8.5 deployment manager.
    Ensure that the previous version of the deployment manager is not running.
    1. Change to the new Version 8.5 deployment manager profile bin directory.
    2. Run the startManager command.
    3. While the deployment manager is running, check the SystemOut.log file for warnings or errors.
       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.
    4. Check all of the node's nodeagent and application server logs for new warnings or errors.
       If automatic synchronization is enabled, allow the node to synchronize, allow the applications to restart, and then check the logs for new warnings or errors.
12. Migrate backed-up compute grid data to the new deployment manager
    To migrate data that is saved in the compute grid migration backup directory into the new deployment manager, run the migrateConfigTo85 command with the --restore parameter.
    1. Run the migrateConfigTo85.py script.
       For example:

       /opt/WebSphereV85/profiles/Dmgr01/bin/wsadmin.bat -lang jython  -username myuser -password mypass -f 
       /opt/WebSphereV85/bin/migrateConfigTo85.py --restore -nameOfProfile Dmgr01 -configBackupDir /opt/WSMigration/CGBackup01 -lreeJNDIName jdbc/lree -lreeSchema LREESCHEMA

       The following parameters are optional:

       -configBackupDir

       Use this parameter to specify the location on the file system where the configuration was backed up using the --backup parameter.

       -lreeJNDIName

       Use this parameter to change the default JNDI name that is used by the batch endpoints. The default is jdbc/lree.

       -lreeSchema

       Use this parameter to change the default database schema that is used by the batch endpoints. The default is LREESCHEMA.

       -nameOfProfile

       Use this parameter to change the default profile name. The default is Dmgr01.

    2. Review warnings or errors in the console output.
       After the migrateConfigTo85 command is complete, check the console output for Failed with errors or Completed with warnings messages. If there are errors, fix the errors and run the migrateConfigTo85 command again. Check whether the warnings affect any other migration or runtime activities on Version 8.5.

       If the command completed successfully, it is not necessary to check the logs for errors or warnings.

13. Back up the Version 8.5 migrated deployment manager configuration
    To save the Version 8.5 migrated deployment manager configuration to a file, run the backupConfig command on theVersion 8.5 deployment manager.

    Avoid trouble: This is an important step in the cell migration plan. If there are any node migration failures, you can restore the cell configuration to the point before the failure, apply remedial actions, and attempt the node migration again.
    1. Change to the deployment_manager_profile_root/bin directory.
    2. Run the backupConfig command with the appropriate parameters and save the Version 8.5 profile configuration to a file.
       For example:

       

       /opt/WebSphereV85/profiles/Dmgr01/bin/backupConfig.sh /mybackupdir/Dmgr01.zip -username myuser -password mypass

14. Migrate application client installations
    Migrate client resources to Version 8.5 level resources.
    1. Install the WebSphere Version 8.5 Application client.
    2. Run the clientUpgrade command on your application client EAR files.

       For more information, see clientUpgrade command.

    3. Run the Version 8.5 WASPreUpgrade command to save the Application client security settings to a migration backup directory.
       For example:

       /opt/AppClientV85/bin/WASPreUpgrade.sh /mybackup/v70clientTov85 /opt/AppClientV70

    4. Run the Version 8.5 WASPostUpgrade command to restore the Application client security settings to the new Version 8.5 client.
       For example:

       /opt/AppClientV85/bin/WASPostUpgrade.sh /mybackup/v70clientToV85 

15. Migrate databases
    You can migrate your WebSphere Extended Deployment Compute Grid or Feature Pack for Modern Batch databases to Version 8.5. The database migration DDL scripts are in the WAS_HOME/util/Batch directory.
    • WebSphere Extended Deployment Compute Grid
      • For DB2® databases, run the following commands:
        1. db2 -tvf MigrateLRSCHEDTablesDB2v6TOv85.ddl
        2. db2 -tvf MigrateLREETablesDB2.ddl
      • For Derby databases, run the following commands:
        1. >java -Djava.ext.dirs=<WAS_INSTALL_ROOT> /derby/lib -Dij.protocol=jdbc:derby: org.apache.derby.tools.ij MigrateLRSCHEDTablesDerbyv6TOv85.ddl
        2. >java -Djava.ext.dirs=<WAS_INSTALL_ROOT> /derby/lib -Dij.protocol=jdbc:derby: org.apache.derby.tools.ij MigrateLREETablesDerby.ddl
      • For Oracle databases, run the following scripts:
        1. MigrateLRSCHEDTablesOraclev6TOv85.ddl
        2. MigrateLREETablesOracle.ddl
    • Feature Pack for Modern Batch
      • For DB2 databases, run the following command: db2 -tvf MigrateLRSCHEDTablesDB2FePTOv85.ddl
      • For Derby databases, run the following command: >java -Djava.ext.dirs=<WAS_INSTALL_ROOT> /derby/lib -Dij.protocol=jdbc:derby: org.apache.derby.tools.ij MigrateLRSCHEDTablesDerbyFePTOv85.ddl
      • For Oracle databases, run the following script: MigrateLRSCHEDTablesOraclevFePTOv85.ddl
16. Migrate nodes
    Use the migration tool to migrate the previous versions of the nodes in the configuration to Version 8.5. Perform the following procedure for each node that you plan to migrate to Version 8.5.

    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.
    1. Ensure that the Version 8.5 deployment manager is running.
    2. Create the target node profile. Run the manageprofiles command with the appropriate parameters to create a new managed profile.
       For example:

       

       /opt/WebSphereV85/manageprofiles.sh -create -profileName node1 -templatePath 
       /opt/WebSphereV85/profileTemplates/managed -nodeName currentNode1Name -cellName 
       currentCellName -hostName mynode1host.company.com

    3. 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:

       

       /opt/WebSphereV85/bin/WASPreUpgrade.sh /mybackup/v70tov85node1 
       /opt/WebSphereV70  -oldProfile 70node1

    4. If the WASPreUpgrade command completed with Success, then checking the logs for errors or warnings is not necessary.
    5. Check the WASPreUpgrade console output for the following messages: Failed with errors or Completed with warnings.
    6. Look in the following logs for warnings or errors:
       • migration_backup_dir/logs/WASPreUpgrade.old_profile.timestamp.log
       • migration_backup_dir/logs/WASPreUpgrade.trace
    7. Stop the node agent.
       If you have Version 7.0 or later nodes running during a migration to Version 8.5, you must stop the node agent on the node that you are migrating. If you do not stop the node agent, you might encounter corruption problems.
    8. Run the WASPostUpgrade command to restore the saved node X configuration into the new Version 8.5 managed profile.
       For example:

       

       /opt/WebSphereV85/bin/WASPostUpgrade.sh /mybackup/v70tov85node1 -profileName 
       v70tov85node1 -oldProfile 70node1 -replacePorts TRUE -backupConfig TRUE  
       -scriptCompatibility TRUE -username myuser -password mypass

       Avoid trouble: The script compatibility flag on your deployment manager must be the same as the flag that you use on your nodes.
    9. If the command completed with Success, then checking the logs for errors or warnings is not necessary.
    10. Check the WASPostUpgrade console output for the following messages: Failed with errors or Completed with warnings.
    11. Look in the following log files for errors or warnings:
        • migration_backup_dir/logs/WASPostUpgrade.target_profile.timestamp.log
        • migration_backup_dir/logs/WASPostUpgrade.target_profile.trace

        Note: If the WASPostUpgrade command fails, you might have to restore the Version 8.5 deployment manager from the backupConfig file. If the WASPostUpgrade processing executed the syncNode command, the deployment manager is aware that the node X has been migrated. The node X cannot be migrated again until you restore the deployment manager to the state before the node X migration.
    12. To update the Compute Grid data in the new node, run migrateConfigTo85.py.
        For example:

        /opt/WebSphereV85/profiles/node1/bin/wsadmin.sh -lang jython -username myuser-password mypass -f
        /opt/WebSphereV85/bin/migrateConfigTo85.py --restore -node node1 

    13. Check the Version 8.5 deployment manager SystemOut.log for warnings or errors.
        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 warnings or errors.
    16. Synchronize the cell.
    17. Stop all the application servers on the Version 8.5 migrated node X.
    18. Start the appropriate application servers on the Version 8.5 migrated node X.
    19. Run the backupConfig command with the appropriate parameters and save the Version 8.5 profile configuration to a file.
        For example:

        

        /opt/WebSphereV85/profiles/v70tov85node1/bin/backupConfig.sh /mybackupdir/
        v70tov85node1.zip -username myuser -password mypass -nostop

        Each time that you run the backupConfig command, use a new backup file name.
    20. To save the Deployment Manager configuration, run the backupConfig command.
        On the Version 8.5 Deployment Manager host, change to the deployment_manager_profile root/bin directory. Run the backupConfig command with the appropriate parameters and save the Version 8.5 profile configuration to a file.
        For example:

        

        /opt/WebSphereV85/profiles/Dmgr01/bin/backupConfig.sh /mybackupdir/
        Dmgr01backupMigratedDmgrPlusNodeX.zip -username myuser -password mypass

        Notes:

        • If you are migrating a node to a different host, refer to the applicable steps in Migrating cell configurations to new host machines using the command-line tool.
        • For each node that you migrate, back up the Version 8.5 Deployment Manager configuration to a new backup file.
17. Migrate plug-ins for web servers

    The product supports several different web servers, as described in the system requirements. For installation information, see the documentation for your web server type and version.

    1. Ensure that the Version 8.5 deployment manager is running.
    2. Update the version of the web server plug-in that is used in the cell.
    3. For all application servers in the cell that you want to be served by the web server, create a new web server definition for web server plug-in.
       For more information about creating web server definitions, see Implementing a web server plug-in.