Skip to main content

Installing and Configuring Multiple WebSphere Application Server 4.0 Domains on a Single UNIX Server

Dave Draeger (ddraeger@us.ibm.com), WebSphere Execution Team, IBM
David Draeger is a WebSphere Software Engineer and member of the WebSphere Execution Team based in Rochester, MN. He has worked onsite with multiple customers during critical situations to resolve numerous issues, among them WebSphere failover. Dave has also authored many white papers related to WebSphere Application Server. He has helped in developing tools for WebSphere and has driven new innovations into the WebSphere Application Server software. Dave received a BS in Computer Science from the engineering college of the University of Illinois at Urbana/Champaign. You can reach Dave at ddraeger@us.ibm.com.

Summary:  This document describes how to install multiple IBM WebSphere Application Server Version 4.0 domains on the same physical machine and allow them to run concurrently. It describes how to set up this configuration on Solaris 8.

Date:  19 Dec 2001
Level:  Intermediate
Activity:  83 views

© 2001 International Business Machines Corporation. All rights reserved.

Introduction

This document describes how to install multiple IBM WebSphere Application Server Version 4.0, both Advanced Edition (AE) and Advanced Single Server Edition (ASSE), domains on the same physical machine and allow them to run concurrently. This configuration is useful to allow developers and testers to isolate their WebSphere Application Server domain from other WebSphere Application Server domains on the same machine. It also provides a developer and tester the ability to make changes to the overall domain without affecting other domains. Please note that these steps can be applied to Version 4.0 and higher of WebSphere Application Server.

The steps documented here can also be applied to WebSphere Application Server Version 4.0. Also, this document describes how to set up this configuration on Solaris 8, but the same principals can be applied to other UNIX-based operating systems that WebSphere Application Server runs on, except for AS/400® or OS/390®.

This paper is intended for experienced administrators of WebSphere Application Server domains who need to set up and maintain multiple WebSphere Application Server instances on multiprocessor servers.

If a setting is specific to either the Advanced Edition or Advanced Single Server Edition of WebSphere Application Server 4.0, then I will note the edition before the entry, for example, (ASSE).

In this document, I will be addressing the following key issues:

  1. Installing and configuring separate HTTP servers and their WebSphere plugins.
  2. Running the WebSphere Application Server installation twice with the appropriate configuration information.
  3. Changing the default ports for the bootstrap service, LSD service, and (ASSE) Trace Service.

Prerequisites

The configuration used in this document is:

HardwareSoftware
Sun Ultra 80 4x300MHzSun Solaris 8
1024 MB of RAMIBM DB2 Version 7.1.0.43
WebSphere Application Server 4.0 AE and ASSE
IBM HTTP Server 1.3.19.0

A WebSphere Application Server 4.0-supported version of Linux, Sun Solaris, AIX®, or HP-UX must be installed and functioning correctly.

For AE, a WebSphere Application Server 4.0-supported database such as IBM DB2® must be installed and functioning correctly.


Install the first HTTP server instance

Install the IBM HTTP server as you normally would, and make note of the port that the IBM HTTP Server is listening on. In this example, look for the "Port" line in the /opt/IBMHTTPD/conf/httpd.conf file. (The default port is set to Port 80.)

Note: Alternatively, you could simply install the IBM HTTP Server using the WebSphere Application Server 4.0 installation program. WebSphere Application Server includes the IBM HTTP Server and the first HTTP Server instance can be installed using this process, if preferred.


Install the first WebSphere Application Server instance

Important! Make sure that the HTTP server is not running when installing WebSphere Application Server.

Install WebSphere as you normally would making note of the following items:

  • The path that WebSphere Application Server is installed on (for example, /opt/WebSphere/AppServer40a).
  • (AE) The name of the database that WebSphere Application Server is using (i.e. was40a). (Note: Make sure that you create the "was40a" and "was40b" databases before you start the WebSphere Application Server installation. In this example, was40a is the database for the first installation and was40b is the database for the second installation.)

Note: It is recommended that the sample configuration be installed to help in verifying that WebSphere Application Server is functioning correctly.


