Overview of Cache Clusters

Configuring High Availability Solutions 3-9 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: ■ Section 3.4.1, Oracle Web Cache Solely as a Software Load Balancer or Reverse Proxy ■ Section 3.4.2, Operating System Load Balancing Support

3.4.1 Oracle Web Cache Solely as a Software Load Balancer or Reverse Proxy

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. 3-10 Oracle Fusion Middleware Administrators Guide for Oracle Web Cache ■ 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 ■ Section 3.9 for instructions on configuring operating system load balancing capabilities ■ Section 3.6 for instructions on configuring a cache cluster ■ Oracle Fusion Middleware Enterprise Deployment Guide for Java EE for instructions on using Oracle Web Cache as reverse proxy for Oracle Portal and Oracle Single Sign-On.

3.4.2 Operating System Load Balancing Support

Certain operating systems provide load balancing support, which can increase the availability of Oracle Web Cache, particularly in cache clusters. 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

For more information about session binding, see Section 3.2 . Configuring High Availability Solutions 3-11 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 Fusion Middleware Control. See Section 2.6.2 .

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

Configuration . The Session Configuration page displays.

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

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

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

session.

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