3.1.1 Surge Protection

Oracle Web Cache passes requests for non-cacheable, stale, or missing objects to origin servers. To prevent an overload of requests on the origin servers, Oracle Web Cache has a surge protection feature that enables you to set a limit on the number of concurrent requests that the origin servers can handle. When the limit is reached, subsequent requests are queued. If the queue is full, then Oracle Web Cache rejects the request and serves a site busy error page to the client that initiated the request.

3.1.2 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 3-1 shows two sites, www.company.com:80 and www.server.com:80. The site www.company.com:80 is supported by application servers company-host1 and company-host2 with capacities of 50 each. The site www.server.com:80 is supported by application servers server-host1, server-host2, and server-host3 with capacities of 150, 50, and 50, respectively.

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

Oracle Web Cache distributes the requests to www.company.com:80 between the two application servers using round robin.

Oracle Web Cache distributes the requests to company-host1 and company-host2 between the two application 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 application server that has the highest weighted available capacity.

Oracle Web Cache distributes the requests to www.server.com:80 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.

If you do not require caching support and need a low-cost solution to a hardware load balancer, you can configure Oracle Web Cache solely as a software load balancer. This configuration mode is useful for managing traffic to a low-volume, departmental, or test Web site. See Section 3.4 for further information.

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

For further information about configuring the number of request failures, see Section 2.11.2.

The failover feature is shown in Figure 3-2. 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.

3.2 Overview of 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 to maintain state for a period. 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 created the user session. Oracle Web Cache binds the user session to that particular origin server.

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 server www.server2.com is selected.

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.

Oracle Web Cache sends subsequent requests for the session to the origin server that established the session, bypassing load balancing. In this example, application 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 3.6.4 for further information.

Notes:

When a session expires, Oracle Web Cache does not continue to bind the user session to the origin server. Instead, Oracle Web Cache uses load balancing to choose an origin server. To avoid pages being served past the client session expiration time, ensure that the session cookie expires before the origin server expires the client session.

If an origin server is busy, Oracle Web Cache disables session binding to that origin server.

3.3 Overview of 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 3-4 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.

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

In a cache cluster, administrators can decide whether to propagate invalidation messages to all cache cluster members or to send invalidation messages individually to cache cluster members.

Cache clusters provide the following benefits:

High availability

With or without cache clusters, Oracle Web Cache ensures that cache misses are directed to the most available, highest-performing Web server. With cache clusters, Oracle Web Cache supports failure detection and failover of caches. If a Web cache fails, other members of the cache cluster detect the failure and take over ownership of the cacheable content of the failed cluster member.

Scalability and performance

By distributing the site's content across multiple caches, more content can be cached and more client connections can be supported, expanding the capacity of your Web site.

By deploying multiples caches in a cache cluster, you make use of the processing power of more CPUs. Because multiple requests are executed in parallel, you increase the number of requests that are served concurrently.

Network bottlenecks often limit the number of requests that can be processed. Even on a node with multiple network cards, you can encounter operating system limitations. By deploying caches on separate nodes, more network bandwidth is available. Response time is improved because of the distribution of requests.

In a cache cluster, fewer requests are routed to the application Web server. Retrieving content from a cache (even if that request is routed to another cache in the cluster) is more efficient than materializing the content from the application Web server.

Reduced load on the application Web server

In a cache cluster environment, popular objects are stored in multiple caches. If a cache fails, requested cacheable objects are likely to be stored in the cache of surviving cluster members. As a result, fewer requests for cacheable objects require routing to the application Web server even when a cache fails.

When a failed cache returns to operation, it has no objects cached. In a noncluster environment with multiple independent caches, that cache must route cache misses to the application Web server. In a cache cluster environment, that cache can route cache misses to other caches in the cluster, reducing the load on the application Web server.

Cache clusters maximize system resource utilization. When each cache in a cache cluster resides on a separate node, more memory is available than for one cache on a single node. With more memory, Oracle Web Cache can cache more content, resulting in fewer requests to the application Web server.

Improved data consistency

Because Oracle Web Cache uses one set of invalidation rules for all cache cluster members and because it makes it easy to propagate invalidation requests to all cache cluster members, the cached data is more likely to be consistent across all caches in a cluster.

