Skip Headers
Oracle® Fusion Middleware High Availability Guide
11g Release 1 (11.1.1)

Part Number E10106-15
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

9 Configuring High Availability for Web Tier Components

The Web tier receives each incoming HTTP request and invokes the requested business logic operation in the application. Based on the results of the operation and state of the model, the next view is selected to display. The selected view is transmitted to the client for presentation.

This chapter describes high availability concepts and configuration procedures for Oracle HTTP Server and Oracle Web Cache. This chapter includes the following topics:

9.1 About the Web Tier

The Web tier of Java EE application server is responsible for interacting with the end user such as web browsers primarily in the forms of HTTP requests and responses. It is the outermost tier in the application server, closest to the end user. At the highest level, the Web tier does four basic tasks:

The Web tier receives each incoming HTTP request and invokes the requested business logic operation in the application. Based on the results of the operation and state of the model, the next view is selected to display. The selected view is transmitted to the client for presentation.

Oracle Web Cache is a content-aware server accelerator, or reverse proxy, for the Web tier that improves the performance, scalability, and availability of Web sites that run on Oracle HTTP Server.

Oracle Web Cache is the primary caching mechanism provided with Oracle Fusion Middleware. Caching improves the performance, scalability, and availability of Web sites that run on Oracle Application Server by storing frequently accessed URLs in memory.

By storing frequently accessed URLs in memory, Oracle Web Cache eliminates the need to repeatedly process requests for those URLs on the application Web server and database tiers. Unlike legacy proxies that handle only static objects, Oracle Web Cache caches both static and dynamically generated content from one or more application Web servers. Because Oracle Web Cache is able to cache more content than legacy proxies, it provides optimal performance by greatly reducing the load on application Web server and database tiers. As an external cache, Oracle Web Cache is also an order of magnitude faster than object caches that run within the application tier.

Because Web Cache is fully compliant with HTTP 1.0 and 1.1 specifications, it can accelerate Web sites that are hosted by any standard web servers, such as Apache and IIS. In Oracle Fusion Middleware, Oracle Web Cache resides in front of one or more instances of Oracle HTTP Server. Responses to browser based HTTP requests are directed to the Oracle HTTP Server instance and transmitted through Oracle Web Cache. The Oracle Web Cache instance can handle any Web content transmitted with standard HTTP protocol.

9.2 Oracle HTTP Server and High Availability Concepts

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

9.2.1 Oracle HTTP Server Single-Instance Characteristics

Oracle HTTP Server is based on Apache 2.2.10 infrastructure, and includes modules developed specifically by Oracle. The features of single sign-on, clustered deployment, and high availability enhance the operation of the Oracle HTTP Server. 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 Fusion Middleware to support integration between Oracle HTTP Server and other Oracle Fusion Middleware components.

  • Perl interpreter, a persistent Perl runtime environment embedded in Oracle HTTP Server through mod_perl.

Oracle HTTP Server enables developers to program their site in a variety of languages and technologies, such as the following:

  • Perl (through mod_perl and CGI)

  • C (through CGI and FastCGI)

  • C++ (through FastCGI)

  • PHP (through mod_php)

  • Oracle PL/SQL

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 coming from one server.

The Oracle HTTP Server is essentially a stateless application. Session State can be maintained using browser-based cookies.

Figure 9-1 Oracle HTTP Server Architecture

Oracle HTTP Server Architecture
Description of "Figure 9-1 Oracle HTTP Server Architecture"

Figure 9-1 illustrates the following Oracle HTTP Server components:

  • The Oracle Process Manager and Notification Service (OPMN) is used to start, stop, and monitor Oracle HTTP Server. OPMN periodically polls Oracle HTTP server to ensure that it is still functioning. If Oracle HTTP Server is not functioning, OPMN takes appropriate action to restart the failed component to ensure that service is maintained.

  • Oracle HTTP server is based on the industry leading Apache Web Server. The Oracle HTTP Server's core functionality can be extended using the following modules:

    • The mod_dms module enables performance monitoring of site components using Oracle Dynamic Monitoring Service (DMS).

    • The mod_onsint module provides integration support with Oracle Notification Service (ONS) and OPMN.

    • The mod_oradav module is an Oracle Call Interface (OCI) application written in C, that extends the implementation of mod_dav. The mod_oradav directive can read and write to local files, or to an Oracle database.

    • The mod_ossl module enables strong cryptography for Oracle HTTP Server. This Oracle module is a plug-in to Oracle HTTP Server that enables the server to use SSL.

    • The mod_osso module enables Oracle Single Sign-on.

    • The mod_perl module embeds the Perl interpreter into Oracle HTTP Server. This eliminates start-up overhead and enables Perl applications to be accessed through Oracle HTTP Server.

    • The mod_plsql module connects Oracle HTTP Server to an Oracle database, enabling Web application creation using Oracle stored procedures.

    • The mod_wl_ohs module allows requests to be proxied from Oracle HTTP Server to Oracle WebLogic Server.

9.2.1.1 Oracle HTTP Server and Oracle WebLogic Server

Oracle HTTP Server does not require an Oracle WebLogic domain. However, Oracle HTTP Server is typically used in conjunction with an Oracle WebLogic Domain.

The link to Oracle WebLogic managed servers is handled through the module mod_wl_ohs. This module is configured by routing requests of a particular type, for example, JSPs, or by routing requests destined to a URL, to specific WebLogic Managed Servers. In a non high availability deployment, this destination is defined by specifying the host name and port on which the WebLogic manage server resides.

In a high availability deployment, the WebLogic managed servers are typically clustered together. In such a deployment, a special mod_wl_ohs directive, WebLogicCluster, is used to specify a comma-separated list of cluster members. This list is not necessarily a complete list of cluster members. When a request requiring a WebLogic managed server is received, mod_wl_ohs send that request to one of the WebLogic cluster members listed in the directive. When the WebLogic managed server receives the request, it not only processes it, but it also sends a complete list of cluster members back to mod_wl_ohs. When mod_wl_ohs receives this updated list, it dynamically adds any previously unknown servers to the list of known servers, allowing all future requests to be load balanced across the full cluster member list. This process has the advantage of allowing new managed servers to be added to the cluster without updating mod_wl_ohs, or adding the Oracle HTTP Server.

In an example scenario, assume that the WebLogic Cluster consists of WLS1, WLS2, and WLS3. Also assume that WLS1 and WLS2 are known to mod_wl_ohs.

When mod_wl_ohs first receives a request, it attempts to send that request to either WLS1 or WLS2, if it is successful then the list is updated to include WLS3 for future requests. If, however, WLS1 and WLS2 are unavailable, but WLS3 is available, the request is rejected because mod_wl_ohs has no way of knowing WLS3 exists.

When using the Oracle HTTP server with an Oracle WebLogic domain, Oracle recommends associating Oracle HTTP Server with the WebLogic domain. This allows the Oracle HTTP Server to be incorporated into the Oracle Fusion Middleware Console for centralized management and monitoring.

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

