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

Idelways · 27/04/2011, 14h26

Amazon explique les raisons de la panne étendue de son Cloud
Et évoque une « tornade de re-mirroring »

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 ?

Faiche · 27/04/2011, 14h43

Au pire, faire un backup auto vers GAE ;p

abriotde · 27/04/2011, 14h53

0.07% c'est pas grand chose. L'expérience montre qu'en local on perd beaucoup plus souvent et plutôt avec des pourcentage de l'ordre de 40%... Alors certes peut-être que certains ont perdu 100%... Mais cela reste le moyen le plus sur au monde.

Tab · 27/04/2011, 15h01

Citation:

Envoyé par abriotde

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

ProgVal · 27/04/2011, 15h14

https://forums.aws.amazon.com/thread...65649&tstart=0

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

Julien Bodin · 27/04/2011, 15h20

Citation:

Envoyé par abriotde

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.

Uther · 27/04/2011, 15h28

Citation:

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.

Faereth · 27/04/2011, 15h32

Citation:

Envoyé par ProgVal

https://forums.aws.amazon.com/thread...65649&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.

ProgVal · 27/04/2011, 15h35

Ah oui, j'avais zappé la deuxième page de commentaires.

shkyo · 27/04/2011, 16h14

Citation:

Envoyé par Uther

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...

sevyc64 · 27/04/2011, 16h24

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.

Thorna · 27/04/2011, 17h45

Petite question : lorsqu'on sait qu'une entreprise sérieuse qui met en oeuvre des solutions de sauvegarde, un stockage performant etc. risque tout de même de subir de temps en temps quelques pertes de données, comment pense-t-on au départ que répartir ces-dites données à l'autre bout du monde, via des liaisons internet plus ou moins disponibles et dont la permanence n'est pas assurée, sur des serveurs qu'on ne connait pas trop et qui sont gérés par on ne sait qui, va améliorer la sécurité ?
0,07%, c'est un bon début. Peut mieux faire !

Citation:

Mais cela reste le moyen le plus sur au monde.

Ah bon ? Selon quelles statistiques ? Sur quel "long" terme ?

Bluespear · 27/04/2011, 19h59

Citation:

Envoyé par sevyc64

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.

Tout à fait d'accord

Et en général, si on a paramétré correctement ses serveurs, on est assez vite averti quand un disque commence à avoir du mal => le remplacer dans la grappe raid 10.

Alors oui, le cloud permet d'oublier les soucis de configuration de serveur, onduleur, alertes techniques, sécurisation des locaux mais ça ne sera jamais autant fiable qu'un solution maison pour moi

sevyc64 · 27/04/2011, 20h38

Citation:

Envoyé par Bluespear

Et en général, si on a paramétré correctement ses serveurs, on est assez vite averti quand un disque commence à avoir du mal => le remplacer dans la grappe raid 10.

Oui, si le problème vient du disque dur. Mais ce n'est pas la seule cause d'un problème de fichier.

On peut aussi avoir une perte d'alimentation durant une phase d'écriture, un petit malin qui s'amuse à débrancher la prise du serveur à chaud (cas vécu, pour brancher une perceuse bien parasitée qui, le temps que l'on s'en rende compte, a flinguée le circuit de sortie de l'onduleur) ou appuyer sur le bouton d'alimentation.
Une alimentation qui lâche subitement, ou même la survenue d'un bel écran bleu au plus mauvais moment

shkyo · 28/04/2011, 09h13

Citation:

Envoyé par sevyc64

Oui, si le problème vient du disque dur. Mais ce n'est pas la seule cause d'un problème de fichier.

On peut aussi avoir une perte d'alimentation durant une phase d'écriture, un petit malin qui s'amuse à débrancher la prise du serveur à chaud (cas vécu, pour brancher une perceuse bien parasitée qui, le temps que l'on s'en rende compte, a flinguée le circuit de sortie de l'onduleur) ou appuyer sur le bouton d'alimentation.
Une alimentation qui lâche subitement, ou même la survenue d'un bel écran bleu au plus mauvais moment

OUCH !!! Violent le coup de la perceuse!!!