You can configure a cache cluster that does not support requests between cache cluster members, but allows propagating invalidation requests, as well as synchronizing configuration changes. See Section 3.6.7 for more information.

Manageability

Cache clusters are easy to manage because they use one configuration for all cache cluster members. For example, you specify one set of caching rules and one set of invalidation rules. Oracle Web Cache distributes those rules throughout the cluster by synchronizing the configuration to each cluster member.

3.4 Overview of High Availability without a Hardware Load Balancer

For environments in which a hardware load balancer is not available, you can select to configure the following options:

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 or reverse proxy to origin servers. 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.

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 cache 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 using multiple Oracle Web Cache servers 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.

For more information, see:

Section 3.8 for instructions on configuring Oracle Web Cache as a load balancer

3.4.2 Operating System Load Balancing Support

When the operating system detects a failure of one cache, automatic IP takeover is used to distribute the load to the remaining caches in the cluster configuration. Because requests are sent to the virtual IP address, not to a specific host, requests can be served even if one hosts is unreachable.

In addition, some operating systems provide load balancing for incoming requests. You can configure the operating system to balance the load of incoming requests across caches on multiple nodes.

A network load balancer does not provide all the features, such as firewall or ping URL mechanisms, that a hardware load balancer may provide, but if those needs are met, you could consider using a network load balancer.

Section 3.9 describes how to configure a network load balancer on one operating system.

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

Navigate to the Web Cache Home page in Fusion Middleware Control. See Section 2.6.2.

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

The Session Configuration page displays.

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

Select Global to specify default settings 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.

Create a session definition in the Session Definitions table. See Section 2.12.

- Use global settings: Select this option 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 origin 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/server binding is 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:

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

From the Session Binding Mechanism list, select a binding mechanism 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.

3.6 Configuring a Cache Cluster for Caches Using the Same Oracle WebLogic Server

To increase the availability and scalability of your Web site, you can configure multiple instances of Oracle Web Cache to run as members of a cache cluster. For more information about cache clusters, see Section 3.3.

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:

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 Section 3.7 to use Oracle Web Cache Manager to configure the cluster.

3.6.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, as described in Section 5.2.

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

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

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.

3.6.2.2 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 is to be owned by the cluster member. The percentage is calculated using the following formula:

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.

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

Incoming traffic is distributed equally to all the cache cluster members.

Ownership of content is 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:

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

See Section 3.6.7 for further information about invalidation-only clusters.

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 does not receive requests from other cluster members. However, that cluster member does forward requests to other cluster members, the owners of the content. If you assign a capacity of 0 to all cluster members, Oracle Web Cache does not forward requests 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.

3.6.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 3.6.1 are met.

To add cache members to a cluster with Fusion Middleware Control:

Navigate to the Web Cache Home page in Fusion Middleware Control for an Oracle Web Cache instance. See Section 2.6.2.

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

The Cluster page displays.

For each cache member you want to add:

Click Add.

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 3.6.2 for more information about capacity.

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.

In the Ping URL field, enter the URL that cache cluster members uses 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.

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.

Click Apply.

3.6.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 3.6.3, configure session binding with a session binding mechanism of Cookie Based or Session Binding IAS. Do not use the Internal-Tracking option, as it does not work for cache clusters.

To configure session binding with the Cookie-based mechanism, see Section 3.5.

3.6.5 Task 3: Synchronize the 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 with Fusion Middleware Control:

Navigate to the Web Cache Home page in Fusion Middleware Control for the Oracle Web Cache you established properties for in Section 3.6.3.

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

The Cluster page displays.

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

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

The cache cluster is ready to use.

3.6.6 Removing a Cache Member from a Cluster

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

To remove a cache from a cluster with Fusion Middleware Control:

Navigate to the Web Cache Home page in Fusion Middleware Control for an Oracle Web Cache instance, but not the cache to remove from the cluster. See Section 2.6.2.

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

The Cluster page displays.

Select the cache you want to remove and click Delete.

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

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 remedy this situation in the next steps.

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

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

The Cluster page displays with all the member of the cache.

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

Click Restart.

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

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

