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

Overview

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.

Load-balancing support

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.

Inform.gif (183 bytes) Session persistence cannot be used with the workload management facility.

Failover support

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.)

Typical use

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.

Instructions

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:

  1. Install the appropriate WebSphere Application Server components.
  2. Start the database server, administrative server and administrative console.
  3. Configure the application server on Machine B.
  4. Start the application server on Machine B.
  5. Configure the Web server plug-in on Machine A for Remote OSE.
  6. If a firewall is being used between Machine A and the other machines in the configuration, open the appropriate firewall ports.
  7. If WebSphere security is being used to secure resources on the Web server, modify the appropriate configuration files.
  8. Restart all Web servers, application servers, and administrative servers.

The rest of this section describes how to complete these steps.

Install WebSphere Application Server components

The product components required for Remote OSE are listed in the following table:

  Web server Application server Web server plug-in Administrative server
Machine A (and possibly others)

When doing the installation, select Core server and the appropriate plug-in for your Web server.

The administrative server, Web server plug-in, and IBM Java 2 SDK must be installed on Machine A in order for the OSERemoteConfig tool to run successfully.

Machine B  

Perform a production application server installation.

 
Machines D, E, ...N  

Perform a production application server installation.

 

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.

Start the database server, administrative server, and administrative console

Before you configure the plug-in for OSE remote, start the software that is needed for the configuration:

  1. Start a DB2 instance for the administrative repository (if it was not already started).
  2. Start the administrative server on Machine B.
  3. Start the administrative console on Machine B.
  4. Make sure that Machine B is listed in the administrative console.
Configure the application server on Machine B

Configure the application server on Machine B by completing the following steps:

  1. Add the aliases of each Web server machine to the alias list of the virtual host for Machine B by following these steps:
    1. Locate and click the virtual host in the Topology tree view to display its properties.
    2. 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.
    3. 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.

  2. 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:
    1. Locate and click the servlet engine in the Topology tree view to display its properties.
    2. In the advanced properties, access the plug-in configuration settings.
    3. Change the transport type to INET Sockets.
    4. Click OK.
    5. 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).

  3. 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
  4. Make any other desired changes to the application server.
  5. 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

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.

Configure the Web server plug-in on Machine A for Remote OSE

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).

  1. 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:
    1. 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
    2. Stop and restart the administrative server on Machine B.
  2. Open a command window on Machine A.
  3. Change directory to product installation root/bin.
  4. 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.

  5. 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:

  1. 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.

  2. 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
  3. 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:
    1. Create a type entry, such as:
      ose.srvgrp.ibmoselink.clone2.type=remote
    2. 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.

    3. 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.

    4. Update the clonescount property to match the number of clones configured, such as:
      ose.srvgrp.ibmoselink.clonescount=2
Open ports in the firewall

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
Using remote OSE with WebSphere security

To secure the resources on the Web server (Machine A) with WebSphere security, you need to do the following:

  1. If a firewall is in use, open a port between Machine A and Machine B. See Open ports in the firewall for details.
  2. Modify the product_installation_root/properties/bootstrap.properties files on both Machine A and Machine B (the administrative server machine) as follows:
    1. Modify the bootstrap.properties file on Machine A as follows:
      1. Set the clone type property to remote:
        ose.srvgrp.ibmappserve.clone1.type=remote
      2. 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.

    2. Modify the bootstrap.properties file on Machine B as follows:
      1. Set the clone type property to remote:
        ose.srvgrp.ibmappserve.clone1.type=remote
      2. 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.

      3. 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.

Restart all Web servers, administrative servers, and application servers

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.

Updating the remote OSE configuration

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.

Go to previous article: HTTP server separation sample topologies Go to next article: Semi-remote OSE sample topology

 

 
Go to previous article: HTTP server separation sample topologies Go to next article: Semi-remote OSE sample topology