CacheGuard-OS
User's Guide - Version UF-2.1.3


High Availability

The HA (High Availibility) feature allows you to assure service continuity in case of hardware or software failure. In a HA configuration, redundant internal and external network interfaces may be bound to support network interface, network cable or switch failures. Also two hardware (or virtual) appliances can act as a single logical appliance so in case one fails, the second one may assure service continuity.

Link Bonding

CacheGuard uses two logical network interfaces: the "internal" interface and the "external" interface. In forwarding mode, internal clients access the CacheGuard via the internal interface while CacheGuard uses its external interface to access the internet. In reverse mode, end users (Web users) come from the external interface and cross the appliance to reach protected Web servers (real Web servers) located behind the internal area.

Each logical network interface could be associated to several physical interfaces to increase the system availability in case of a physical network failure. To do this, the appliance uses a link bonding mechanism in "active/backup" mode.

Example

Consider an appliance installed on a machine with the four physical network interfaces eth0, eth1, eth2 and eth3. In this configuration, physical interfaces eth0 and eth1 could be affected to the internal logical interface while "eth2" and "eth3" may together assure the external connectivity. To set such a configuration up use the following commands: The above diagram shows a high available architecture in which two distinct switches are implemented per logical network interface. To eliminate all SPoF (Single Point of Failure) and improve the availability of the technical architecture, internet routers are also redundant. This architecture supports single failure or even double straight or crossed vertical failures (For instance failures on the master appliance and a backup switch).

Virtual Redundant Appliances

CacheGuard implements the VRRP v2 (Virtual Redundancy Router Protocol) to assure the High Availability in a redundant appliance configuration. When using VRRP, two appliances share the same virtual IP (VRRP IP) address for the internal or external interface. Thus all clients (Web servers, Web users, routers or any other network equipment) accessing the redundant system should use VRRP IP addresses instead of real IP addresses.

In a VRRP configuration, one appliance is elected as the master (active) and the others act as backups. In case of a failure of the master appliance, a backup appliance is then elected as the new master and the floating VRRP IP address is affected to the new master appliance.

A complete Example

Consider two appliances "cacheguard1" and "cacheguard2" acting as a redundant system. Each real appliance has four network interfaces and uses the link bonding mechanism. The internal network is "172.18.2.0/255.255.255.0" and the external network "192.168.2.0/255.255.255.240".

On the first appliance the internal IP address is set to "172.18.2.252/24" and the external IP address is "192.168.2.1/28" while on the second appliance the internal IP address is set to "172.18.2.251" and the external IP address is "192.168.2.2".

Two VRRP IP addresses are then configured for internal interfaces. The same configuration is set for external interfaces. The first internal VRRP IP address is "172.18.2.254" and the second one is "172.18.2.253". The first VRRP IP address is configured as master on cacheguard1 and as backup on cacheguard2. The second VRRP IP address mirrors the first one and is configured as master on the cacheguard2 and as backup on the cacheguard1. Each appliance is then configured to use the other as a HA Peer. A similar VRRP configuration is done for the external network interfaces using VRRP IP addresses "192.168.2.3" and "192.168.2.4".

To set up this configuration, the following commands must be executed on the first appliance:

The second appliance has a mirror configuration so the following commands should configure this one:

Note that the same VRRP IP addresses are used on both appliances while real IP addresses are unique. In this configuration, IP addresses used by clients should be VRRP IP addresses since real IP addresses are then reserved for an internal usage.

To use equitably both appliances and make sure both caches are regularly up to date, clients should be configured to use both appliances. To perform that automatically a WPAD (Web Proxy Auto Discovery) script may be used on clients to automatically configure their settings to use both appliances A WPAD example could be:

	
  function FindProxyForURL( url, host )
  {
  if (url.substring(0, 5) == "http:"   ||
  url.substring(0, 4) == "ftp:"    ||
  url.substring(0, 6) == "https:") {
  
  if ( (Math.floor( Math.random() * 2)) == 0 ) {
  return "PROXY 172.18.2.254:8080 ; DIRECT";
  }
  else {
  return "PROXY 172.18.2.253:8080 ; DIRECT";
  }
  }
  return DIRECT;
  }
Save the above script in a file that ends with ".pac" and make it available on a web server. Remember to add the setting "application/x-ns-proxy-autoconfig dat" to the mime-definition file of your web server.

Note: A more sophisticated script is automatically generated on every appliance configured in HA mode and is available at the URL: http://v.x.y.z/ha.pac (where v.x.y.z is one of the master VRRP IP configured on the redundant system). The generated script uses persistency so the same proxy is always used for the same accessed URL.