Semilla de Software Libre (S.L.)

Hemos estado haciendo pruebas sobre como afectaría al rendimiento de nuestros servidores el web el poner delante de ellos una serie de cachés inversos de forma que e tráfico vaya contra estos cachés, vean si esa petición es una petición dinámica, si lo es remitirla a los servidores web y si no es que lo resuelva el sólo.

Hemos quedado gratamente satisfechos con las pruebas y muy posiblemente lo empecemos a implantar en algunos servicios que empiezan a tener mucho tráfico. Esto es más o menos lo que hemos hecho.

Nuestro esquema actual sería algo parecido a esto:

Bueno vamos al lío de cómo se haría esto, lo primero sería saber que servicios vamos a tener que tocar para poner esto en marcha, en nuestro caso serían:

• Apache, no mucho para decirle que ahora también escuche por real.example.com
• Bind9, para decirle que www.example.com es la máquina de cache
• Squid, el que va a hacer el trabajo sucio

En nuestro esquema cada servicio corre en una máquina distinta, así que empezaremos por apache y bind, que es donde menos hay que tocar…

En apache simplemente añadimos esta línea por cada dominio que queramos que sea resuelto por el cache:

/etc/apache/sites-enabled/example.com

[...]

ServerAlias real.example.com

[..]

Esto únicamente nos sirve para cuando queramos acceder al servidor sin pasar por la cache.

En la parte de bind, también es bastante sencillo, en el archivo de definición de la zona cambiamos la entrada del www

/etc/bind/db.example.com

[...]

www  IN  CNAME  cache

[...]

Ahora llega la parte importante instalar el squid y modificar la configuración para que haga de cache inverso.

Lo primero sería instalar squid con su orden favorita, apt-get install squid, urpmi squid, “instalame el squid becario”. En nuestro caso la configuración está hecha sobre una debian 4.0, pero no debería haber mucha diferencia entre nuestros unixes. Vamos a configurar squid

/etc/squid/squid.conf

http_port 80 vhost # Si vamos a escuchar en el puerto 80 haciendo la vhost (proxy inverso, esto sería todo

hierarchy_stoplist cgi-bin ?

acl QUERY urlpath_regex cgi-bin \?
cache deny QUERY

cache_mem 600 MB # tenemos 750MB y esta máquina sólo va a hacer esto…

maximum_object_size 30 MB # nos interesa cachear también archivos mas o menos grandes

maximum_object_size_in_memory 128 KB
access_log /var/log/squid/access.log squid

hosts_file /etc/hosts # esto es importante, por que aqui es donde resolvemos a la máquina que realmente tiene el apache

refresh_pattern .        0    20%    4320

collapsed_forwarding on
acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl to_localhost dst 127.0.0.0/8

acl Safe_ports port 80        # http

acl purge method PURGE
acl CONNECT method CONNECT
http_access allow manager localhost
http_access deny manager
http_access allow purge localhost
http_access deny purge
http_access deny !Safe_ports
http_access deny to_localhost
acl dominios dstdomain “/etc/squid/dominios” all # esto es importante en este fichero le decimos a squid los dominios que vamos a cachear
http_access allow dominios
always_direct allow dominios
http_access allow localhost
http_access deny all
http_reply_access allow all

icp_access allow all

cache_effective_group proxy
visible_hostname cache-001.example.com # podemos tener muchos

coredump_dir /var/spool/squid

Tachan! ya casi lo tenemos, ahora hemos dejado dos ficheros más que debemos tocar

/etc/squid/dominios

www.example.com

example.com

coreapp.example.com

/etc/hosts

[...]

192.168.0.2 www.example.com example.com

192.168.0.3 copreapp.example.com

[...]

y ya releemos las configuraciones de todos los servicios y a ver como el dns va llevando poco a poco el tráfico al caché.

Es interesante que se instalen siempre algunas estadísticas… pero eso ya será otro artículo rápido como este.