9.2.1.2 Oracle HTTP Server External Dependencies

Oracle HTTP Server is dependent on the Oracle Process Management and Notification Server to start the HTTP server itself.

In order to access other resources, such as Oracle WebLogic, or Oracle Single Sign-On, Oracle HTTP Server is also dependent on the appropriate loading of Apache module.

9.2.2 Oracle HTTP Server Startup and Shutdown Lifecycle

The Oracle HTTP Server process is invoked indirectly through OPMN. When OPMN receives a request to start the Oracle HTTP Server, it starts the Oracle HTTP Server process (httpd).

After Oracle HTTP Server is started, 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. Although the server has the ability to dynamically bring up additional child processes, it is best to configure the server to start enough child processes initially so that requests can be handled without a need for more child processes.

9.2.3 Starting and Stopping Oracle HTTP Server

You can use Fusion Middleware Control or the opmnctl command to start and stop Oracle HTTP Server.

Note:

Do not use the apachectl utility to manage Oracle HTTP Server.

You can determine the status of Oracle HTTP Server using opmnctl:

opmnctl status

Processes in Instance: instance1
---------------------------------+--------------------+---------+---------
ias-component                    | process-type       |     pid | status  
---------------------------------+--------------------+---------+---------
webcache1                        | WebCache-admin     |   19556 | Alive   
webcache1                        | WebCache           |   19555 | Alive   
ohs1                             | OHS                |    7249 | Alive 

9.2.3.1 Understanding the PID File

When Oracle HTTP Server starts up, it writes the process ID (PID) of the parent httpd process to the httpd.pid file located, by default, in the following directory:

ORACLE_INSTANCE/diagnostics/logs/OHSComponent/ohs1/

The process ID can be used by the administrator when restarting and terminating the daemon. If a process stops abnormally, it is necessary to stop the httpd child processes using the kill command.

The PidFile directive in httpd.conf specifies the location of the PID file.

Note:

For UNIX platforms, if you edit the PidFile directive, you also have to edit the ORACLE_HOME/ohs/bin/apachectl file to specify the new location of the PID file.

See Also:

PidFile directive in the Apache Server documentation at:

http://httpd.apache.org/docs/

9.2.3.2 Starting and Stopping Oracle HTTP Server Using Oracle Fusion Middleware Control

To start Oracle HTTP Server using Fusion Middleware Control:

  1. Navigate to the Oracle HTTP Server home page.

  2. Select Control from the Oracle HTTP Server menu.

  3. Select Start Up from the Control menu.

To stop Oracle HTTP Server using Fusion Middleware Control:

  1. Navigate to the Oracle HTTP Server home page.

  2. Select Control from the Oracle HTTP Server menu.

  3. Select Shut Down from the Control menu.

9.2.3.3 Starting and Stopping Oracle HTTP Server Using opmnctl

To start all Oracle HTTP Server components in an Oracle instance using opmnctl:

opmnctl startproc process-type=OHS

To start a specific Oracle HTTP Server component, such as ohs1, using opmnctl:

opmnctl startproc ias-component=ohs1

To stop all Oracle HTTP Server components in an Oracle instance using opmnctl:

opmnctl stopproc process-type=OHS

To stop a specific Oracle HTTP Server component, such as ohs1, using opmnctl:

opmnctl stopproc ias-component=ohs1

9.2.4 Oracle HTTP Server Configuration Artifacts

Oracle HTTP Server is configured using several operating system files. When Oracle HTTP Server is deployed, its configuration information is placed into the following directory structure:

  • ORACLE_INSTANCE/config/OHS/OHS_NAME/

  • ORACLE_INSTANCE/config/OHS/OHS_NAME/moduleconf

The primary configuration file is httpd.conf, located in the ORACLE_INSTANCE/config/OHS/OHS_NAME. All other configuration files are invoked through this main control file.

Note:

The http.conf file has a general include directive. As a result, all files with a .conf extension in the directory moduleconf are automatically included in the configuration. Many Oracle applications, such as Oracle Portal and Oracle Forms, place their Oracle HTTP directives into files located in this directory.

9.2.5 Oracle HTTP Server Log File Locations

There are two types of log files for Oracle HTTP Server:

  • Error logs, which record server problems.

  • Access logs, which record which components and applications are being accessed, and by whom.

You can view Oracle Fusion Middleware log files using either Oracle Fusion Middleware Control or a text editor. The log files for Oracle HTTP Server are located in the following directory:

ORACLE_INSTANCE/diagnostics/logs/OHS/OHS_NAME.

The default name of a log file is ohs_name.log.

For more information about Oracle HTTP Server log files, see the Oracle Fusion Middleware Administrator's Guide for Oracle HTTP Server.

9.2.6 Oracle HTTP Server High Availability Architecture and Failover Considerations

Figure 9-2 shows two Oracle HTTP Servers, which have been placed behind a load balancer. The load balancer receives requests from users and forwards them on to the connected Oracle HTTP Servers. In the example, the Load Balancer receives the requests on the standard HTTP/HTTPS ports (80/443), however, it then passes them on to the Oracle HTTP Servers using completely different ports. This 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 9-2 Oracle HTTP Server High Availability Architecture

Description of Figure 9-2 follows
Description of "Figure 9-2 Oracle HTTP Server High Availability Architecture"

Figure 9-2 also shows how Oracle HTTP Server distribute requests to Web Logic Managed Servers. For High Availability, it is assumed that each pair of components (Oracle HTTP Server and Web Logic Managed Servers) exist on different hosts.

This architecture could simply be separated across two servers. Alternatively, in more complex implementations, each component could be located on a completely separate server.

9.2.7 Oracle HTTP Server Protection from Failures and Expected Behaviors

Oracle HTTP Servers failures can be divided into two categories: process failures and node failures. Individual operating system process may fail, where as node failures are involve the entire host upon which the Oracle HTTP Server failing.

Process Failure

The Oracle HTTP Server processes are protected by the Oracle Process Manager and Notification system (OPMN). If an Oracle HTTP Server process fails, OPMN automatically restarts the process.

Node Failure

If an entire node fails, the load balancer or Oracle Web Cache, 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 allows redirected requests access to the same state information.

Database Failure

Database failures are only likely to be an issue where 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 only fails over select statements, and package variables are lost.

9.2.8 Oracle HTTP Server Cluster-Wide Configuration Changes

Oracle HTTP Servers are not deployed in a clustered framework. The Oracle HTTP server configuration is file-based, so changes made to one Oracle HTTP Server must be manually copied to other Oracle HTTP Servers in the configuration. This also applies to static HTML files stored in the htdocs directory.

9.2.9 Configuring Oracle HTTP Server for High Availability

This section describes the prerequisites and procedures for configuring an example high availability deployment of Oracle HTTP Server.

9.2.9.1 Prerequisites

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

