Multiple configuration instances, as it applies to WebSphere Application Server products, is the ability to install the base WebSphere Application Server product or the Network Deployment product once, and to use the wsinstance command to create multiple instances of the initial installation, all running on the same machine at the same time.
Before you begin
Subsequent installation of
the Enterprise product to the initial installation of the WebSphere Application
Server or Network Deployment product, installs the Enterprise extensions on
the initial installation but does not automatically update existing configuration
instances. Any configuration instances that you create after installing Enterprise
do have Enterprise extensions.
In contrast to multiple configuration instances is coexistence, which refers to multiple installations of WebSphere Application Server, running on the same machine at the same time. Both coexistence and multiple configuration instances of the base WebSphere Application Server product imply various combinations of Web server interaction.
You can find a description of coexistence in Migrating and coexisting.
Why and when to perform this task
You can install the base WebSphere Application Server product or the Network Deployment product one time and use the wsinstance tool in the install_root\bin\wsinstance folder to create multiple configuration instances. Each WebSphere Application Server configuration instance is a stand-alone instance with a unique name, and its own set of configuration files and user data folders. Configuration folders include config, etc and properties. User data folders include installedApps, installableApps, temp, logs, tranlog and wstemp. Each instance has the administrative console application to manage the configuration instance. The configuration instance shares all run-time scripts, libraries, the Software Development Kit, and other files with the initial Application Server.
Each configuration instance of the Network Deployment product is a stand-alone deployment manager (dmgr) with its own set of unique configuration files and user data folders for the cell. Configuration folders include config, etc and properties. User data folders include installedApps, installableApps, temp, logs, tranlog and wstemp. The dmgr configuration instance also includes the administrative console and the file transfer applications to manage the configuration instance.
You can configure and operate each configuration instance independently of other instances.
These limitations apply to multiple configuration instances:
Reasons to use configuration instances include:
One reason to not use configuration instances is that you cannot federate a configuration instance of the base product into a deployment manager cell. A deployment manager cannot manage a configuration instance.
Use the following procedure to create and configure multiple V5 instances:
Steps for this task
You must specify a unique directory path and a unique node name for each configuration instance.
You must also specify unique port numbers for each configuration instance. For example, on a Windows platform, specify ports beginning at 20002, for node shasti, in configuration instance_root G:\shasti\WebSphere, on the planetjava machine, by issuing this command:
wsinstance.bat -name shasti -path G:\shasti\WebSphere -host planetjava -startingPort 20002 -create
This command creates a separate set of configuration and other data files.
If you install the Enterprise product, the installation wizard displays a list of installed base WebSphere Application Server installation instances in a list box. It also displays a list of installed Network Deployment installation instances. If you select an installation instance that has configuration instances, the Enterprise installation wizard installs Enterprise extensions on the initial installation instance but not on existing configuration instances.
Windows systems:
Alternatively, you can set WAS_USER_SCRIPT to instance_root\bin\setupCmdLine.bat, which has the same effect as sourcing the setupCmdLine.sh script or running the setupCmdLine.bat script.
Linux and UNIX systems:
Alternatively, you can set WAS_USER_SCRIPT to instance_root/bin/setupCmdLine.sh, which has the same effect as sourcing the setupCmdLine command. For example:
export WAS_USER_SCRIPT=/opt/inst1/bin/setupCmdLine.sh
After completing this step, you can start the application server configuration instance with the startManager or startServer command.
If you are using the embedded messaging feature, and you are logging on as a non-root user on a UNIX-based or Linux platform, you must add the mqm user and the root user to the mqm and mqbrkrs operating system groups, as described in Installing WebSphere embedded messaging as the JMS provider.
You must download and apply any interim fixes for the embedded messaging feature to each configuration instance:
If you create multiple configuration instances of the base WebSphere Application Server product, you can configure each instance to either share a Web server with other configuration instances, or to use a separate Web server.
instance_root/WebSphere/AppServer/config/cells/plugin-cfg.xml
If you use the same server name in multiple instances, (for example, suppose there are two server1 entries), the merged file has duplicate entries that you must address. All requests for either server1 instance are routed to the last one in the merged list.
To correct the problem, change duplicate server name entries to make them unique in the PrimaryServers stanza:
<PrimaryServers> <Server Name="server1"/> <Server Name="server1a"/> </PrimaryServers>Change each duplicate name in the merged file to match its unique name in the PrimaryServers stanza.
Three tips to follow when merging the files are:
Repeat this process to add or remove a configuration instance from the configuration that shares the Web server, or when you regenerate a plug-in configuration file for any configuration instance in the group.
For example, to install multiple images of the IBM HTTP Server:
updateSilent -ihsOnly -install -ihsInstallDir directoryInstalling a fix pack removes all interim fixes except those installed for the IBM HTTP Server feature (or the embedded messaging feature). The fix pack includes all interim fix changes up to the point of the fix pack. You might have to reinstall interim fixes that are more current than the fix pack to bring the HTTP Server back to the fix level you require.
What to do next
Refer to the description of the wsinstance command to learn more about the command, and to see examples of use.