Download (direct link):
By deploying a load balancer, we can easily solve the scalability and availability problems in forward-proxy cache deployments. As shown in Figure 7.2, a load balancer is deployed in front of the forward-proxy caches. We define a VIP on the load balancer and bind the VIP to the IP address of each cache server on port 8080. We use port 8080 here on the load balancer because many customers use port 8080 for proxy communication. That means the browser is configured with a port number for proxy communication and it sends all requests to that port number. load balancing here immediately solves two issues: scalability and availability. We can now transparently add more caches for scalability. If a cache goes down, the requests are immediately redistributed across the available caches, improving availability. Further, we now provide superior manageability because the administrator can gracefully bring down a cache for maintenance, such as software updates, without
interrupting user service.
rJ[— . • -Jl— -J.~ rJ Figure 7.2: Forward-proxy load balancing.
Forward-proxy load balancing is just like server load balancing. The VIP on the load balancer is used as the proxy server IP address when configuring the client browsers. The biggest issue in using forward-proxy caches is configuring each client’s browser to point to the cache. While this problem can be solved by using some automatic scripts that run when a user logs in to the network, using a transparent proxy can eliminate the configuration altogether.
By deploying a cache as transparent proxy, we can avoid configuring each user’s browser to point to the forward-proxy cache server. As shown in Figure 7.3, a cache can be deployed as a transparent proxy by placing it in the path of the Internet connection. Since all traffic passes through the cache, it can terminate the connections for Web traffic and service them from the cache itself, or go to the origin servers if the cache does not have the requested content. Users may not even be aware that there is a cache deployed here. But transparent proxy poses a different set of problems of scalability and availability. First, if we need to deploy multiple caches, we cannot do that since there may be only one or two Internet-access links. We can only deploy one cache in each Internet-access path. Second, if the cache goes down, we lose Internet access completely—not just for Web traffic. This approach also makes it difficult for administrators to maintain the caches for software upgrades or to replace failed hardware parts.
Figure 7.3: How transparent cache works.
By using a load balancer to perform transparent-cache switching, as shown in Figure 7.4, we can simplify the transparent-proxy cache deployment. The load balancer must be configured with a traffic-redirection policy to redirect all TCP traffic with destination port 80 to the cache. This policy must only be applied to the traffic coming in on the physical port that’s connected to the inside network. This is important because, if the cache does not have the object, it’s going to send the request to the origin server and this request will pass through the load balancer again. The load balancer must not perform the redirection for traffic received from the cache; instead, the load balancer must forward the request to the origin servers.
Figure 7.4: Transparent-cache switching.
With transparent cache switching, the load balancer can perform health checks on the cache and detect any failures immediately. If the cache fails, the load balancer simply acts as a pass-through switch, forwarding traffic in either direction. The clients will still be able to access the Internet, but they won’t get the benefit of caching. The important thing here is that the clients don’t lose Internet access if a cache fails because the cache is not in-line in the network path. If the load balancer fails, the clients will lose Internet access, but the premise here is that the load balancer is a lot more reliable than a cache (as are switches or routers that connect us to the Internet).
Just as a forward proxy acts as a proxy for clients sending requests to servers, the name reverse proxy indicates acting as a proxy for servers, as shown in Figure 7.5. When we deploy a reverse-proxy cache in front of a Web server, we must configure the DNS to resolve the Web site name to the IP address of the reverse-proxy cache so that user requests are received by the cache instead of the Web server. If the cache does not have the requested object, it in turn makes the request to the Web server to retrieve the object.
Figure 7.5: How reverse-proxy cache works.
What if we want to deploy multiple reverse-proxy cache servers for scalability and availability? We can deploy a load balancer in front of a set of reverse-proxy caches, as shown in Figure 7.6. The load balancing of reverse-proxy caches is exactly the same as server load balancing. We need to define a VIP on the load balancer and bind it to each reverse-proxy cache on the specific application ports that are being cached—such as HTTP, FTP, and so forth. As far as the load balancer is concerned, the reverse-proxy cache looks just like a Web server.