InfoCenter Home >
7: Multimachine management >
7.1: Using WebSphere Application Server in a multimachine environment >
7.1.3: Multimachine topologies >
7.1.3.6: HTTP server separation sample topologies >
7.1.3.6.1: Remote OSE sample topology
7.1.3.6.1: Remote OSE sample topology
Open Servlet Engine (OSE) is a lightweight communication protocol developed by IBM for
interprocess communication. Remote OSE uses this proprietary transport to route requests
from the Web server plug-in to application servers on remote machines.

In the diagram, Machine A hosts the Web server and receives HTTP requests from clients.
The Web server forwards the requests to the application server on Machine B by using the
WebSphere plug-in for the Web server and some special configuration. Machine C hosts the
application and administrative repository databases.
Variations on this configuration include vertical scaling of the application servers,
which is discussed in Vertical scaling sample topology.
Additional application server machines (D, E, ... N), can be added to the configuration to
implement horizontal scaling.
Usually, a WebSphere administrative server on a Web server machine generates Web server plug-in configuration files to tell the Web server
how to route requests. However, the Remote OSE configuration does not place an
administrative server on the Web server machine. Instead, a Remote OSE script runs on the
Web server machine, communicating with an administrative server on the remote application
server machine. The script gathers the necessary information about the application server
configuration and generates the plug-in configuration files.
The script uses RMI/IIOP to communicate with the remote administrative server. RMI/IIOP
does not work through a firewall that performs Network Address Translation (NAT). However,
Remote OSE can be modified to support environments using NAT. The instructions in this
section include the additional steps required to run Remote OSE in a NAT firewall
environment. (See Instructions for details).
Remote OSE requires the following firewall ports to be opened:
- One port for each application server or clone process.
- A port if WebSphere security is used on the machine that hosts the Web server (Machine
A).
- A port to run the remote OSE configuration script, OSERemoteConfig.
See Instructions for details.
For more information on firewall configurations in WebSphere Application Server, see
articles 7.1.3.7 and 7.1.4.
OSE is fully integrated with WebSphere Application Server's cloning facility. It
balances loads between individual application servers and their clones, and among the
clones of an application server. This load balancing is separate from the workload
management facility.
- Load balancing between application servers. OSE can be configured to
forward requests from each URL to a different application server and its clones, enabling
manual load balancing. For instance, URLs that generate a large number of requests can be
forwarded to application servers on more-powerful machines.
- Load balancing among application server clones. OSE automatically
distributes requests among the clones of an application server that is defined to respond
to a single URL.The method for selecting which clone handles a particular request combines
a round-robin selection policy with server affinity.
If session persistence is not
enabled (the default), requests are distributed among all available clones of an
application server using a strict round-robin policy. Each clone gets the next request in
turn. The only exception is when a clone is added or restarted; see Failover support (later in this article) for details.
If session persistence is enabled (that is, session clustering and server affinity are
enabled), requests are distributed as follows:
- OSE distributes the first request of each session and all requests that are not
associated with a session as if session persistence is not enabled. That is, they are
distributed using a round-robin policy except when clones are added or restarted.
- OSE attempts to distribute all requests associated with a particular session to the same
clone of an application server. Different sessions are assigned to different clones of the
application server.
Be aware that there is no guarantee that the same clone will be
used for all requests within a session. Session affinity cannot always be maintained in
situations where the number of available clones changes during the lifetime of a session.
The Session Manager's session clustering facility ensures that session state is not lost
if requests are switched to another clone during a session.In any case, applications that
require session information to be available across multiple client invocations must store
session information in a database.
Session persistence cannot be used with the workload management facility.
OSE automatically handles failover and changes in the number of available clones.
- If a clone is stopped or unexpectedly fails, all subsequent requests are distributed
among the remaining clones. The unavailable clone is skipped.
- If a clone is added or restarted, the system automatically begins to distribute requests
to it. The next several requests are dispatched to that clone before OSE resumes its
normal methods for distributing requests to the clones of an application server based on
whether session persistence is enabled. (See Load-balancing
support, for details.)
Remote OSE has the following advantages:
- It supports load balancing and failover.
- It does not require database access through the firewall. The administrative server runs
on the machine that hosts the application server, which is typically behind the firewall.
- It supports WebSphere security.
- It works with NAT firewalls.
- Performance is relatively fast.
Remote OSE also has the following disadvantages:
- It does not support Secure Sockets Layer (SSL) encryption for communications between the
Web server and the application server.
- It requires at least one firewall port, more if multiple application server clones are
configured, the OSERemoteConfig script is used, or WebSphere security is used on the
machine hosting the Web server.
- Its configuration is relatively complicated.
The instructions describe how to set up the illustrated configuration, allowing for
multiple Web server machines (like Machine A) and application server machines (like
Machine B). They are summarized as follows:
- Install the appropriate WebSphere Application Server components.
- Start the database server, administrative server and
administrative console.
- Configure the application server on Machine B.
- Start the application server on Machine B.
- Configure the Web server plug-in on Machine A for Remote OSE.
- If a firewall is being used between Machine A and the other machines in the
configuration, open the appropriate firewall ports.
- If WebSphere security is being used to secure resources on the Web server, modify the appropriate configuration files.
- Restart all Web servers, application servers, and
administrative servers.
The rest of this section describes how to complete these steps.
The product components required for Remote OSE are listed in the following table:
Machines D through N are additional, optional application server machines that host
clones of the application server on Machine B. They do not contain the default resources.
Machine C contains the administrative database for all of the above administrative
servers, as well as the database for application data. However, the arrangement shown
under Overview is not the only option for database placement. For
example, Machine C could be omitted if the database resides on B, D, E or another machine
instead. Note that a DB2 client is required for accessing a remote DB2 database.
Before you configure the plug-in for OSE remote, start the software that is needed for
the configuration:
- Start a DB2 instance for the administrative repository (if it was not already started).
- Start the administrative server on Machine B.
- Start the administrative console on Machine B.
- Make sure that Machine B is listed in the administrative console.
Configure the application server on Machine B by completing the following steps:
- Add the aliases of each Web server machine to the alias list of the virtual host for
Machine B by following these steps:
- Locate and click the virtual host in the Topology tree view to display its properties.
- In the virtual host alias list, specify the host names and IP addresses of the Web
server machines. Add the port numbers, if not port 80.
- Save your changes and close the properties dialog box.
For example, if the configuration contains two Web servers (a.bigcorp.com and
b.bigcorp.com) talking to the application server against the same virtual host, add
aliases for a.bigcorp.com and b.bigcorp.com and their IP addresses.
Application servers that have
already been started must be stopped and restarted before they can use the new host
aliases.
- Configure the transport type for the OSE queue. The servlet engine must be configured to
use INET sockets instead of local pipes as the transport type. This is the default for
Solaris machines. However, you must explicitly select INET sockets as the transport type
on other supported operating systems. To do so, follow these steps:
- Locate and click the servlet engine in the Topology tree view to display its properties.
- In the advanced properties, access the plug-in configuration settings.
- Change the transport type to INET Sockets.
- Click OK.
- Save your changes and close the properties dialog box. The new transport does not take
effect until you restart the application server.
On Windows-based systems, the
default application server does not start when the servlet engine configuration is changed
to OSE INET sockets. You must change the servlet engine Maximum Connections parameter to
25 (from the default value of 50).
- If NAT is being used to resolve IP addresses, the interoperable object reference (IOR)
must include the host's short name to enable clients inside the firewall to locate the
desired server using a DNS server or a HOSTS file on the client machine. To include the
short name instead of the IP address or the fully qualified name in the IOR, add the
following line to the Command line arguments field, which is located in the general
settings tab for the default server on the administrative console:
-Dcom.ibm.CORBA.LocalHost=short_name
If NAT is using indirect IORs or IORs returned from naming services, this line must
also be added to the following file:
product installation root/bin/admin.config
- Make any other desired changes to the application server.
- If you are planning to clone the application server, do so now. As a model, use the
application server you just configured.
Start the application server (and its clones, if applicable).
Wait for the product to refresh the automatically generated plug-in configuration
files. This usually takes a few minutes. Verify that a refresh operation has occurred by
checking the time stamp in any of the three properties files in the product installation root/temp directory.
You can configure the Web server plug-in on Machine A either automatically or manually.
Automatic configuration
You can automatically configure the Web server plug-in by running the remote OSE
configuration script, OSERemoteConfig, on each Web server machine. The
OSERemoteConfig script cannot be used if a NAT firewall is between the Web server machine
(Machine A) and the application server machines (Machine B and D through N).
- If a non-NAT firewall is in use, you must open up a port to run the OSERemoteConfig
script. Configure the CORBA listener port for the administrative server that is running on
Machine B as follows:
- Add the -Dcom.ibm.CORBA.ListenerPort parameter to the line
com.ibm.ejs.sm.util.process.Nanny.adminServerJvmArgs in the product
installation root/bin/admin.config file on Machine B. For example:
com.ibm.ejs.sm.util.process.Nanny.adminServerJvmArgs -Dcom.ibm.CORBA.ListenerPort=33000
- Stop and restart the administrative server on Machine B.
- Open a command window on Machine A.
- Change directory to product installation root/bin.
- Issue the following command to start and configure remote OSE:
- On Windows systems:
OSERemoteConfig -adminNodeName administration_server_hostname
- On UNIX-based systems:
OSERemoteConfig.sh -adminNodeName administration_server_hostname
where administration_server_hostname is the host name of the WebSphere
application server machine to which requests should be routed.
OSERemoteConfig has additional, optional parameters. For details, type OSERemoteConfig
(add .sh on UNIX systems) without any parameters.
- Wait for OSERemoteConfig to complete.
Manual configuration
Manually configure the Web server plug-in for remote OSE if a NAT firewall is being
used between the Web server machine (Machine A) and application server machines (Machines
B and D through N) or if you do not want to open up an additional port in a non-NAT
firewall. Follow these steps:
- Copy the following Web server plug-in configuration files
from the product_installation_root/temp directory of
Machine B to the same directory on Machine A:
- vhosts.properties
- rules.properties
- queues.properties
All users must have read and write access to these files.
- Add a host entry for each application server or clone to the queues.properties file on
the Web server machine (Machine A). The format of the entry is:
ose.srvgrp.ibmoselink.clone.host=clone_hostname
where clone.is the name of the application server or clone and clone_hostname
is the IP address or host name of the machine where the application server or clone is
running. The original application server or server group is clone1. For example:
ose.srvgrp.ibmoselink.clone1.host=bigcorp1
- If you are running WebSphere 3.5 Fix Pack 1 or earlier, you must modify the
queues.properties file on Machine B. For each clone on a machine other than Machine B (in
other words, for each clone on a machine other than the one specified in the
-adminNodeName argument to OSERemoteConfig), do the following:
- Create a type entry, such as:
ose.srvgrp.ibmoselink.clone2.type=remote
- Create a port entry, such as:
ose.srvgrp.ibmoselink.clone2.port=servlet_engine_port
To find the servlet engine port, use the administrative console to check the Advanced
properties for the servlet engine contained in the cloned application server.
- Create a host entry, such as:
ose.srvgrp.ibmoselink.clone2.host=clone_hostname
where clone_hostname is the host name of the machine where the cloned
application server is running.
- Update the clonescount property to match the number of clones configured, such as:
ose.srvgrp.ibmoselink.clonescount=2
If a firewall is in use between Machine A and Machines B and D through N, open the
ports listed in the file:
product_installation_root/temp/queues.properties
To secure the resources on the Web server (Machine A) with WebSphere security, you need
to do the following:
- If a firewall is in use, open a port between Machine A and Machine B. See Open ports in the firewall for details.
- Modify the product_installation_root/properties/bootstrap.properties
files on both Machine A and Machine B (the administrative server machine) as follows:
- Modify the bootstrap.properties file on Machine A as follows:
- Set the clone type property to remote:
ose.srvgrp.ibmappserve.clone1.type=remote
- If necessary, change the clone port number:
ose.srvgrp.ibmappserve.clone1.port=port_number
where port_number is the number of an unused port that is assigned to the clone. The
clone port numbers on Machines A and B must be identical.
- Modify the bootstrap.properties file on Machine B as follows:
- Set the clone type property to remote:
ose.srvgrp.ibmappserve.clone1.type=remote
- If necessary, change the clone port number:
ose.srvgrp.ibmappserve.clone1.port=port_number
where port_number is the number of an unused port that is assigned to the clone. The
clone port numbers on Machines A and B must be identical.
- Set the clone host name property:
ose.srvgrp.ibmappserve.clone1.host=admin_server_hostname
where admin_server_hostname is the host name of Machine B, the machine where
the administrative server is running.
For the remote OSE configuration to take effect, you must stop and restart all Web
servers, administrative servers, and application servers on each machine in the system.
You need to update the remote OSE configuration after doing any of the following:
- Adding or removing a URL (Web resource) in the environment
- Adding or removing a virtual host alias
- Changing the queue properties of a servlet engine (such as the name or port)
- Adding or removing a servlet engine
- Adding or removing an application server clone
See Configure the WebSphere plug-in on Machine A for remote OSE
for details.
|
|