Migrating a large WebSphere Application Server, Network Deployment configuration with a large number of applications

If you have an existing WebSphere® Application Server Version 5.1.x or Version 6.x WebSphere Application Server, Network Deployment configuration with a significant number of large applications and you must meet a specific maintenance window for migration, you might have some difficulty if you use the standard migration scenario. In this case, you might want to copy the resources in the configuration tree from a Version 5.1.x or Version 6.x deployment manager configuration to a Version 7.0 deployment-manager management profile but defer adding applications to the Version 7.0 profile so that you can continue managing the environment using the Version 5.1.x or Version 6.x deployment manager.

Before you begin

Tip: To avoid possible connection-timeout problems, modify the connection-timeout value before running the WASPostUpgrade command to migrate the federated nodes in a cell containing many small applications, a few large applications, or one very large application. If you use a SOAP connector, for example, perform the following actions:
  1. Go to the following location in the Version 7.0 directory for the profile to which you are migrating your federated node:
    profile_root/properties 
  2. Open the soap.client.props file in that directory and find the value for the com.ibm.SOAP.requestTimeout property. This is the timeout value in seconds. The default value is 180 seconds.
  3. Change the value of com.ibm.SOAP.requestTimeout to make it large enough to migrate your configuration. For example, the following entry would give you a timeout value of a half of an hour:
    com.ibm.SOAP.requestTimeout=1800
    Note: Select the smallest timeout value that will meet your needs. Be prepared to wait for at least three times the timeout that you select—once to download files to the backup directory, once to upload the migrated files to the deployment manager, and once to synchronize the deployment manager with the migrated node agent.
  4. Go to the following location in the backup directory that was created by the WASPreUpgrade command:
    backupDirectory/profiles/profile_name/properties
  5. Open the soap.client.props file in that directory and find the value for the com.ibm.SOAP.requestTimeout property:
  6. Change the value of com.ibm.SOAP.requestTimeout to the same value that you used in the Version 7.0 file.

Read Overview of migration, coexistence, and interoperability and Premigration considerations. For resources to help you plan and perform your migration, visit Knowledge Collection: Migration planning for WebSphere Application Server.

About this task

You can use this strategy to satisfy your specific maintenance-window requirement by building the full WebSphere Application Server, Network Deployment configuration in the background while the existing topology is still running and being managed.

For help in troubleshooting problems when migrating, read Troubleshooting migration.

Procedure

  1. Make sure that the WebSphere Application Server Version 5.1.x or Version 6.x deployment manager is running and managing the existing environment, and make sure that no Version 7.0 deployment manager is running.

    This is important in order to prevent two different deployment managers from trying to manage the same environment.

  2. Start the Qshell environment so that you can run WebSphere Application Server scripts.
    Enter the following command from a command line:
    STRQSH
  3. Run the WASPreUpgrade command.
    Use the following parameters:
    app_server_root/bin/WASPreUpgrade 
     backup_directory_name
     old_profile_root
    where
    • app_server_root is the location where Version 7.0 is installed
    • backup_directory_name (required parameter) is the fully qualified path to the integrated file system directory where the WASPreUpgrade migration tool stores the saved configuration and files

      The directory is created if it does not already exist. Additionally, the tool writes a log file called WASPreUpgrade.log that chronicles the steps taken by the WASPreUpgrade command.

    • old_profile_root (required parameter) is the path to the Version 5.1.x or Version 6.x instance or profile to be migrated

    For a full explanation of the WASPreUpgrade command and its parameters, read WASPreUpgrade command.

  4. Run the WASPostUpgrade command.
    Use the following parameters:
    app_server_root/bin/WASPostUpgrade
     backup_directory_name
     -profileName 70ND_profile_name
     -includeApps script
     -keepDmgrEnabled true
    where
    • app_server_root is the location where Version 7.0 is installed
    • backup_directory_name (required parameter) is the fully qualified path to the integrated file system directory that the WASPreUpgrade migration tool previously used to save the Version 5.1.x or Version 6.x deployment manager configuration
    • 70ND_profile_name (required parameter) is the name of the Version 7.0 deployment-manager management profile to which the script migrates your configuration

    For a full explanation of the WASPostUpgrade command and its parameters, read WASPostUpgrade command.

    At this point, you can exit the maintenance window and still manage the environment using the WebSphere Application Server Version 5.1.x or Version 6.x deployment manager.

  5. Customize the administration files.
    1. Go to the migration backup directory location that contains the generated administration files.
    2. Combine and tailor the administration files as needed.

      This might include grouping applications together in some administration files or specifying the installedApplications directory using the installed.ear.destination parameter .

  6. Start the Qshell environment so that you can run WebSphere Application Server scripts.
    Enter the following command from a command line:
    STRQSH
  7. Run the wsadmin command to install the applications.
    • Install the applications in the Version 7.0 configuration during either normal operations or in applicable maintenance windows.
    • Specify -conntype NONE. For example:
      wsadmin -f application_script -conntype NONE

    After all applications have been installed, you are ready to start using the WebSphere Application Server Version 7.0 deployment manager.

  8. Stop the WebSphere Application Server Version 5.1.x or Version 6.x deployment manager.

    This is important in order to prevent two different deployment managers from trying to manage the same environment.

    You can do this in a number of ways. One easy way is to rename the serverindex.xml file in the node directory of the Version 5.1.x or Version 6.x deployment manager to something else.

  9. Start the WebSphere Application Server Version 7.0 deployment manager.
    1. Start the Qshell environment so that you can run WebSphere Application Server scripts.
      Enter the following command from a command line:
      STRQSH
    2. If the QWAS7 subsystem has not been started, start the default profile.
      Enter the following command from a command line:
      STRSBS QWAS7/QWAS7
    3. Start the Version 7.0 deployment manager using the startManager script.
      Use the following parameters:
      app_server_root/bin/startManager
       -profileName 70ND_profile_name
      where
      • app_server_root is the location where Version 7.0 is installed
      • 70ND_profile_name is the name of the Version 7.0 deployment-manager management profile

Results

At this point, the WebSphere Application Server Version 7.0 deployment manager should be running and the normal application synchronization should occur.

You can follow either of the following procedures:
  • Migrate the entire cell before installing the applications.
  • Perform the following actions:
    1. Install the applications and leave the cell in a mixed state.
    2. When you are ready, modify the connection-timeout values (as described in the tip at the beginning of this article) before running the WASPostUpgrade command to migrate the federated nodes.
Task topic    

Terms of Use | Feedback

Last updated: Oct 22, 2010 2:45:02 AM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=compass&product=was-nd-iseries&topic=tmig_largend
File name: tmig_largend.html