WAS v8.0 > Migration and coexistence > Distributed operating systems > Overview

Premigration considerations

Overview

This topic is about configuration migration, such as migrating dmgrs and federated nodes in a network deployment environment. The Application Migration Toolkit for WAS provides support for migrating applications from previous versions of WAS to the latest product version. For information about migrating applications, read more about the Application Migration Toolkit.

Consider the following information before you migrate Application Server:

• After you install WAS v8.0, you might want to build a complete WAS ND cell configuration and verify that it works correctly before you attempt to migrate an existing cell or node. This process ensures that the system has all of the necessary prerequisites and supports the new level of WAS.

• Before you perform the migration, evaluate the items deprecated in WAS v8.0.

• High-availability manager (HAM) and core-group functionality are included in WAS v6.0 and later. Read Core group migration considerations

  In most cases the recommended number of servers in a core group should not exceed 50. You receive a warning message when the migration tools add a server that exceeds the recommended upper limit.

• Before you migrate to Java SE JDK 6 from JDK 5 or JDK 1.4 , review the applications for necessary changes based on the Sun Microsystems Java specification.

• Unconfigure any ITCAM for WebSphere Data Collectors

  Verify supported versions of ITCAM for WAS v8, then upgrade ITCAM to the corresponding release and re-configure ITCAM on the migrated nodes.

• When migrating a cell with multiple nodes, the applications must remain at the lowest JDK level until all nodes are migrated.

• Java Native Interface (JNI) applications that work with WAS v6.0.2 on Solaris x64 must be recompiled in a 64-bit environment for them to work with WAS v8.0. This includes all JNI applications that run in a WAS process—code called from Enterprise JavaBeans for example.

  On Solaris x64, WAS Version 6.0.2 runs as a 32-bit application even though the underlying operating system supports a 64-bit environment. This is because the underlying Java Virtual Machine (JVM) is 32-bit. WAS v8.0 runs as a 64-bit application because the underlying JVM is 64-bit. JNI applications compiled in a 32-bit environment for v6.0.2 cannot run in the 64-bit environment of v8.0.

• The migration articles in this information center assume that WAS v8.0 is being installed in an environment where it must coexist with prior levels of WAS.

  Consider the following items when planning to enable coexistence:

  • Update prerequisites to the levels required by WAS v8.0.

    Prior levels of WAS continue to run at the higher prerequisite levels.

  • Review the ports that have been defined to ensure that the WAS v8.0 installation does not conflict.

    Read Port number settings in WAS versions for default port information.

  Read Run multiple application server versions for more information.

• Consider the following information if you are planning to have any mixed-release cells:

  • We can upgrade a portion of the nodes in a cell to WAS v8.0 while leaving others at the previous release level. This means that, for a period of time, you might be administering servers that are at the previous release level and servers that are running the newer release in the same cell.

    In this mixed-release environment, some restrictions on what you can do with servers at the previous release level might exist. For details, read the "Creating application servers" article in the information center.

  • A WAS v8.0 WAS ND cell can contain mixed releases of v6.x nodes; however, no mixed-node management support exists for v6.0.0.x and v6.0.1.x.

    The v8.0 migration tools still migrate these nodes during deployment-manager migration; however, these tools issue a warning message that the nodes cannot be managed by the v8.0 dmgr. We can then perform one of the following actions.

    • Upgrade all v6.0.0.x and v6.0.1.x nodes to at least Version 6.0.2. This allows them to be administered by a v8.0 dmgr.

    • Migrate these nodes to v8.0.

• During migration, v8.0 cluster information is distributed throughout the cell. v6.0.x nodes that are not at v6.0.2.11 or later fail to read this information and the cluster function might fail. Therefore, upgrade all Version 6.0.x nodes that will be contained in or interoperating with a v8.0 cell to v6.0.2.11 or later before migrating your dmgrs to v8.0.

• WAS v8.0 migration converts HTTP transports to channel-framework web container transport chains.

  See:

  • Configure transport chains
  • HTTP transport channel settings
  • Transport chains

• The default profile location was changed in WAS v6.0.x. The previous file path WAS_HOME/profiles/ <profile>/ <node>/installedApps/ <ear>/ <war> was changed to WAS_HOME/profiles/ <profile>.

  To avoid configuration errors, use servlet APIs to control the file location instead of using the default location.

• The following restrictions apply to a dmgr migration:

  • The v8.0 cell name must match the cell name in the v6.x configuration.

    If you create a profile with a new cell name, the migration will fail.

  • Either one or the other of the following options must be true:
    • The v8.0 dmgr node name must be the same as the v6.x dmgr node name.
    • The v8.0 dmgr node name must be different from every node name in the Version 6.x configuration.

    Otherwise, the migration fails with the following message:

    MIGR0488E: The dmgr node name in the new configuration ({0}) cannot be the same as a nodeagent node in the old configuration.

• When migrating a federated node, the WAS v8.0 cell name and node name must match their respective v6.x names.

• If you create a profile that does not meet the migration requirements such as naming requirements, you can remove the previous profile and create a new one rather than uninstalling and reinstalling the WAS WAS v8.

• If you migrate a node to WAS v8.0 and then discover that revert back to v6.x, read Rolling back environments.

• If we have a web services gateway running on a WAS v6.x application server that is part of a WAS ND cell and you want to migrate the cell from a v6.x to a v8.0 dmgr, first preserve the gateway configuration as described in the "Coexisting with previous gateway versions" article in the information center.

• The migration tools create a migration backup directory containing a backup copy of the configuration from the previous version. The following guidelines might help you to determine the amount of file-system space that this directory might require:

  • If you are migrating from v6.x, the space available for this directory must be at least the size of the configuration directory and applications from the previous profile.

• If you use the migration tools to create more than one Version 8.0 target profile on the same host or installation instance and you use the default port settings, there is a chance that the target profiles will share the same ports for some of the new v8.0 port definitions. This will cause startup problems if both of the migrated profiles are used.

  If you are migrating two or more profiles that reside on the same host or installation instance, perform the following actions for each additional target profile:

  1. Before using the migration tools, use the Profile Management tool or manageprofiles command to create the target profile and make sure that you select unique ports rather than using the default ports.

  2. When you use the migration tools, select the target profile rather than letting the tools create it.

• The amount of storage that the system requires during migration to v8.0 depends on the environment as well as on the migration tool that you are using.

  • WASPreUpgrade storage requirements

    • Location: Backup directory specified as a parameter of the WASPreUpgrade command

    • Amount: For an estimate of your storage requirements when using this command, add the following amounts.

      • Size of the following items for all of the profiles in your previous configuration:
        • PROFILE_ROOT/installableApps
        • PROFILE_ROOT/installedApps
        • PROFILE_ROOT/config
        • PROFILE_ROOT/properties
        • Shared libraries referenced in libraries.xml
        • RAR files referenced in resources.xml

      • If trace is enabled, which is the default, up to 200 MB (depending on the size and complexity of the configuration)

    For more information about this command, read WASPreUpgrade command.

  • WASPostUpgrade storage requirements

    • For an estimate of your storage requirements when using this command, add the following amounts.

      • Location: New configuration relative to the new PROFILE_ROOT

        Size of the following items for the previous profile that you are migrating:

        • PROFILE_ROOT/installableApps
        • PROFILE_ROOT/installedApps
        • PROFILE_ROOT/config
        • PROFILE_ROOT/properties
        • Shared libraries referenced in libraries.xml
        • RAR files referenced in resources.xml

      • Location:

        Backup directory specified as a parameter of the WASPreUpgrade and WASPostUpgrade commands

        If trace is enabled, which is the default, up to 1 GB (depending on the size and complexity of the configuration)

    For more information about this command, read WASPostUpgrade command.

