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

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

7.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 OHS's core functionality. OHS 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 Server and other Oracle HTTP Server components.

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.

7.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 the 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 mod_wl_ohs receives the updated list, it dynamically adds any previously unknown servers to the list of known servers, enabling all future requests to be load balanced across the full cluster member list. This process has the advantage of enabling new Managed Servers to be added to the cluster without updating mod_wl_ohs or adding the Oracle HTTP Server

Note:

You do not need to include all the 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.

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

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

7.5 Oracle HTTP Server High Availability Architecture and Failover Considerations

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

Figure 7-1 Oracle HTTP Server High Availability Architecture

The text that follows this graphic describes it.
Description of "Figure 7-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 7-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 which uses a port less than 1024.

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

Figure 7-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 Web Logic Managed Servers) exist on different host computers.

You can separate this architecture across two servers. Alternatively, in more complex implementations, each component can reside on a completely separate server.

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

7.7 Oracle HTTP Server Cluster-Wide Configuration Changes

Oracle HTTP Servers are managed independently by Fusion Middleware Control. The Oracle HTTP server configuration is file-based; if you make changes to one Oracle HTTP Server, you must manually copy the changes to other Oracle HTTP Servers in the configuration. This also applies to static HTML files stored in the htdocs directory.

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

7.8.1 Prerequisites

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

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

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

7.8.1.3 Configuring Virtual Host(s)

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

7.8.1.4 Configuring mod_wl_ohs.conf

After you install and configure Oracle HTTP Server, link it to any defined WebLogic Managed Servers by editing the mod_wl_ohs.conf file located in DOMAIN_HOME/config/fmwconfig/components/OHS/instances/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.

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>

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 WebLogic Managed Servers, the following lines also need to be added.

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 Oracle WebLogic 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 WebLogic Managed Server cluster located on Apphost1 and Apphost2.

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

7.8.3 Configuring and Validating the OHS High Availability Deployment

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

7.8.3.1 Configuring Virtual Host(s)

Add an entry for each virtual host or site name to the Oracle HTTP Server configuration. Copy the file virtual_hosts.conf from WEBHOST1 to WEBHOST2. The file is located in the directory DOMAIN_HOME/config/fmwconfig/components/OHS/ohs_name/moduleconf

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