mercredi, 11 mai 2011 20:51

La panne d'Amazon Web Services (AWS)

Écrit par
Évaluer cet élément
(0 Votes)

Fin avril 2011, Amazon Web Services (AWS) observe une panne de grande ampleur dans l’est des Etats-Unis. Retour sur cet incident des services de Elastic Cloud Computing (EC2) d'Amazon.

Le saut à l’élastique

La panne aura finalement duré 4 jours : du 21 avril à 0h47 au 24 avril à 19h30. Elle a touché les clients de la côte Est des Etats-Unis comme le site de géolocalisation mobile Foursquare ou le site de questions / réponses Quora. Elle concerne l'Elastic Block Store (EBS), une des briques de stockage de l'offre EC2 d'AWS. Gênant alors que le nuage d'AWS est présenté par Amazon comme "distribué, sécurisé et résistant" ce qui est censé procurer "une énorme fiabilité". Cette fiabilité serait due à la redondance des équipements. Seulement voilà : la redondance seule ne permet pas de garantir la continuité informatique car elle ne permet pas de pallier toutes les menaces.

La tête dans les nuages ?

En guise de mea culpa, Amazon a publié sur son site un document expliquant l'incident. Visiblement, l'erreur est humaine. Tout démarre avec un changement réseau sur une zone du datacenter d'Amazon situé en Virginie du Nord dont l'objectif était d'augmenter la capacité du réseau primaire. Lors de ce changement, le trafic du réseau primaire a été routé par erreur sur un réseau secondaire de plus faible capacité. Finalement, par cette opération, les réseaux primaire et secondaire ont été mis hors service au même moment, isolant des nœuds de cluster. Lorsque la connectivité réseau fut rétablie, de nombreux nœuds de cluster ont cherché à se synchroniser provoquant un "re-mirroring storm". Ces resynchronisations furent bloquées par un espace de stockage insuffisant. La solution fut alors de rajouter de l'espace de stockage mais cette opération prit beaucoup de temps.

Mais Monsieur, le SLA a été respecté...

Selon plusieurs sources le Service Level Agreement (SLA) passé entre Amazon et ses clients se base sur une disponibilité de 99,5%. Mais le SLA ne porte que sur la capacité à se connecter aux instances des serveurs ce qui a été le cas pendant la panne. Visiblement, les conditions du SLA sont à revoir et Amazon serait avisé d'y introduire un Recovery Time Objective (RTO) pour des situations exceptionnelles que l'on peut qualifier de sinistres. De plus, certains clients ont perdus irrémédiablement des données et il n'est pas sûr que le SLA parle de Recovery Point Objective (RPO).

Se baser sur plusieurs datacenters

Les clients d'Amazon qui n'ont pas observé de panne sont ceux qui avaient envisagé et s'étaient protégés de la panne d'un datacenter d'Amazon. En effet, la panne étant localisée sur le datacenter de Virginie du Nord, les 4 autres régions (Californie, Irlande, Singapour et Tokyo) ont continué à fonctionner. Seulement, chaque région a ses propres règles ce qui oblige les clients d'Amazon à un travail important s'ils veulent être présents sur plusieurs régions.

La réponse d'Amazon

En réponse à cet incident majeur, Amazon propose le plan d'action suivant :

  1. Augmenter l'automatisation des changements pour éviter les erreurs humaines
  2. Augmenter les capacités de stockage dans les clusters EBS
  3. Corriger l'implémentation du mécanisme de resynchronisation pour éviter le phénomène de "re-mirroring storm"

Une panne riche en enseignements

Cet incident restera dans la mémoire des ingénieurs d'AWS mais sans doute dans l'esprit de nombreux acteurs. On peut en tirer un certain nombre de leçons :

  • Un système, aussi redondant soit-il, n'est pas à l’abri de panne, d'erreurs humaines, de bugs logiciels, etc.,
  • Le réseau et le stockage sont deux domaines importants à étudier quand on s'intéresse à la continuité informatique,
  • Un bon SLA parle des sinistres et fixe des objectifs en matière de RTO et de RPO,
  • La répartition géographique d'une application critique sur plusieurs datacenters peut prévenir d'une panne réseau localisée dans un datacenter,
  • L'automatisation peut diminuer les erreurs humaines,
  • Et enfin, le Cloud Computing n'est pas une solution magique qui permettrait d'obtenir une résilience sans effort ni réflexion.
Lu 10788 fois
Serge Baccou

Serge Baccou est Directeur Associé d'Alterest. Il est en charge des services Continuité Informatique, Cloud Consulting et Management de Transition.

Plus dans cette catégorie : « BlackBerry Blackout