• If you use isolated data repositories—specifically, nonshared data repositories such as transaction logs for SIB and IBM Cloudscape or Apache Derby databases—and you migrate from a previous release, your existing databases and transaction logs are saved when the WASPreUpgrade tool is run. Any database changes that you make after the WASPreUpgrade tool is run will not be reflected in the migrated environment.

  • If we have mission-critical information stored in these local data repositories, you should safely shut down all servers that interact with those repositories before attempting migration. Those servers should remain offline until the migration has been successfully completed or rolled back.

  • If you make multiple attempts at migration, either because of unexpected rollback or to apply fixes, rerun the WASPreUpgrade tool so that any changes to your isolated data repositories are reflected in the migrated environment.

  After the migration is complete or we have rolled back to the previous version, you can restart the servers that interact with these isolated data repositories.

• Do not migrate a node with active servers if the SIB uses the file-store option for one or all of the messaging engines.

  • The WASPreUpgrade tool fails with a file-locked exception when you try to copy the file stores on an active application server.

  • The WASPreUpgrade tool copies a locked file, which could compromise data consistency.

  A data store for the messaging engine is an option for a hot migration; but if a file store must be used, the servers should not be running.

• If you try to run the WASPreUpgrade command to migrate from v6.1 with the node and application server that own the SIB file store still running, you might get an error similar to the following:

  C:\was80A\bin>WASPreUpgrade c:\bkupWAS6.1.0.17June30B C:\was61B
  MIGR0385I: Starting to save profile AppSrv01.
  MIGR0215W: The migration function cannot copy the file and open the destination file
  c:\bkupWAS6.1.0.17June30B\migrated\C_\FSJune19\Log.
  MIGR0272E: The migration function cannot complete the command.
  

  If you then shut down the application server and node, the WASPreUpgrade command completes.

• Before you migrate an Apache Derby database, ensure that any application servers hosting applications that are using the Apache Derby database are closed. Otherwise, the Apache Derby migration fails.

• You should be aware of the following rules related to migrating security domains:

  • If you migrate a dmgr that has a security domain with a cell-level scope, the migration tools take the following actions:

    • Migration creates a domain in the new configuration called PassThroughToGlobalSecurity if it does not already exist.

    • Migration adds a cluster mapping to the new configuration for all clusters that existed in the old configuration.

      • Clusters that only existed in the v8.0 deployment-manager configuration before migration do not have their mappings to PassThroughToGlobalSecurity changed.

        • If mappings for the v8.0 clusters exist before migration, they still exist after migration.

        • If no mappings for the v8.0 clusters exist before migration, they still do not exist after migration.

      • If a cluster exists in both the previous configuration and the v8.0 configuration before migration, the cluster in the new configuration is added to the PassThroughToGlobalSecurity domain and behaves like the cluster in the previous release.

    • Migration adds a bus mapping for any busses that exist in a migrated Version 6.1.x configuration.

      Bus mappings are updated following the same rules as those for cluster mapping described above.

    • Administrative servers (dmgr) are not added to the PassThroughToGlobalSecurity domain.

  • If you migrate a federated node that has a security domain with a cell-level scope, the migration tools take the following actions:

    • Migration creates a domain in the new configuration called PassThroughToGlobalSecurity if it does not already exist.

    • Migration adds a server-level mapping to the PassThroughToGlobalSecurity domain for all non-clustered servers in the old node's configuration.

      • Servers on the node that is being migrated that are part of a cluster do not receive entries in the PassThroughToGlobalSecurity domain because this was addressed through a cluster mapping during deployment-manager migration.

        If we have removed that mapping, migration maintains that behavior.

      • Administrative servers (node agents) are not added to the PassThroughToGlobalSecurity domain.

  Read the "Security domains in a mixed-version environment" section of the "Multiple security domains" article in the information center.

