1. Administering Oracle HTTP Server
  2. Managing Oracle HTTP Server
  3. Configuring High Availability for Web Tier Components

6 Configuring High Availability for Web Tier Components

Use the instructions in this chapter to configure an Oracle HTTP Server highly available deployment in which Oracle HTTP Servers and WebLogic Managed Servers reside on different hosts, behind a load balancer.

This chapter includes the following sections:

Parent topic: Managing Oracle HTTP Server

Oracle HTTP Server Single-Instance Characteristics

Oracle HTTP Server (OHS) is based on Apache infrastructure and includes Oracle modules that you can use to extend OHS core functionality.

OHS has these components to handle client requests

  • HTTP listener handles incoming requests and routes them to the appropriate processing utility.

  • Modules (mods) implement and extend OHS functionality. OHS includes many standard Apache modules. Oracle also includes modules that are specific to OHS to support OHS and OHS component integration.

OHS can also be a proxy server, both forward and reverse. A reverse proxy enables content served by different servers to appear as if it comes from one server.

Parent topic: Configuring High Availability for Web Tier Components

Oracle HTTP Server and Domains

Oracle HTTP Server (OHS) doesn't require a WebLogic domain but you usually use it with one. Oracle recommends associating OHS with a domain so that you can incorporate OHS into the Administration Console, where you can manage and monitor it.

The mod_wl_ohs module handles the link to Managed Servers. You configure mod_wl_ohs by routing requests of a particular type, such as JSPs, or by routing requests destined to a URL to specific Managed Servers.

OHS usually front ends a cluster. In this configuration, a special mod_wl_ohs directive, WebLogicCluster, specifies a comma-separated list of cluster members.

These steps describe the mod_wl_ohs directive process:

  1. mod_wl_ohs receives a request for a Managed Server then sends the request to one cluster member in the directive. At least one Managed Server must be available to fulfill the request.

  2. The Managed Server receives the request, processes it, and sends a complete list of cluster members back to mod_wl_ohs.

  3. When mod_wl_ohs receives the updated list, it dynamically adds previously unknown servers to the known servers list. By doing this, all future requests are load balanced across the cluster member list. The benefit is that new Managed Servers are added to a cluster without updating mod_wl_ohs or adding OHS.

    Note:

    The mod_wl_ohs directive DynamicServerList controls whether or not unknown servers are added to the known servers list. You must set DynamicServerList to ON to enable dynamic addition of servers.

Note:

When you start, you don't need to include all current Managed Servers in the mod_wl_ohs directive. A high availability setup requires only two cluster members in the list for the first call to work. For more information about running an OHS high availability deployment, see Configuring the WebLogic Proxy Plug-In for Oracle HTTP Server in Using Oracle WebLogic Server Proxy Plug-Ins.

For more information about Oracle WebLogic clusters, see Introduction and Roadmap in Administering Clusters for Oracle WebLogic Server.

Parent topic: Configuring High Availability for Web Tier Components

Oracle HTTP Server Startup and Shutdown Lifecycle

After Oracle HTTP Server starts, it is ready to listen for and respond to HTTP(S) requests.

The request processing model is different on Microsoft Windows systems compared to UNIX systems:

  • For Microsoft Windows, there is one parent process and one child process. The child process creates threads that handle client requests. The number of created threads is static and you can configure them for performance.

  • For UNIX, there is one parent process that manages multiple child processes. Child processes handle requests. The parent process brings up more child processes as necessary, based on configuration.

Note:

For more information about the OHS processing model, see Oracle HTTP Server Processing Model.

Parent topic: Configuring High Availability for Web Tier Components

Starting and Stopping Oracle HTTP Server

Use Fusion Middleware Control or the WebLogic Scripting Tool (WLST) to start, stop, and restart Oracle HTTP Server.

If you plan to use WLST, you should familiarize yourself with that tool; see Getting Started Using the Oracle WebLogic Scripting Tool (WLST) in the Oracle Fusion Middleware Administrator's Guide.

Note:

For more information about starting and stopping an OHS instance, see Performing Basic Oracle HTTP Server Tasks.

Parent topic: Configuring High Availability for Web Tier Components

Oracle HTTP Server High Availability Architecture and Failover Considerations

Oracle HTTP Servers and Managed Servers reside on different hosts, behind a load balancer, in a high availability topology.

Figure 6-1 shows two Oracle HTTP Servers behind a load balancer.

Figure 6-1 Oracle HTTP Server High Availability Architecture

Description of Figure 6-1 follows
Description of "Figure 6-1 Oracle HTTP Server High Availability Architecture"

The load balancer receives user requests and forwards them to connected Oracle HTTP Servers. The load balancer receives requests on standard HTTP/HTTPS ports (80/443). However, it then passes requests to Oracle HTTP Servers using completely different ports. Advantages of this setup are:

  • Actual ports are hidden from users.

  • Users don't have to add port numbers to the URL.

On UNIX-based systems, starting OHS with root privileges isn't mandatory. Only root can start a process that uses a port less than 1024. However, for processes that use a port number below 1024, you must use root privilege to start a process.

The load balancer routes requests to the functioning Oracle HTTP Server.

Figure 6-1 also shows how OHS distributes requests to Managed Servers. For high availability, each pair of components (OHS and Managed Servers) should reside on different host computers. Managed Servers belong to the same cluster; to load balance across a set of Managed Servers, they must belong to the same cluster.

Parent topic: Configuring High Availability for Web Tier Components

Oracle HTTP Server Failure Protection and Expected Behaviors

Oracle HTTP Server (OHS) has two failure types: process failures and node failures. An individual operating system process may fail. A node failure can involve failure of the entire host computer that OHS runs on.

Table 6-1 OHS Failure Types and Failure Protections

Failure Type Protection

Process

Node Manager protects and manages OHS processes. If an OHS process fails, Node Manager automatically restarts it.

Node

Load balancer in front of OHS sends a request to another OHS if the first one doesn't respond or URL pings indicate it failed.

Managed Server

If a Managed Server in a cluster fails, mod_wl_ohs automatically redirects requests to one of the active cluster members. If the application stores state, state replication is enabled within the cluster, which enables redirected requests access to the same state information.

Database

Typically, an issue only when using mod_oradav or mod_plsql. With Oracle RAC databases, the Oracle RAC connection determines failure characteristics.

If client connection failover is configured, in-flight transactions roll back. Database reconnection is required.

If Transparent Application Failover (TAF) is configured, any in-flight database write rolls back but automatic database reconnection occurs and select statements recover automatically. TAF fails over select statements only; package variables are lost. TAF, a JDBC Oracle Call Interface driver feature, enables an application to automatically reconnect to a database if the database instance the connection is made to fails. In this case, active transactions roll back.

Parent topic: Configuring High Availability for Web Tier Components

Configuring Oracle HTTP Server Instances on Multiple Machines

If you use the Configuration Wizard to configure Oracle HTTP Server (OHS) and OHS is part of a domain, update the mod_wl_ohs.conf file for each instance.

The file is in the DOMAIN_HOME/config/fmwconfig/components/OHS/componentName directory. Restart the Administration Server to propagate changes to all OHS instances in the domain, even if they reside on a different host. See Configuring mod_wl_ohs.conf.

Note:

If you install and configure OHS instances in separate domains, you must manually copy changes to other Oracle HTTP Servers. You must verify that the changes apply to all OHS instances and that they are synchronized.

Parent topic: Configuring High Availability for Web Tier Components

Configuring Oracle HTTP Server for High Availability

To configure an example high availability deployment of Oracle HTTP Server (OHS), you must meet specific prerequisites. You can then install OHS on an additional web server, then configure and validate OHS high availability.

Parent topic: Configuring High Availability for Web Tier Components

Prerequisites to Configure a Highly Available OHS

Complete the following prerequisites before configuring a highly available Oracle HTTP Server deployment:

Parent topic: Configuring Oracle HTTP Server for High Availability

Load Balancer Prerequisites

To distribute requests against Oracle HTTP Server, you can either use an external load balancer to distribute HTTP(S) requests between available Oracle HTTP Servers, or configure Oracle HTTP Server VirtualHost proxy for load balancing.

If you have an external load balancer, it must have features that Third-Party Load Balancer Requirements describes.

If you want to configure Oracle HTTP Server for load balancing, use virtual host based proxy configuration. To do this, create a separate configuration file, for example, proxy.conf with the configuration details, and append this configuration into httpd.conf using include tag. For example, include "proxy.conf". For more information, see Creating proxy.conf File.

Configuring Load Balancer Virtual Server Names and Ports

In an OHS installation, virtual servers are configured for HTTP connections, which are distributed across the HTTP servers.

If your site serves requests for HTTP and HTTPS connections, Oracle recommends that HTTPS requests terminate at the load balancer and pass through as HTTP requests. To do this, the load balancer should be able to perform the protocol conversion and must be configured for persistent HTTP sessions.

This example configuration assumes that the load balancer is configured as:

  • Virtual Host: Myapp.example.com

  • Virtual Port: 7777

  • Server Pool: Map

  • Server: WEBHOST1, Port 7777, WEBHOST2, Port 7777

Managing Load Balancer Port Numbers

Many Oracle Fusion Middleware components and services use ports. As an administrator, you must know the port numbers that services use and ensure that two services don't use the same port number on your host computer.

Most port numbers are assigned during installation. It is important that any traffic going from Oracle HTTP Servers to Oracle WebLogic Servers has access through any firewalls.

Installing and Validating Oracle HTTP Server on WEBHOST1

To install Oracle HTTP Server on WEBHOST1, see the steps in Installing the Oracle HTTP Server Software in Installing and Configuring Oracle HTTP Server.

Validate the installation using the following URL to access the OHS home page:

http://webhost1:7777/

Creating Virtual Host(s) on WEBHOST1

For each virtual host or site name that you use, add an entry to the OHS configuration.

Create a file named virtual_hosts.conf in the DOMAIN_HOME/config/fmwconfig/components/OHS/ohs_component_name/moduleconf directory as follows: 

NameVirtualHost *:7777
<VirtualHost *:7777>
 ServerName http://myapp.example.com:80
 RewriteEngine On
 RewriteOptions inherit
 UseCanonicalName On
</VirtualHost>

If you are using SSL/SSL Termination (*):

NameVirtualHost *:7777
<VirtualHost *:7777>
 ServerName https://myapp.example.com:443
 RewriteEngine On
 RewriteOptions inherit
 UseCanonicalName On
</VirtualHost>

Note:

You can also use Fusion Middleware Control to create virtual hosts. See Wiring Components Together in Administering Oracle Fusion Middleware.

Configuring mod_wl_ohs.conf

After you install and configure OHS, link it to any defined Managed Servers by editing the mod_wl_ohs.conf file.

The file is in DOMAIN_HOME/config/fmwconfig/components/OHS/componentName directory.

For more information about editing the mod_wl_ohs.conf file, see Configuring the WebLogic Proxy Plug-In for Oracle HTTP Server in Oracle Fusion Middleware Using Oracle WebLogic Server Proxy Plug-Ins 12.1.2.

Note:

You can also use Fusion Middleware Control to link OHS to Managed Servers. See Wiring Components Together in Administering Oracle Fusion Middleware.

The following example shows mod_wl_ohs.conf entries: 

LoadModule weblogic_module PRODUCT_HOME/modules/mod_wl_ohs.so
 
<IfModule mod_weblogic.c>
 WebLogicCluster apphost1.example.com:7050, apphost2.example.com:7050
 MatchExpression *.jsp
 </IfModule>
 