Synchronize the configuration to all cluster members, as described in Section 3.6.5.

3.7 Configuring a Cache Cluster for Unassociated Caches or Caches Using Different Oracle WebLogic Servers

This section contains the following topics to help you in configuring a cache cluster in a configuration in which all unassociated caches are using different Oracle WebLogic Servers. These instruction explain how to configure a cluster using Oracle Web Cache Manager.

To configure a cache cluster for a configuration in which the caches are associated with same Oracle WebLogic Server, follow the instructions in Section 3.6 to use Fusion Middleware Control to configure the cluster.

3.7.1 Task 1: Configure Cache Cluster Settings

To configure settings for a cache cluster with Oracle Web Cache Manager:

The Clustering page appears. The General Cluster Information section displays the default clusterwide values for failover and invalidation synchronization. The Cluster Members table displays the current cache (the cache to which you are connected) as the only cluster member. Oracle Web Cache ignores the cluster information if there is only one cluster member.

In the General Cluster Information section of the Clustering page, click Edit.

The Edit General Cluster Information dialog box appears.

In the Cluster Name field, enter a name for the cluster.

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.

In the Ping URL field, enter the URL that cache cluster members uses 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.

In the Ping Interval 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.

In the Propagate Invalidation field, select Yes or No to specify whether you want all invalidation requests from any cache cluster member to be synchronized with other cache cluster members.

Click Submit.

In the Cluster Members table of the Clustering page, default values are displayed for the current cache. Select the cache and click Edit Selected.

The Edit Cluster Member dialog box appears.

In the Cache Name field, enter a name for the Oracle Web Cache instance. The name must be unique from the names of other caches in the cache cluster.

By default, the Host Name field contains the host name of the node on which Oracle Web Cache is installed. Usually, you do not have to modify this field.

By default, the Oracle Home field contains the file specification for the Oracle home in which Oracle Web Cache is installed. Usually, you do not have to modify this field. Note that the combination of Host Name and Oracle Home must be unique in a cache cluster.

In the Capacity field, enter the number of concurrent incoming connections from other cache cluster members that Oracle Web Cache can sustain.

The cache is now part of the cluster and is listed in the Cluster Member table.

To add more Oracle Web Cache instances to the cache cluster, repeat Steps 2 through 8.

When you have completed adding members to the cache cluster, click Apply Changes.

Oracle Web Cache adds the cache-specific information from the new cache cluster members to the cluster configuration.

You can add more Oracle Web Cache instances to the cluster at any time by choosing Add. You can modify the settings for a cache cluster member by choosing Edit Selected. You can delete a cache cluster member, other than the current cache, by choosing Delete Selected.

3.7.3 Task 3: 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. To configure session binding in a cache cluster, you select a session binding mechanism of Cookie-based. Setting this mechanism adds a cookie that tracks session information so that it can be read by all cluster members. Oracle Web Cache includes a Set-Cookie response-header in the response so that subsequent requests from the client include the cookie. The cookie provides information so that any of the cluster members can resolve the binding regardless of which cache handled the initial request.

To configure session binding with the Cookie-based mechanism, see Section 3.5.

3.7.4 Task 4: Synchronize the 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 cache server process of the cluster members.

To synchronize the configuration to new cluster members with Oracle Web Cache Manager:

In the navigator frame, select Operations > Cache Operations.

The Cache Operations page appears. The Operation Needed column indicates the caches to which the configuration should be synchronized.

Synchronize the configuration to all cache cluster members:

Select All caches in the Operate On field.

Select an Interval of Immediate. (No other interval is allowed for synchronization.)

Click Propagate.

(Alternatively, you can synchronize the configuration to one cluster member at a time. Click Selected cache in the Operate On field, and then click Propagate.)

When the operation completes, the Operation Needed column in the Cache Operations page indicates the cluster members that must be restarted.

Stop and restart all cluster members:

Select All caches in the Operate On field.

Select an Interval to stagger the time that operation begins on the caches, and then click Restart.

(Alternatively, you can restart one cluster member at a time.) Choose Selected cache in the Operate On field and then click Restart.)

When the operation completes, the Operation Needed column in the Cache Operations page indicates that no operations are needed. The cache cluster is ready to use.

