Etiquetas

, , ,

En mi apunte sobre los que nos pasó con Amazon AWS dejaron todo tipo de comentarios, la mayoría razonable, pero otros simplemente comentan de oídas, sin conocer las características, precios, limitaciones de la arquitectura de AWS… e incluso temas básicos de costes. El siguiente comentario es un estereotipo del que repite blablás con mucha autoridad sin conocer a fondo el problema de lo que ocurrió, por lo que aprovecharé para contestar:

Varias cosas:

1. AWS falló, falla y fallará. Algunos caisteis pero muchos otros aguantaron. Por poner un ejemplo, la caida de abril no afectó a Netflix. Es una cuestión de arquitectura pero sobretodo de previsión. Al “chaos monkey” me remito.

2. No es necesario comerte tanto el coco en redundarlo todo. Con tener una máquina en otra AZ como slave y duplicando la partición que exportas por NFS con DRBD basta. Económico y rápido de implementar.

3. Tienes varios SPOF en la arquitectura pero el más evidente eres tu. Lo primero que debes buscar es una solución a eso.

Saludos.

Vamos por el punto 1.

Por supuesto que Amazon fallará, por ello teníamos planes de contingencia, con backups en múltiples sitios y rehacer prácticamente la infraestructura completa en 4 horas, como expliqué en el apunte. Lo que no pensábamos que podía ocurrir es que los 4 EBS (repito, vendidos como sistema de alta disponibilidad y persistencia) de una instancia fallasen al mismo tiempo, y que además Amazon fuese incapaz de recuperar los datos de 3 de ellos.

¿Que podríamos haber pensado que esto iba a ocurrir? Sí, por eso el plan de 4 horas máximo estimado.

¿Por qué no se pudo hacer? Porque nunca pensé se llegaría a este extremo, y en el peor de los casos posibles. Ese fue mi error.

Mi otro error es no haber dejado una “chuleta” para que podamos recurrir a una persona externa (Menéame no puede pagar otro sysadmin experto en Amazon AWS para hacerlo, ni Benjamí u otros admins se pueden dedicar a perder semanas para adquirir experiencia) pudiese hacerlo si yo no estoy disponible. Esto sí debe solucionarse, por eso anoche ya hablé con las tres personas más expertas en Amazon AWS que conozco (además son de Mallorca y amigos desde hace muchos años, Guillem Cantallops, Antoni Aloy y Bernardo Cabezas) para que puedan hacerlo ellos en situaciones de emergencia similares (que espero nunca ocurran otra vez, si no, es para dejar Amazon espantados y sin duda alguna).

Pero vayamos a la frase matadora que indica una carencia total de economía básica, de evaluación de riesgos y del sentido común más elemental:

 la caida de abril no afectó a Netflix

¿Cuánto deja de facturar Netflix si está un día “offline”? La módica suma de 8.5 millones de dólares.

¿Cuánto deja de facturar Menéame si está un día “offline”? Con [mala] suerte, la impresionante suma de 500 euros.

Creo que no hace falta seguir discutiendo sobre la cantidad de dinero que puede u debe invertir una y otra, o la cantidad de servidores que tiene cada una, o la cantidad de expertos y contacto directo con Amazon que puede tener una u otra, o la importancia que da Amazon a una empresa como Netflix y a Menéame.

Independientemente de eso, está claro que Menéame tiene que invertir los mismos recursos que empresas como Netflix para asegurar el mismo nivel de disponibilidad </sarcasmo>

El siguiente punto:

2. No es necesario comerte tanto el coco en redundarlo todo. Con tener una máquina en otra AZ como slave y duplicando la partición que exportas por NFS con DRBD basta. Económico y rápido de implementar.

La primera parte propone tener el slave en otra región, sí, pero eso hubiese implicado un coste adicional de unos 200 € adicionales al mes si queremos que sirva de failback, y en este caso no nos hubiese solucionado nada, porque no hubo problemas con la base de datos ni con sus backups (que toman 110 minutos en recuperarse). Es decir, no es gratis, y no hubiese ayudado.

Sin embargo, sí estamos pensando (si seguimos en Amazon) en usar RDS con multi-AZ y failback automático. Eso rebajaría las dos horas de recuperación a unos pocos minutos, con un coste adicional de unos 300 € mensuales (pero nos quita todo el trabajo de administración de la base de datos y su replicación). A estos costes adicionales, si se quiere dar tolerancia a los servidores webs, hay que tener en cuenta el coste adicional de las instancias webs autobalanceadas que deben arrancarse al menos a pares en dos zonas diferentes, lo que implica un coste adicional de unos 200 € mensuales (estimación aproximada).

Sólo con esto ya subimos el coste de 1300 € al mes a 1800 €, con un sistema más complejo de administrar (lo que incrementa también costes). ¿Vale la pena hacerlo? Posiblemente, en eso estamos pensando, porque en esta caída, el sistema RDS con fallback automático (Multi AZ) también falló en muchas instancias.

Aún así, eso no hubiese solucionado el problema, y viene la segunda parte, el servidor NFS (que fue el fallo más gordo) con DRB. Dice:

duplicando la partición que exportas por NFS con DRBD basta. Económico y rápido de implementar.

Lo siento, pero no tiene idea de lo que está hablando. Es lo que tiene el hablar basado en el boca oreja sin experiencia.

Para tener una idea de la complejidad de montar un DRBD con múltiples zonas en Amazon, este documento, hecho en colaboración con gente de Amazon AWS (que lo ha “bendecido”) Aún así, la arquitectura propuesta no soluciona el problema de que una zona completa quede fuera de servicio, como ha pasado. La solución que propone consiste de 2 servidores para el DRBD en distintas zonas, y un tercer servidor NFS que hace el failover. Ya hay un problema evidente muy relacionados: costes y mayores latencias.

