6 Le disque dur (à plateaux) est une cible redoutable pour les logiciels d’entreprise à l’échelle du cloud. Il permet aux entreprises de stocker des volumes massifs de données à un coût proche de celui de la bande. Et il peut offrir aux organisations une durabilité allant jusqu’à 14 neuf, sur site. Mais les disques à plateaux ne sont pas infaillibles. Il arrive qu’il y ait des défauts de fabrication ou des pannes en série. C’est là que vous avez vraiment besoin d’un système de stockage capable d’aider votre organisation à s’en remettre efficacement — et rapidement. Et c’est aussi là que vous voulez travailler avec un fournisseur capable de vous accompagner tout au long du processus. Découvrez la situation inquiétante qu’a récemment vécue l’un de nos clients — et comment nous avons évité tout déraillement. C’est la promesse de Scality : nous ne fournissons pas seulement un produit, nous sommes un véritable partenaire pour les organisations avec lesquelles nous travaillons ! Le scénario : un disque dur tombe en panne Un organisme public de la région APAC disposait d’un RING (en anglais) de six serveurs équipés de disques durs de 8 To (56 disques de 8 To par serveur). Il utilise la fonction S3 native du RING comme cible pour les sauvegardes de toute l’organisation. Tout se passait bien jusqu’à ce que l’un des disques de 8 To tombe en panne. L’organisme a contacté les ingénieurs customer success (CSE) de Scality. La bonne nouvelle, c’est qu’avec Scality, la panne d’un seul disque n’est pas un gros problème. Son Scality RING (en anglais) est protégé par un schéma d’erasure coding (en anglais) 8,4, qui tolère la perte de deux serveurs entiers (sur six) ou de quatre disques au hasard, n’importe où dans le cluster, sans aucune perte de données. Le processus de reconstruction du RING Dans un scénario de panne classique, le mécanisme de reconstruction interne du RING prend le relais et reconstruit les données du disque défaillant sur les autres disques du serveur. Ce processus de reconstruction présente deux avantages clés : Il ne reconstruit que les données écrites — pas le disque entier — et ne gaspille donc pas de cycles à reconstruire de l’espace vide. Il n’a pas le goulet d’étranglement des disques de parité dédiés, très sollicités lors des reconstructions, car il écrit les données sur tous les disques restants du serveur. Dans ce cas précis, l’application du client écrivait des objets assez petits — environ 300 Ko en moyenne par objet envoyé au RING. Après découpage en huit (pour le schéma EC 8,4), l’objet moyen écrit sur disque faisait 37,5 Ko. Même rempli à 80 %, un disque de 8 To contenait plus de 170 millions d’objets, à reconstruire un par un. Cela prenait forcément du temps, mais sans conséquence au final. Une nouvelle panne Mais deux jours plus tard, un deuxième disque de 8 To est tombé en panne sur un autre serveur. Le premier disque était presque entièrement reconstruit, donc cette deuxième panne n’était pas préoccupante — pour l’instant. Cependant, face à ces deux pannes rapprochées — et connaissant le schéma des pannes en série — l’équipe IT du client s’inquiétait et examinait ses autres disques à la recherche de nouvelles défaillances. Là encore, RING a pu aider en prédisant de façon fiable les pannes suivantes à partir de temps de réponse erratiques et de confirmations d’écriture retardées. Quand le troisième disque a lâché, notre équipe CSE était quasiment certaine d’avoir affaire à la redoutée panne en série. Les disques n’étaient pas vieux (environ deux ans et demi en production) et n’avaient pas été trop sollicités par les écritures, suppressions et lectures occasionnelles. Une seule question nous occupait : quelle serait l’ampleur de cette série de disques défaillants ? La réponse ? Bien plus importante que prévu, comme nous allions vite le découvrir. Survivre à une panne en série : se remettre de la perte de 10 disques en seulement trois semaines ! Après les deux premières pannes, le client a subi huit autres pannes de disques successives. Soit au total 10 disques défaillants en trois semaines ! La configuration du client pouvait supporter quatre pannes de disques simultanées n’importe où dans le RING, mais pas cinq, six… et certainement pas dix ! Les pannes s’accélérant, notre équipe d’ingénierie savait qu’elle devrait aller plus loin pour y faire face. Scality RING permet à nos ingénieurs d’analyser tous les objets écrits et d’établir un rapport sur le volume total de données et le nombre de fragments de parité restant pour chaque objet sur le RING. À chaque nouvelle panne, nos CSE ont exploité ce rapport, examiné les objets les plus à risque et modifié l’ordre de reconstruction pour traiter ces objets en priorité. Certaines tâches de reconstruction ont été lancées manuellement pour reconstruire d’abord les objets disposant du moins de parité. Cette réorganisation de l’ordre de reconstruction, qui ciblait les objets avec le moins de parité restante, a été déterminante pour le client. Le résultat : aucune perte de données Le processus a parfois été ardu et manuel, mais nous avons atteint l’objectif le plus important : aucune donnée n’a été perdue. Et quand on pense à l’immense volume de données précieuses que stocke aujourd’hui n’importe quel organisme du secteur public (en anglais) — voire n’importe quelle organisation —, c’est une réussite importante. En cas de panne de disque ordinaire, la reconstruction automatique suffit à ramener le RING à son état nominal. Mais avec plusieurs pannes simultanées, une intervention manuelle a été nécessaire pour gérer une situation qui évoluait très vite, parfois plusieurs fois par jour ! Malgré une panne en série de 10 disques, aucune donnée n’a été perdue. Nous avons tenu bon. Ce fut un véritable test grandeur nature des capacités de RING, et la preuve du travail et de l’engagement de notre équipe de support. Chez Scality, protéger vos données est notre mission, et nous sommes à la hauteur — même quand plusieurs disques lâchent. Carpe datum !