3.7.5 Removing Caches from a Cluster

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

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

Enter the URL for the Oracle Web Cache Manager of a cache in cluster, but not the cache to remove from the cluster.

In the navigator frame, select Properties > Clustering.

In the Cluster Members section of the Clustering page, select the cache you want to remove from the cluster and click Delete Selected.

In the Oracle Web Cache Manager main window, click Apply Changes.

Synchronize the change to the other remaining cache cluster members:

In the navigator frame, select Operations >Cache Operations.

Select All caches in the Operate On field.

Select an Interval of Immediate.

Click Propagate.

The change is synchronized with all the remaining cluster members, but not to the removed cluster member.

Restart all cluster members:

In the Cache Operations page, select All caches in the Operate On field.

Select an Interval to stagger the time that operation begins on the caches, and then 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. To remedy that situation, take the next steps.

Enter the URL for the Oracle Web Cache Manager of the cache you removed from the cluster.

In the navigator frame, select Properties > Clustering.

The Clustering page appears. The Cluster Members section still shows all members of the cluster.

In the Cluster Members section of the Clustering page, select each cache except the current one, and click Delete Selected. Repeat until only the current cache remains in the Cluster Members list.

In the Oracle Web Cache Manager main window, click Apply Changes.

In the navigator frame, select Operations >Cache Operations.

Select the cache and click Restart.

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

Create a cluster and add members to it as discussed in Section 3.7.1 and Section 3.7.2, with the exception noted in the following step.

For each cluster member, set the capacity to 0. (Select Properties > Clustering. Then, select a cluster member and click Edit. In the Edit Cluster Member dialog box, set the Capacity to 0.)

Synchronize the configuration to all cluster members, as described in Section 3.7.4.

3.8 Configuring Oracle Web Cache as a Software Load Balancer

For an overview of high availability without a hardware load balancer, see Section 3.4.

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

Map virtual host site definition for www.app1.company.com mapped to app1-host1 and app1-host2.

3.9 Configuring Microsoft Windows Network Load Balancing

For an overview of high availability without a hardware load balancer, see Section 3.4.

On certain Microsoft Windows platforms, you can use the Microsoft Network Load Balancing (NLB) component of the operating system instead of a hardware load balancer. NLB is part of the Microsoft clustering offerings and is available on the following platforms:

Windows 2000 Advanced Server

Windows 2000 Datacenter Server

Windows 2003 (all editions)

You configure the hosts as a cluster and you configure the operating system to provide load balancing. Then, you configure NLB for hosts running Oracle Web Cache in a cache cluster, taking the following steps for each host:

In the Cluster Parameters tab of the Network Load Balancing Properties dialog box, take the following steps:

For Primary IP Address, enter the virtual IP address to be shared by all members of the cluster.

For Subnet mask, enter the subnet mask for the virtual IP address.

For Full Internet Name, enter the full internet name for the virtual IP address.

Note the Network Address, which is a generated address.

For Multicast support, check enabled.

Optionally, enter a Remote password and enable Remote control.

Select the Host Parameters tab and take the following steps:

For Priority, enter an integer between 1 and 32. The lower the number, the higher the priority. Priority establishes the default handling priority among hosts for requests that are not load-balanced by port rules. (See Step 6 for information about configuring port rules.)

For Initial cluster state, check active. This specifies that this host should be included in the cluster array immediately upon Windows startup.

For Dedicated IP address, enter the IP address of this host.

For Subnet mask, enter the subnet mask of this host.

Select the Port Rules tab, and take the following steps:

For Port Range, to balance the load from all client requests with a single port rule, use the default port range (1-65535). Use multiple port rules if different applications require different protocols, filtering modes, or affinity.

For Affinity, you can select one of three options. None results in load balancing of all requests across all hosts. Single results in all requests from a particular client being processed by the same host. Use this option to maintain session state. Class C results in all client requests from a TCP/IP class C address range being processed by the same host.

For Load Weight, either enter a percentage of the load to be handled by the host or select equal.

Note that Port Rules must be identical for all hosts in the cluster.

For more information about Microsoft Network Load Balancing, see the Microsoft documentation at: