Cuando diseñamos sistemas de alta disponibilidad tenemos que cubrir cada uno de los puntos posibles de fallo con infraestructura o servicios redundantes.
Veamos cuales son nuestras opciones.
De una manera simplificada podemos ver la redundancia de los diferentes servicios así:
- DNS: Redundante con Route53
- Balanceo de Carga: Redundante con ELB - Elastic Load Balancer
- Servidor Web: Redundante con múltiples máquinas EC2. Opcionalmente con autoscaling para mayor elasticidad.
El problema típico: Almacenamiento local
Las aplicaciones de contenido en PHP en un rango desde eZ Publish, Drupal, Wordpress, Typo3, Joomla, Moodle, etc. usan un esquema de almacenamiento de contenido similar:
- Estructura y contenido: Almacenado en la base de datos.
- Archivos de contenido (imagenes, videos, archivos de word, excel, pdf, etc) van al sistema de archivos local de la máquina.
- Cache sistema de archivos local de la máquina.
Viendo lo anterior tenemos que garantizar durabilidad (la habilidad de datos a perdurar después de un fallo)
Replicación de la Base de Datos
Es un problema relativamente resuelto. Para Mysql, Amazon Web Services permite el modo Multi-AZ en su servicio RDS y esto nos da replicación a nivel de la plataforma de la nube. En otras bases de datos como Oraclo o SQL Server se lanzan dos o más instancias y se usan los mecanismos nativos de cada base de datos para hacer replicación master-master.
El Cache
El cache se puede regenerar después de un fallo, por lo que no nos preocupa que se pierda. Es, por naturaleza, efímero.
Archivos de Contenido
Si queremos escalar horizontalmente, vamos a lanzar nuevas instancias, pero ¿cómo hacer que los archivos estén sincronizados entre ellas de manera instantánea, o casi instantánea?
Diseñando para el fallo, todo va a estar bien
Sabiendo que todo va a fallar, las cosas van a estar bien. U
n sistema de archivos de bloque como EBS - Elastic Block Storage es altamente disponible (99.99% - cuatro nueves) y más durable que un disco duro normal, pero el problema que tenemos es que *solamente se puede asignar a una instancia EC2**.
1. Rsync
Rsync es un comando eficiente para copiar, o sincronizar solamente los archivos cambiados de un directorio.Lo hace rápido y es confiable. Al poner un cronjob o proceso recurrente que haga sincronización de los archivos desde una máquina a las demás, tenemos los archivos sincronizados con algo de demora.
¿Qué pasa si alguien busca el contenido en una de las máquinas * antes de que se haya sincronizado*? Le sale un error 404 por no estar disponible.
¿Cuándo funciona bien esta solución? Si el contenido no se actualiza frecuentemente, esta solución funciona razonablemente bien.
¿Cómo es el comando?
rsync -avz [usuario]@[maquina_origen]:/[ruta_origen] [usuario]@[maquina_destino]:/[ruta_destino]
¿Cómo excluir archivos?
A veces queremos sincronizar todo un directorio excluyendo algunos tipos de archivo. Para esto existe el parámetro --exclude en Rsync.
2. Archivos en la base de datos
Si podemos replicar las bases de datos, la sugerencia muchas veces es simple: pongamos los archivos de contenido en la base de datos.
Suena fácil y funciona bien si son archivos pequeños. Qué hacemos cuando los editores empiecen a publicar grandes videos o archivos PDF de 500 mb? La base de datos va a quedar gigantesca.
¿Cuándo usar esta estrategia? Si nuestros archivos son pequeños y podemos vivir con una ligera demora al accederlos, almacenar en la base de datos es una buena opción.
Esto depende directamente de la aplicación que estemos usando. Por ejemplo eZ Publish permite usar la base de datos para almacenar archivos en su configuración en modo cluster.
3. Sistema de archivos compartido (shared filesystem)
NFS en una sola máquina
Es la opción más sencilla pero la más peligrosa. Si solo tenemos una máquina ¿cómo garantizamos alta disponibilidad en ella?
Es verdad, una máquina poderosa que solamente sirva de NFS (Network File System) tiende a ser bastante estable.
Los volúmenes de EBS son estables aunque tienen fallos de 3-5% por año. Mucho mejores que un disco duro normal pero mucho menores que la estelar durabilidad de un bucket de Amazon S3 * (99.999999999%). La solución: montar dos o más volumenes usando RAID10*.
Bien, si la durabilidad está garantizada, ¿qué pasa si se corre en una sola máquina?
Bienvenidos los sistemas de archivos distribuidos:
DRDB
La usamos hace tiempo en un sitio de alto rendimiento. Toma tiempo y experiencia su implementación por lo que he querido buscar algo mejor. Acá encontrarán un tutorial de DRDB - OCFS2
GlusterFS
Gluster es una de las soluciones de archivos distribuidos más mencionadas en la red. Entiendo que Drupal Gardens de Acquia usa GlusterFS para mantener un repositorio distribuido para archivos accesibles por varios servidores web.
Ceph
No sabía de Ceph hasta Mayo de 2013 cuando lo mencionaron en el entrenamiento de Amazon AWS Architect. Inmediatamente lo investigué aunque en algunos sitios el comentario era que la versión de ese momento era casi espectacular.
Ceph es una herramienta open source, definida así:
Ceph is a distributed object store and file system designed to provide excellent performance, reliability and scalability.
El futuro: EBS con montaje múltiple
No existe…todavía. Y nadie me ha dicho que lo vayan a lanzar porque AWS no publica sus planes. Es inevitable que AWS permita montar un volumen EBS en más de una máquina o lance un nuevo servicio para compartir sistemas de archivos fácilmente.
Ya Google (Junio de 2013) permite montar un disco en varias máquinas en modo de sólo lectura, es solo cuestión de tiempo.
Conclusión
En mi experiencia la manera más difícil de hacer arquitectura en la nube para aplicaciones tradicionales como un manejador de contenido es la replicación instantánea y confiable de archivos entre múltiples máquinas.
Se puede? Si, pero se requiere diferentes estrategias, más trabajo y más mantenimiento. En este post vimos diferentes opciones para lograrlo que espero que les ayuden a tomar mejores decisiones.
Photo by lenards - http://flic.kr/p/72qFP4