PamchoBlog

Para montar caceresnews.com tenía que crear un sistema de muy bajo coste (el mínimo de servidores) consiguiendo suficiente redundancia como para superar caídas y que pudiera resistir picos muy importantes de trafico.

La opción que adopté fue la de contratar dos servidores dedicados en Acens donde me garantizaban aguantar picos de hasta 100 Mbps en cada uno. Ambos servidores (cc1 y cc2) son prácticamente idénticos, conectados por un cable cruzado para poder detectar la caída del otro servidor y optimizar el trafico de datos entre ellos.

Los seridores tienen instalado el típico entorno LAMP: Linux (Ubuntu Hardy), Apache, MySQL y PHP.

El MySQL está configurado en ambos servidores como Maestro-Maestro, es decir, ambos son maestros y ambos hces de esclavo del otro servidor. De esta manera cada servidor, llegado el caso, podría funcionar solo. La aplicación intenta siempre escribir en el MySQL de cc1 y, si falla, lo intenta en cc2. De esta forma se evitan posibles problemas de concurrencia al escribir en ambas BBDD a la vez.

La aplicación sirve un video personalizado generado a partir de 5 imágenes, generadas a su vez a partir del nombre de la persona. El uso masivo de la aplicación requiere del almacenaje de gran cantidad de imágenes que deben ser guardadas en ambos servidores, con la garantía de que ambos tengan en todo momento todas las imágenes, incluso tras la recuperación de una caída.

Para solucionar esto opté por usar glusterfs, un sistema que permite tener una carpeta virtual de archivos en varios servidores con garantía de replicación en muy poco tiempo.

El balanceo de carga lo realiza directamente el sistema de DNS, ya que el nombre de caceresnews.com tiene asociadas 2 IPs, una asignada a cada servidor. Los servidores de DNS, cuando se les consulta, entregan alternadamente una de las IP (Round-Robin), por lo que hay un balanceo casi perfecto de peticiones por número (no por carga, no se puede tener todo). El único problema de este sistema de balanceo por DNS es que no se detecta la posible caída de uno de los servidores, en cuyo caso la mitad de las peticiones fallarían.

Para solucionar esto recurrimos a Wackamole, un software que, instalado en ambos servidores, puede detectar la caída de uno de ellos y asignar su(s) IP(s) al que queda en pie, recibiendo éste así todas las peticiones.

En estas condiciones hemos llegado a tener sin problema hasta 30.000 visitantes únicos diarios, y el día que la página salió en Espejo Público:

CaceresNews en Espejo Público

ambos servidores alcanzaron el límite de los 100Mbps sin despeinarse.

Aunque como de todo se aprende, hay una serie de decisiones que ahora serían diferentes:

1. Actualmente ya no usaría servidores dedicados, sino Amazon Web Services que permite levantar servidores de una forma mucho más flexible, rápida y económica.
2. Tampoco usaría el glusterFS. Cada vez soy más de la opnión de que los servidores deben ser completamente independientes para que los problemas no se propaguen. GlusterFS no te protege contra un borrado accidental de ficheros, como me ocurrió a mí, y la gran mayoría de los problemas suelen deberse a fallos humanos. Actualmente haría que las imágenes se generaran en todos los servidores sin sincronización entre ellos.