+ Répondre à la discussion Actualité déjà publiée
Page 1 sur 2 12 DernièreDernière
  1. #1
    Expert éminent sénior
    Avatar de Idelways
    Homme Profil pro
    Développeur Ruby on Rails / iOS
    Inscrit en
    juin 2010
    Messages
    1 374
    Détails du profil
    Informations personnelles :
    Sexe : Homme

    Informations professionnelles :
    Activité : Développeur Ruby on Rails / iOS

    Informations forums :
    Inscription : juin 2010
    Messages : 1 374
    Points : 68 469
    Points
    68 469

    Par défaut 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 ?

  2. #2
    Membre confirmé
    Homme Profil pro
    Consultant informatique
    Inscrit en
    septembre 2006
    Messages
    572
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Consultant informatique

    Informations forums :
    Inscription : septembre 2006
    Messages : 572
    Points : 623
    Points
    623

    Par défaut

    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

  3. #3
    Membre éclairé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juillet 2007
    Messages
    472
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    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 : 472
    Points : 743
    Points
    743

    Par défaut

    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.
    Tout ce que j'écris est libre de droits (Licence CC0) et je vous incite à faire de même.

  4. #4
    Tab
    Tab est déconnecté
    Membre averti
    Homme Profil pro
    Développeur .NET
    Inscrit en
    mai 2005
    Messages
    78
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 29
    Localisation : France, Cher (Centre)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mai 2005
    Messages : 78
    Points : 405
    Points
    405

    Par défaut

    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

  5. #5
    Membre éclairé
    Avatar de ProgVal
    Homme Profil pro
    Étudiant
    Inscrit en
    mai 2006
    Messages
    636
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 23
    Localisation : France, Moselle (Lorraine)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : mai 2006
    Messages : 636
    Points : 729
    Points
    729

    Par défaut

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

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

  6. #6
    Membre éclairé Avatar de Julien Bodin
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    février 2009
    Messages
    470
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Calvados (Basse Normandie)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2009
    Messages : 470
    Points : 819
    Points
    819

    Par défaut

    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.

  7. #7
    Expert éminent Avatar de Uther
    Homme Profil pro
    Inscrit en
    avril 2002
    Messages
    3 487
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : avril 2002
    Messages : 3 487
    Points : 8 059
    Points
    8 059

    Par défaut

    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.

  8. #8
    Membre actif Avatar de Faereth
    Homme Profil pro
    Développeur informatique
    Inscrit en
    janvier 2007
    Messages
    92
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Bâtiment

    Informations forums :
    Inscription : janvier 2007
    Messages : 92
    Points : 294
    Points
    294

    Par défaut

    Citation Envoyé par ProgVal Voir le message
    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.
    Un sage se distingue des autres hommes, non par moins de folie, mais par plus de raison.

    Emile-Auguste Chartier, dit Alain

  9. #9
    Membre éclairé
    Avatar de ProgVal
    Homme Profil pro
    Étudiant
    Inscrit en
    mai 2006
    Messages
    636
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 23
    Localisation : France, Moselle (Lorraine)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : mai 2006
    Messages : 636
    Points : 729
    Points
    729

    Par défaut

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

  10. #10
    Membre expérimenté Avatar de shkyo
    Homme Profil pro
    Développeur Robotique - Administrateur systèmes
    Inscrit en
    juin 2003
    Messages
    831
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Développeur Robotique - Administrateur systèmes

    Informations forums :
    Inscription : juin 2003
    Messages : 831
    Points : 1 408
    Points
    1 408

    Par défaut

    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...
    L'homme sage apprend de ses erreurs, l'homme plus sage apprend des erreurs des autres. - Confucius -

    Pour les fans de SF "à l'anglo-saxone", voici un bon roman de SF, (écrit par ma moitié... ), il suffit de s'inscrire au panel des lecteurs pour le lire gratuitement et l'évaluer... Il est là: L'Archéofoetus

    Si vous avez quelques minutes, passez donc voir mon site http://www.photospicsandco.fr/
    Envie de tee-shirts (et goodies!) originaux et sympa ? Visitez mon site... http://www.zazzle.com/shkyo30

  11. #11
    Modérateur
    Avatar de sevyc64
    Homme Profil pro
    Développeur informatique
    Inscrit en
    janvier 2007
    Messages
    8 953
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : janvier 2007
    Messages : 8 953
    Points : 23 771
    Points
    23 771

    Par défaut

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

    Parce que le partage est notre force, la connaissance sera notre victoire

  12. #12
    Membre éclairé
    Profil pro
    Inscrit en
    décembre 2004
    Messages
    514
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2004
    Messages : 514
    Points : 893
    Points
    893

    Par défaut

    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 !
    Mais cela reste le moyen le plus sur au monde.
    Ah bon ? Selon quelles statistiques ? Sur quel "long" terme ?
    L'avis publié ci-dessus est mien et ne reflète pas obligatoirement celui de mon entreprise.

  13. #13
    Membre régulier
    Homme Profil pro
    Inscrit en
    septembre 2006
    Messages
    64
    Détails du profil
    Informations personnelles :
    Sexe : Homme

    Informations forums :
    Inscription : septembre 2006
    Messages : 64
    Points : 73
    Points
    73

    Par défaut

    Citation Envoyé par sevyc64 Voir le message
    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

  14. #14
    Modérateur
    Avatar de sevyc64
    Homme Profil pro
    Développeur informatique
    Inscrit en
    janvier 2007
    Messages
    8 953
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : janvier 2007
    Messages : 8 953
    Points : 23 771
    Points
    23 771

    Par défaut

    Citation Envoyé par Bluespear Voir le message
    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
    --- Sevyc64 ---

    Parce que le partage est notre force, la connaissance sera notre victoire

  15. #15
    Membre expérimenté Avatar de shkyo
    Homme Profil pro
    Développeur Robotique - Administrateur systèmes
    Inscrit en
    juin 2003
    Messages
    831
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Développeur Robotique - Administrateur systèmes

    Informations forums :
    Inscription : juin 2003
    Messages : 831
    Points : 1 408
    Points
    1 408

    Par défaut

    Citation Envoyé par sevyc64 Voir le message
    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...
    L'homme sage apprend de ses erreurs, l'homme plus sage apprend des erreurs des autres. - Confucius -

    Pour les fans de SF "à l'anglo-saxone", voici un bon roman de SF, (écrit par ma moitié... ), il suffit de s'inscrire au panel des lecteurs pour le lire gratuitement et l'évaluer... Il est là: L'Archéofoetus

    Si vous avez quelques minutes, passez donc voir mon site http://www.photospicsandco.fr/
    Envie de tee-shirts (et goodies!) originaux et sympa ? Visitez mon site... http://www.zazzle.com/shkyo30

  16. #16
    Modérateur
    Avatar de sevyc64
    Homme Profil pro
    Développeur informatique
    Inscrit en
    janvier 2007
    Messages
    8 953
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : janvier 2007
    Messages : 8 953
    Points : 23 771
    Points
    23 771

    Par défaut

    Citation Envoyé par shkyo Voir le message
    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.

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

    Parce que le partage est notre force, la connaissance sera notre victoire

  17. #17
    Modérateur
    Avatar de kolodz
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    avril 2008
    Messages
    2 122
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : avril 2008
    Messages : 2 122
    Points : 7 928
    Points
    7 928
    Billets dans le blog
    51

    Par défaut

    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**** !
    Si une réponse vous a été utile pensez à
    Si vous avez eu la réponse à votre question, marquez votre discussion
    Pensez aux FAQs et aux tutoriels et cours.

  18. #18
    Expert éminent Avatar de Uther
    Homme Profil pro
    Inscrit en
    avril 2002
    Messages
    3 487
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : avril 2002
    Messages : 3 487
    Points : 8 059
    Points
    8 059

    Par défaut

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

  19. #19
    Membre éclairé
    Profil pro
    Inscrit en
    décembre 2004
    Messages
    514
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2004
    Messages : 514
    Points : 893
    Points
    893

    Par défaut

    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 !
    L'avis publié ci-dessus est mien et ne reflète pas obligatoirement celui de mon entreprise.

  20. #20
    Expert éminent sénior
    Avatar de Idelways
    Homme Profil pro
    Développeur Ruby on Rails / iOS
    Inscrit en
    juin 2010
    Messages
    1 374
    Détails du profil
    Informations personnelles :
    Sexe : Homme

    Informations professionnelles :
    Activité : Développeur Ruby on Rails / iOS

    Informations forums :
    Inscription : juin 2010
    Messages : 1 374
    Points : 68 469
    Points
    68 469

    Par défaut

    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 ?

Discussions similaires

  1. Réponses: 0
    Dernier message: 27/04/2011, 14h26
  2. Réponses: 3
    Dernier message: 26/02/2007, 14h43
  3. Récuperation des données envoyées par Form en POST
    Par bobatel dans le forum Formulaires
    Réponses: 9
    Dernier message: 26/04/2006, 14h59
  4. Taille limite des données passées par POST
    Par FoxLeRenard dans le forum PHP & MySQL
    Réponses: 2
    Dernier message: 23/03/2006, 17h46
  5. Voir l'intégralité des données transmises par le formulaire
    Par EvilAngel dans le forum Formulaires
    Réponses: 5
    Dernier message: 27/12/2004, 00h38

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo