Set up coexisting product installations

We can install WebSphere Application Server to coexist with another product installation instance as long as no ports conflict. When we install coexisting installations, we can share a single web server.

See Overview of migration, coexistence, and interoperability and Migration considerations.

Each installation of the product has its own set of unique configuration files.

Manage profiles using the graphical user interface describes installing the WAS once and creating multiple profiles.

Tasks

1. Use the Installation Manager to install another instance of WAS.

   If we intend to share a single web server among installations, install the appropriate v9.0 web server plug-in.

   See Install and configure the application-serving environment.

2. 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.

3. If a node cannot start because of port conflicts, change the port assignments in the configuration files.

   If ports are already defined in a configuration that we are migrating, the migration tools fix the port conflicts in the v9.0 configuration and log the changes for our verification.

4. Avoid port conflicts in the coexisting node agents.

   If we create a federated node on the same system where another 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 we federate a custom node during the creation of the custom profile.

   If we install a v9.0 product on a system where an earlier version of the product is installed, neither the addNode command nor the Profile Management tool has a record of the port assignments from the earlier version. Port assignments on the second, v9.0 node agent process are not incremented. Conflicts occur that prevent multiple nodes from starting.

   Create a v9.0 federated node with nonconflicting ports.

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

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

   2. Check for ports in use to determine a starting port number for the v9.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 V90MngNode in the default installation root directory on a Linux system.

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

   4. Use the addNode command with the -startingport parameter to federate the 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 node agent process is already running.

   This procedure results in the ability to start you the earlier node at the same time as your v9.0 node. The node agents can run on the same server.

   We can also assign ports individually by setting 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 v7.0 or later deployment manager to a v9.0 deployment manager, we can migrate the v7.0 or later federated nodes incrementally. For more information, see Migrate a v7.0 or later federated node.

Related:

Install and configure the application-serving environment

Roadmap: Migrating and coexisting application servers

Running coexisting application servers

Manage profiles using the graphical user interface

Port number settings