Dans ce cas-là, un accès sécurisé aux salles serveur (badge ou code) peut éviter ce type de problèmes!
C'est vrai que les prises ondulées sont souvent vues comme pas différentes des autres (ben quoi elles sont rouge, et alors?...

) du coup, dans mon ancienne boite, j'avais trouvé dessus une jolie multiprise à deux balles avec dessus le fax, 2 imprimantes laser et le photocopieur, rien que ça...

sevyc64 · 28/04/2011, 09h30

Citation:

Envoyé par shkyo

Dans ce cas-là, un accès sécurisé aux salles serveur (badge ou code) peut éviter ce type de problèmes!

C'était le cas, pas de badge ou code mais salle fermée à clé. Mais il avait besoin d'intervenir dans cette salle. Il avait une prise sur le tableau électrique qui était aussi dans cette salle sur laquelle on lui avait vivement recommandé de brancher son matériel, mais le câble de sa perceuse était trop court.

Citation:

C'est vrai que les prises ondulées sont souvent vues comme pas différentes des autres (ben quoi elles sont rouge, et alors?...

)

Pas de ça ici. L'onduleur était dans la baie des serveurs avec une multiprise en sortie pour brancher les serveurs uniquement. Pour des raisons de commodités les portes arrières de la baie avaient été enlevées et donc la multiprise accessible au milieu du fatras de câbles dans la baie, mais ça ne l'a pas fait reculé.

Résultat, un onduleur et un serveur HS, un patron furax qui a dû venir en urgence terminé le travail de son ouvrier qui avait été viré des locaux et qui a dû consentir une bonne remise sur sa facture (quasiment la totalité) pour compenser les frais de réparation et perte d'activité.
L'onduleur a été envoyé en réparation. Le serveur en question a dû être formater et réinstallé, annulant du coup l'intervention de l'ingé système chez un client et pour laquelle on s'est pris des pénalités.
Heureusement que la dernière sauvegarde complète datait de quelques heures à peine. Les autres serveurs n'ont pas souffert malgré l’arrêt brutal lorsque l'onduleur à lâché.

On a jamais eu de nouvelle de l'ouvrier ni d'autres ouvriers de la boite. Suite à ce problème, c'est toujours le patron qui s'est, par la suite, déplacé en personne pour faire le boulot.

kolodz · 29/04/2011, 20h57

Je vais dire une connerie, mais personnellement, j'ai toujours plusieurs versions d'un même document. Encore plus quand il est important.
Ca évite les versions corrompu, la mauvaise manipulation etc...
J'ai toujours la dernière version valide en local en plus de la version courante.

Donc, le jour où je perd 0.07% de mes données dans le "could", je me dirai :
"De toute façon, c'est dans une sauvegarde d'archive que j'aurai probablement jamais réutiliser."

Rien n'est sûr à 100%... Si ton bâtiment prend feu, même si t'as fait 50 sauvegarde en local... t'es dans la m**** !

Uther · 30/04/2011, 00h46

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é.

Thorna · 30/04/2011, 08h43

Citation:

Envoyé par kolodz

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 !

Idelways · 02/05/2011, 18h20

Amazon explique les raisons de la panne étendue de son Cloud
Et évoque une « tornade de re-mirroring »

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 ?

27/04/2011, 14h26	#1
Idelways Coordinateur publications Développeur Ruby on Rails / iOS et journaliste Inscription : juin 2010 Messages : 1 101 Détails du profil Informations professionnelles : Activité : Développeur Ruby on Rails / iOS et journaliste Informations forums : Inscription : juin 2010 Messages : 1 101 Points : 24 230 Points : 24 230	0.07% des données hébergées par Amazon ne seront pas récupérées Amazon explique les raisons de la panne étendue de son Cloud Et évoque une « tornade de re-mirroring » 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 ?
	30

27/04/2011, 14h43	#2
Faiche Membre expérimenté Consultant informatique Inscription : septembre 2006 Messages : 568 Détails du profil Informations personnelles : Sexe : Localisation : France Informations professionnelles : Activité : Consultant informatique Informations forums : Inscription : septembre 2006 Messages : 568 Points : 519 Points : 519	Au pire, faire un backup auto vers GAE ;p __________________ Venez partager vos expériences au sein d'un projet sur slicesofit, agile & amélioration continue
	01