• Modifications to the java.security file are lost during migration.

  If you've updated your java.security file in the previous version of WAS, the new version will not have your updates. For example, if you modified your provider list to use FIPS or Hardware crypto, your migrated cell will not use these providers, and therefore will not use FIPS or Hardware Crypto.

  To migrate your modified java.security file, use the following steps:

  1. Before migrating, copy the java.security file from the old WAS_HOME/java/jre/lib/security to a temporary directory.

  2. Migrate WAS to v8.0.

  3. Compare the old java.security file with the new v8.0 java.security file that is located in V8WAS_HOME/java/jre/lib/security/java.security.

  4. Update V8WAS_HOME/java/jre/lib/security/java.security with changes to the provider list from the old java.security file.

  5. Repeat this procedure for each installation of WAS.

• During migration, some of the application metadata might be reset to the default and cause the application to function differently from what you expect.

  If you installed an application in your old environment with Use Metadata From Binaries set to true and during that installation or a future update of the application you made a change to the application's metadata (such as JNDI resource references or database entries for example), the change might be lost when you migrate.

  When Use Metadata From Binaries is set to true, the administrative code only updates the metadata in the binary EAR file. This option is not supported in a mixed cell; therefore, it is automatically turned to false as part of migration. When this happens, the expanded metadata in the configuration directories take precedence over the values in the binary EAR file. This causes the values from the original EAR file installation to take precedence over any updates that you might have made.

  Perform one of the following actions to resolve this issue:

  • Before migrating, update the applications in the old environment and set Use Metadata From Binaries to false. Ensure that the applications are functioning correctly with this new setting, and then run the migration.

  • After migrating, update the applications and correct the metadata as required to allow the applications to function appropriately.

• After you use the migration tools to migrate to WAS v8.0, you might need to perform some actions that are not done automatically by the migration tools.

  • Verify LTPA security settings are set appropriately.

  • Check the WASPostUpgrade.log file in the logs directory for details about any JSP objects that the migration tools did not migrate.

    If v8.0 does not support a level for which JSP objects are configured, the migration tools recognize the objects in the output and log them.

  • Review JVM settings

  • Verify the results of the automatic Apache Derby database migration, and manually migrate any Apache Derby databases that are not automatically migrated by the tools.

  • WAS v8.0 does not include the WebSphere Connect JDBC driver for SQL Server. The WebSphereConnectJDBCDriverConversion tool is provided to convert data sources from the WebSphere Connect JDBC driver to the DataDirect Connect JDBC driver or the Microsoft SQL Server JDBC driver.

    Read Migrate from the WebSphere Connect JDBC driver for more information.

  • During cell migrations to v8.0, the v6.0.x server user ID is not migrated or mapped to the v8.0 Primary administrative user name field as shown in the administrative console at Security > Global security > user_account_repository > Configure. The server user identity value is transferred, and the proper user ID from the v6.0.x cell is migrated along with a password.

    The primary administrative user name is required when defining LDAP as the security repository in v8.0.

    The Primary administrative user name field and server user identity value are used by the product when you use administrative scripts (wsadmin) to update the configuration. v6.0.x and earlier versions of the product store a valid username-and-password pair in the authenticating registry inside the local product configuration files. Beginning with Version 6.1, an administrative user ID can be set but the authentication information is not stored in the local product configuration files (thereby improving security).

    If you migrate from an older release of the product to v6.1 or later, the old model is still used in order to maintain backward compatibility and to allow the mixed cell to function properly. When you are ready to upgrade to the new model, which requires that all nodes in the cell be at v6.1.x or later, you can perform the following actions:

    • Input a Primary administrative user name that represents a valid user identity in the authentication authority (user registry).

    • Change the server user identity value from Server identity stored in the repository to Automatically generated server identity.

    If you are still using a mixed cell in v8.0 that contains Version 6.0.x nodes, continue to use the old model or the older nodes will not be able to communicate with the new nodes. You should not make any changes to the security settings in the mixed cell. If editing the user registry becomes necessary in a mixed cell that is not ready to be upgraded to the new model, however, select a valid user identity in the authentication authority (user registry) and put that value into the Primary administrative user name field but do not change the value of the server user identity. On all platforms, it is important to select a user ID that is valid for the scripting tools (wsadmin).

Migrate and coexisting application servers

+

Search Tips   |   Advanced Search