WAS v8.0 > Migration and coexistence > Distributed operating systems > Run multiple application server versions


Set up v6.x, v7.0 and v8.0 coexistence

We can install v8.0 to coexist with another installation instance of v6..x or Version 7.0.

Supported configurations:

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. Read Overview of migration, coexistence, and interoperability and Premigration considerations.


Procedure

  1. Be aware of the basic rules of WAS coexistence.

    Each installation of the base product is a stand-alone application server with its own set of unique configuration files.

    Reasons to use multiple installation instances include the following items:

    • We can achieve complete isolation between each WAS instance. You can uninstall one instance independently of the others.
    • We can install the WAS (base) more than once on the same machine.
    • We can install the WAS ND v6.x or v7.0 product and the WAS v8 on the same machine.

    Reasons you should not use multiple installation instances include the following items:

    • The machine might have a hard-disk space constraint.
    • We can use the operating system registry to locate the last installed instance of a WAS only.

      When you install any product a second time, the last installation is the one that is displayed in the registry.

    • Uninstall the last instance removes any record of the product in the registry.

      Suppose we have installed three instances of the WAS (base). You use the remove program function of the operating system to uninstall the registered third copy of the base product. A registry record no longer exists that indicates the existence of the other two installation instances. Other applications cannot use a query of the operating system registry to detect the presence of either WAS (base) product instance.

    The "Creating profiles using the graphical user interface" article in the information center describes installing the WAS once and creating multiple profiles.

  2. Use the Installation wizard to install another instance.

    Read the "Installing the product and additional software" article in the information center for more information.

    If you intend to share a single web server among installations, install the appropriate v8.0 web server plug-in using the stand-alone Web server Plug-in installation wizard provided on the WAS disk.

  3. Share a web server among multiple installation instances.

    1. Use the Plug-in installation wizard to select a Web server plug-in.

    2. Use the administrative console to generate the plug-in configuration files for every installation instance and merge them into one primary configuration.

    3. Use the administrative console to replace the original plugin-cfg.xml file with the primary file on the web server.

    We can access samples from only one of the installation instances.

  4. Change the port assignments in the configuration files if we have a node that you cannot start because of port conflicts.

    Read Port number settings in WAS versions for more information.

    If ports are already defined in a configuration being migrated, the migration tools fix the port conflicts in the v8.0 configuration and log the changes for your verification .

  5. Avoid port conflicts in coexisting Version 6.x, v7.0, and v8.0 node agents.

    If you create a v8.0 federated node on the same system where another v8.0 federated node exists, the addNode command increments the port assignments of the second node agent process so that no conflict occurs. The Profile Management tool also handles the port assignments successfully when you federate a custom node during the creation of the custom profile.

    Contrast the v8.0 coexistence scenario just described to the following cross-version scenario where a v6.x or v7.0 federated node exists.

    Assume that you create a v8.0 federated node on the same system where a v6.x or v7.0 federated node exists. Neither the addNode command nor the Profile Management tool has a record of the v6.x or Version 7.0 port assignments. Port assignments on the second, v8.0 node agent process are not incremented. Conflicts occur.

    The conflicts prevent the second node from starting. If you start the v6.x or Version 7.0 node first, the v8.0 node cannot start. If you start the v8.0 node first, the Version 6.x or v7.0 node cannot start.

    Perform the following procedure to create a v8.0 federated node with nonconflicting ports.

    1. Create a v78.0 application server profile or the custom profile.

      Do not federate the node as you create the profile. Select the check box on the Profile Management tool panel that specifies that you will federate the node later.

    2. Check for ports in use to determine a starting port number for the v8.0 node agent process.

      Use the netstat -a command to check existing port assignments. Analyze the port assignments to determine 12 sequential free ports.

      This procedure assumes that no port assignments exist between 3320 and 3380.

    3. Change directories to the bin directory of the new profile.

      Assume that you create an application server profile named V70MngNode in the default installation root directory on a Linux system. 

      cd /opt/IBM/WebSphere/AppServer/profiles/V70MngdNode/bin

    4. Use the addNode command with the -startingport parameter to federate the node into the dmgr cell and to assign ports from a beginning value.

      Assume that the dmgr has the following characteristics:

      • Host name is the domain name system address: nittany.ibm.raleigh.com
      • JMX connector type: remote method invocation (RMI)
      • RMI port assignment: 8879
      • Security status: Enabled
      • Applications to install: DefaultApplication and the samples

      In a Linux environment, for example, issue the following command: 

      ./addNode.sh nittany.ibm.raleigh.com \
-conntype RMI 8879 \
-includeapps \
-user lions44 \
-password PSU
-startingport 3333

      The \ character is a continuation character for using more than one line to submit commands.

    The -startingport parameter supplies the base port number for all node agent ports and increments all of the port values from the starting point. The nonconflicting port assignments let the new node agent run when the v6.x or v7.0 node agent process is already running.

    This procedure results in the ability to start your v6.x or v7.0 node at the same time as your v8.0 node. The node agents can run on the same server.

    We can also assign ports individually using the -portprops parameter. The parameter identifies a flat file of key words and port number assignments that create. The following example of a portprops file shows all key words and their default port assignments: 

    WC_defaulthost 9081
WC_adminhost 9062
WC_defaulthost_secure 9444
WC_adminhost_secure 9045
BOOTSTRAP_ADDRESS 2810
SOAP_CONNECTOR_ADDRESS 8881
SAS_SSL_SERVERAUTH_LISTENER_ADDRESS 9901
CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS 9201
CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS 9102
ORB_LISTENER_ADDRESS 9900
CELL_DISCOVERY_ADDRESS 7272
DCS_UNICAST_ADDRESS 9354


What to do next

After migrating a v6.x dmgr to a v8.0 dmgr, you can migrate the v6.x federated nodes incrementally. Read Migrating a v6.x or 7.x federated node for more information.
Coexistence support
Migrate and coexisting application servers
Set up v8.0 coexistence


Related


Port number settings in WAS versions

+

Search Tips   |   Advanced Search