27
Chapter 4
Transparent Proxy Caching
About WCCP load balancing
If a WCCP router serves several nodes, as in Figure 4-2‚ on page 24 the router balances load among the Traffic
Servers. The router sends each node requests aimed at a particular range of IP addresses, so that each node is
responsible for caching content residing at particular IP addresses.
You can monitor the percentage of traffic that goes to each node. If a node becomes unavailable, its traffic is
redistributed.
Traffic Server also supports cache affinity. If a node becomes unavailable and then recovers, Traffic Server
returns the node to its former load distribution. This means that the node’s cache need not be repopulated.
The WCCP cache farm acts as a simple form of distributed cache, which is sufficient for many applications.
A WCCP-enabled network device distributes traffic to individual Traffic Servers based on the IP address of
the origin server. Each node caches objects requested from a particular set of origin servers, which belong to
that node’s assigned range of destination IP addresses.
Traffic Server’s full clustering option is not required for WCCP and you can run Traffic Server nodes in
management-only clustering mode. During Traffic Server installation, if you select clustering and enable
WCCP, management-only clustering is enabled by default. Management-only clustering conserves CPU
resources, and slightly improves performance over full clustering. See
Chapter 6‚ Traffic Server Clusters
for
details.
Busy origin servers are often mapped to several IP addresses (using a DNS round-robin mechanism). Using
WCCP-based load balancing alone, each of these different IP addresses could be allotted to different Traffic
Server nodes. This can result in a slightly lower hit rate and wasted cache space, since the same content is being
replicated across nodes. Traffic Server’s full clustering mode ensures that all requests to a specific page on that
origin server (no matter which IP address is used) are cached on the same node.
With full clustering, objects are distributed among nodes according to their URLs; WCCP distributes objects
according to destination IP address. If a particular IP address is receiving many requests, WCCP load
balancing may lead to a hot spot, where all of that site’s traffic is cached on one node, instead of being
distributed among the nodes. Traffic Server’s full-clustering mode distributes different pages from the busy
site to different Traffic Server nodes.
In general, if load-handling capacity and latency are most important, HP recommends management-only
clustering in WCCP environments. If hit rate, bandwidth savings, and better load balancing are most
important, then full clustering can provide an improvement in WCCP environments.
If you are running clustered Traffic Servers, HP recommends that you do not enable virtual IP failover in
WCCP environments. Traffic Server’s WCCP failover mechanism handles node failures and restarts. See
Virtual IP failover‚ on page 47
for details about virtual IP failover.
Using policy-based routing to filter transparency requests
Instead of the WCCP protocol, you can use the policy routing capabilities of a router to send traffic to Traffic
Server. However, policy-based routing has a performance impact on the router, and it does not support load
balancing or heartbeat messaging. Use WCCP or an L4 switch instead of policy-based routing for better
results. Figure 4-3‚ on page 28 illustrates how policy-based routing filters HTTP requests.
•
All client Internet traffic is sent to a router that feeds Traffic Server.
•
The router sends port 80 (HTTP) traffic to Traffic Server and sends the remaining traffic to the next hop
router.
•
The ARM translates intercepted requests into Traffic Server requests.
•
Translated requests are sent to Traffic Server.
•
Web documents to be served transparently are readdressed by the ARM on the return path to the client, so
that the documents appear to have come straight from the origin server.
