InfoCenter Home >
6: Administer applications >
6.6: Tools and resources quick reference >
6.6.41: Administering administrative domains >
6.6.41.5: Establishing multiple administrative domains on a machine

6.6.41.5: Establishing multiple administrative domains on a machine

  Configuring multiple domains on a machine is neither recommended nor formally supported. In the event that you find it necessary, considerations for making it work correctly are outlined here.

Visual overview

Discussion

As discussed in article 0.14, an administrative domain is a collection of one or more administrative servers that share an administrative database. That is, the set of application servers and their contents appears the same to all administrative servers in a domain because they share the same administrative data.

When a machine contains multiple domains:

  • Administrative servers in Domain A are unaware of administrative servers in Domain B, and the other way around.
  • Similarly, application servers on the machine will be unaware of one another if residing in different domains.
  • Application servers will receive application requests from separate Web servers.

The obvious implications are that application servers in different domains are not cloned. Workload management activities can occur only among servers within the same domain.

The diagram is intentionally vague regarding whether the WebSphere plug-ins for the Web server communicate with administrative servers or directly with application servers. Either case can be true, depending on the multiple machine configuration that you select for routing requests from the Web servers to IBM WebSphere Application Server.

Considerations

Install two of each component

This configuration requires two separate installations of each item in the topology:

  • Two separate Web servers (perhaps on different machines)
  • Two separate IBM WebSphere Application Server runtimes
  • Two separate database clients
  • Two separate databases
Ensure database names do not conflict

The database logistics highlight a consideration for multiple domains on a machine. The product administrative database is typically named WAS. If you select a single database instance, you will need to rename the database for the second domain something other than WAS and make sure the administrative server configuration file points to the correct database for the second domain.

Ensure server ports do not conflict

To avoid conflicts with the default port numbers of components in the first domain, assign unique port numbers to the components in the second domain.

Specifically, in the second domain, change these properties in the administrative server configuration file:

com.ibm.ejs.sm.adminServer.lsdPort=xxxx
com.ibm.ejs.sm.adminServer.bootstrapPort=yyyy
com.ibm.ejs.sm.util.process.Nanny.adminServerJvmArgs=-mx128m -Dcom.ibm.CORBA.ListenerPort=zzzz

For xxxx, yyyy, and zzzz, put values that are not in conflict with the same properties in the first administrative domain.

For each application server in each domain, specify a Java command line argument to identify the correct ORB for that server:

-Dcom.ibm.CORBA.ListenerPort=zzzz
Ensure servlet queues and ports do not conflict

Each time you add an application server to either domain, check queue name and port of the new servlet engine associated with the application server. Make sure the values do not conflict with any queue name and queue port used by other servlet engines in other domains running on the same machine.

Ensure redirector configurations do not conflict

Whichever multiple machine configuration you use to route application requests from the Web servers to the application servers, there are bound to be potential conflicts. As with other components, make sure all queue names and port values are set so as not to conflict with those in other domains on the same machine.

Test components and domains separately, then together

Consider the following strategy when setting up and verifying the configuration:

  1. Test each component separately after installing it.

    For example, ensure that each Web server functions properly.

  2. Test each domain separately, with the components in the other domain stopped.
  3. Test the entire setup.
Go to previous article: Administering administrative domains Go to next article: Administering WebSphere plug-ins for Web servers

 

 
Go to previous article: Administering administrative domains Go to next article: Administering WebSphere plug-ins for Web servers