Jerarquías de Cachés - Configuración de Squid

El empleo de cachés jerarquizadas puede ser difucultoso, trabajoso y a veces puede no merecer la pena. Dependiendo del tipo de instalación y del tráfico puede ser interesante su consideración. A lo largo de este capítulo iré comentando diversos ejemplos.

Cuando una caché obtiene una petición de un cliente, comprueba si ese objeto (página, gráfico, o fichero) está en el disco duro.

Sí está, comprueba que el objeto no esté caducado y procede a enviarlo al cliente. Si el objeto no está o ha caducado, comprueba que otras cachés (padres o hermanas) lo tengan. Lo hace a la vez, enviando paquetes UDP a esas máquinas con la URL.

La otra caché comprueba a continuación si tiene dicho objeto en el disco duro, y envía un mensaje indicando si lo posee o no.

La máquina original espera las respuestas y después decide si debe obtener el objeto de la otra caché o debe ir directamente a por ello.

Padres versus Hermanas

Si configura su caché para tener sólo hermanas, dicha caché enviará las peticiones UDP a la lista de hermanas, y si no poseen dicho objeto squid se conectará directamente al servidor remoto.

Si configura su caché para tener un padre, significa que si dicha caché no tiene el objeto, y ninguna de las hermanas lo posee, abrirá una conexión TCP a la caché padre para que esa caché padre obtenga el objeto. Al ser una conexión TCP, esta caché padre posiblemente recorrerá la lista de cachés padres y hermanas para buscar el objeto (sólo les envía una petición UDP para comprobar si la poseen en el disco duro). Lo que complica las cosas es tener múltiples cachés padres y hermanas.

Obviamente, si sólo un padre tiene el objeto, la descargará de allí, pero si ninguna lo posee, su caché dará la petición a la máquina que respondió mas rápida, creyendo que es la máquina que menos saturada o que posee el mejor enlace. También se pueden balancear las cachés, repartiendo la carga. Incluso se puede especificar que use una caché padre para descargar las peticiones que no haya podido obtener.

Veamos un ejemplo:

cache_host cache.idesoft.com parent 3128 3130

En este ejemplo sólo existe una caché a la que squid va a preguntar, y es probable que en muchas ocasiones esté saturada y esto sea una pérdida de tiempo.

Una configuración mejor podría ser esta:

cache_host cache.idesoft.com parent 3128 3130 no-query default

En este caso, su caché no enviará paquetes UDP para saber si está activa, y se conectará a ella para todas las peticiones. Este sistema es similar al utilizado por el proxy de Netscape.

Otra característica muy útil de este sistema es la capacidad de cachés hermanas. Supongamos que no desea gastar mucho dinero en una sola caché, y desea balancear la carga entre varias máquinas, pero no duplicando los objetos en cada máquina. Es posible configurar estas máquinas para que hablen entre ellas mediante las señales "proxy-only", como este ejemplo:

En este caso, si una petición se dirige a la caché 1 y no se encuentra en el disco, esta caché enviará una petición ICP a la caché 2 (3, 4, etc) y la descargará de allí, pero no la salvará en su disco duro, tan sólo la descargará de la otra caché cuando la necesite de nuevo. Este sistema duplicará la capacidad del disco duro sin necesidad de gastar grandes cantidades de dinero en sistemas raid para soportar muchos gigas. La caché de Netscape no soporta este sistema.

Por último, indicar que un Squid tanto bajo en Windows NT como en Linux puede utilizar una caché padre bajo Microsoft Proxy Server 2.0.

Un ejemplo de configuración podría ser este (editamos squid.conf):

cache_peer servidor-proxy-nty.com parent 80 7 no-query login=name:passwd
acl all src 0.0.0.0/0.0.0.0
http_access allow all
miss_access allow all
always_direct deny all
never_direct allow all