About this task
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:
- You can achieve complete isolation between each WebSphere Application Server instance. You
can uninstall one instance independently of the others.
- You can install the WebSphere Application Server (base) more than
once on the same machine.
- You can install the WebSphere Application Server, Network Deployment Version 6.1
or above product and the Version 8.5 product
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.
- You can use the operating system registry to locate the last installed
instance of a WebSphere Application Server only.
When
you install any product a second time, the last installation is the
one that is displayed in the registry.
- Uninstalling the last instance removes any record of the product
in the registry.
Suppose you have installed three instances of the WebSphere Application Server (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 WebSphere Application Server (base) product instance.
Managing profiles using the graphical user interface describes
installing the WebSphere Application Server once
and creating multiple profiles.
- Use the Installation wizard to install another instance
of WebSphere Application Server.
If
you intend to share a single web server among installations, install
the appropriate Version 8.5 web
server plug-in using the stand-alone web server plug-in installation
wizard that is provided on the WebSphere Application Server disk.
See Installing
and configuring your application serving environment for more
information.
- Share a web server among multiple installation instances.
- Use the plug-in installation wizard to select a web
server plug-in.
- Use the administrative console to generate the plug-in
configuration files for every installation instance and merge them
into one primary configuration.
- Use the administrative console to replace the original plugin-cfg.xml file
with the primary file on the web server.
You can access samples from only one of the installation instances.
- Change the port assignments in the configuration files
if you have a node that you cannot start because of port conflicts.
Read Port number settings for
more information.
Note: If ports are already defined
in a configuration being migrated, the migration tools fix the port
conflicts in the Version 8.5 configuration
and log the changes for your verification .
- Avoid port conflicts in coexisting Version
6.1 or above and Version 8.5 node
agents.
If you create a Version 8.5 federated node on
the same system where another Version 8.5 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 Version 8.5 coexistence
scenario just described to the following cross-version scenario where
a Version 6.1 or above federated node exists.
Assume that you
create a Version 8.5 federated
node on the same system where a Version 6.1 or above federated node
exists. Neither the addNode command nor the Profile
Management tool has a record of the Version 6.1 or above port assignments.
Port assignments on the second, Version 8.5 node agent process
are not incremented. Conflicts occur.
The conflicts prevent
the second node from starting. If you start the Version 6.1 or above
node first, the Version 8.5 node
cannot start. If you start the Version 8.5 node first, the Version
6.1 or above node cannot start.
Perform the following procedure
to create a Version 8.5 federated
node with nonconflicting ports.
- Create a Version 8.5 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.
- Check for ports in use to determine a starting port
number for the Version 8.5 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.
- 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
- 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,
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 Version 6.1 or above node agent process
is already running.
This procedure results in the ability to
start your Version 6.1 or above node at the same time as your Version 8.5 node. The node agents
can run on the same server.
You can also assign ports individually
using the -portprops parameter. The parameter identifies a flat file
of key words and port number assignments that you must 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 Version 6.1 or above deployment manager
to a Version 8.5 deployment
manager, you can migrate the Version 6.1 federated nodes incrementally.
Read Migrating a Version 6.1 or above federated node for more information.