Oracle Web Cache Backend Failover Oracle Web Cache Session Binding

9-20 Oracle Fusion Middleware High Availability Guide ■ 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 Administrators 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. Configuring High Availability for Web Tier Components 9-21 Figure 9–6 Failover See the Oracle Fusion Middleware Administrators 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 company1-host company2-host Oracle Web Cache Web Browser Web Browser Web Browser Web Browser Incoming Requests to www.company.com:80 Incoming Requests to www.server.com:80 Capacity:50 Capacity:50 server1-host server2-host server3-host Capacity:150 Capacity:50 Load balancing of requests Load balancing of requests Site: www.server.com:80 Site: www.company.com:80 Application Servers www.company1.com Application Servers 9-22 Oracle Fusion Middleware High Availability Guide 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 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