9.1 The Hot Spare

only for RuBoard - do not distribute or recompile

One way to provide redundancy is to have a second cache available on standby. In normal operation, all the traffic goes to the primary cache; if the primary fails, the secondary takes over. This arrangement is not exactly a cluster, since just one of the caches is active at any one time. However, the techniques for clustering and redundancy are similar.

You can use the DNS to support a hot spare. Your users configure their browsers with a hostname for the caching proxy service. You specify the primary cache's IP address in the DNS zone file. If the primary fails, simply change the DNS file to use the secondary's IP address. Manually updating the DNS zone files is a big drawback to this technique. If you're brave enough, you might be able to automate the process with some scripts. For example, if the primary cache doesn't respond to pings , swap zone files and restart named . Any DNS-based technique also requires relatively low TTL values (e.g., five minutes) for the cache's address record. Some user agents will continue using the old address until its TTL expires . Another drawback is that some users might enter the cache's IP address rather than the hostname. Those users' traffic always goes to one of the caches, regardless of the DNS configuration.

Another simple approach is to give two caches the same IP address, but connect only one at a time to the network. If the primary fails, just unplug its network cable and replace it with the secondary. Alternatively, for a Unix-based system, you can use ifconfig to enable and disable interfaces without touching network cables. Again, this method requires manual intervention or, in the case of ifconfig , some carefully written scripts. There is also an issue with ARP ”the protocol that maps IP addresses to Ethernet addresses. When you enable the secondary machine, other devices on the subnet won't be able to talk to it until their ARP caches time out, which usually takes a minute or so.

A number of products are available that can automatically provide faster and smoother failover to backup systems. These are the same products listed in Table 5-1 (i.e., layer four switches). You can configure them for interception or with a virtual server address. You also tell the switch the real IP addresses for the primary and backup caches. Normally, it forwards all connections to the primary. If the switch determines that the primary is down, it uses the backup instead. Since users always talk to the virtual server, there are no issues with the DNS or ARP cache timeouts.

The hot spare technique has some characteristics that make it unpopular. Primarily, the secondary system probably sits idle most of the time. Those resources (CPU, disk, memory) are hardly being utilized at all. It's somewhat wasteful to have the box powered up but not doing anything useful. Another concern is that the secondary cache could fail and the failure go unnoticed until the secondary was actually needed. For these reasons, many people prefer a load sharing configuration rather than a hot standby. The remainder of this chapter talks about load sharing configurations.

only for RuBoard - do not distribute or recompile