Test the single instance setup

  1. Start the IBM HTTP Server and verify that you can connect to the default page (http://<HTTP_Server_hostname>/) with a Web browser.

  2. Once the HTTP Server is verified to be running correctly, start WebSphere Application Server by running the (AE) startupServer.sh script or running the (ASSE) startServer.sh script. After you see the "Server open for e-business" message in the tracefile, (AE) run the administration console, or run (AE) adminclient.sh.
    (AE) Click on the Default Server (from the default configuration) and start it.
    (ASSE) Use a browser to bring up the ASSE console by going to http://<hostname>:9090/admin. In ASSE, the Default Server is automatically started when the startServer.sh script is run. This can be changed if desired.
    • (ASSE) (/opt/WebSphere/AppServer40a/bin/startServer.sh)
    • (AE) (/opt/WebSphere/AppServer40a/bin/startupServer.sh)
    • (AE) (/opt/WebSphere/AppServer40a/bin/adminclient.sh)
    • (AE) (/opt/WebSphere/AppServer40a/logs/tracefile)

  3. To test the WebSphere Application Server/HTTP Server setup, connect to the snoop servlet, http://<HTTP_Server_hostname>/servlet/snoop. This confirms that the "one instance" setup has basic functionality. Once you have verified that basic functionality exists, shut down the HTTP Server and WebSphere Application Server after making note of the ports that the Web Container Services are listening on. Write this down as you'll need it for future reference. You can view this in the administration console by going to:

    (AE) Nodes => <NodeName> => Application Servers =>
    <AppServerName> => Services Tab => Web Container Service =>
    Edit Properties button => Transport Tab => HTTP Transports


    (ASSE) Nodes => <NodeName> => Application Servers =>
    <AppServerName> => Web Container => HTTP Transports

Install the second HTTP server instance

To install the second instance of the HTTP server, you either need to 1) create a new HTTP server instance using the HTTP server configuration application, as used by Netscape Enterprise Server, or 2) make copies of the necessary configuration files and manually edit them to insert appropriate values, as is necessary when using IBM HTTP Server or Apache. In this example, we will manually edit the configuration files since we are using IBM HTTP Server.

  1. Start by making copies of the httpd.conf and apachectl files in their corresponding directories:

    • In /opt/IBMHTTPD/conf/httpd.conf, make a copy of httpd.conf and name the file httpd2.conf.
    • In /opt/IBMHTTPD/bin/apachectl, make a copy of apachectl and name the file apachectl2.

  2. Open the httpd2.conf file in a text editor and make the following changes (note the bolded characters):

    • Port 81 (Here, you want to change to an unused port. In this example, we will use 81.)
    • ErrorLog /opt/IBMHTTPD/logs/error_log2
    • CustomLog /opt/IBMHTTPD/logs/access_log2 common
    • PidFile /opt/IBMHTTPD/logs/httpd2.pid
    • ScoreBoardFile /opt/IBMHTTPD/logs/httpd2.scoreboard

  3. Save the httpd2.conf file.

  4. Open the apachectl2 file in a text editor and make the following changes:

    PIDFILE=/opt/IBMHTTPD/logs/httpd2.pid
    HTTPD='/opt/IBMHTTPD/bin/httpd -f /opt/IBMHTTPD/conf/httpd2.conf'

  5. Save the apachectl2 file.

(Notice the quotes (') in the HTTPD command.)


Install the second WebSphere Application Server instance

  1. Start the WebSphere Application Server installation again.
  2. Skip the migration assistant if it is present and do not select to "Backup and Uninstall" the previous version if this option is made available. Click the Next button.
  3. When the dialog appears stating that the installation has found another copy of WebSphere Application Server 4.0 installed, simply click the OK button to continue.

    Figure 1
    Screen capture of the Information dialog box

  4. Select Custom Install.

    Figure 2
    Screen capture of Install Options dialog box

  5. Deselect the IBM HTTP Server 1.3.19 checkbox. Deselect the option to install UDB, if it is selected.

    Figure 3
    Screen capture of Choose Application Server Components dialog box

  6. Select the appropriate plugin. In this case, select IBM HTTP Server Plugin.

    Figure 4
    Screen capture of Choose Application Server Components dialog with IBM HTTP Server Plugin checkbox selected

  7. (AE) For the database options, change the "Database Name" to something unique such as was40b.

    Figure 5
    Screen capture of Database Options dialog

  8. For the Destination Directory, enter a unique directory for this instance of WebSphere Application Server.
    (In this example, we use /opt/WebSphere/AppServer40b.)

    Figure 6
    Screen capture of Select Destination Directory dialog

  9. Complete the installation as normal.

After the files have been installed, the installation program will ask for the location of the httpd.conf file. In the WebSphere Application Server 4.0 installation, you must enter the location of a file named httpd.conf or the installation will not continue. To do this, move the httpd.conf file to httpd.confA and move httpd2.conf to httpd.conf. Then, enter the path of the new httpd.conf file into the edit box for the installation program. The installation will update this httpd.conf file with the proper settings for the second instance of WebSphere Application Server. After the installation program updates the httpd.conf file, move the files back to their original names, httpd.conf and httpd2.conf.

Test the second instance installation just as we did with the first instance to verify that each set of HTTP Server/Application Server functions correctly alone.

Note: You may need to restart the HTTP server to have it read in the plugin-cfg.xml file.


Run both instances at the same time

With the configuration as it stands, you can run each HTTP Server/Application Server combination separately but you cannot run both instances concurrently. This is due to conflicting ports.

  1. To allow for running both instances at the same time, edit the following port settings:

    (AE) Add the following lines to the admin.config file of one of the WebSphere installations (the admin.config file is located in the following directory: /opt/WebSphere/AppServer40b/bin/admin.config):

    • com.ibm.ejs.sm.adminServer.bootstrapPort=901
    • com.ibm.ejs.sm.adminServer.lsdPort=9001

    (ASSE) Edit the server-cfg.xml file with a text editor (the server-cfg.xml file is located in the following directory: /opt/WebSphere/AppServer40b/config/server-cfg.xml):

    1. Search for orbSettings and change the bootstrapPort attribute to 901.
    2. Search for locationServiceDaemon and change the port attribute to 9001.
    3. Search for traceService and change the diagThreadPort attribute to 7001.
    4. Skip to step 4 below.

    (Note: 901 and 9001 were arbitrarily chosen here. These values should be unused ports available on your system.)

  2. (AE) At this point, start up this instance of WebSphere Application Server by running startupServer.sh from a command prompt. The startupServer.sh file is located in the following directory: /opt/WebSphere/AppServer40b/bin/startupServer.sh.

  3. (AE) After you see the "adminServer open for e-business" message in the tracefile, start the administration console for this WebSphere instance by running the following from a command prompt:

    adminclient.sh <hostname> 901

    Note that the adminclient.sh file is located in /opt/WebSphere/AppServer40b/bin/adminclient.sh and the tracefile is located in
    /opt/WebSphere/AppServer40b/logs/tracefile.

  4. (AE) Append a new port number to all of the virtual host settings of this instance of WebSphere Application Server. This is the value that the corresponding HTTP Server will listen on. This can be found by clicking on the Virtual Hosts folder and then editing the default ports. Change the values as follows:

    • *:80 to *:81
    • *:9080 to *:9081

    Click the Apply button.

    (ASSE) Edit the server-cfg.xml file with a text editor.

    Search for VirtualHosts and increment all of the aliases' port attributes by 1 (for example, change 9080 to 9081). (Note: By default there are two VirtualHosts. Be sure to change the ports in both sections.)

    Of course, make sure that this port is free and is valid.

  5. Verify that each Web Container port does not conflict with any other Web Container port both on this instance of WebSphere and other instances. This can be found by going to:

    (AE) Nodes => <NodeName> => Application Servers =>
    <AppServerName> => Services Tab => Web Container Service =>
    Edit Properties button => Transport Tab => HTTP Transports


    Change the port to something that doesn't conflict, and click the OK button and then the Apply button. You need to regenerate the plugin at this point, so right-click on the <NodeName> component and select Regen WebServer Plugin. (Note: You may need to restart the HTTP Server for it to reread the new plugin-cfg.xml file.)

    (ASSE) Edit the server-cfg.xml file with a text editor.

    Search for webContainer and increment all of the transports' port attributes by 1 (for example, change 9080 to 9081).

    Of course, make sure that this port is free and is valid.

  6. To run this configuration, you will need to use a command prompt to start up each HTTP server and each WebSphere Application Server.

    HTTP Instance 1:

    /opt/IBMHTTPD/bin/apachectl start

    HTTP Instance 2:

    /opt/IBMHTTPD/bin/apachectl2 start

    WebSphere Application Server Instance 1:

    (AE) /opt/WebSphere/AppServer40a/bin/startupServer.sh
    (ASSE) /opt/WebSphere/AppServer40a/bin/startServer.sh

    WebSphere Application Server Instance 2:

    (AE) /opt/WebSphere/AppServer40b/bin/startupServer.sh
    (ASSE) /opt/WebSphere/AppServer40b/bin/startServer.sh

Test each HTTP Server and WebSphere Application Server combination

To test that each HTTP Server/WebSphere Application Server combination has basic functionality, start the "Default Server" in each WebSphere instance, and use the snoop servlet and HitCount servlet to verify that basic functionality exists.

  • http://<HTTP_Server_hostname>/servlet/snoop
  • http://<HTTP_Server_hostname>:81/servlet/snoop
  • http://<HTTP_Server_hostname>/webapp/examples/HitCount
  • http://<HTTP_Server_hostname>:81/webapp/examples/HitCount

Issues to be aware of

  • (AE) To use the WebSphere administration console with the instance of WebSphere that you changed the port settings, you must invoke it with the hostname and new port number on the command line.

    adminclient.sh MyServer 901

    Note that the adminclient.sh file is located in the following directory: /opt/WebSphere/AppServer40b/bin/adminclient.sh.

  • Whenever you add a new Web Container to either instance of WebSphere Application Server, you must make sure that the port number of the Web Container Service does not conflict with another Web Container Service on either instance of WebSphere.

Questions and answers

  1. Q: Why can't you simply install IBM HTTP Server into a different directory like you can on Windows?

    A: That is by design of the IBM HTTP Server packages. Since you can't specify a different installation directory on all of the UNIX platforms, it was decided to not show how to change it on any UNIX platform.

  2. Q: Why isn't this whole process automated yet?

    A: Coming soon!

  3. Q: Why don't you use the HTTP console for configuring the second ASSE instance?

    A: Many people find it easier and more efficient to edit the server-cfg.xml file directly as opposed to using the HTTP console. All of the configurations can be made in the console but you must be careful to not have both ASSE instances running at the same time before changing the necessary port values.

    To change the bootstrap port, go to:

    Nodes => <NodeName> => Application Servers =>
    <AppServerName> => ORB Settings => Bootstrap Port


    To change the LSD port, go to:

    Nodes => <NodeName> => Application Servers =>
    <AppServerName> => Location Server Daemon => Port

    To change the Trace Service Port, go to:

    Nodes => <NodeName> => Application Servers =>
    <AppServerName> => Trace Service => Trace Port

    To change the HTTP Transports, go to:

    Nodes => <NodeName> => Application Servers =>
    <AppServerName> => Web Container => HTTP Transports => Port

    To change the Aliases' ports, go to:

    Virtual Hosts => <virtual_host> => Aliases => Port

About the author

David Draeger is a WebSphere Software Engineer and member of the WebSphere Execution Team based in Rochester, MN. He has worked onsite with multiple customers during critical situations to resolve numerous issues, among them WebSphere failover. Dave has also authored many white papers related to WebSphere Application Server. He has helped in developing tools for WebSphere and has driven new innovations into the WebSphere Application Server software. Dave received a BS in Computer Science from the engineering college of the University of Illinois at Urbana/Champaign. You can reach Dave at ddraeger@us.ibm.com.

Comments (Undergoing maintenance)



Trademarks  |  My developerWorks terms and conditions

Help: Update or add to My dW interests

What's this?

This little timesaver lets you update your My developerWorks profile with just one click! The general subject of this content (AIX and UNIX, Information Management, Lotus, Rational, Tivoli, WebSphere, Java, Linux, Open source, SOA and Web services, Web development, or XML) will be added to the interests section of your profile, if it's not there already. You only need to be logged in to My developerWorks.

And what's the point of adding your interests to your profile? That's how you find other users with the same interests as yours, and see what they're reading and contributing to the community. Your interests also help us recommend relevant developerWorks content to you.

View your My developerWorks profile

Return from help

Help: Remove from My dW interests

What's this?

Removing this interest does not alter your profile, but rather removes this piece of content from a list of all content for which you've indicated interest. In a future enhancement to My developerWorks, you'll be able to see a record of that content.

View your My developerWorks profile

Return from help

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=13915
ArticleTitle=Installing and Configuring Multiple WebSphere Application Server 4.0 Domains on a Single UNIX Server
publish-date=12192001
author1-email=ddraeger@us.ibm.com
author1-email-cc=

My developerWorks community

Tags

Help
Use the search field to find all types of content in My developerWorks with that tag.

Use the slider bar to see more or fewer tags.

Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).

My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).

Use the search field to find all types of content in My developerWorks with that tag. Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere). My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).

Special offers