Pocas personas deben no haber escuchado del problema que tuvo Amazon para mantener sus cloud services funcionando estos días y, si no lo sabían directamente, esta es la lista de sitios o servicios afectados de una manera u otra por la disponibilidad: Foursquare, Quora, Reddit, Hootsuite, ow.ly, SCVNGR, Discovr, Wildfire, Livefyre, CampgroundManage, Totango, ESchedule, ZeHosting, Recorded Future, PercentMobile, ELog.com, About.me, ECairn, Travelmuse, Drupal Gardens, PeekYou, Gamechanger.io, hasta The Cydia Store pero la pregunta real es ¿fué esto una muestra de la debilidad del Cloud Computing o una muestra de su fortaleza y de como planificar la infraestructura que uno tiene en la nube?
“Si tus sistemas fallaron en el Amazon Cloud esta semana, no fue culpa de Amazon. Ustedes consideraron que esto era un problema aceptable o simpelemente fallaron al diseñar para la arquitectura de Amazon” George Reese en O’Reilly (fundador de enStratus)
Y pese a lo impactante de la frase, creo que debo estar de acuerdo, más de un servicio abre instancias en Amazon y, esto lo digo sin conocer ni siquiera de cerca la arquitectura de Amazon, muchos piensan que el concepto de “servicios en la nube” ya los protege de todo…
Al usar ese tipo de razonamiento uno deja de pensar en el desarrollo de redundancia para sus propios servicios y por eso nota de Reese es realmente buena, como es buena la nota del CEO de BigDoor al decir porque es capaz de perdonar este tipo de caídas (por sus ventajas de escalabilidad y costos elásticos)
Pero también es cierto que vale la pena leer la nota del CSO de Joyent acerca de los problemas que la arquitectura de Amazon presenta; como también la de como Twilio piensa en su propia redundancia pero de proveedores.
Entonces me pregunto realmente si esto es un problema para aquellos que confían ciegamente en el concepto de “cloud computing” como punto de salvación celestial sin entender realmente que riesgos incluye o como entender las arquitecturas de los servicios para salir adelante… creo que este golpe a la confianza ciega que muchos tienen va a ser genial para mejorar el entendimiento del cloud-computing y de los proveedores de plataformas (PaaS) como servicios en los cuales hay concesiones que hacer y que entender antes de saltar a estas plataformas sin haberlas entendido seriamente.
7 respuestas en “Amazon Web Services y la redundancia de la nube”
El incidente solo afecto una de las availability-zones ( us-east-1d ) de North Virgina. En esa zona yo tenia un una instancia corriendo y un par de volumes EBS. Cuando supe del problema y vi habia perdido el acceso a la instancia EC2, simplemente dispare otra instancia a partir de un snapshot ( backup en S3 que se habia generado unas horas antes ) en otra availability-zone. Todo el proceso para volver a estar arriba tardo menos de 4 minutos.
Amazon te da un centro de computos en la nube y al igual que un centro de computo tangible, uno puede tener la informacion critica en un solo equipo y cuando cae se pierde todo o bien puede usar la potencia del centro de computos y tener armada una estrategia tolerante a fallos. Es mas, yo tenia la posibilidad de facilmente re-lanzar mis snapshot en cualquiera de las availability-zone de North Virgina ( como dije, solo una fue afectada ) pero con un poco mas de prevision puedo copiar los volumens a otra “Region” y en minutos tener todo corriendo nuevamente en Singapore, North California, Irlanda o Tokyo
El FUD que hay contra Amazon y el cloud-computing es totalmente injusto
Gustavo,
Tampoco exageremos, no hay FUD hay gente que entiende mas o menos de como es la arquitectura que podes tener y cual es el costo aceptable… Ahora, en serio te parece que de todas las empresas mencionadas a nadie se le ocurrió esto?
Son concesiones que uno hace y nada mas
Gustavo quiero aclarar que la totalidad de las cuatro availability zones fallaron al mismo tiempo. Este detalle es importante. Por eso tuvieron que poner fuera de funcionamiento las APIs y eso hizo imposible para sitios como Reddit, Foursquare y demás recuperarse inmediatamente del outage. Sin mencionar que Amazon había documentado profusamente que hacer un setup multi AZ en una misma región te daba 4 niveles de redundancia, porque se suponía que no representaban un único punto de fallo, cosa que fue negada por el outage.
Jorge
Si cayeron todas la AZ de us-east relamente no lo sabia, cuando me di cuenta de la situacion disparé la creacion ( via script ) de una nueva instancia y sus EBSs desde los ultimos snapshots, lo hice sin especificar AZ. No se si suerte, casualida o que pero la API respondio y levanto una nueva instancia. Recien mas de 48 hs. despues puede borrar los EBS que quedaron colgados en us-east-1d
Ahora estoy leyendo que muchisimo no pudieron acceder a la API ( se habia saturado ) y por lo tanto no pudieron hacer lo que hice, eso es realmente muy grave porque entonces si, al no poder llamar a la API hay un punto unico de falla y toda posibilidad de redundancia desaparece.
Lamentablemente los snapshots estan atados a una “Region” y la unica forma que conozco de hacer redundancia multi-region es levantar un EBS desde el snapshot y sincronizarlo con otro en otra Region
Hola Mariano,
Por favor agregá en la lista de sitios caídos el mío http://www.grippo.com
Todos los que dicen que este incidente muestra la fortaleza del cloud computing, tienen razón, incluyendo los Oreilly que no hacen otra cosa que lobby, pero igual tienen 100% de razón, y ¿como no van a tenerla si cloud computing es bueno para la web?
Por otro lado, quienes quieran desconfiar del cloud computing, tambien tienen muchas razones, porque es cierto que todos vamos aprendiendo on the go. Así es la web, lo siento, no hay otra manera que ir haciendo el camino y caminar al mismo tiempo. Muchos dicen ahora que había que tener un setup multiregión, pero hubiera estado mucho mejor que lo dijeran antes del jueves pasado y no ahora. Sobretodo Amazon que hizo extremadamente complicado poner en marcha un setup multiregión. Hasta el día del outage, tener recursos en multiples availability zones era suficiente. Te daba cuatro niveles de redundancia. Lo que dice el comentarista anterior no es cierto, la totalidad de las cuatro AZ de la región N. Virginia fallaron, todas al mismo tiempo. Sino fuera asi, sitios como Reddit que no es manejado por una banda de adolescentes, no hubiera estado off line 48 horas.
Habiendo dicho que cloud computing es bueno para la web, quizás Amazon no sea el mejor provider. La falta de skills comunicacionales durante la crisis fueron y son espantosas.
Quizás este incidente, favorezca a iniciativas open source de provisión de servicios de cloud computing.
El que piense que algún sistema, sea dedicado, o en la nube, pueda a llegar a ser 100% libre de error que no haga mas backups. Cualquier sistema que haya sido validado tiene posibilidades de error de cualquier magnitud.
Fabricio, los backups no ayudaron en nada a los sitios caidos, entre ellos Reddit, Foursquare. Ese es el punto. La plataforma completa estuvo caída. Los APIs no se ejecutaban. Ahora hasta se especula que puede haber uno o dos sitios que se hayan borrado completamente. Incluso los backups. Aún hoy, hay muchos volúmenes que no fueron recuperados, y están sujetos a revisión manual uno por uno.