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 2011-04-27 14:26:03, par Idelways, Expert éminent sénior
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 ?
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 ?
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 ?
-
sevyc64ModérateurIl 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.le 27/04/2011 à 16:24 -
Julien BodinMembre éclairé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.le 27/04/2011 à 15:20 -
UtherExpert éminent sénior0.07% c'est pas grand chose.le 27/04/2011 à 15:28
-
UtherExpert éminent séniorC'est pour ca qu'un hébergeur sérieux a au moins une sauvegarde en local et une sauvegarde sur un site séparé.le 30/04/2011 à 0:46
-
ThornaMembre éprouvéExcellent lapsus qui donne tout son sens au fameux "cloud" : ça "could" marcher, mais des fois, ça marche pas !le 30/04/2011 à 8:43
-
TabMembre avertiEn 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êmele 27/04/2011 à 15:01 -
FaerethMembre actif
En même temps si tu lis les derniers commentaires ca sent le Hoax...
Ou alors ce sont vraiment des irresponsables.le 27/04/2011 à 15:32 -
ProgValMembre éclairéle 27/04/2011 à 15:14
-
ProgValMembre éclairéAh oui, j'avais zappé la deuxième page de commentaires.le 27/04/2011 à 15:35
-
shkyoMembre expérimenté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...le 27/04/2011 à 16:14