9 Configuring High Availability for Web Tier Components

The Web Tier of Oracle Fusion Middleware is the outermost tier in the architecture, closest to the end user. The key component of the Web Tier is Oracle HTTP Server. This chapter describes high availability concepts and configuration procedures for Oracle HTTP Server and includes the following topics:

9.1 Oracle HTTP Server and High Availability Concepts

Oracle HTTP Server (OHS) is the Web server component for Oracle Fusion Middleware. It provides a listener for Oracle WebLogic Server and the framework for hosting static pages, dynamic pages, and applications over the Web.

See Also:

For more information on working with OHS, see the following:

9.2 Oracle HTTP Server Single-Instance Characteristics

Oracle HTTP Server is based on Apache infrastructure and includes modules developed by Oracle that you can use to extend Oracle HTTP Server core functionality. Oracle HTTP Server has the following components to handle client requests:

  • HTTP listener, to handle incoming requests and route them to the appropriate processing utility.

  • Modules (mods), to implement and extend the basic functionality of Oracle HTTP Server. Many of the standard Apache modules are included with Oracle HTTP Server. Oracle also includes several modules that are specific to Oracle HTTP Server to support integration between Oracle HTTP Serverand other Oracle HTTP Servercomponents.

Oracle HTTP Server 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.

9.2.1 Oracle HTTP Server and Oracle WebLogic Server

Oracle HTTP Server does not require an Oracle WebLogic domain but is usually used in conjunction with one. Oracle recommends associating Oracle HTTP Server with a WebLogic domain because it enables Oracle HTTP Server to be incorporated into the Administration Console for centralized management and monitoring.

The link to WebLogic Managed Servers is handled through the mod_wl_ohs module. This module is configured by routing requests of a particular type, for example, JSPs, or by routing requests destined to a URL to specific Managed Servers.

Typically you use Oracle HTTP Server to front end a cluster of WebLogic servers. When Oracle HTTP Server front-ends a cluster of WebLogic servers, a special mod_wl_ohs directive, WebLogicCluster, specifies a comma-separated list of cluster members. The process works as follows:

  1. When mod_wl_ohs receives a request requiring a Managed Server, it sends that request to one of the WebLogic cluster members listed in the directive. At least one server must be available to service the request.

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

  3. When the mod_wl_ohs directive receives the updated list, it dynamically adds any previously unknown servers to the list of known servers. This action enables all future requests to be load balanced across the full cluster member list. The advantage of this process is that it enables new Managed Servers to be added to the cluster without updating mod_wl_ohs or adding the Oracle HTTP Server.

    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 this dynamic addition of servers.

Note:

You do not need to include all current Managed Servers in the mod_wl_ohs directive when you start; a high availability setup requires only two cluster members in the list for the first call to work. See "Configuring the WebLogic Proxy Plug-In for Oracle HTTP Server" in the guide Oracle Fusion Middleware Using Oracle WebLogic Server Proxy Plug-Ins for more information on running a high availability deployment of Oracle HTTP Server.

See Also:

For more information on Oracle WebLogic clusters, see Oracle Fusion Middleware Using Clusters for Oracle WebLogic Server.

9.3 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 on Microsoft Windows systems differs from that on UNIX systems:

  • For Microsoft Windows, there is a single parent process and a single child process. The child process creates threads that are responsible for handling client requests. The number of created threads is static and can be configured for performance.

  • For UNIX, there is a single parent process that manages multiple child processes. The child processes are responsible for handling requests. The parent process brings up additional child processes as necessary, based on configuration.

See Also:

For more information on the OHS processing model, see "Oracle HTTP Server Processing Model" in the Administrator's Guide for Oracle HTTP Server.

9.4 Starting and Stopping Oracle HTTP Server

You can 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.

See Also:

For information on starting and stopping OHS, see Starting, Stopping, and Restarting Oracle HTTP Server in the Administrator's Guide for Oracle HTTP Server.

9.5 Oracle HTTP Server High Availability Architecture and Failover Considerations

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

Figure 9-1 Oracle HTTP Server High Availability Architecture

The text that follows this graphic describes it.
Description of "Figure 9-1 Oracle HTTP Server High Availability Architecture"

The load balancer receives requests from users and forwards them on to the connected Oracle HTTP Servers. In Figure 9-1, the load balancer receives the requests on the standard HTTP/HTTPS ports (80/443). However, it then passes the requests on to the Oracle HTTP Servers using completely different ports. This setup has the following advantages:

  • Actual ports are hidden from users.

  • Users do not have to add the port numbers to the URL.

On UNIX-based systems, it is not mandatory to start Oracle HTTP Server with root privileges. Only root can start a process that uses a port less than 1024. However, for processes that use a port number below 1024, root privilege is required to start the process.

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

Figure 9-1 also shows how Oracle HTTP Server distributes requests to WebLogic Managed Servers. For high availability, it is assumed that each pair of components (Oracle HTTP Server and WebLogic Managed Servers) exist on different host computers. In Figure 9-1, the Managed Servers belong to the same cluster. To load balance across a set of Managed Servers, they must belong to the same cluster.

9.6 Oracle HTTP Server Protection from Failures and Expected Behaviors

There are two categories of Oracle HTTP Server failures: process failures and node failures. An individual operating system process may fail. A node failure could involve failure of the entire host computer that Oracle HTTP Server runs on. This section describes failure types and the systems or processes that take over if they occur.

Process Failure

Node manager protects and manages Oracle HTTP Server processes. If an Oracle HTTP Server process fails, Node Manager automatically restarts the process.

Node Failure

If an entire node fails, the load balancer in front of Oracle HTTP Server sends a request to another Oracle HTTP Server if the first one does not respond, or is determined to be failed through URL pings.

WebLogic Managed Server Failure

In a high availability deployment, Oracle WebLogic Managed Servers are part of a cluster. If one of the Managed Servers 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 Failure

Typically, database failures are an issue only when mod_oradav or mod_plsql is used. If this is an Oracle Real Application Clusters (Oracle RAC) database, the failure characteristics are determined by the defined Oracle RAC connection.

If client connection failover is configured, any in-flight transactions are rolled back, and a database reconnection is required.

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

9.7 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 (located in the DOMAIN_HOME/config/fmwconfig/components/OHS/componentName directory) for each instance. Restart the Administration Server to propagate changes to all OHS instances in the domain, even if they reside on a different host.

See Also:

See Section 9.8.1.4, "Configuring mod_wl_ohs.conf" for more information on the mod_wl_ohs file.

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.

9.8 Configuring Oracle HTTP Server for High Availability

This section describes how to configure an example high availability deployment of Oracle HTTP Server.

This section includes the following topics:

9.8.1 Prerequisites

Review the following prerequisites before configuring a high availability Oracle HTTP Server deployment.

9.8.1.1 Configuring the Load Balancer

To distribute requests against Oracle HTTP Servers, you must use an external load balancer to distribute HTTP(S) requests between available Oracle HTTP Servers. If you have an external load balancer, it must have the features that Section 2.1.1, "Third-Party Load Balancer Requirements"describes, including:

  • Virtual server name and port configuration

  • Process failure detection

  • Monitoring of ports (HTTP, HTTPS) for Oracle HTTP and HTTPS

  • SSL Protocol Conversion (if required)

The following sections describe steps to configure your load balancer:

Configuring Virtual Server Names and Ports for the Load Balancer

For each application, such as myapp.example.com, configure the load balancer with a virtual server name and associated ports. In an Oracle HTTP Server installation, these virtual servers are configured for HTTP connections, which are distributed across the HTTP servers.

If your site is serving 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 Port Numbers

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

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

9.8.1.2 Installing Oracle HTTP Server on WEBHOST1

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

Validating the OHS Installation

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

http://webhost1:7777/

9.8.1.3 Creating Virtual Host(s) on WEBHOST1

For each virtual host or site name that you use, add an entry to the Oracle HTTP Server configuration. Create a file named virtual_hosts.conf located in the ORACLE_HOME/config/fmwconfig/components/OHS/componentName/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. For more information see "Wiring Components Together" in Oracle Fusion Middleware Administering Oracle Fusion Middleware

9.8.1.4 Configuring mod_wl_ohs.conf

After you install and configure Oracle HTTP Server, link it to any defined Managed Servers by editing the mod_wl_ohs.conf file located in DOMAIN_HOME/config/fmwconfig/components/OHS/componentName directory.

See "Configuring the WebLogic Proxy Plug-In for Oracle HTTP Server" in the guide Oracle Fusion Middleware Using Oracle WebLogic Server Proxy Plug-Ins 12.1.2 for more information on editing the mod_wl_ohs.conf file.

Note:

You can also use Fusion Middleware Control to link OHS to Managed Servers. For more information see "Wiring Components Together" in Oracle Fusion Middleware Administering Oracle Fusion Middleware

The following is an example of 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>

Note:

If you use SSL termination AND route requests to WebLogic, then the following additional configuration is required.

In the WebLogic console, WebLogic Plugin Enabled must be set to true, either at the domain, cluster or Managed Server level.

In the Location block, which directs requests to the Managed Servers, you must add the following lines:

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.

These examples show two different ways of routing 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 prefixed by /weblogic to the Managed Server cluster located on Apphost1 and Apphost2.

9.8.2 Installing Oracle HTTP Server on WEBHOST2

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

Validating the OHS Installation

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

http://webhost2:7777/

9.8.3 Configuring and Validating the OHS High Availability Deployment

To configure and validate the OHS high availability deployment, follow these steps:

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

9.8.3.2 Validating the Oracle HTTP Server Configuration

Validate the configuration by using the following URLs:

http://myapp.example.com/

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

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