27/04/2011, 15h14	#5
ProgVal Membre chevronné Valentin Lorentz Étudiant Inscription : mai 2006 Messages : 624 Détails du profil Informations personnelles : Nom : Valentin Lorentz Âge : 18 Localisation : France, Moselle (Lorraine) Informations professionnelles : Activité : Étudiant Informations forums : Inscription : mai 2006 Messages : 624 Points : 644 Points : 644	https://forums.aws.amazon.com/thread...65649&tstart=0 Je pense que ça se passe de commentaire... __________________ Troll à temps plein.
	00

27/04/2011, 15h35	#9
ProgVal Membre chevronné Valentin Lorentz Étudiant Inscription : mai 2006 Messages : 624 Détails du profil Informations personnelles : Nom : Valentin Lorentz Âge : 18 Localisation : France, Moselle (Lorraine) Informations professionnelles : Activité : Étudiant Informations forums : Inscription : mai 2006 Messages : 624 Points : 644 Points : 644	Ah oui, j'avais zappé la deuxième page de commentaires. __________________ Troll à temps plein.
	00

27/04/2011, 16h24	#11
sevyc64 Modérateur Yves Développeur informatique Inscription : janvier 2007 Messages : 3 878 Détails du profil Informations personnelles : Nom : Yves Âge : 39 Localisation : France, Pyrénées Atlantiques (Aquitaine) Informations professionnelles : Activité : Développeur informatique Informations forums : Inscription : janvier 2007 Messages : 3 878 Points : 7 655 Points : 7 655	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. __________________ Sevyc64 --- Le partage est notre force NON AU LANGAGE SMS & FAUTES VOLONTAIRES SUR LES FORUMS
	131

27/04/2011, 14h53	#3
abriotde Membre actif Développeur informatique Inscription : juillet 2007 Messages : 132 Détails du profil Informations personnelles : Sexe : Âge : 30 Localisation : France, Loire Atlantique (Pays de la Loire) Informations professionnelles : Activité : Développeur informatique Secteur : High Tech - Opérateur de télécommunications Informations forums : Inscription : juillet 2007 Messages : 132 Points : 152 Points : 152	0.07% c'est pas grand chose. L'expérience montre qu'en local on perd beaucoup plus souvent et plutôt avec des pourcentage de l'ordre de 40%... Alors certes peut-être que certains ont perdu 100%... Mais cela reste le moyen le plus sur au monde.
	04

29/04/2011, 20h57	#17
kolodz Membre Expert Patrick Kolodziejczyk Étudiant Inscription : avril 2008 Messages : 440 Détails du profil Informations personnelles : Nom : Patrick Kolodziejczyk Âge : 24 Localisation : France, Val d'Oise (Île de France) Informations professionnelles : Activité : Étudiant Secteur : Enseignement Informations forums : Inscription : avril 2008 Messages : 440 Points : 1 559 Points : 1 559	Je vais dire une connerie, mais personnellement, j'ai toujours plusieurs versions d'un même document. Encore plus quand il est important. Ca évite les versions corrompu, la mauvaise manipulation etc... J'ai toujours la dernière version valide en local en plus de la version courante. Donc, le jour où je perd 0.07% de mes données dans le "could", je me dirai : "De toute façon, c'est dans une sauvegarde d'archive que j'aurai probablement jamais réutiliser." Rien n'est sûr à 100%... Si ton bâtiment prend feu, même si t'as fait 50 sauvegarde en local... t'es dans la m**** !
	00

30/04/2011, 00h46	#18
Uther Expert Confirmé Inscription : avril 2002 Messages : 2 297 Détails du profil Informations personnelles : Sexe : Localisation : France Informations forums : Inscription : avril 2002 Messages : 2 297 Points : 3 957 Points : 3 957	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é.
	20

02/05/2011, 18h20	#20
Idelways Coordinateur publications Développeur Ruby on Rails / iOS et journaliste Inscription : juin 2010 Messages : 1 101 Détails du profil Informations professionnelles : Activité : Développeur Ruby on Rails / iOS et journaliste Informations forums : Inscription : juin 2010 Messages : 1 101 Points : 24 230 Points : 24 230	Amazon explique les raisons de la panne étendue de son Cloud Et évoque une « tornade de re-mirroring » 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 ?
	10

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email