<Location /weblogic>
 SetHandler weblogic-handler
 WebLogicCluster apphost1.example.com:7050,apphost2.example.com:7050
 DefaultFileName index.jsp
</Location>

<Location /console>
 SetHandler weblogic-handler
 WebLogicCluster apphost1.example.com
 WebLogicPort 7003
</Location>

These examples show two different ways to route requests to Managed Servers:

  • The <ifModule> block sends any requests ending in *.jsp to the WebLogic Managed Server cluster located on APPHOST1 and APPHOST2.

  • The <Location> block sends any requests with URLs that have a /weblogic prefix to the Managed Server cluster located on APPHOST1 and APPHOST2.

Configuring mod_wl_conf if you use SSL Termination

If you use SSL termination AND route requests to WebLogic, you must take additional configuration steps.

To configure mod_wl_conf if you use SSL termination:

  1. In the WebLogic console, verify that WebLogic Plugin Enabled is set to true, either at the domain, cluster, or Managed Server level.
  2. Add these lines to the Location block, which directs requests to Managed Servers:
    WLProxySSL ON
WLProxySSLPassThrough ON

For example:

<Location /weblogic>
 SetHandler weblogic-handler
 WebLogicCluster apphost1.example.com:7050,apphost2.example.com:7050
 WLProxySSL On
 WLProxySSLPassThrough ON
 DefaultFileName index.jsp
</Location>

After you enable the WebLogic plugin, restart the Administration Server.

Creating proxy.conf File

If you are not using an external load balancer, you can configure Oracle HTTP Server virtual host proxy for load balancing.

To do this, create a separate configuration file, for example, proxy.conf at the following locations:

  • MW_HOME/user_projects/domains/DOMAIN_NAME/config/fmwconfig/components/OHS/INSTANCE_NAME/
  • MW_HOME/user_projects/domains/DOMAIN_NAME/config/fmwconfig/components/OHS/instances/INSTANCE_NAME/

Add the following snippet to the newly created configuration file (at both the locations):

LoadModule lbmethod_byrequests_module
"${PRODUCT_HOME}/modules/mod_lbmethod_byrequests.so"

<VirtualHost myohs.com:8080>

   # Proxy : HTTP - HTTP
   <Proxy "balancer://ha">
      ProxySet lbmethod=byrequests
      BalancerMember http://OHS_Host1:Port
      BalancerMember http://OHS_Host1:Port
   </Proxy>

   # Proxy pass : HTTP - HTTP
   ProxyPass        "/ha"   "balancer://ha"
   ProxyPassReverse "/ha"   "balancer://ha"

</VirtualHost>

Append this configuration file (proxy.conf) into httpd.conf file.

Installing and Validating Oracle HTTP Server on WEBHOST2

To install Oracle HTTP Server on WEBHOST2, see Installing the Oracle HTTP Server Software in Oracle Fusion Middleware Installing and Configuring Oracle HTTP Server.

Validate the installation on WEBHOST2 by using the following URL to access the Oracle HTTP Server home page:

http://webhost2:7777/

Parent topic: Configuring Oracle HTTP Server for High Availability

Configuring and Validating an OHS High Availability Deployment

To configure and validate the OHS high availability deployment, update mod_wl_ohs.conf and then use test URLs to validate OHS configuration.

Parent topic: Configuring Oracle HTTP Server for High Availability

Configuring Virtual Host(s) on WEBHOST2

Update the mod_wl_ohs.conf file located in DOMAIN_HOME/config/fmwconfig/components/OHS/componentName directory.

You must then restart the Administration Server to propagate changes to all OHS instances in the domain.

Validating the Oracle HTTP Server Configuration

You validate the OHS configuration by using specific URLs.

http://myapp.example.com/

https://myapp.example.com (if using SSL/SSL termination)

http://myapp.example.com:7777/weblogic