Etiquetas

, , , ,

Recibo muchos emails con consultas por tema de Amazon AWS, cuando son breves y concretas las contesto, cuando no, que paguen una consultoría. Una cosa es contar las experiencias para todos, otra muy distinta solucionar gratis  los problemas de una empresa con la que no tengo relación.Hace unas horas recibí uno largo, pero como tiene preguntas interesantes lo contesto, pero para todo el mundo ;)

¿Qué documentación y/o bibliografia es la más adecuada para adiquirir un buen criterio del cloud computing y más concretamente de AWS?

Hay un libro que me gustó para principiantes: Programming Amazon EC2 (ver descuentos para clientes de Amazon).

Un libro genérico pero que considero imprescindible si haces proyectos webs: Web Operations.

Si trabajas con MySQL, High Performance MySQL es un libro obligatorio.

Los podcasts especial sysadmin y el Amazon EC2.

En tu post desaconsejas a las startups empezar con Amazon, ¿Mantienes esa opinión después de la reacción de Amazon (si es que la ha habido)?

Mi frase literal en el apunte de la crisis con Amazon fue:

Por ahora y mientras no haya esa aclaración técnica de cómo será en el futuro, no aconsejaría a ninguna startup que se mudara allí: te pueden arruinar las vacaciones, y afectar a la familia. Me ha pasado, en el peor momento posible

La sigo manteniendo, con el condicional. Como conté y enlacé en el apunte anterior, Amazon ha pedido disculpas y promete mejorar el sistema (además del problema de infraestructura, se les sumó un bug en el software de gestión de las copias (snapshots) de los EBS). Espero que sea así, los EBS son un sistema crítico para la infraestrctura de Amazon. Son prácticamente equivalente a un SAN (sistema remoto de almacenamiento de bloques) con replicación similar al DRBD, por lo que deberían ser muy fiables. Pero tanto en el fallo de unos meses en EEUU como en este último en Dublín, fueron los EBS los que causaron los mayores dolores de cabeza (nosotros pedimos trés “discos” que no se pudieron recuperar). Evidentemente no están suficientemente probados en una arquitectura tan compleja (con decenas o cientos miles de servidores) como la de Amazon.

Si no fuese por eso, diría que Amazon es lo mejor que se inventó desde el pan con mantequilla.

Si tu arquitectura es distribuida y replicada por naturaleza, no tendrás problemas. Si por el contrario basas tu “tolerancia” en la fiabilidad de EBS, entonces corres el mismo riesgo que nosotros: si no hay nadie experto en Amazon AWS (en las crisis hay que mantener la calma y no hacer experimentos, sólo se deben hacer operaciones bien conocidas) que esté disponible y online (con los comandos de Amazon instalados y funcionando en el ordenador/portátil) estarás jodido. En caso contrario, y con una buena política de backups, migrar tu sistema a otra región o zona de Amazon que esté funcionando no debería tomar más de unas pocas horas en el peor de los casos.

Y para acabar algo un poco más personal, ¿algún consejo para un sysadmin menos que novato que no sabe dónde le han metido?

AWS tiene una ventaja importantísima, puedes hacer pruebas por muy bajo coste, se trata de sólo software y pagar por horas. Dedica tu tiempo de aprendizaje para eso.

Antes de comenzar, diseña la arquitectura que deseas independientemente de Amazon, luego intentas montarla. No es tan difícil, una vez conocidos los conceptos fundamentales de Amazon, que no son tan obvios. Usan una terminología específica y muy de ellos, con conceptos fáciles pero la primera vez que lo vez te suenan a chino: instancia (servidor virtual), AMI (imagen de arranque de las instancias), elastic IP (IP públicas estáticas y reasignables sobre la marcha), EBS (dispositivos de bloques remotos), ELB (balanceador de carga), launch configuration (cómo arranca las instancias el ELB), RDS (bases de datos admnistradas por ellos), regiones (en países o ciudades), zonas (centros de datos independientes), grupos de de seguridad (reglas del firewall, que por defecto tiene los puertos cerrados hacia afuera, y todos abiertos entre instancias), etc.

Además la documentación de Amazon es demasiado formal, y los comandos son largos y demasiados “verborrágicos” (cosa de javeros y xmleros) que no ayudan nada al principiante. Yo también sufrí ese problema, me salía caspa cuando lo estudiaba (y no había tutoriales y apuntes de blogs como ahora), pero una vez coges los conceptos enseguida empiezas a ver la luz.  También hay que tener en cuenta que la consola web cada vez tiene  más funcionalidades, así que los comandos se usan sólo para las tareas más complejas o sofisticadas.

Aunque administrar una instancia (o servidor) en Amazon es igual que administrar uno normal (incluso diría que más fácil, por el tema del arranque y recuperación que genera tantos malos rollos y miedos cuando son servidores físicos remotos), hay que tener en cuenta algunos puntos claves que podrían darte desagradables sorpresas si no las conoces:

  1. Todos los dispositivos de las instancias son compartidos, no sólo la CPU, también la interfaz de red y el ancho de banda (y creo ya da muchas pistas sobre variabilidad y latencia).
  2. A cada instancia se le asigna una prioridad (que no un ancho de banda reservado) para acceder a la red, depende del tipo. Las normales tienen “alta”, pero las de mucha memoria tienen menos prioridad. Esto significa que no tienes el ancho de banda sólo para ti, que si generas mucha E/S afectará a la red, que hay más variabilidad que en un servidor y red dedicada, que si genera mucho tráfico tienes que usar una instancia de las “normales”, una de “mucha memoria” no sirve.
  3. Los EBS son dispositivos de red, y compiten con todo el otro tráfico del servidor de la instancia, y su rendimiento es muy inferior al de un disco físico. Había hecho varias mediciones, leía y escribía unos 22.000 bloques/por segundo. Luego de la caída de Dublin noté que iban mejor, hice las mismas pruebas y superaban los 50.000 bps (aunque no estoy seguro que la mejora haya sido posterior, o que no sea sólo coyuntural o temporal). Ten en cuenta que si alcanzas el límite de tráfico en la red, no vale de nada que tengas RAID por software de EBS (es muy usual), el cuello de botella sigue en la red.
  4. Por las restricciones de los EBS que comenté, una base de datos te irá muy mal si tiene que hacer mucha E/S. Pero si tienes la memoria y buffer ben configurados para minimizar esa E/S (básicamente mucha memoria RAM asignada), el problema desaparece. Alerta con este tema.
  5. Si no eres experto administrando bases de datos MySQL (también han agregado Oracle recientemente) y configurando slaves para la replicación, usa el RDS. Es 10% más caro que una instancia equivalente, pero funciona muy bien, incluso son algo más rápidos que el MySQL en una instancia normal (se sospecha que usan arrays de EBS). Además puedes crear slaves para distribuir carga o hacer consultas “pesadas” con un par de clics en la consola web.
  6. Por el doble de precio del RDS puedes conratar el Multi AZ, que en pocas palabras significa una réplica sincronizada en otro CPD otra zona y que te hace un failback automático si falla el primero (aunque en la caída de Dublín, también fallaron).
  7. A las pocas semanas terminarás teniendo chuletas para ejecutar las tareas más habituales (como actualizar el software y generar nuevos AMI de arranques), y harás copy&paste en vez de estar escribiendo comandos larguísimos. Eso está muy bien, pero recuerda que en situaciones de crisis lo normal ya no funciona, por lo que es más importante que recuerdes bien los “conceptos” más que los comandos (que se encuentran fácil con Google, y el –help de los comandos suele ser bastante autoexplicativos, casi un man).
  8. Con AWS (y todos los VPS similares) te olvidas del hardware y sólo piensas en software y datos, es una ventaja enorme. Pero es importante que haya otra persona que conozca en profundidad esos conceptos de Amazon, los comandos y la arquitectura de tu sistema (no te fíes de documentación, no suelen servir de base para crisis, sólo de consulta de temas específicos). Si no te pasará como a nosotros, que si te pilla desconectado la empresa queda en pelotas (lastimosamente no hay demasiada gente que lo domine, por allí veo oportunidades de consultoría y “salvatajes”).
  9. Cuando ocurre una crisis, lo fundamental es recuperarla lo antes posible, pero es mucho más importante es que no la cagues con los datos.  Con los nervios es muy fácil cargarse el backup completo de una base de datos: mucha frialdad, tranquilidad, olvídate del mundo exterior y ejecuta con tranquilidad y sin prisas, pensando y releyendo varias veces cada comando que estás a punto de ejecutar. Esto lo aprendí con la edad, porque hasta no hace mucho los nervios me traicionaban y cometía varias cagadas en el proceso (afortunadamente siempre fui exagerado haciendo copias de ficheros antes de hacer cualquier comando peligroso, ¡vaya si me salvaron el culo! ;) ).
  10. Siempre es mejor tener diez items que nueve.

Me estaba olvidando.

Cuando creas instancias puedes hacerlo en diferentes CPDs zonas, en Dublin hay tres zonas, a, b, y c (la letra no dice nada de la localización precisa, es sólo un distintivo que depende de cada cuenta, la a para uno puede ser la b o c para otros clientes). Pero no te entusiasmes y cometas el error de distribuir tus servidores en zonas diferentes sin duplicación real. Algunos piensan que así se disminuyen los riesgos sin necesidad de replicar, pero es lo contrario. Si pones la base de datos en una y los servidores webs en otra, la probabilidad de fallo de ambos se multiplica, exactamente igual que con un disco RAID0. Y nada te asegura que no se joda la zona de la base de datos y pieras lo más importante (levantar servidores es muy fácil y rápido, tardan 3 minutos). Además las latencias son ligeramente mayores, te cobran por el tráfico entre zonas diferentes, y dependes de más equipamiento. Si quieres distribuir entre zonas, no queda más remedio que duplicar (como con un disco RAID1).

La solución en todo caso es hacer los backups en un servidor en otra diferente, en el S3, que es muy fiable, muy rápido desde Amazon, y ya se encarga el sistema de S3 de la replicación entre CPDs diferentes. Y por supuesto, no está demás hacer backups cruzados entre serviodores, por si S3 también falla (no conozco casos), o para recuperarlos más rápidos (basta con un scp en el peor de los casos). Otro truco es hacer backups en dos buckets (algo así como “dominios”) diferentes de S3.

Otro que me olvidaba, si tienes un servidor NFS con muchos accesos, nunca uses NFS4 en Amazon, genera mucho tráfico adicional para cada operación de stat() y open() en los clientes, independientemente de su configuración de cache. En Amazon esto se nota mucho. En cambio el NFS2 y 3 van como un seda.