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:
- 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).
- 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.
- Los EBS son dispositivos de red, y compiten con todo el otro tráfico
del servidorde 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. - 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.
- 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.
- Por el doble de precio del RDS puedes conratar el Multi AZ, que en pocas palabras significa una réplica sincronizada en
otro CPDotra zona y que te hace un failback automático si falla el primero (aunque en la caída de Dublín, también fallaron). - 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).
- 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»).
- 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! 😉 ).
- 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.
Ricardo Galli, de software 
Pingback: Preguntas y 10 puntos claves de Amazon EC2
Así da gusto leer blogs. Hasta a estas horas.
Gracias por la consultoría ‘genérica’.
Y yo que pensaba que migrar hacia Amazon AWS iba a ser facíl. Pero leyendo por aqui veo que puede que no.
Una única pregunta, ya que apenas lo mencionas, ¿qué tan bueno es el soporte para bases de datos en Oracle, o es muy reciente su implementación?
Saludos,
@gallir
* 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.
No se si te estas haciendo el loco o una semana después no entiendes lo que propuse.. It’s the Disaster Recovery strategy, stupid! (en referencia a tu entrada en google+)
* 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).
DRBD entre zonas para DR, eso propuse. No te salva de la caida, minimiza el tiempo de recuperación. Y de paso no estaria de mas poner puppet o chef para construir tus maquinas a partir de S3.
http://stu.mp/2011/04/the-cloud-is-not-a-silver-bullet.html
[ Much of the banter was mainly around how the “AWS outage” had “brought down” these sites, which couldn’t be further from the truth. What brought down these services was poor architectural choices combined with a lack of understanding of the unique characteristics of cloud infrastructure. ]
[ The #1 characteristic that people fail over and over to recognize is that the cloud is entirely ephemeral. Everything from EBS, to EC2, to EBS volumes could vaporize in an instant. If you are not building your system with this in mind, you’ve already lost. ]
La pregunta es: si tan eras consciente de la fragilidad de EBS, porqué no hiciste algo al respecto? y no me digas que backup diario, que se da por supuesto.
En serio, puedes escribir largos artículos para recuperar tu estatus de guru (sic) pero si se cayera tu AZ hoy a las 18h y perdieras todos tus EBS, que pasaria? Que tendrias de recuperar de la última copia y perderias 12 horas de datos.
Como mínimo levanta un slave en otra zona, da igual si se retrasa 1 minuto, es mejor eso que 12 horas.
Joer @gallir, lo que siempre me sorprende de ti es la mala baba con la que te contestan, por ejemplo pero no excluido a, @Oriol. ¡Si que eres bueno haciendo amigos! XDDD
Por lo demás interesantísimo esta mini intro a AWS. Gracias, al leerlo me ha apetecido enterarme más del tema y ya tengo por ahí programadas varias lecturas.
Gracias por la clase.
Si montaras una consultoria seguro que te iria muy bien.
@oriol
Oriol, evidentemente no lees, o tienes serios problemas de comprensión lectora o sólo quieres trolear. Pero te contestaré a esa, y por última vez (y controla esa bilis, que dices una tontería tras otra):
> La pregunta es: si tan eras consciente de la fragilidad de EBS, porqué no hiciste algo al respecto? y no me digas que backup diario, que se da por supuesto.
¿Cómo voy a ser consciente de la fragilidad de EBS si lo venden como de alta durabilidad Amazon EBS volume data is replicated across multiple servers in an Availability Zone to prevent the loss of data from the failure of any single component. ?
Citas además un documento de hace tres meses, cuando la arquitectura del Menéame tiene casi dos años, y ese desastre ocurrió una sóla vez (lo que me hizo pensar no volvería a ocurrir) y que no generó pérdidas de datos como en el caso de Dublín.
¿Cómo voy a adivinar que tienen un bug que los datos de un snapshot se pueden perder (es lo que nos pasó) si dicen explícitamente Amazon EBS provides the ability to back up point-in-time snapshots of your data to Amazon S3 for durable recovery? (y S3 es reconocido por su fiabilidad).
En serio, puedes escribir largos artículos para recuperar tu estatus de guru (sic) pero si se cayera tu AZ hoy a las 18h y perdieras todos tus EBS, que pasaria?
No perdimos 1 EBS, perdimos 3 EBS y un snapshot, pero no perdimos ningún dato. ¿O vas a seguir con «presuntos» que no ocurrieron aunque lo que nos pasó es más grave que perder 1 EBS?
> Que tendrias de recuperar de la última copia y perderias 12 horas de datos.
No sólo que no perdimos datos, los binlogs del MySQL lo tenemos replicados en 2 EBS diferentes, en servidores diferentes y sincronizados a S3 cada hora (y la base de datos también está duplicada en tiempo real en 2 EBS diferentes, en dos servidores diferentes.
Si se quiere dar todavía más seguridad y no perder ni un segundo de datos aunque caigas todos los EBS, es un slave en otra zona. Es la solución más económica y práctica, nada de tonterías de DRBD innecesarios como propones (todos los demás ficheros tienen copia inmediata en S3, como ya expliqué varias veces).
> Como mínimo levanta un slave en otra zona, da igual si se retrasa 1 minuto, es mejor eso que 12 horas.
Levantar desde cero y recuperar los 3 EBS perdidos costó 2 horas, sin perder ni un sólo byte a pesar de haber perdido un servidor y 3 EBS de datos. Nada de 12 horas. Y lo hice, demostrado, ¿cuántas veces más lo tengo que repetir?
Tus ganas de troleo te hacen repetir tonterías que ya fueron contestadas, o decir barbaridades enormes como comparar Menéame con Netflix, o proponer DRBD cuando se soluciona más simple con una réplica slave de la bbdd y tardas casi lo mismo que levantar un servidor NFS nuevo.
Si quieres criticar, critica que no tengamos otra persona que pudiese haber levantado como lo hice yo. Pero esa autocrítica ya me le hice, en cada uno de los apuntes. Todo lo demás que dices, son gilipolleces de alguien que nunca ha pasado una crisis similar como perder 3 discos de una vez, que te borren backups… y que además no puedas conectarte a Internet a solucionaro. Pero por hablar tonterías que no quede.
Ricardo, gracias por el post. Pero también por tu voluntad de compartir. Así mejoramos todos los profesionales y en consecuencia los productos y servicios que ofrecemos, que es precisamente lo que necesitamos cambiar en este país y dejar de hacer de una puta vez chapuzas y trabajillos de segunda y dejar ya de estar a la cola de europa y el mundo.
Los que critican por criticar tienen un problema con su propio ego que les casua ceguera y sordera permanente. De esos tenemos cientos (o miles) y desgraciadamente són los que están arriba. Los que no ven ni escuchan y entonces pasa lo que pasa, mejor dicho, nos pasa lo que nos pasa. La humildad es una herramienta muy útil, más que la verborrea y la prepotencia.
De nuevo graicas.
Pingback: Preguntas y 10 puntos claves de Amazon EC2
@gallir
* Citas además un documento de hace tres meses, cuando la arquitectura del Menéame tiene casi dos años, y ese desastre ocurrió una sóla vez (lo que me hizo pensar no volvería a ocurrir) y que no generó pérdidas de datos como en el caso de Dublín.
Cito un documento de hace tres meses porque el problema entonces fue similar, solo que en otra región y cuento con que lees opiniones de otros cuando afectan a la misma plataforma con la que trabajas. Entonces se demostró que EBS no era tan fiable como se habia vendido.
Es más, cualquiler arquitectura es revisable. Tu mismo hiciste cambios en la arquitectura cuando moviste aws1 a una m1.large sobre EBS, dejaste de usar memcached por xcache, moviste los DNS a route53 y el correo de salida al un proveedor externo. Y de eso hace algo más de un año.
* No sólo que no perdimos datos, los binlogs del MySQL lo tenemos replicados en 2 EBS diferentes, en servidores diferentes y sincronizados a S3 cada hora (y la base de datos también está duplicada en tiempo real en 2 EBS diferentes, en dos servidores diferentes.
En una zona! Ahora imagina que pierdes todos los EBS en esa zona (que podria haber pasado) y que hay un problema con los snapshots de EBS por un bug en el software que se encarga de hacerlos, que es lo que pasó. Si la caida hubiese sido a las 18h tendrias que haber intentado recuperar del último snapshot cuando estuviera funcional. Imagina el snapshot corrupto, entonces deberias restaurar del último dump que guardas en S3, que es lo que hiciste por precaución. Ahi hubieses perdido datos: 12 horas de datos.
No es lo que te ha pasado sino lo que te puede pasar.
* Si se quiere dar todavía más seguridad y no perder ni un segundo de datos aunque caigas todos los EBS, es un slave en otra zona.
Esto es un «aceptamos pulpo, aunque no me guste reconocerlo». Ya tienes algo que revisar.
* nada de tonterías de DRBD innecesarios como propones (todos los demás ficheros tienen copia inmediata en S3, como ya expliqué varias veces).
* Levantar desde cero y recuperar los 3 EBS perdidos costó 2 horas, sin perder ni un sólo byte a pesar de haber perdido un servidor y 3 EBS de datos. Nada de 12 horas. Y lo hice, demostrado, ¿cuántas veces más lo tengo que repetir?
Si replicas los dispositivos de bloques (en los que escribes poco) es instantáneo: desconectas el nodo secundario, lo promueves a primario y lo montas. En definitiva, reduces el tiempo de recuperación. Demostrado.
* barbaridades enormes como comparar Menéame con Netflix, o proponer DRBD cuando se soluciona más simple con una réplica slave de la bbdd y tardas casi lo mismo que levantar un servidor NFS nuevo.
Sobre mi referencia a una arquitectura pensada a partir de que algo puede fallar (como Netflix) tu respuesta fue que era un tema de costes y mi propuesta son 100 euros al mes para reducir el tiempo recuperación. Es un ajuste, no un rediseño. Es pensar en que, como se ha demostrado, la nube es flexible pero frágil.
Lo que dije inicialmente fue literalmente que «Con tener una máquina en otra AZ como slave y duplicando la partición que exportas por NFS con DRBD basta». Al final voy a tener que hacer un dibujo, hablo de una instancia en otra zona haciendo lo siguiente:
1. Slave de MySQL. Esto lo has aceptado.
2. Copia del par de dispositivos de bloques sobre los que tienes montado el NFS (un par de EBS atachados a aws0) con DRBD.
El tiempo de recuperación es el que tardes en levantar las instancias en la otra zona porque ya tienes los datos ahi, accesibles, al instante y no hace falta que los bajes de S3 ni recuperes de backups.
Lo que me jode más es que estoy seguro de que si esta conversación fuera privada no hubiese habido tanta bilis por parte de ninguno de los dos y, de hecho, no tengo ningún inconveniente en seguir por mail.
Pingback: de la red – 20/08/2011 | Notas tecnológicas
@Oriol: Me da, no sé por qué, que te has encelado en que Ricardo te dé las vendiciones a lo que propones aunque decida que para Meneame no merece la pena y que una posible perdida de datos es asumible.
Hace mucho tiempo aprendí, por las malas (me costó un examen ;D ) que la mejor solución es siempre la más simple de todas las posibles. La replicación supone no sólo duplicar problemas y puntos de fallo, añade otros nuevos, por lo que ha de ser usado cuando se requiere.
Según parece tu pretendes crear una estructura a prueba de todo, que falle la zona al completo y no se pierda un solo byte con una parada de unos pocos minutos… Ricardo es realista y no pretende pensar en cómo se haría algo que no necesita. El planteamiento de Ricardo parte de lo que necesita Meneame y de lo que es razonable y asumible para dicho entorno, a partir de ahí crea la estructura más simple que mejor cumple los requisitos.
Estoy convencido que alguien que es capaz de hacer desde cero todo lo que Ricardo ha hecho no desecha una idea sin antes meditarla, lo que me da que pensar que tu solución plantea más problemas que ventajas respecto a la estructura de Meneame que es lo que a Ricardo le importa, ya que un planteamiento teorico genérico me da a mi que no le interesa mucho, al menos en estos momentos.
Un saludo
@Fernando
No necesito a Ricardo para saber que lo que propongo es válido y que si fuera mira la decisión no dudaria aplicarlo. La replicación, en este contexto, tiene sentido ya que mantener una máquina en otra zona, por mucho que introduzcas algo de fragilidad en la arquitectura, proporciona beneficios mayores sin un coste excesivo.
Otra cosa es que a meneame, como negocio, le de lo mismo estar caido 10 minutos que 2 horas. Al final cada uno hace lo que quiere en su casa.
Luego está el tema de las formas. Me dedica un post entero a la respuesta y dice que soy un troll, que digo gilipolleces, que no tengo experiencia, que tengo problemas de comprensión lectora y que me dejo llevar por el hype. Claramente se le va de las manos.
Por otra parte seamos claros: aqui Ricardo es el rey, pero solo porque es un tuerto en un pais de ciegos. Estos posts no tienen el nivel que se le presupone, mi único consejo es que contrasteis leyendo a gente de fuera siempre. En el contexto EEUU y si no fuera el founder estaria despedido.
Ricardo, muchas gracias por el post. Es de gran ayuda para gente que estamos arrancando startup, comenzando con Amazon y toda esta movida.. Impagables desde luego tanto este como otros anteriores contenidos sobre el mismo tema. Quien ha renegado con ello de sobra sabe que follón es comprender la terminología, puesta en marcha, etc (excepto seguramente para los «mas listos del portal» de toda la vida que lo saben todo) Me imagino que gestionar una crisis de esta entidad y naturaleza completamente nueva e imprevista tiene que ser sencillamente la puta ostia. Gracias por estar compartiendo con los demás tu experiencia con este nivel de detalle.
Por otra parte queda muy claro de que va el «personal» y sus complejos y rollos mentales. Yo no le daría mucha bola.
Saludos!
Pingback: De como un rayo se cargó una nube | Saasmania