Oracle9iAS Web Cache Administration and Deployment Guide Release 2 (9.0.2) Part Number A95404-02 |
|
You can configure multiple instances of Oracle9iAS Web Cache to run as independent caches, with no interaction with one another. Most of the deployment scenarios in this guide describe this type of configuration.
However, to increase the availability and scalability of your Web cache, you can configure multiple instances of Oracle9iAS Web Cache to run as members of a cache cluster. A cache cluster is a loosely coupled collection of cooperating Web cache instances working together to provide a single logical cache.
This chapter contains the following topics:
In a cache cluster, multiple instances of Oracle9iAS Web Cache, the cache cluster member, operate as one logical cache. A cache cluster can consist of two or more members. 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-1 shows an Oracle9iAS 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.
Oracle9iAS 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 document. This content is called owned content.
In addition to the owned content, Oracle9iAS Web Cache stores popular documents in the cache of each cluster member. These documents are known as on-demand content. By storing the on-demand content, Oracle9iAS Web Cache responds to requests for those documents quickly and decreases the number of cache misses. Fewer requests are sent to the application Web server. The result is improved performance.
Cache clusters provide the following benefits:
With or without cache clusters, Oracle9iAS Web Cache ensures that cache misses are directed to the most available, highest-performing Web server. With cache clusters, Oracle9iAS Web Cache supports failure detection and failover of Web 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.
By distributing the site's content across multiple Web 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 at one time. 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.
In a cache cluster environment, popular documents are stored in more than one cache. If a cache fails, requested cacheable documents are likely to be stored in in the cache of surviving cluster members. As a result, fewer requests for cacheable documents need to be routed to the application Web server even when a cache fails.
When a failed cache returns to operation, it has no documents 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, Oracle9iAS Web Cache can cache more content, resulting in fewer requests to the application Web server.
Because Oracle9iAS 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.
Cache clusters are easy to manage because they use one configuration for all cache cluster members. For example, you specify one set of cacheability rules and one set of invalidation rules. Oracle9iAS Web Cache copies those rules to all cluster members by propagating the configuration to all cluster members.
In a cache cluster, multiple instances of Oracle9iAS Web Cache operate as one logical cache.
A cache cluster uses one configuration that is propagated to all cluster members. The configuration contains general information, such as security, session information, and cacheability 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 Oracle9iAS 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, Oracle9iAS Web Cache propagates the configuration to all members of the cluster. Because adding a new member changes the relative capacity of each Web cache, Oracle9iAS 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, Oracle9iAS 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 propagated to 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.
See Also:
"Invalidation Propagation" for more information about invalidation propagation in cache clusters |
Oracle9iAS Web Cache uses the relative capacity of each cache to automatically distribute ownership of documents among the cache cluster members. For example, in a three-cache cluster, if cache_X has a capacity of 10, cache_Y has a capacity of 10, and cache_Z has a capacity of 20, Oracle9iAS Web Cache distributes ownership of 25% of the cached content to cache_X, 25% of the cached content to cache_Y, and 50% of the cached content to cache_Z.
Oracle9iAS Web Cache maintains a structure to record ownership of documents. When a request for a cacheable document is received, Oracle9iAS Web Cache uses the structure to assign a cache cluster member to be the owner of the document.
Note that in addition to the owned content, Oracle9iAS Web Cache stores popular documents (on-demand content) in the Web cache of each cluster member. By storing the on-demand content, Oracle9iAS Web Cache returns future requests for those documents quickly and decreases the number of cache misses. The result is improved performance.
When an incoming request for a noncacheable document is received by one of the cache cluster members, the requested is forwarded to the application Web server.
When an incoming request for a cacheable document is received by one of the cache cluster members, what happens next depends on whether or not the requested content is cached by that cluster member and whether or not the content is owned by that cluster member. Suppose that cluster member cache_Y receives a request for cacheable content:
When you add a member to or remove a member from the cache cluster, Oracle9iAS Web Cache uses the information about capacity to recalculate which cluster member owns which documents. If the ownership of a document changes and the document is currently cached, Oracle9iAS Web Cache designates the document as on-demand content, rather than owned content, for that cache. The document is not removed from the previous owner cache, nor is it moved to the new owner cache. The document is not cached in the new owner cache until another request for the document is received.
Oracle9iAS Web Cache clusters ensure high availability through failure detection and failover. In clusters, failure detection ensures that Oracle9iAS Web Cache can detect when a cache cluster member is unavailable; failover ensures that Oracle9iAS Web Cache transfers ownership of the content of the failing member to the remaining cluster members.
Cache cluster members send requests to the cluster member who is the owner of the requested content. If a cache cluster member does not receive a response from another cluster member after a specified failover threshold (the number of consecutive attempts to reach a cache), the cache cluster member assumes that the other cluster member has failed. Each cluster member individually detects the failure of other cluster members.
As each cache cluster member detects the failure of another cluster member, it recalculates the relative capacity of the remaining cache cluster members. Then, it reassigns ownership of documents based on the new relative capacity and the ownership array. Note that although ownership is reassigned, the content is not cached in the new owner cache until another request for the document is received.
The cache cluster members poll the failed Web cache server for its current status until it is reachable again. When the failed Web cache is reachable, it rejoins the cache cluster. Each cache cluster member again recalculates the relative capacity of the cache cluster members and reassigns ownership of the documents.
See Also:
Configuring a Cache Cluster for information about configuring a cache cluster, including specifying a failover threshold. |
|
Copyright © 2002 Oracle Corporation. All Rights Reserved. |
|