+

Search Tips   |   Advanced Search

Migrate a large WAS ND configuration with a large number of applications

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

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 we use a SOAP connector, for example, perform the following actions:

  1. Go to the following location in the v9.0 directory for the profile to which we are migrating the 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 is 180 seconds.

  3. Change the value of com.ibm.SOAP.requestTimeout to make it large enough to migrate the configuration. For example, the following entry would give you a timeout value of a half of an hour:

      com.ibm.SOAP.requestTimeout=1800

    Select the smallest timeout value that will meet our needs. Be prepared to wait for at least three times the timeout that we 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 created by the WASPreUpgrade command:

      backupDirectory/profiles/profile/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 we used in the v9.0 file.

Read Overview of migration, coexistence, and interoperability and Migration considerations. For resources to help us plan and perform our migration, visit Knowledge Collection: Migration planning for WAS.

Use this strategy to satisfy your specific maintenance-window requirement by building the full WAS v9.0 WAS ND configuration in the background while the existing topology is still running and being managed.

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


Tasks

  1. Verify the WAS v7.0 or later deployment manager is running and managing the existing environment, and make sure that no v9.0 deployment manager is running.

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

  2. Run the WASPreUpgrade command.

    • Run the WASPreUpgrade command from the v9.0 app_server_root/bin directory.
    • Specify the name of the v7.0 or later migration backup directory.
    • Specify the name of the v7.0 or later WAS ND installation.
    • Optional: Specify the name of a specific instance or profile to be migrated from a previous version of WAS.
    • Optional: Specify the location of user preferences for the administrative console for one or more profiles.

    For example:

      WASPreUpgrade /WAS6.1_backup_directory /WAS6.1_install_directory

  3. Run the WASPostUpgrade command.

    • Run the WASPostUpgrade command from the v9.0 app_server_root/bin directory.

    • Specify the name of the v7.0 or later migration backup directory.

    • Specify -includeApps script. This will not migrate the applications, but it will create some scripts that we can run later to install the applications

    • Specify -keepDmgrEnabled true.

    • Specify any other options that we want.

    For example:

      WASPostUpgrade /WAS6.1_backup_directory -profileName dmgr_profile -includeApps script -keepDmgrEnabled true

    At this point, we can exit the maintenance window and still manage the environment using the WAS v7.0 or later deployment manager.

  4. Customize the administration files.

    1. Go to the migration backup directory location containing 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 .

  5. Run the wsadmin command to install the applications.

    • Install the applications in the v9.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, we are ready to start using the WAS v9.0 deployment manager.

  6. Stop the WAS v7.0 or later deployment manager.

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

    We can do this in a number of ways. One way is to rename the serverindex.xml file in the node directory of the v7.0 or later deployment manager to something else.

  7. Start the WAS appservers v9.0 deployment manager.

    Start the deployment manager from its profile_root/bin directory. For example:

At this point, the WAS v9.0 deployment manager should be running and the normal application synchronization should occur.

We can follow either of the following procedures: