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:
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.
For more information on working with OHS, see the following:
"Managing Oracle HTTP Server" in the guide Administering Oracle HTTP Server. This section includes topics such as "Performing Basic OHS Tasks," "Creating an OHS Instance," and "Managing and Monitoring Server Processes.
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.
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:
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.
When the Managed Server receives the request, it processes it and sends a complete list of cluster members back to
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.
DynamicServerList controls whether or not unknown servers are added to the known servers list. You must set
ON to enable this dynamic addition of servers.
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.
For more information on Oracle WebLogic clusters, see Oracle Fusion Middleware Using Clusters for Oracle WebLogic Server.
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.
For more information on the OHS processing model, see "Oracle HTTP Server Processing Model" in the Administrator's Guide for 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.
For information on starting and stopping OHS, see Starting, Stopping, and Restarting Oracle HTTP Server in the Administrator's Guide for Oracle HTTP Server.
Figure 9-1 shows two Oracle HTTP Servers placed behind a load balancer.
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.
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.
Node manager protects and manages Oracle HTTP Server processes. If an Oracle HTTP Server process fails, Node Manager automatically restarts the process.
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.
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.
Typically, database failures are an issue only when
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.
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 Section 220.127.116.11, "Configuring mod_wl_ohs.conf" for more information on the
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.
This section describes how to configure an example high availability deployment of Oracle HTTP Server.
This section includes the following topics:
Review the following prerequisites before configuring a high availability Oracle HTTP Server deployment.
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:
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:
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.
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.
Validate the installation using the following URL to access the Oracle HTTP Server home page:
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/
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>
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
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/
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
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
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>
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
<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:
<ifModule> block sends any requests ending in *.jsp to the WebLogic Managed Server cluster located on Apphost1 and Apphost2.
<Location> block sends any requests with URLs prefixed by /weblogic to the Managed Server cluster located on Apphost1 and Apphost2.
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.
Validate the installation on WEBHOST2 by using the following URL to access the Oracle HTTP Server home page:
To configure and validate the OHS high availability deployment, follow these steps:
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.
Validate the configuration by using the following URLs:
https://myapp.example.com (if using SSL/SSL termination)