0.07 % des données hébergées par Amazon ne seront pas récupérées

Ce premier couac du Cloud montre-t-il la nécessité d'un back-up local ?

Mise à jour du 02/05/2011 par Idelways

Amazon vient de publier la rétrospective de la panne étendue de sa région est des États-Unis, ayant provoqué l'indisponibilité prolongée de la plateforme EC2 (Elastic Compute Cloud) et la perte irrécupérable de 0.07 % de ses données.

Techniquement, il s'agit d'une « panne en cascade » étant survenue à la suite à la tentative d'augmentation des capacités réseau de la région est.

Il s'agit d'une opération de scalabilité habituelle pour Amazon qui a cette fois dérapé en raison d’une erreur humaine compliquée par un bogue logiciel. Le tout, a fait basculer l'ensemble du réseau de cette région vers le mauvais routeur.

Un réseau secondaire redondant du sous-système de stockage EBS (plus lent, de faible capacité et habituellement réservé aux sauvegardes et à l'intercommunication) a donc subitement reçu tout le trafic de la région, plombant tout le système.

Les volumes de stockage EBS fonctionnent de paires en réseau, un volume primaire et un volume secondaire plus lent destinés à la sauvegarde. Chaque EBS est composé de clusters contenant des noeuds, et chaque noeud agit comme une unité de stockage distincte.

Pour préserver l'intégrité des données, il existe toujours deux copies du même noeud (re-mirroiring).
Si un noeud n'arrive pas à trouver son partenaire pour y écrire les données de sauvegarde, il refuse de fonctionner (en lecture comme en écriture) et tente sans relâche jusqu'à ce qu'il trouve un noeud de remplacement.

Si la correction de la défaillance initiale a été rapidement réussie, le rétablissement du fonctionnement normal du système, conçu pour ne plus « faire confiance » aux noeuds défaillants, a pris beaucoup de temps.

À la correction de la défaillance initiale, le réseau secondaire a été largement saturé et de nombreux noeuds principaux n'ont pas pu reformer leurs paires et n'ont pas pu donc « re-mirroirer » correctement.

Cette situation a été compliquée par le nombre sans cesse croissant des demandes de création de nouveaux noeuds en attente, ayant amené les ingénieurs d'Amazon à désactiver la création de nouveaux noeuds. Ce qui a provoqué ce que qualifie Amazon de « tornade de re-mirroiring »

Un bogue logiciel est venu compliquer la situation : quand de nombreux noeuds EBS annulent leurs requêtes de re-mirroiring simultanément, ils tombent en panne et amènent davantage de noeuds à vouloir se mirroirer.

Les ingénieurs d'Amazon ont donc dû localiser physiquement et un par un les noeuds défaillants et ont du les reconnecter manuellement pour former de nouveaux noeuds fonctionnels.

De plus, la récupération de 2.2 % des données a été effectuée manuellement.

L'entreprise reconnait en tout cas ses erreurs, aussi bien sur le plan technique que sur la mauvaise gestion de la crise qui a essuyé de violentes critiques. Des crédits de 10 jours seront offerts à tous les clients affectés par cette interruption de service.

Amazon recommande à ses utilisateurs une série de mesures antidésastres, mais n'explique pas le sort ni les raisons de la perte des 0.07 % des données, un chiffre d'apparence dérisoire, mais qui représente à l’échelle d’Amazon des quantités colossales d’informations.

Source : Amazon

Et vous ?

Que pensez-vous des explications d'Amazon ?

0.07% des données hébergées par Amazon ne seront pas récupérées
Ce premier gros couac du Cloud montre-t-il la nécessité d'un back-up en local ?

À la suite d'une panne étendue ayant frappé les infrastructures d'Amazon, et au terme de l'opération de restauration, il s'avère que des parties non négligeables des données confiées au géant du Cloud Computing ne peuvent être récupérées.

Une histoire qui sème le doute sur la fiabilité du Cloud et montre la nécessité des sauvegardes locales.

Le tableau de bord de l'état des Amazon Web Services (AWS) a en effet affiché brièvement que 0.07 % des données stockées dans la région est des États-Unis ne peuvent être complètement restaurées.

Sur la même page, Amazon avait fait savoir qu'il enquête sur des problèmes de connectivité avec EC2 (Elastic Compute Cloud), le sous-système qui offre un accès « on-demand » flexible aux capacités de calcul à travers le Web.

La panne qui a affecté de nombreux sites de renommés (dont FourSquare, Quora et Sencha) aurait été déclenchée par un « effet réseau » ayant « re-mirroirer » un grand nombre d'Elastic Block Store (EBS) des centres de calcules d'Amazon de la région est.

Ces EBS assurent le stockage des données liées généralement à des instances Amazon EC2. Les données qui y sont stockées sont censées le rester même lorsqu'une instance EC2 est indisponible.

Samedi passé, l'entreprise avait signalé que la majorité des EBS affectées ont été restaurées et que la récupération du reste n'est qu'une question de temps. Mais L'entreprise a fini par reconnaitre que 0.07 % des données enregistrées dans la région est des États-Unis ne peuvent être restaurées et a assuré prendre contact avec les clients concernés pour discuter des mesures nécessaires.

Si cet incident provoque beaucoup d'interrogations et de doutes quant à la fiabilité du Cloud, il a aussi le mérite de rappeler qu'aucun système n'est parfait ni infaillible, malgré les efforts des fournisseurs des services Cloud pour mettre en place des architectures « multitenants » avancées pour réduire le nombre et la sévérité des pannes.

Une stratégie de sauvegarde, par exemple en local, en complément des services Cloud, semble donc encore indispensable pour les données les plus critiques des entreprises.

C'est en tout cas ce que semble montrer ce premier gros couac du Cloud.

Source : New York Times

Et vous ?

Qu'en pensez-vous ?