Overview of Session Binding

Configuring High Availability Solutions 3-7

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. Figure 3–4 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 synchronized with all cluster members. The configuration contains general information, such as security, session information, Application Server Application Server Internet Oracle Web Cache Cluster 3-8 Oracle Fusion Middleware Administrators Guide for Oracle Web Cache 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 sites 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 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.