Lo incaíble se cayó, Amazon ec2 down

Para los que siguen pensando que "el cloud" es lo mejor por que "no puede fallar"
Un artículo sobre la caída de amazon

Mas datos desde Amazon
Amazon Elastic Compute Cloud (N. Virginia) Instance connectivity, latency and error rates.

• 10:26 AM PDT We have made significant progress in stabilizing the affected EBS control plane service. EC2 API calls that do not involve EBS resources in the affected Availability Zone are now seeing significantly reduced failures and latency and are continuing to recover. We have also brought additional capacity online in the affected Availability Zone and stuck EBS volumes (those that were being remirrored) are beginning to recover. We cannot yet estimate when these volumes will be completely recovered, but we will provide an estimate as soon as we have sufficient data to estimate the recovery. We have all available resources working to restore full service functionality as soon as possible. We will continue to provide updates when we have them.
• .....
• 1:41 AM PDT We are currently investigating latency and error rates with EBS volumes and connectivity issues reaching EC2 instances in the US-EAST-1 region.

Amazon Relational Database Service (N. Virginia) Database instance connectivity and latency issues

• 10:35 AM PDT We are making progress on restoring access and IO latencies for affected RDS instances. We recommend that you do not attempt to recover using Reboot or Restore database instance APIs or try to create a new user snapshot for your RDS instance - currently those requests are not being processed.
• ......
• 6:29 AM PDT We continue to work on restoring access to the affected Multi AZ instances .......
  
• 1:48 AM PDT We are currently investigating connectivity and latency issues with RDS database

Lo dicho, la nube es eso, una nube que en cualquier momento se puede disipar o convertirse en una tormenta....

 

Un poco más sobre la noticia....
Amazon Server Outage Blanks Popular Websites

 

11:09 AM PDT A number of people have asked us for an ETA on when we'll be fully recovered. We deeply understand why this is important and promise to share this information as soon as we have an estimate that we believe is close to accurate. Our high-level ballpark right now is that the ETA is a few hours. We can assure you that all-hands are on deck to recover as quickly as possible. We will update the community as we have more information

 

IM, lo tuyo es odio profundo a la nube, jajajaja.
Y es que no hay nada infalible

 

No, no es odio por "la nube", la utilizamos mucho antes de que estuviera de moda, es lógica, realidad y experiencia con hardware

Hay una cosa clara, que ya comente en algún otro post, cuando has trabajado con unidades de almacenamiento grandes, distribuidas y duplicadas que son usadas por miles de instancias, sabes que una replicación es algo que siempre se va a tomar su tiempo.

En un caso como este, cuando cae la unidad "A" el sistema intenta relanzar miles de instancias simultaneas en la unidad "B", a la vez que intenta resincronizar esta con la "A" y hay es cuando explota, porque el gran problema de la nube es el I/O.

Insisto, "la nube" es muy buena para investigación y cálculo científico o una empresa grande que necesite muchos recursos, pero muy, muy peligrosa para hosting compartido que es lo que están poniendo de moda todos los comerciales...

De momento lleva más de 12 horas sin solución y tampoco saben dar una ETA ni siquiera aproximada....

 

Fernando gracias por tus aportes informativos técnicos. Enserio, has pensado en lo que te dije de montar una escuela para hosters? Seguro tendría éxito.

No te puedo dar más karma positivo:

Tu debes de esparcir algo de Reputación a otros usuarios antes de darle otra vez a ideasmultiples.

Saludos,

 

Secundo la opinión

Para según que cosas, es mejor repartir en cestas pequeñas y totalmente independientes.

 

+1

Si se quiere HA cada uno que se monte su propio tinglado he instale virtuozzo en el nodo entero y tenga varios containers en varios datacenters geograficamente separados.

Eso si es HA. No el Cloud.

El cloud son pamplinas.

 

Aquí la de Google:

http://www.fredberinger.com/google-outage-a-broken-cloud/

Saludos,

 

Por cierto, después de tres días todavía siguen los problemas....

 

Ups ... si 2 de los que tienen mas experiencia implementando este tipo de sistemas como Google y Amazon aún tienen gravísimos problemas, que se puede esperar de los que recién tienen solo un par de meses y ya están ofreciendo "servidores cloud" ... hasta el minuto de todos los que he analizado solo 2 o 3 cumplirían con lo que yo consideraría un verdadero cloud ... los demás son simplemente "grid servers" o mejor dicho un cluster de nodos administrados por un hypervisor, pero muy pocas veces pueden satisfacer los requerimientos "mínimos" a nivel de hadware requeridos para un verdadero sistema cloud con HA.

Concuerdo plenamente con que el principal problema lo tienen a nivel de IO.

Pero yo también lo veo al no contar con backups remotos propios y plataformas compatibles que permitan "por último" reinstalar un sistema sobre otra plataforma similar ... aca solo queda esperar hasta que el problema sea resuelto, no creo que sea sencillo reinstalar un sistema basado en EC2 sobre otra plataforma.

Por lo mismo varias veces he recomendado seleccionar un buen panel de control que haya sido probado sobre múltiples plataformas de virtualización y que pueda ser migrado en forma simple y rápida con un nuevo proveedor.

Si por alguna razón llegara a existir una "caída" mas o menos grave de varias horas a nivel de datacenter ( por ejemplo lo que le pasó hace poco a Wiredtree ), puedo en minutos reinstalar los dominios sobre otra plataforma en otro datacenter y con otro proveedor.

Da una "inmensa tranquilidad" no depender de un proveedor único, siempre que la plataforma a nivel de software sea compatible.

Obviamente que un verdadero sistema cloud con alta disponibilidad y SAN redundantes podría llegar a ser mejor que un VPS con RAID-10, pero la idea es poder mover el mismo dominio sin hacer absolutamente ninguna modificación.

Mientras mas analizo y pruebo los "clouds" ... mas ventajas le encuentro a cPanel

Creo además que el nivel de confiabilidad de un cloud aumenta hasta un cierto tamaño del cluster y posteriormente comienza a decrecer, justamente afectado por la carga del IO, la complejidad del sistema, la calidad del soporte, la cantidad de nodos involucrados, la sincronización, etc.

Mientras mas crece el nivel de virtualización ... mas seguro me siento conociendo la ubicación física de los nodos que tienen mis VPS y los backups de respaldo

 

yo no creo que haya nada incaible. gmail cayo varias veces, los servicios de google tambien. amazon? creo que amazon ha caido no una, dos sino incontables veces ya. De hecho que amazon es uno de los clouds mas inestables, es el mas grande pero nadie lo usa para servicios criticos, sino mas bien para servicios baratos.

Hasta hoy creo que no hay servicios al 100% que nunca caigan. Al menos si empresas gigantes como Google y microsoft han tenido en sus problemas no creo que ninguna otra empresa publicitando que no lo tiene sea cierto. Mi gmail el año pasado casi no anduvo todo un dia y salio hasta en el periodico en dicha ocasion la falla.

 

alvarito ... es muy distinto que se caiga un servicio gratuito como gmail, hotmail o yahoo a que se caiga un servicio pagado y sobre el cual existen ciertas garantías de uptime y rendimiento.

Y muchísimas empresas están utilizando estos sistemas para implementar sistemas críticos, de hecho hay muchas empresas que han migrado parcial o totalmente a sistemas cloud como EC2 y obviamente no pagan US$ 10 mensuales por el servicio sino que varios miles de dólares mensuales ... Sería bueno que te informaras un poco antes de opinar.

Como experiencia para la gente que esta usando servicios AWS es tener replicada la información en otro cloud completamente independiente, ya que en este caso la caída afectó al cloud de Virginia, afectando principalmente los servicios EC2 y RDS que son los más utilizados en servicios online, pero no se vieron afectados los mismos servicios en California, Irlanda, Tokio o Singapur.

Más información en status.aws.amazon.com

Obviamente eso implica duplicar los costos, pero aumenta considerablemente la confiabilidad y redundancia global de un sistema.

Es obvio que no existe un servicio 100,00% confiable, pero la idea es poder recuperarse de una caída dentro de un plazo razonable de tiempo y eso en sistemas cloud tan complejos parece cada vez mas complicado.

 

Por fin amazon dio su explicación del problema, que al final y resumido es que fue un problema de I/O

neocomp amazon NO permite manejar replicas automatizadas entre diferentes regiones, es decir si se cae la región, como en este caso, se cae el sistema a menos que tu lo hagas por tus propios medios, cada región es un control de API diferente.

 

NUNCA he mencionado que AWS tenga replicas automatizadas entre diferentes regiones y obviamente uno tendría que implementar una forma de hacer la sincronización, falto tal vez aclarar un poco más el punto.

Básicamente era mencionar que Amazon como otros proveedores de servicios cloud cuentan con distintos farms que funcionan en forma completamente independiente y además que no siempre las caídas afectan a todos los servicios.
Además al contar con una réplica en otro farm permitiría levantar el servicio en corto tiempo mientras se normaliza el servicio principal, principalmente porque demoraría más tiempo montar el servicio en una plataforma distinta a AWS en este caso.

Un servicio 100% cloud debiera ser capaz de mantener y sincronizar replicas automatizadas entre diferentes farms distribuídas en datacenters independientes, pero para eso aún falta tiempo

 

Asi lo tienen montado y eso fué parte del problema, las réplicas, de las réplicas

Todo se extiende, se encarece, se complica y al final la seguridad del failsafe, no es failsafe

Insisto, es mas sencillo y seguro virtualizado en la tierra que "vivir" en las nubes

 

Completamente de acuerdo ... si revisas un post que está mas arriba comenté el hecho de que cuando se llega a un cierto nivel de tamaño de los farms la complejidad global del sistema aumenta proporcionalmente y cuando hay un problema de cierto nivel llega a ser inmanejable ... y ya sabemos que el principal problema que afecta a los clouds es el IO y mientras mas nodos y discos involucrados es peor.

Creo que un "verdadero cloud" va a ser probablemente mucho mas confiable que un VPS tradicional, pero solo hasta un cierto tamaño del cloud, donde las réplicas y el IO puedan ser manejables y permanecer bajo control.

Obviamente AWS está fuera de ese rango de tamaño.

 

De acuerdo a la explicación de Amazon, el problema se produjo al hacer un upgrade de la conexión primaria en esa zona y mientras se realizaba el proceso un router se conectó por error al enlace secundario de baja capacidad y velocidad.

Eso hizo colapsar el enlace secundario y se perdió la conexión con las réplicas, por lo que el sistema comenzó automáticamente a realizar nuevas réplicas ... entrando además en un loop de réplicas

Me gustó el término usado por Amazon "re-mirroring storm" ... calza perfecto y es obvio lo que va a pasar cuando se produce