Set up V5.x or 6.0.x and V6.1 coexistence

 

+

Search Tips   |   Advanced Search

 

You can install WAS V6.1 to coexist with another installation instance of V5.x.

See...

 

Procedure

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

    Each installation of the base product is a standalone appserver with its own set of unique configuration files. Reasons to use multiple installation instances include the following items:

    • You can achieve complete isolation between each WebSphere Application Server instance. You can uninstall one instance independently of the others.

    • You can install the base WAS more than once on the same machine.

    • You can install ND Version 5.x or 6.0.x product and the V6.1 product on the same machine.

    Reasons to not use multiple installation instances include the following items:

    • The machine might have a hard-disk space constraint.

    • You can use the operating system registry to locate the last installed instance of a WAS product 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 you have installed three instances of the base WAS product. 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 base WAS product instance.

    The Creating profiles through the graphical user interface article describes installing the WAS product once and creating multiple profiles.

  2. Use the Installation wizard to install another instance.

    If you intend to share a single Web server among installations, install the appropriate V6.1 Web server plug-in using the standalone Web server Plug-in installation wizard that is provided on the WAS product 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 console to generate the plug-in configuration files for every installation instance and merge them into one master configuration.

    3. Use the console to replace the original plugin-cfg.xml file with the master file on the Web server.

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

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

  5. Avoid port conflicts in coexisting V5.x or 6.0.x and V6.1 node agents.

    If you create a V6.1 managed node on the same system where another V6.1 managed 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 V6.1 coexistence scenario just described to the following cross-version scenario where a V5.x or 6.0.x managed node exists.

    Assume that you create a V6.1 managed node on the same system where a V5.x or 6.0.x managed node exists. Neither the addNode command nor the Profile Management tool has a record of the V5.x or 6.0.x port assignments. Port assignments on the second, V6.1 node agent process are not incremented. Conflicts occur.

    The conflicts prevent the second node from starting. If you start the V5.x or 6.0.x node first, the V6.1 node cannot start. If you start the V6.1 node first, the V5.x or 6.0.x node cannot start.

    Perform the following procedure to create a V6.1 managed node with nonconflicting ports.

    1. Create the V6.1 appserver profile or the custom profile.

      Do not federate the custom node as you create the custom profile. Select the check box on the Profile Management tool panel to federate the node later.

    2. Check for ports in use to determine a starting port number for the V6.1 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 appserver profile named V61MngNode in the default installation root directory on a Linux system.

      cd /opt/IBM/WAS/AppServer/profiles/V61MngdNode/bin

    4. Use the addNode command with the -startingport parameter to federate the appserver or custom node into the deployment manager cell and to assign ports from a beginning value. Assume that the deployment manager 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,...

      ./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 V5.x or 6.0.x node agent process is already running.

    This procedure results in the ability to start your V5.x or 6.0.x node at the same time as your V6.1 node. The node agents can run on the same server. Learn more about the addNode command. You 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
    

    After migrating a V5.x or 6.0.x deployment manager to a V6.1 deployment manager, you can migrate the V5.x or 6.0.x managed nodes incrementally. See Migrating to a V6.1 managed appserver for more information.



Coexistence support

 

Related tasks

Migrating and coexisting Set up V6.1 coexistence
Create profiles through the graphical user interface

 

Related Reference

Port number settings in WAS versions