Apache + Squid + Nginx
— 1859 hits¡Menuda combinación!. A decir verdad empecé jugando un poco con el maldito slowloris y al final acabé montando este batiburrillo de servidores, primero para paliar el efecto del dichoso gusano y segundo para preparar el servidor para la inminente nueva versión del blog - que me gustaría estrenar con el décimo aniversario de este humilde rinconcito -.
En un esquema inicial analógico de esos que tantos nos gustan podemos ver la pirula (pido perdón de antemano por la calidad de la foto):
Probablemente no sea necesario tener 3 servidores para este entorno, seguro que puedo poner a escuchar Nginx en el puerto 80 y redirigir todo el tráfico dinámico al 81 a la vez que responde al tráfico estático de ciertos subdominios (static*) de forma automática y en la misma instancia. Pero tenía la tarde libre y me apetecía probar una configuración rara con Squid.
Apache
La configuración de Apache es de lo más sencilla, lo único que he hecho ha sido ponerlo a escuchar en el puerto 81 por defecto, y a todos sus Virtualhosts también. No había mucho más que tocar puesto que ya tenía el mod_php y todas las dependencias instaladas.
Nginx
Nunca había jugado con él y a primera vista me gustó la sencillez de sus archivos de configuración. Tampoco tenía que hacer gran cosa, ponerlo a escuchar en el puerto 82 y poco más puesto que sólo serviría contenido estático. Creé los Virtualhosts que atenderían las peticiones estáticas, los activé vía enlace simbólico a sites-enabled y poco más. La configuración de un Virtualhost cualquiera:
server {
listen 82;
server_name static.dominio.com;
root /home/www/dominio/sd/static/;
autoindex on;
}
Squid
Aquí vino la diversión, ¿cómo decirle a Squid que balanceara el tráfico dinámico al puerto 81 y el estático al puerto 82?. Después de leer la documentación y hacer varias pruebas con cache_peer, y cache_peer_domain he llegado a la conclusión que la configuración "buena" es la siguiente:
cache_peer ip parent 81 0 no-query originserver name=server_1 cache_peer_domain server_1 dominio.com www.dominio.com cache_peer ip parent 82 0 no-query originserver name=server_2 cache_peer_domain server_2 static.dominio.com
Como se puede ver, habría que cambiar ip por la ip pública correspondiente y los fqdn por los reales.
Conclusión
He pasado una tarde agradable en compañía de mis amigos los servidores web. No, en serio, al final he conseguido reproducir el escenario que me había propuesto, (aún sabiendo que se podría mejorar), he frenado los sockets incompletos de Apache y he preparado el servidor para servir estáticos de forma independiente del contenido dinámico (que en breve cambiará de PHP a Python + Django).
No ha estado mal :).
Comentarios
One solution fits all!
Con nginx puedes hacer balanceo de carga (y tiene caché, tanto como proxy HTTP como con fastcgi).
Si por lo que sea no quieres usar fastcgi y seguir con Apache (mal!), puedes... pero sigue sin encajar squid en esa foto.
Está claro que has disfrutado aprendiendo, pero en un entorno real me lo pensaría dos veces (precisamente porque squid es complicadillo de afinar bien :D).
Con una instancia de nginx + vhost podrás cubrir tus necesidades en el futuro: fastcgi (o wsig) a django, otro vhost para contenido estático, y a correr :)
Apúntate otro para otra tarde de pruebas: http://www.apsis.ch/pound/
(no hace de caché, "solo" es un balanceador de carga que permite "añadir" SSL a esos servicios que no lo proporcionan o no lo hacen con garantías)
Muy interesante comentario @reidrac, intuía que con Nginx podía reducir el esquema a 2 y había pensado de forma remota en la solución que propones sin estar del todo seguro de que pudiera implementarse.
Me gustaría reducir toda la configuración a Nginx + fcgi/wsgi puesto que - en este servidor en concreto - habrá dinámicas PHP y Python conviviendo. Sin embargo lo que más me tira para atrás es la traducción de todas las reglas rewrite.
Supongo que invertir tiempo en ello merecerá la pena ;).
Yo tengo en mis server Nginx como dice Reidrac, configurado para q dirva los estaticos directamente de disco (no por fqdn sino por extension de archivo), las peticiones a apps en ruby las pase al server de aplicaciones, y las php a un apache que funciona en el 8080. Y es killer. Se configura facilin y funciona como un cristal :-)
Yo tuve tiempo PHP con fastcgi, pero entiendo que en algunas aplicaciones puede dar un poco de problema. Básicamente es la pega del 'mod_php-centrismo' de muchos desarrolladores.
Pero vamos, si pones Apache en localhost y le metes nginx de frontal... como dice Iván: es killer XDDDD
Mi primera opción para ciertas aplicaciones podría ser nginx:80 -> apache:81 básicamente por no reescribir todas las reglas.
Viendo que el rendimiento de nginx pueda ser tan bueno (o mejor) que apache para webs con mucho (¡mucho!) tráfico entonces sí se podría invertir tiempo en una migración total.
Desconfío que nginx+fcgi pueda igualar el rendimiento de apache+mod_php en altas cargas de tráfico, básicamente por desconocimiento, nunca lo he probado. Y como es complicado montar una maqueta para "simular" tráfico real (tan sólo se me ocurre ab) y hacer un benchmark, probaré fcgi en apps menores antes de migrar las críticas.
No estoy seguro de que mod_php sea la panacea. Menéame (si no ando desencaminado) usa nginx + fastcgi.
Así divagando un poco, creo que por una parte nginx es más eficiente sirviendo muchas conexiones concurrentes, y por otra fastcgi será algo así como desacoplar mod_php de apache.
Entiendo ese "desacoplado" implicará cierta penalización por la comunicación nginx <-> fastcgi, y te tocará tener un pool de procesos en el fastcgi de la misma forma que lo haces con apache (porque PHP tiene muchos componentes no reentrantes, y por lo tanto no hay otra); pero no tiene porqué ser significativa.
Puedes buscar comparativas, que alguna idea te darán de por donde van los tiros. Por ejemplo:
http://till.klampaeckel.de/blo...
Aún así veo dos cosas distinas: que puede depender de la aplicación que sea más interesante un modelo o el otro, y que es más complicado de configurar fastcgi "bien" configurado (básicamente porque mod_php no tiene nada que "toquetear" :D).