Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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 ?

Le , par Idelways

0PARTAGES

3  0 
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 ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de sevyc64
Modérateur https://www.developpez.com
Le 27/04/2011 à 16:24
Il n'y a pas besoin de perdre 0,07% pour que ça soit grave. Il suffit par exemple de perdre un cluster sur un fichier essentiel (la base de donnée de la compta par exemple) qui rende ce fichier totalement inaccessible et irrécupérable, pour que la perte soit énorme, pas en terme d'octets mais en termes de données.

0,07% sur plusieurs To de données, oui, c'est énnnoorrrrmmmme

Faites du Cloud, c'est à la mode.

Mais lorsque vous aurez perdus vos données vitales, vous vous rappellerez de l'adage "On est jamais mieux servir que par soi-même", et vous vous souviendrez que vos données vitales, c'est à vous à en prendre soin et non pas les confier à des tiers, fussent-ils de confiances.
13  1 
Avatar de Julien Bodin
Membre éclairé https://www.developpez.com
Le 27/04/2011 à 15:20
Citation Envoyé par abriotde Voir le message
0.07% c'est pas grand chose.
C'est marrant je me suis dis exactement l'inverse. Pour moi ce chiffre est énorme.
Ca se chiffre probablement en To.

En clair il ne faut rien stocker de critique, même si les taux de disponibilités sont plus qu'alléchants on constate bien qu'il y a quand même une probabilité de ne plus être en mesure d'accéder à certaines de ses données.
3  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 27/04/2011 à 15:28
0.07% c'est pas grand chose.
Je dirais au contraire que pour un service professionnel d'hébergement de ce niveau c'est beaucoup.
2  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 30/04/2011 à 0:46
C'est pour ca qu'un hébergeur sérieux a au moins une sauvegarde en local et une sauvegarde sur un site séparé.
2  0 
Avatar de Thorna
Membre éprouvé https://www.developpez.com
Le 30/04/2011 à 8:43
Citation Envoyé par kolodz Voir le message
Donc, le jour où je perd 0.07% de mes données dans le "could", je me dirai :
Excellent lapsus qui donne tout son sens au fameux "cloud" : ça "could" marcher, mais des fois, ça marche pas !
2  0 
Avatar de Tab
Membre averti https://www.developpez.com
Le 27/04/2011 à 15:01
Citation Envoyé par abriotde Voir le message
0.07% c'est pas grand chose.
En proportion non mais en quantité brute c'est pas négligeable...

rien que sur 1000 Go de données ça fait 700 Mo c'est pas rien, alors sur les To que doit manipuler un service de genre ça représente beaucoup quand même
1  0 
Avatar de Faereth
Membre actif https://www.developpez.com
Le 27/04/2011 à 15:32
Citation Envoyé par ProgVal Voir le message
https://forums.aws.amazon.com/thread...9&tstart=0

Je pense que ça se passe de commentaire...

En même temps si tu lis les derniers commentaires ca sent le Hoax...
Ou alors ce sont vraiment des irresponsables.
1  0 
Avatar de ProgVal
Membre éclairé https://www.developpez.com
Le 27/04/2011 à 15:14
https://forums.aws.amazon.com/thread...9&tstart=0

Je pense que ça se passe de commentaire...
0  0 
Avatar de ProgVal
Membre éclairé https://www.developpez.com
Le 27/04/2011 à 15:35
Ah oui, j'avais zappé la deuxième page de commentaires.
0  0 
Avatar de shkyo
Membre expérimenté https://www.developpez.com
Le 27/04/2011 à 16:14
Citation Envoyé par Uther Voir le message
Je dirais au contraire que pour un service professionnel d'hébergement de ce niveau c'est beaucoup.
Je suis d'accord avec toi!!!
Voyons, dans ma boite, on a des sauvegardes d'environ 350Go chaque nuit (et pas en cloud... ) avec 0.07% de perte sur un soucis, ça voudrait dire qu'on perdrait 245Mo...
Ouille!! Surtout si c'est la boite mail du boss...
0  0