9.2.9.1.1 Load Balancer

In Order to distribute requests against Oracle HTTP Servers a load balancer is required. This can either be an external load balancer or Oracle Web Cache. If using an external load balancer, it should have the following features:

  • Virtual server name and port configuration

  • Process failure detection

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

  • SSL Protocol Conversion (if required)

Configuring Virtual Server Names and Ports for the Load Balancer

For each application, such as myapp.mycompany.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 are terminated at the load balancer and passed 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.

For this example configuration, it is assumed that a the load balancer has been configured as:

  • Virtual Host: Myapp.mycompany.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, it is important to know the port numbers used by these services, and to ensure that the same port number is not used by two services on your host.

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.2.9.1.2 Associating Oracle HTTP Server with a WebLogic Domain

If registering Oracle HTTP Server with a WebLogic Administration Server, that server must be up and running and configured to accept JMX requests.

9.2.9.2 Install Oracle HTTP Server on WEBHOST1

Start the Oracle Universal Installer for Oracle Fusion Middleware Web Tier and Plug-ins 11g (11.1.1.1.0) DVD installation as follows:

For UNIX, run the following command: runInstaller

For Windows, double-click setup.exe

  1. In the Welcome screen, click Next.

  2. In the Select Install Type screen, select Install and Configure, and click Next.

  3. In the Specify Installation Location screen, enter the following installation location:

    /u01/app/oracle/product/FMW/Web1

  4. In the Prerequisite Checks screen, click Next.

  5. In the Configure Components screen, select Oracle HTTP Server and click Next

    Note:

    If this installation is to be associated with a WebLogic Domain, select the Associate Selected Components with WebLogic Domain check box.

    If this installation is not to be associated with a WebLogic domain deselect the Associate Selected Components with WebLogic Domain check box. If required, this association can be created after the installation.

  6. In the Specify WebLogic Domain Details screen (optional), enter the following values:

    • Domain Host Name: The name of the server hosting the WebLogic administration server, for example, wladmin.mycompany.com.

    • Domain Port Number: The WebLogic Administration server Port, for example, 7001.

    • Username: The WebLogic Administration Server user, for example WebLogic.

    • Password: Administration Server password

  7. Click Next.

  8. In the Specify Component Details screen, enter the following values:

    • Instance Home Location: /u01/app/oracle/admin/web1

    • AS Instance Name: web1

    • OHS Component Name: ohs1

    • WebCache Component Name: webcache1

  9. Click Next.

  10. In the Web Cache Administrator Password screen, specify the password for your Web Cache administrator.

    Valid passwords are 5 to 30 characters long, must begin with an alphabetic character, use only alphanumeric, underscore (_), dollar ($) or pound (#) characters and include at least one number.

  11. Click Next.

  12. In the Specify Web Tier Port Details screen, create a file with the following entries:

    • [OHS]#: The http_main port for the OHS component.

    • OHS Port = 7777

    Save the file and specify the name of the file in the File name field after highlighting Specify Ports using the Configuration file option.

    Note:

    It is not mandatory to have the same port numbers on all Web tier instances, however, it is recommended. For this configuration example, it is assumed.
  13. Click Next.

  14. In the Configuration Summary screen, review the selections to ensure that they are correct. If they are not correct, click Back to modify selections on previous screens.

  15. Click Install.

  16. In the Configuration screen, multiple configuration assistants are launched in succession. When this process completes, click Next.

    The Installation Complete screen appears.

  17. Click Finish.

Validate the Installation

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

http://webhost1:7777/

9.2.9.2.1 Configure Virtual Host(s)

For each virtual host or site name used add an entry to the Oracle HTTP server configuration. Create a file called virtual_hosts.conf file located in the ORACLE_INSTANCE/config/OHS/ohs_component_name /moduleconf directory as follows:

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

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

NameVirtualHost *:7777
<VirtualHost *:7777>
    ServerName https://myapp.mycompany.com:443
    RewriteEngine On
    RewriteOptions inherit
    UseCanonicalName On
</VirtualHost>
9.2.9.2.2 Configure mod_wl_ohs

After installing and configuring Oracle HTTP Server, link it to any defined WebLogic managed servers by editing the mod_wl_ohs.conf file located in ORACLE_INSTANCE/config/OHS/ohs_name directory.

The following is an example of mod_wl_ohs.conf entries:

LoadModule weblogic_module ORACLE_HOME/ohs/modules/mod_wl_22.so
 
<IfModule mod_weblogic.c>
      WebLogicCluster apphost1.mycompany.com:7050, apphost2.mycompany.com:7050
      Debug ON
      WLLogFile /u01/app/oracle/admin/WL1/logs/mod_wl_ohs.log
      MatchExpression *.jsp
 </IfModule>
  
<Location /weblogic>
  SetHandler weblogic-handler
  WebLogicCluster apphost1.mycompany.com:7050,apphost2.com:7050
  Debug ERR
  WLLogFile /u01/app/oracle/admin/WL1/logs/mod_wl_ohs.log
  DefaultFileName index.jsp
</Location>

Note:

If using SSL termination AND routing 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.mycompany.com:7050,apphost2.com:7050
  WLProxySSL On
  WLProxySSLPassThrough ON
  Debug ERR 
  WLLogFile /u01/app/oracle/admin/WL1/logs/mod_wl_ohs.log
  DefaultFileName index.jsp
</Location>

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

9.2.9.2.3 Restart Oracle HTTP Server

Restart the Oracle HTTP Server using the following commands:

opmnctl restartproc process-type=OHS
9.2.9.2.4 Validate the Oracle HTTP Server Configuration

Validate the configuration using the following URLs:

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

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

9.2.9.3 Install Oracle HTTP Server on WEBHOST2

On WEBHOST2, perform the steps from Section 9.2.9.2, "Install Oracle HTTP Server on WEBHOST1."

Validate the Installation

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

http://webhost2:7777/

9.2.9.3.1 Configure 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. This is located in the ORACLE_INSTANCE/config/OHS/ohs_component_name/moduleconf directory.

9.2.9.3.2 Configure mod_wl_ohs

After installing and configuring the Oracle HTTP Server, link it to any defined WebLogic Server instances by copying the file mod_wl_ohs.conf file located in the ORACLE_INSTANCE/config/OHS/ohs_component_name directory from WEBHOST1.

9.2.9.3.3 Restart Oracle HTTP Server

Restart the HTTP Server using the following commands:

opmnctl restartproc process-type=OHS
9.2.9.3.4 Validate the Oracle HTTP Server Configuration

Validate the configuration using the following URLs:

http://myapp.mycompany.com/

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

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

9.3 Oracle Web Cache and High Availability Concepts

Oracle Web Cache is a content-aware server accelerator, or reverse proxy, for the Web tier that improves the performance, scalability, and availability of Web sites that run on Oracle HTTP Server.Oracle Web Cache is the primary caching mechanism provided with Oracle Fusion Middleware. Caching improves the performance, scalability, and availability of Web sites that run on Oracle Application Server by storing frequently accessed URLs in memory.By storing frequently accessed URLs in memory, Oracle Web Cache eliminates the need to repeatedly process requests for those URLs on the application Web server and database tiers. Unlike legacy proxies that handle only static objects, Oracle Web Cache caches both static and dynamically generated content from one or more application Web servers. Because Oracle Web Cache is able to cache more content than legacy proxies, it provides optimal performance by greatly reducing the load on application Web server and database tiers. As an external cache, Oracle Web Cache is also an order of magnitude faster than object caches that run within the application tier.

9.3.1 Oracle Web Cache Single-Node Characteristics

Oracle Web Cache is fully compliant with HTTP 1.0 and 1.1 specifications. Therefore, it can accelerate Web sites that are hosted by any standard web servers, such as Apache and IIS. In Oracle Fusion Middleware, Oracle Web Cache resides in front of one or more instances of Oracle HTTP Server. Responses to browser based HTTP requests are directed to the Oracle HTTP Server instance and transmitted through Oracle Web Cache. The Oracle Web Cache instance can handle any Web content transmitted with standard HTTP protocol.

A reverse proxy appears to be the content server to clients but internally retrieves its objects from other backend origin servers as a proxy. A reverse proxy acts as a gateway to the origin servers. It relays requests from outside the firewall to origin servers behind the firewall, and delivers retrieved content back to the client.

Figure 9-3 shows an overview of how reverse proxy Web caching works. Oracle Web Cache has an IP address of 144.25.190.241 and the application Web server has an IP address of 144.25.190.242.

The steps for browser interaction with Oracle Web Cache are as follows:

  1. A browser sends a request to a Web site named www.company.com:80.

    This request in turn generates a request to Domain Name System (DNS) for the IP address of the Web site.

  2. DNS returns the IP address of the load balancer for the site, that is, 144.25.190.240.

  3. The browser sends the request for a Web page to the load balancer. In turn, the load balancer sends the request to Oracle Web Cache server 144.25.190.241.

  4. If the requested content is in its cache, then Oracle Web Cache sends the content directly to the browser. This is called a cache hit.

  5. If Oracle Web Cache does not have the requested content or the content is stale or invalid, it hands the request off to application Web server 144.25.190.242. This is called a cache miss.

  6. The application Web server sends the content to Oracle Web Cache.

  7. Oracle Web Cache sends the content to the client and stores a copy of the page in cache.

    A page stored in the cache is removed when it becomes invalid or outdated.

Figure 9-3 Web Server Acceleration

Web Server Acceleration
Description of "Figure 9-3 Web Server Acceleration"

9.3.1.1 Oracle Web Cache Component Characteristics

An Oracle Web Cache system component consists of two performance-oriented native processes, the cache server process and the admin server process. The cache server process handles client requests serving content back to the client. The admin server process provides administration, configuration, and monitoring capabilities.

9.3.1.2 Oracle Web Cache Process Monitoring

You manage the cache and admin server processes withOracle Process Manager and Notification Server (OPMN) using the Fusion Middleware Control, Oracle Web Cache Manager, or the opmnctl utility, as described in the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.

9.3.1.3 Oracle Web Cache Startup and Shutdown Lifecycle

OPMN is responsible for the direct start, stop, restart, and monitoring of the cache server and admin server processes. Anytime the Oracle Web Cache configuration is statically modified, you must stop and restart Oracle Web Cache processes:

The executable for the cache process is webcached, and the executable for the admin server process is webcachea. These executables reside in the following directories:

(UNIX) ORACLE_HOME/webache/bin
(Windows) ORACLE_HOME\bin

When you stop Oracle Web Cache, all objects are cleared from the cache. In addition, all statistics are cleared.

After you configure Oracle Web Cache, restart Oracle Web Cache. In addition, if you change the administrator password, restart the admin server.

To restart Oracle Web Cache, use one of the following tools:

  • Use Fusion Middleware Control or the opmnctl command-line utility to restart the cache or admin server processes.

  • Use Oracle Web Cache Manager to restart the cache server process.

You must restart both the cache server and admin server processes if you modified one of the following configuration settings:

  • Administration port properties

  • Trusted subnets

  • User and group ID information

See the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache for further information about starting and stopping Oracle Web Cache.

9.3.1.4 Oracle Web Cache Request Flow

Figure 9-4 shows further details of the request flow within the Oracle Web Cache tier.

Figure 9-4 Request Flow to Oracle Web Cache within the Web Tier

Request Flow to Oracle Web Cache
Description of "Figure 9-4 Request Flow to Oracle Web Cache within the Web Tier"

As shown in Figure 9-4, the following occurs within the Oracle Web Cache tier:

  1. The incoming browser request is analyzed for the correct HTTP format.

  2. The browser request is then further analyzed to determine if it is in HTTPS format:

    1. If the browser request is in HTTPS format, Oracle Web Cache decrypts SSL.

    2. If the browser request is not in HTTPS format, Oracle Web Cache parses the request.

  3. After the request is understood, it is filtered by a set of prescribed filtering rules.

  4. A cache lookup is performed to see if the HTTP request was sent previously and is present in the cache.

    If the request is present in the cache, a cache hit, the request is compressed and the content is sent directly to the browser.

    If the request is not present in the cache, a cache miss, then either:

    1. The request is sent directly to a single origin server.

    2. The request is sent to load-balanced origin servers.

Each load balanced origin server pings each Oracle Web Cache server on a periodic basis to check the status of the cache. The load balancer distributes any incoming requests among cache cluster members. If Oracle Web Cache does not have the requested content or the content is stale or invalid, it hands the request off to the application Web server. The application Web server sends the content to Oracle Web Cache. Oracle Web Cache sends the content to the client and stores a copy of the page in cache.

The proxy server is placed in a less secure zone, the Demilitarized Zone (DMZ), instead of the origin server.

Caching rules determine which objects are cached. When you establish a caching rule for a particular URL, those objects contained within the URL are not cached until there is a client request for them. When a client first requests an object, Oracle Web Cache sends the request to the origin server. This request is a cache miss. Because this URL has an associated caching rule, Oracle Web Cache caches the object for subsequent requests. When Oracle Web Cache receives a second request for the same object, Oracle Web Cache serves the object from its cache to the client. This request is a cache hit.

When you stop Oracle Web Cache, the cache clears all objects. In addition, Oracle Web Cache clears and resets statistics.

9.3.1.5 Oracle Web Cache Configuration Artifacts

Oracle stores configuration for Oracle Web Cache in the webcache.xml file, located in the following directories:

(UNIX) ORACLE_INSTANCE/instance_name/config/WebCache/webcache_name
(Windows) ORACLE_INSTANCE\instance_name\config\WebCache\webcache_name

Oracle offers two tools for managing the configuration files.

  • Fusion Middleware Control.

  • Oracle Web Cache Manager.

Use these tools rather than edit the webcache.xml configuration file, to perform all administrative tasks unless a specific procedure requires you to edit a file. Editing a file may cause the settings to be inconsistent and generate problems.

For further information about these tools, see the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.

9.3.1.6 Log File Locations

Oracle Web Cache records event and error information in event logs. An event log entry can help you determine what objects have been inserted in the cache and alert you to any cache-related issues. Oracle Web Cache stores every request internally and then writes them in bulk at the end of the request. Request-based logging groups all the requests together.

By default, the event log has a file name of event_log for the Oracle Web Cache and Oracle Diagnostic Logging (ODL) text formats and log.xml for the ODL XML format.

Oracle Web Cache records information about the received HTTP requests in access logs. By default, the access log has a file name of access_log.

By default, Oracle Web Cache stores logs files in the following directories:

(UNIX) ORACLE_INSTANCE/diagnostics/logs/WebCache/<webcache_name>
(Windows) ORACLE_INSTANCE\diagnostics\logs\WebCache\<webcache_name>

For further information about these tools, see the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.

9.3.2 Oracle Web Cache High Availability Considerations

The following sections describe the high availability solutions available with Oracle Web Cache:

9.3.2.1 Oracle Web Cache Stateless Load Balancing

Most Web sites are served by multiple origin servers running on multiple computers that share the load of HTTP and HTTPS requests. All requests that Oracle Web Cache cannot serve are passed to the origin servers. Oracle Web Cache balances the load among origin servers by determining the percentage of the available capacity, the weighted available capacity of each origin server. Oracle Web Cache sends a request to the origin server with the most weighted available capacity. The weighted available capacity is determined by the following formula:

(Capacity - Load) / Capacity

where:

  • Capacity is the maximum number of concurrent connections that the origin server can accept

  • Load is the number of connections currently in use

If the weighted available capacity is equal for multiple origin servers, Oracle Web Cache sends requests to the origin servers using round robin. With round robin, the first origin server in the list of configured servers receives the request, then the second origin server receives the second request. If the weighted available capacity is not equal, Oracle Web Cache sends the request to the origin server with the most available capacity.

If the load of origin servers is equivalent, Oracle Web Cache continues to use round robin, even when capacity is not equal for origin servers. Therefore, it is possible to see an even distribution of requests to origin server when the capacities are not configured to be the same.

To configure load balancing for a site, set the capacity of each origin server, and create one site-to-server mapping that maps all the applicable origin servers to the site.

Figure 9-5 shows two sites, www.company.com:80 and www.server.com:80. The site www.company.com:80 is supported by application Web servers company-host1 and company-host2 with capacities of 50 each. The site www.server.com:80 is supported by application Web servers server-host1, server-host2, and server-host3 with capacities of 150, 50, and 50, respectively.

Figure 9-5 Load Balancing

Description of Figure 9-5 follows
Description of "Figure 9-5 Load Balancing"

Assuming all application Web servers have an initial load of 0, the requests to www.company.com:80 and www.server.com:80 will be distributed in the following manner:

  • The requests to www.company.com:80 are distributed between the two origin servers using round robin.

    The requests to company-host1 and company-host2 will be distributed between the two origin servers so that they maintain an equal load. The first request is sent to company-host1. The second request is sent to company-host2 if company-host1 is still processing the first request. The third and subsequent requests are sent to the origin server that has the highest weighted available capacity.

    When the capacities are equal, Oracle Web Cache uses round robin to distribute requests.

  • The requests to www.server.com:80 are distributed between three origin servers using the weighted available capacity percentage.

    The first request to www.server.com:80 is sent to server-host1, because it is the first in the configured list. The second request is sent to server2-host, because server-host1 is still processing the first request and has a weighted available capacity of 99.3 percent and server-host2 has a weighted available capacity of 100 percent. The third request is sent to server-host3 because server2-host is still processing a request and has a weighted available capacity of 98 percent and server3-host has a weighted available capacity of 100 percent. The fourth request is sent to server-host1 because server-host2 and server3-host are still processing requests and have weighted available capacities of 98 percent. The fifth request is sent to server-host1 because its weighted available capacity is 98.6 percent, which is still greater than server-host2 and server-host3, respectively.

    When the capacities and loads are not equal, Oracle Web Cache uses the weighted available capacity to distribute requests. If requests were processed before new requests came in, then it is possible for all three origin servers to have loads of 0. In this case, Oracle Web Cache uses round robin.

See the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache for instructions on specifying capacity and creating site-to-server mappings.

9.3.2.2 Oracle Web Cache Backend Failover

After a specified number of continuous request failures, Oracle Web Cache considers an origin server as failed. When an origin server fails, Oracle Web Cache automatically distributes the load over the remaining origin servers and polls the failed origin server for its current up or down status until it is back online. Existing requests to the failed origin server result in errors. However, new requests are directed to the other origin servers. When the failed server returns to operation, Oracle Web Cache includes it in its weighted available capacity to load balance requests.

The failure feature is shown in Figure 9-6. An outage of server-host3, which had a capacity of 50, results in 75 percent of requests being distributed to server-host1 and 25 percent request being distributed to server-host2.

See the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache for instructions on specifying the failover threshold.

9.3.2.3 Oracle Web Cache Session Binding

You can configure Oracle Web Cache to support session binding, whereby a user session for a particular site is bound to an origin server in order to maintain state for a period of time. To use this feature, the origin server itself must maintain state; that is, it must be stateful.

If a request is forwarded to an origin server for an object requiring session binding, the origin server creates the user session by including the session information to clients through Oracle Web Cache in the form of a session cookie, or an embedded URL parameter. Oracle Web Cache does not process the value of the parameter or cookie; it simply passes the information back to the client browser. When a client includes the session information in a subsequent request, Oracle Web Cache forwards the request to the origin server that originally created the user session. Oracle Web Cache binds the user session to that particular origin server.

Figure 9-7 shows how Oracle Web Cache supports objects that use session binding.

Figure 9-7 Session Binding

Description of Figure 9-7 follows
Description of "Figure 9-7 Session Binding"

The steps for how session binding works for requests are as follows:

  1. When a request first comes in, Oracle Web Cache uses load balancing to determine to which origin server the request is forwarded. In this example, application Web server www.server2.com is selected.

  2. If the requested object requires session binding, the origin server sends the session information back to the client through Oracle Web Cache in the form of a cookie or an embedded URL parameter.

  3. Oracle Web Cache sends subsequent requests for the session to the origin server that established the session, bypassing load balancing. In this example, application Web server www.server2.com handles the subsequent requests.

If you configure a cache cluster, when you configure session binding, do not select the Internal-Tracking mechanism option, as it does not work for cache clusters. The other mechanisms work for cache clusters.

See Section 9.3.2.3, "Oracle Web Cache Session Binding" for instructions on configuring session binding.

9.3.2.4 Oracle Web Cache Cluster-Wide Configuration Changes

Oracle Web Cache provides cluster-wide capabilities through cache clusters. In a cache cluster, multiple system components of Oracle Web Cache operate as one logical cache. This one logical cache is referred to as the cache cluster member. The cache cluster members communicate with one another to request cacheable content that is cached by another cache cluster member and to detect when a cache cluster member fails.

Figure 9-8 shows an Oracle Web Cache cluster that contains three cache cluster members. As the figure shows, the cluster members communicate with one another as well as with the application Web servers and with the clients.

Figure 9-8 Oracle Web Cache Cluster Architecture

Description of Figure 9-8 follows
Description of "Figure 9-8 Oracle Web Cache Cluster Architecture"

Oracle Web Cache uses the relative capacity of each cache instance to distribute the cached content among the cache cluster members. In effect, it assigns a cache cluster member to be the owner of a particular object. This content is called owned content.

In addition to the owned content, Oracle Web Cache stores popular objects in the cache of each cluster member. These objects are known as on-demand content. By storing the on-demand content, Oracle Web Cache responds to requests for those objects quickly and decreases the number of cache misses. Fewer requests are sent to the application Web server. The result is improved performance.

A cache cluster uses one configuration that is synchronize to all cluster members. The configuration contains general information, such as security, session information, and caching rules, which is the same for all cluster members. It also contains cache-specific information, such as capacity, administration and other ports, resource limits, and log files, for each cluster member.

Each member must be authenticated before it is added to the cache cluster. The authentication requires that the administration username and password of the Oracle Web Cache instance to be added be the same as the administration username and password of the cluster.

When you add a cache to the cluster, the cache-specific information of the new cluster member is added to the configuration of the cache cluster. Then, Oracle Web Cache synchronizes the configuration to all members of the cluster. Because adding a new member changes the relative capacity of each Web cache, Oracle Web Cache uses the information about capacity to recalculate which cluster member owns which content.

When cache cluster members detect the failure of another cluster member, the remaining cache cluster members automatically take over ownership of the content of the failing member. When the cache cluster member is reachable again, Oracle Web Cache again reassigns the ownership of the content.

When you remove a Web cache from a cache cluster, the remaining cache cluster members take over ownership of the content of the removed member. In addition, the configuration information about the removed member is deleted from the configuration and the revised configuration is synchronized with the remaining cache cluster members.

See Section 9.3.3.2, "Configuring a Cache Cluster" for instructions on configuring a cache cluster.

9.3.2.5 Oracle Web Cache as a Software Load Balancer

You can configure a special mode of Oracle Web Cache that enables you to use Oracle Web Cache solely as a software load balancer of HTTP traffic. This configuration mode is useful to:

  • Manage low-volume, departmental, or test Web sites

  • Manage traffic in the DMZ between a hardware load balancer and an application using Oracle Portal or Oracle Single Sign-On

This mode does not cache any content or provide support for the following features:

  • Compression: Oracle Web Cache ignores all compression settings.

  • Request filtering: Oracle Web Cache ignores any configure request filters and rules.

  • ESI: Oracle Web Cache does not assemble ESI content.

  • Cache hierarchies: If you plan to configure two caches in a cache hierarchy, then you should not configure one of the caches as a load balancer.

You can deploy a single Oracle Web Cache server as a load balancer. However, this deployment makes the Oracle Web Cache server a single point of failure for your application. You can instead configure a cache cluster with multiple Oracle Web Cache servers in conjunction with operating system load balancing capabilities. Take note of the capacity changes mentioned earlier in this section.

In this mode, you can configure Oracle Web Cache to load balance HTTP traffic in front of an application using ESI or in front of another Oracle Web Cache. The Oracle Web Cache load balancer does not process ESI content or participate in hierarchical caching. For example, a typical Oracle Portal deployment has a built-in Oracle Web Cache used for ESI assembly. For these configurations, do not configure the Oracle Web Cache used for ESI assembly as a load balancer.

If you require other Oracle Web Cache features, such as caching or compression support, do not configure this mode. Instead, configure a hardware load balancer or operating system load balancing support, and use the load balancing feature to manage requests to origin servers.

See Section 9.3.3.3, "Configure Oracle Web Cache as a Software Load Balancer" for instructions on configuring this mode.

9.3.3 Configuring Oracle Web Cache High Availability Solutions

The following sections describe how to configure the following high availability solutions:

9.3.3.1 Configure Oracle Web Cache Session Binding

To configure session binding, you specify a set of session binding rules, and then apply them to the sites. By default, sites are configured to use a default rule. You can use the default rule or select another rule customized for the site.

If you decide to change the value of the default session binding rule, ensure all named sites currently configured with this rule require session binding. If some sites do not require session binding, leave the value of default rule, and instead specify session binding settings for the site.

To configure session binding:

  1. Navigate to the Web Cache Home page in the Fusion Middleware Control.

  2. From the Web Cache menu, select Administration and then select Session Configuration.

  3. From the Site list, select the site to create customized session-bindings.

    Select Global to specify default settings for sites and for requests which do not match any defined site. If you do not specify customized session-binding settings for a site, then you can click the Use global settings option to apply the settings you specify for Global. The default selection for the Global selection is the Disable session binding. You change the default setting by selecting Global from the Site list and selecting on of the other session-binding selections.

  4. Create a session definition in the Session Definition table.

    - Use global settings: Select this option if you want to apply the session-binding settings you configured for the Global selection from the Site list.

    By default, Oracle Web Cache disables session binding for all requests. The default selection for Global is the Disable session binding option. When you first create a site, it is set by default to use the global session binding settings

    - Disable session binding: Select this option to disable session binding. This selection is the default for the Global site. You change the default setting by selecting Global from the Site list and selecting on of the other session-binding selections.

    - Cookie based session binding with any Set-Cookie: Select this option if the client supports cookies and your application server uses one or more cookies for session state. Oracle Web Cache uses its own cookie to track a session. This cookie, which contains routing information, is maintained between Oracle Web Cache and the client browser. The client to application server binding will be initiated by the first cookie that the application server sends to the client.

    - Bind using a session: Select this option to enable binding for a specific session, and then perform the following steps:

    1. From the Session Name list, select a session to enable binding for a specific session.

    2. From the Session Binding Mechanism list, select one of the following binding mechanisms for the selected session definition:

    3. Select one of the following binding mechanisms for the selected session definition:

      - Cookie Based: Select if the client supports cookies. Oracle Web Cache uses its own cookie to track a session. This cookie, which contains routing information, is maintained between Oracle Web Cache and the client browser.

      - Session Binding IAS: Select if the application is based on OC4J. Oracle Web Cache forwards routing information with each request to OC4J through Oracle HTTP Server.

      - Internal-Tracking: Select if the client does not support cookies and the application is not based on Oracle HTTP Server and OC4J. This option is intended for backward compatibility with earlier releases of Oracle Web Cache. Oracle Web Cache maintains an in-memory routing table, of which each entry maps a session ID to an origin server. The routing table is not shared among cluster nodes. If you select this option and you have a cache cluster configuration, then you must also bind at the load balancer layer.

  5. Click Apply to submit changes.

  6. Restart Oracle Web Cache.

9.3.3.2 Configuring a Cache Cluster

To configure a cache cluster, you configure two or more Oracle Web Cache instances as cache cluster members, and specify properties for the cluster.

A cache cluster uses one configuration that is synchronized from the current cache (the cache to which your client browser is connected) to all cluster members. The configuration contains settings that are the same for all cluster members as well as cache-specific settings for each cluster member.

This section contains the following topics to aid you in configuring a cache cluster in a environment in which all the caches are associated with the same Oracle WebLogic Server. These instruction explain how to configure a cluster using Fusion Middleware Control, which requires all the cache members to use the same Oracle WebLogic Server:

In addition, see the following information about configuring clusters:

If you have want to configure a cache cluster for a configuration in which the caches are associated with different Oracle WebLogic Servers, follow the instructions in Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.

9.3.3.2.1 Configuration Prerequisites

Because a cache cluster contains two or more instances of Oracle Web Cache, you must have two or more instances of Oracle Web Cache installed on one or more nodes before you configure a cache cluster. The instances must be the same version of Oracle Web Cache. In addition, the respective passwords for the Oracle Web Cache administrator, and the invalidator user, invalidator, must be the same across the cluster members. If they are different, you must connect to the cache's admin server and modify the administration password.

9.3.3.2.2 Understanding Failover Threshold and Capacity Settings

To ease with configuration, take the time to understand the following key configuration settings for a cache cluster and its members:

Failover Threshold for the Cache Cluster

You set the failover threshold when you configure cache cluster properties. This setting reflects the number of allowed consecutive request failures before Oracle Web Cache considers another cache cluster member to have failed. In other words, Oracle Web Cache consecutively retries a failed member for certain number of times, before considering the cache-member as down. The number of times Oracle Web Cache is allowed to retry is termed as failover threshold.

Oracle Web Cache considers a request to another cache cluster member to have failed if:

  • There are any network errors

  • The HTTP response status code is either less than 100, or is one of the following: 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, or 504 Gateway Timeout.

For each failed request, Oracle Web Cache increments the failure counter for that cluster member. This counter is kept separately by each cluster member. When a request is successfully processed by a cluster member, Oracle Web Cache resets the failure counter.

When the failover threshold is met, Oracle Web Cache considers the cache cluster member to have failed. Oracle Web Cache recalculates the relative capacity of the remaining cache cluster members. It then reassigns ownership of cache content.

When a cache cluster member is down, Oracle Web Cache starts polling the cache cluster member. It does this by sending requests to the ping URL you specify. When Oracle Web Cache receives a success response from the cache cluster member, it considers that cache cluster member to be up again. It recalculates the relative capacity of the cache cluster members and it reassigns ownership of cache content.

Capacity for Cache Cluster Members

When you configure a cache cluster member, you specify capacity for that member.

Oracle Web Cache uses capacity in two different ways:

  • As the absolute capacity for the number of concurrent incoming connections to this cache cluster member from all other cache cluster members.

    The connections are used to receive requests for owned content from other cache cluster members. The number of connections are divided among the other cluster members. For example, in a three-cache cluster, if the capacity of Cache_A is 50, Cache_B can open 25 connections to Cache_A and Cache_C can open 25 connections to Cache_A.

    More connections are used when another cache cluster member contains little or no data in its cache, such as when it is initially started, when it recovers from a failure, or after invalidation. During this time, the cluster member sends many of the requests to its peers, the owners of the content. In most cases, these requests are served more quickly than requests to the origin server. Having a higher number of connections increases performance during this time and shortens the time it takes to fully load the cache. After a cache is fully loaded, fewer of the connections are used. There is no overhead for unused connections.

  • As the relative capacity of the cache cluster member.

    The capacity of a cache cluster member is weighted against the total capacity of all active cache cluster members. When you set the capacity, Oracle Web Cache assigns a percentage of the ownership array to the cluster member, indicating how much of the cached content will be owned by the cluster member. The percentage is calculated using the following formula:

    cluster_member_capacity / total_capacity_of_all_active_cluster_members
    

    For example, if cache cluster member Cache_A has a capacity of 100 and cache cluster member Cache_B has a capacity of 300, for a total capacity of 400, Cache_A is assigned 25 percent of the ownership array and Cache_B is assigned 75 percent of the ownership array. That means that Cache_A owns 25 percent of the cached content.

    Note that in calculating the relative capacity, Oracle Web Cache considers the capacity of active cluster members; it does not consider the capacity of cluster members that it has determined to have failed.

Set the initial capacity for each cache cluster member to 10 percent of the Maximum Incoming Connections setting.

Once you have a better idea of an application's capacity needs and hit rates, fine tune the capacity. If these two assumptions apply to your cache cluster, then apply the following formula to determine the capacity for each cluster member:

  1. Incoming traffic will be distributed equally to all the cache cluster members.

  2. Ownership of content will be distributed equally among all the cache cluster members.

In the following formula, pick the highest value between the default value or the max_incoming_connections formula:

max(default_value, (max_incoming_connections * (cacheable_misses%/100) * (number_of_caches - 1) / number_of_caches))

In the formula:

  • default_value is one of the following:

    • 100 for production environments

    • 30 for test environments

    • 0 for invalidation-only clusters

    When the capacity increases, the number of file descriptors needed by Oracle Web Cache also increases.

  • max_incoming_connections is the Maximum Incoming Connections setting from the Resource Limits page of Fusion Middleware Control.

  • cacheable_misses% is the percentage of requests for cacheable objects that were not served directly by Oracle Web Cache, but were served by Oracle Web Cache after it fetched the content from the origin server.

    You can find the Cacheable Misses setting in the Web Cache Statistics page of Fusion Middleware Control.

For example, assume a cache cluster with four members. If Oracle Web Cache is operating at 1500 maximum incoming connections, with a 30 percent cacheable miss rate, then the equation to calculate capacity for this configuration looks like the following:

(1500 * (30/100) * (4 - 1) / 4

The equation calculates to 337.5. You would round up to 338, which is the capacity you would then enter for each cache cluster member.

1500 * .3 * 3 / 4 = 337.5

If you assign a capacity of 0 to a cluster member, that cluster member will not receive requests from other cluster members. However, that cluster member will forward requests to other cluster members, the owners of the content. If you assign a capacity of 0 to all cluster members, no requests will be forwarded between cluster members. Even when capacity is set to 0, you can still synchronize the configuration and Oracle Web Cache can automatically propagate invalidation requests to cluster members.

9.3.3.2.3 Task 1: Add Caches to the Cluster and Configure Properties

Before you add a cache to the cluster, ensure the conditions described in Section 9.3.3.2.1, "Configuration Prerequisites" are met.

To add cache members to a cluster:

  1. Navigate to the Web Cache Home page in the Fusion Middleware Control for one of the Oracle Web Cache instances.

  2. From the Web Cache menu, select Administration and then select Cluster.

  3. For each cache member you want to add:

    1. Click Add.

    2. In the Component field, enter the name of the cache member.

      The Capacity field is auto-filled with a default value. You can modify this value. See Section 9.3.3.2.2, "Understanding Failover Threshold and Capacity Settings" for more information about capacity.

  4. In the Failover Threshold field, enter the number of allowed consecutive request failures before Oracle Web Cache considers another cache cluster member to have failed.

    The default is five failures.

    See Section 9.3.3.2.2, "Understanding Failover Threshold and Capacity Settings" for further information about this field.

  5. In the Ping URL field, enter the URL that cache cluster members will use to attempt to contact a cache cluster member that has reached its failover threshold.

    Use a URL that is cacheable and that you can guarantee is stored in each cache. The default is _oracle_http_server_webcache_static_.html, which is stored in the cache.

  6. In the Ping Frequency field, enter the time, in seconds, between attempts by a cluster member to reach the failed cluster member.

    The default, 10 seconds, is a reasonable interval for most situations.

  7. Click Apply.

9.3.3.2.4 Task 2: Enable Tracking of Session Binding

In a cache cluster, all cache cluster members must be able to determine which origin server established the session, although the request was routed originally through only one cache cluster member.

For the Oracle Web Cache you established properties for in Section 9.3.3.2.3, "Task 1: Add Caches to the Cluster and Configure Properties," configure session binding with a session binding mechanism. Do not use the Internal-Tracking option, as it does not work for cache clusters.

To configure session binding, see Section 9.3.3.1, "Configure Oracle Web Cache Session Binding."

9.3.3.2.5 Task 3: Synchronize Configuration to Cluster Members

When you modify the cluster and apply changes, Oracle Web Cache adds the cache-specific information from the new cache cluster members to the configuration. For those changes to take affect in all cluster members, you must synchronize the configuration and restart the cluster members.

To synchronize configuration from a newly-added cache member to the other caches in the cluster:

  1. Navigate to the Web Cache Home page in the Fusion Middleware Control for the Oracle Web Cache you established properties for in Section 9.3.3.2.3, "Task 1: Add Caches to the Cluster and Configure Properties."

  2. From the Web Cache menu, select Administration and then select Cluster.

  3. Select the other cache members in the cluster, click Synchronize.

  4. Select all the cache members, select an interval for staggering the time that the operation begins on the cache sand click Start Up.

The cache cluster is ready to use.

9.3.3.2.6 Removing a Cache Member from a Cluster

To remove a cache-member from a cluster, you must ensure that remaining cluster members no longer include that cache in cluster, and that the removed cache no longer considers itself to be part of the cluster.

To remove a cache from a cluster in Oracle Web Cache Manager:

  1. Navigate to the Web Cache Home page in the Fusion Middleware Control for one of the Oracle Web Cache instances, but not the cache that you want to remove from the cluster.

  2. From the Web Cache menu, select Administration and then select Cluster.

  3. Select the cache you want to remove and click Delete.

  4. Select the other cache members in the cluster, click Synchronize.

  5. With the other caches still selected, click Restart.

    All remaining caches in the cluster no longer consider the removed cache to be part of the cluster. However, the removed cache still considers itself to be part of the cluster. You will remedy this situation in the next steps.

  6. Navigate to the Web Cache Home page in the Fusion Middleware Control of the cache you removed from the cluster.

  7. From the Web Cache menu, select Administration and then select Cluster.

  8. Select any cache except the current one and click Delete. Repeat until only the current cache remains in the Cluster Members list.

  9. Click Restart.

9.3.3.2.7 Configuring Administration and Invalidation-Only Clusters

You can configure a cluster that supports synchronizing the configuration and invalidation requests across all cache cluster members, but that does not forward requests between cache cluster members. That is, in processing requests, each cluster member acts as an individual cache and does not request objects from its peer cluster members. However, configuration changes and invalidation requests can be synchronized to cluster members.

You can use this configuration to simplify administration of many caches. It may be needed in a cluster where members are separated by a firewall. For example, you can have a cluster where two caches are located on either side of a firewall that separates the intranet from Internet. (The network settings of such a setup—of sending Internet traffic to one cache and intranet traffic to another—is beyond the scope of this document.)

To manage these caches as a cluster and avoid sharing contents between the caches, take the following steps:

  1. Create a cluster and add members to it as discussed in Section 9.3.3.2.3, "Task 1: Add Caches to the Cluster and Configure Properties" and Section 9.3.3.2.4, "Task 2: Enable Tracking of Session Binding," with the following exceptions:

    • For each cluster member, set the capacity to 0.

    • In the Cluster Properties section, select option Invalidation requests sent to any cluster member will be propagated to all cluster members.

  2. Synchronize the configuration to all cluster members, as described in Section 9.3.3.2.5, "Task 3: Synchronize Configuration to Cluster Members."

9.3.3.3 Configure Oracle Web Cache as a Software Load Balancer

To configure a single Oracle Web Cache server as a software load balancer:

  1. Use a text editor to open webcache.xml, located in:

    (UNIX) ORACLE_INSTANCE/<instance_name>/config/WebCache/<webcache_name>
    (Windows) ORACLE_INSTANCE\<instance_name>\config\WebCache\<webcache_name>
    
  2. Locate the CACHE element.

  3. Add the ROUTINGONLY attribute to the CACHE element. For example:

    ...
    <CACHE WCDEBUGON="NO" CHRONOSONPERNODE="NO" CAPACITY="301" VOTES="1" 
    INSTANCENAME="instance_name" COMPONENTNAME="component_name"  ORACLEINSTANCE="instance" HOSTNAME="host" 
    ORACLEHOME="directory" NAME="web_cache_name" 
    ROUTINGONLY="YES">
    ...
    
  4. Save webcache.xml.

  5. Restart Oracle Web Cache with the following command:

    opmnctl restartproc ias-component=component_name
    

    This executable is found in the following directory:

    (UNIX) ORACLE_INSTANCE/bin
    (Windows) ORACLE_INSTANCE\bin
    
  6. Verify Oracle Web Cache is running in the load balancer mode from the Oracle Web Cache Manager by verifying the following status message appears beneath the Apply Changes and Cancel Changes buttons:

    Web Cache running in Routing Only Mode with current configuration
    

    Fusion Middleware Control Console does not provide an equivalent verification status.

  7. Configure origin servers, as described in the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.

  8. Create site definitions and map them to the origin servers, as described in the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.

  9. If your application deployment requires session stickiness, enable session binding. See Section 9.3.2.3, "Oracle Web Cache Session Binding."