[Version 5.0.2]Creating multiple Version 5 configuration instances

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

[5.0 only]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

  1. Install the base WebSphere Application Server product. Optionally, you can also install the Network Deployment product.
  2. Back up the install_root/bin/wsinstance/configdefaults directory.
    In certain situations, it might become necessary to restore the following files from the backup to the install_root/bin/wsinstance/configdefaults directory:
    • ./security.xml
    • ./nodes/$NODE_NAME/resources.xml
    • ./nodes/$NODE_NAME/serverindex.xml
    • ./nodes/$NODE_NAME/servers/$SERVER_NAME/resources.xml
    See the description of a possible error that can occur in Backing up required files before installing additional features or before installing the V5.0.x Enterprise product.
  3. Use the wsinstance command in the WAS_HOME\bin\wsinstance folder, to create a configuration instance of the server you installed in step 1.
    Refer to the description of the wsinstance command to learn more about the command, and to see examples of use.

    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.

  4. [5.0 only]Install the Enterprise product.

    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.

  5. Source the setupCmdLine.sh (or run the setupCmdLine.bat) script in the bin directory of the instance_root folder to set the WebSphere Application Server environment to the configuration instance.

    Windows systems:

    1. Open a command prompt window.
    2. Change directories to the install_root\bin directory.
    3. Issue the setupCmdLine.bat command.

    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:

    1. Open a command shell window.
    2. Change directories to the /install_root/bin directory.
    3. Issue the . ./setupCmdLine.sh command. Notice the space between the periods. The special format for this command sources the command to make the setting active for all processes started from the command shell.

    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:

    • Download interim fixes for the embedded messaging feature from the WebSphere MQ Service download site . The readme file that is bundled with the interim fix describes how to install the interim fix.
    • Download any fix packs for the product from the IBM Support site for WebSphere Application Server . The readme file that is bundled with the fix pack describes how to use the update installer (also known as the updateInstaller program or the update installation wizard) for WebSphere Application Server products to install the fix pack. Installing a fix pack removes all interim fixes. You might have to reinstall interim fixes that are not in the fix pack to bring the embedded messaging feature back to the fix level you require.

  6. Associate a Web server with a 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.

    • Share the Web server

    1. Generate a plugin-cfg.xml configuration file for each application server configuration instance that is to share a Web server.
    2. Manually merge all plugin-cfg.xml configuration files into one file of the same name, plugin-cfg.xml.
      Put the file in the default folder for the first configuration instance, such as:
      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:

      • There should be only one instance of the tags Config and Log.
      • The properties "keyring" and "stashfile" should use the same location for all application servers in the merged file.
      • Combine all other tags from both files, so long as the tags do not have duplicate names.

    3. Edit the Web server configuration file on the Web server, as described in the Configuring Web server plug-ins topic, to point to the plugin-cfg.xml file.

    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.

    • Use a separate Web server
    This configuration is simple. Each application server configuration instance uses a different Web server.

    1. Use the Web server documentation to create a new Web server instance for each configuration instance.

      For example, to install multiple images of the IBM HTTP Server:

      1. Use the InstallIHS command script in the IHS directory on the product CD to install IBM HTTP Server for a second or later instance.
      2. Install the multiple installation instance to a new directory.
      3. Set a unique port for each multiple instance by editing the "port" directive in the conf/httpd.conf file in the IBM HTTP Server installation root.
      4. Download and apply any interim fixes to each multiple instance of the IBM HTTP Server from the IBM Support site for IBM HTTP Server . The readme file that is bundled with the interim fix describes how to install the interim fix.
      5. Download any fix packs for the product from the IBM Support site for WebSphere Application Server . The readme file that is bundled with the fix pack describes how to use the update installer for WebSphere Application Server products to install the fix pack to each multiple instance of the IBM HTTP Server using the silent interface of the WebSphere Application Server update installer:
        updateSilent -ihsOnly -install -ihsInstallDir directory
        
        Installing 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.
      6. Copy the current binary plug-in from the install_root\bin directory of the WebSphere Application Server product, to the HTTP Server machine and update the LoadModule directive in the httpd.conf file accordingly.
      7. Copy the plugin-cfg.xml file from the install_root\config\cells directory of the WebSphere Application Server product, to the HTTP Server machine and update the WebSpherePluginConfig directive in the httpd.conf file accordingly.

    2. Modify the Web server configuration file, such as the httpd.conf file for IBM HTTP Server, to point to the configuration instance.

      1. Specify the location of the WebSphere Application Server plug-in binary program. For example, when you install a plug-in feature, the installation wizard installs the plug-in binary program in the install_root/bin folder.
      2. Specify the location of the plugin-cfg.xml file of the configuration instance. This file is located in the config/cells or config\cells folder of the configuration instance root location.

  7. Federate multiple installation instances into a deployment manager cell, as described in Federating multiple Version 5 installation instances
  8. Create additional servers in a multiple instance or coexistence environment, as described in Creating servers in coexistence or multiple instance environments
  9. Change port assignments in configuration files, as described in Changing HTTP transport ports, if you have a node that you cannot start because of port conflicts.

What to do next

Refer to the description of the wsinstance command to learn more about the command, and to see examples of use.


Related tasks
Installing WebSphere Application Server products
Coexistence support
Federating multiple Version 5 installation instances



Searchable topic ID:   tins_instances
Last updated: Jun 21, 2007 8:07:48 PM CDT    WebSphere Business Integration Server Foundation, Version 5.0.2
http://publib.boulder.ibm.com/infocenter/wasinfo/index.jsp?topic=/com.ibm.wasee.doc/info/ee/ae/tins_instances.html

Library | Support | Terms of Use | Feedback