El acceso a un fichero remoto implica el doble de tráfico por red (sin contar con el tráfico al EBS, que también va por red), del cliente al NFS y del NFS al nodo DRBD (además si está en otra región la latencia es mayor). Además la interface de red de cada instancia se comparte con las demás en el mismo hardware, por lo que van priorizadas según el tamaño de la instancia (y con una variabilidad enorme). Es decir, para aproximarnos al máximo al rendimiento actual deberíamos tener dos servidores adicionales de 200 € cada uno, 400 € más de costes mensuales.

Pero eso no es lo peor, si miráis la arquitectura, el punto de fallo sigue siendo uno, por lo que toca agregar como mínimo un segundo servidor NFS de 200 € al mes, e incrementar aún más la complejidad de la arquitectura y la dificultad de mantenimiento bastante elevada de hacer que las instancias “auto balanceadas” hagan el failover automático a otro servidor NFS. Aún así se podrían hacer trucos, como que las imágenes de arranque (AMI) o el “user data” sean diferentes para cada zona, y las instancias web usen siempre el NFS de su propia zona (lo que implica además inconsistencias temporales que hay que gestionar en la aplicación, i.e. modificar el código de Menéame para tenerlo en cuenta). Con estos “trucos” se incrementaría el coste en 600 € mensuales, por lo que estaríamos hablando de un total de 2400 €, y con un rendimiento NFS bastante peor.

Pero vale, supongamos es asumible. También supongamos que en el peor de los casos admitamos como admisible la inadmisible [pun intended] probabilidad de que estas caídas generalizadas ocurran una vez al año, y que puedan dejarnos 24 horas desconectados en el peor de los casos (que yo esté fuera, sin conexión, y que no haya nadie que pueda hacerlo).

Estaríamos pagando un sobrecoste de 13.200 € al año sólo en arquitectura (sin contar sobrecostes de administración)… para evitar pérdidas de 500 € en un sistema que no es crítico para nadie [*].

[*] Salvo para la salud de sus administradores, que sufren como condenados cuando no funciona.

¿Estamos locos? ¿De verdad que algún informático o sysadmin puede proponer algo así y quedarse tan ancho? Como informático, es algo que no puedo aceptar, todavía. Que profesionales no usen el sentido común para analizar las cosas en perspectivas, y no dejarse llevar por el hype o palabras mágicas que leen por allí. Administrar un par de ordenadores es una cosa, administrar una red con fuertes interdependencias entre componentes diversos, y con limitaciones de “distribución y consistencia” es algo completamente diferente. Por eso ocurren los desastres, sistemas carísimos de mantener, pero que al ser muy complejos fallan aún más si no se tiene un equipo de expertos que sean capaces de hacer un mínimo análisis de riesgos y costes.

Pero es lo que hay. Pero aportemos algo al tema, por si a alguien le sirve.

¿Cuál es la solución al problema de sistemas de ficheros replicados?

La verdad, y como me dijo hoy Guillem Cantallops después de discutirlo anoche, el panorama es bastante deprimente. Sencillamente compatibilizar alto rendimiento con replicación y coherencia es muy complicado. El NFS (versión 3, la 4 va bastante peor en latencia y tráfico) es el sistema de ficheros remoto con mejor rendimiento. Si tienes un sistema web con mucho tráfico y que hace varias operaciones stat() y open() para generar cada página, es la único opción si quieres hacerlo en el orden de centésimas de segundos, y ajustando bien los parámetros de cache en los clientes, por ejemplo como usamos nosotros:

nfs-server:/home /home nfs …, noatime, async, nocto, ac, acregmin=20
nfs-server:/cache /cache nfs …, noatime, async, nocto, ac, acregmin=30, acregmax=180

Si no tienes estos requerimientos de cache local y latencias muy bajas, puedes usar GlusterFS. Es una solución “limpia” y en user space, pero tiene su coste (además de los servidores adicionales), el rendimiento con los stat() y open() ni se aproximan al de un NFS bien configurado.

Si en cambio quieres reemplazar al NFS por un distribuido, la única solución razonable parece ser CEPH, pero el código todavía está en experimental y no todas las distros disponibles en AWS incluyen el módulo para el kernel. La última de Ubuntu ya las incluye, no así la LTS que usamos en Menéame (10.4). Pero es la opción que estoy estudiando y en poco tiempo haré mediciones en EC2 (aunque esperaremos por la siguiente LTS, 11.10, para ponerlo en producción, si lo hacemos).

Si no quieres recurrir a sistemas replicados para reemplazar el super fiable y eficiente NFS, ¿qué harías? Fácil y obvio, crear una imagen de arranque de una instancia preparada para servir NFS, tener varios backups e incluso regeneración automática desde S3. Todo eso lo teníamos, y cuando intentamos arrancar esa instancia, el snaphot estaba corrupto por otro bug que descubrieron durante esta última caída. Sí, me dio ganas de cometer las peores sodomías a los de Amazon, pero estaban lejos, y tampoco hubiese ganado nada.

Shit happens, ante emergencias en sistemas complejos es mejor dedicar la adrenalina en solucionar el problema que cagarse en los demás. Por eso mismo, por la complejidad a gestionar y el sentido común que se requiere, los buenos arquitectos y sysadmins ganan más que los programadores.

Nota: Si tienen problemas de fiabilidad de los EBS, la mejor solución es que Amazon implemente “Multi AZ EBS” similar a como hacen con las bases de datos en RDS. Si un EBS queda inutilizado, hacer el failover automático a la copia en otra zona. Es lo más limpio, y dado que lo han hecho con bases de datos, seguro que lo pueden hacer con los EBS.