Balanceo con Squid

Estamos acostumbrados habitualmente a usar Apache como proxy transparente en las DMZ para bajar tráfico a la zona de nuestros servidores. El módulo ProxyPass y ProxyReverse , junto a mod_jk, y mod_proxy_ajp y demás resulta ideal para esta labor, por la versatilidad de configuración que ofrece Squid, pero a veces esto no es suficiente: Cuando tenemos que Apache tiene que servir una aplicación escrita con cantidad de contenido multimedia (pdfs, flash, imágenes, etc) en los que los usuarios acceden a la vez y de forma masiva, como por ejemplo al dar un curso online, los Apaches pueden sufrir: A la carga propia de generar el contenido dinámico (ejecución del PHP, CGI, Java, etc) se suma la carga de servir el contenido multimedia.

Un Apache en un equipo normalito (dual core y 4GB de RAM) soporta muy bien entre 200 y 300 conexiones concurrentes sin penalizar el tiempo de respuesta (más de 2 segundos). Si nuestra aplicación tiene mucho contenido multimedia, cada página que pidan los clientes se convertirá en varias de estas peticiones concurrentes y por ejemplo cada página se transforma en 20 peticiones, 15 usuarios concurrentes podrían estar sobrecargando el servidor Web. En esta situación está claro que deben estudiarse varias cosas: La configuración de Apache, la carga de base de datos, la distribución del contenido estático, el número de Apaches, el tipo de balanceo que realizamos, y un largo etc, pero como primera contramedida se puede incluir un Caché inversa transparente, dedicada a servir el contenido estático de nuestras páginas y descargar de esta labor a Apache.
Para ello podemos usar Squid, que con una mínima configuración podemos realizar esta labor, y además balancear las peticiones hacia nuestros Apaches. El fichero de configuración que podríamos usar es el siguiente:


#------------------------------------------------
# ACLS BASICAS
#
acl all src all
acl localhost src 127.0.0.1/32
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32
# Mi DMZ está en 192.168.3.0
acl localnet src 192.168.3.0/24
acl manager proto cache_object
acl purge method PURGE
acl CONNECT method CONNECT

#------------------------------------------------
# ACCESO PARA MANEJAR LOS FICHEROS DE CACHE
#
# Solo la maneja localhost
http_access allow manager localhost
http_access deny manager
# Solo permitimos la purga desde localhost
http_access allow purge localhost
http_access deny purge


#------------------------------------------------
# REGLAS PARA LA CACHE WEB HACIA LOS APACHES
#
# Decir que vamos a cachear y que no
acl IMAGENES urlpath_regex .jpg .gif .png .swf .JPG .GIF .PNG .SWF .css .CSS .pdf .PDF .bmp .css .doc .docx .exe .jpg .js .mp3 .odt .ppt .rtf .swf .txt .wrl .WRL .xls .XLS .xlsx .zip .exe .html .htm .HTML .HTM
acl QUERY urlpath_regex cgi-bin \? .php .asp .xml .cgi
no_cache allow IMAGENES
no_cache deny QUERY
refresh_pattern . 0 20% 0

# Habilitar HTTP 1.1
server_http11 on


# Configurar aceleracion hacia MiVirtualHost
# Mis servidores están la 192.168.2.0/24

# Como llegar al Nodo1 de Apache
cache_peer 192.168.2.211 parent 80 0 no-query http11 originserver no-digest round-robin weight=5 login=PASS name=srv01
# Como llegar al Nodo2 de Apache
cache_peer 192.168.2.212 parent 80 0 no-query http11 originserver no-digest round-robin weight=3 login=PASS name=srv02
# Como llegar al Nodo3 de Apache
cache_peer 192.168.2.213 parent 80 0 no-query http11 originserver no-digest round-robin weight=1 login=PASS name=srv02

# Esto es para procesar las respuestas 302
header_replace X-Forwarded-For
via off
reply_header_access X-Cache-Lookup deny !localnet
reply_header_access X-Squid-Error deny !localnet
reply_header_access X-Cache deny !localnet

http_port 3128

#debug_options ALL,1 28,9

# Definir el acceso al propio Squid
acl thishost src 192.168.3.121/32
acl to_thishost dst 192.168.3.121/32


#------------------------------------------------
# REGLAS PARA LOS HERMANOS WEB CACHE
#
# Configurar para que escuche multicast
mcast_groups 224.0.14.255
# Configurar para que hable multicast
cache_peer 224.0.14.225 multicast 80 3130 ttl=16
# Configurar hermanos multicast (otros squids en DMZ)
cache_peer 192.168.3.122 sibling 3128 3130 multicast-responder
cache_peer 192.168.3.133 sibling 3128 3130 multicast-responder
mcast_icp_query_timeout 2 sec


# Definir la ACL para redirigir el backup
# y que vaya solo a un nodo.
acl phpBackup urlpath_regex /backup/

# Definir los sitios de cachearemos
acl mivirtualhst dstdomain www.MiVirtualHost.com
http_access allow mivirtualhst
cache_peer_access srv01 allow mivirtualhst !phpBackup
cache_peer_access srv02 allow mivirtualhst !phpBackup
cache_peer_access srv03 allow mivirtualhst


# Esto se hace para no cachear internet :P
cache_peer_access srv01 deny all
cache_peer_access srv02 deny all
cache_peer_access srv03 deny all
http_access deny All


#------------------------------------------------
# MONITORIZACION SNMP DEL SERVIDOR
#
snmp_port 1161
acl Snmppublic snmp_community public
acl Adminhost src 192.168.0.0/16
snmp_access allow Adminhost Snmppublic
snmp_access deny all

#------------------------------------------------
# RESERVA DE DISCO PARA LA CACHE
#
# Regla de oro: Por cada 1MB de RAM, necesita 32MB de disco
# * por defecto: cache_dir ufs /var/spool/squid 100 16 256
# * sintaxis : cache_dir diskd Directory-Name Mbytes L1 L2 [options] [Q1=n] [Q2=n]
cache_dir diskd /var/spool/squid 1600 16 256 Q1=60 Q2=50


#------------------------------------------------

Esta configuración permite que squid derive las peticiones al dominio www.MiVirtualHost.com hacia tres Apaches (192.168.2.211, 192.168.2.212, 192.168.2.213) de forma ponderada (5,3 y 1 respectivamente), cacheando todo el contenido estático (directiva acl IMAGENES). Además evita que dos de los servidores reciban peticiones cuando la URL contenga /backup/, en cuyo caso, las peticiones sólo se derivarán al tercer nodo Apache. También presupone que existirán dos cachés más en DMZ (sibling) que nos ayudarán en la labor y cuya comunicación será vía Multicast que suponemos más rápida que si lo hiciéramos punto a punto.

La foto la he sacado del album de Richard Ling en flickr

No hay comentarios: