Cache Load Balancing High Level

  1. Single node persistency is most important.
  2. The least impacting redistribution of traffic
  3. Simple implementation

Load balancing of cache and proxy servers has long been a standard task for F5's BIG-IP LTM. However, cache and proxies have unique requirements over other types of applications. It's not realistically possible to cache an entire site, let alone the Internet, on a single cache device. The solution is to intelligently load balance requests and 'persist' them to a specific cache not based on who the client is, but based on the content requested. In a forward proxy example, all requests for would go to cache1 while all requests for go to cache2. Since each cache gets all the requests for their respective sites, they will have the most up to date version of the content cached. This also allows the caches to scale more efficiently as each would only need to cache N percent of the possible destination content. In BIG-IP LTM nomenclature, adding more members (nodes or servers) to the pool reduces the percent of content such as URIs that any cache server needs to store.

While this document addresses cache load balancing, the concepts and scripts are easily adapted to a wide range of uses. The solutions discussed cover BIG-IP LTM all version 9.x, except for Election Hash which takes advantage of commands added in version 9.4.2.

Hash Persistence on BIG-IP LTM

There are unlimited variations of hashing available with the LTM's iRules. This document will focus on three of the most representative of these options, pointing out the strengths and weaknesses of each. The goal of each is the same, to ensure an equal and consistent distribution of requested content across an array of devices. This document focuses on hashing the HTTP URI, however this can easily be substituted for other content such as [HTTP::uri], [HTTP::host], [HTTP::cookie <cookiename>] or [IP::client_addr], to name a few. For a site doing virtual hosting, it may be worthwhile to use [HTTP::host][HTTP::uri] which would capture a request such as: [][/index.html]

Hashing is both a persistence and load balancing algorithm. While you can configure a load balancing algorithm within a pool, it will always be overridden by the hash if everything is working correctly.

By default the LTM load balances new connections, which are different than requests. OneConnect must be enabled in order to have the LTM separate and distinctly direct unique HTTP requests over an existing TCP connection. See this article for more information.

Next Section: Basic Hash