Gandi revient sur sa longue panne de début janvier, qui rappelle l’importance des sauvegardes
Ceinture, Bretelle, Parachute !
Le 29 janvier 2020 à 14h20
12 min
Internet
Internet
Il y a trois semaines une unité de stockage de Gandi tombait en panne. Il faudra attendre 5 jours pour un retour à la normale. La société vient de publier un post-mortem complet sur cet incident qui a touché 414 clients. Des explications qui seront utiles tant aux professionnels qu'aux utilisateurs de services en ligne.
Des pannes peuvent survenir chez tout le monde, aucune société ne peut se prétendre à l’abri de gros incidents matériels et/ou logiciels. Elles peuvent par contre avoir des répercussions plus ou moins graves sur la disponibilité des services et, même si on pense avoir pris toutes les précautions, un petit grain de sable peut vite gripper l’ensemble des rouages.
Dans ce genre de situation, plusieurs réactions sont possibles : essayer de glisser l’incident sous le tapis, le minimiser, ou communiquer largement et ouvertement… quitte parfois à même en faire presque trop. On se rappelle de la panne des 50 000 sites mutualisés d’OVH en 2017, à qui on ne pouvait pas reprocher un manque de transparence.
- Mutualisé : OVH s'explique sur la panne de 50 000 sites et annonce un geste commercial
- Derrière les plantages d'OVH, la question de la transparence dans la communication
Gandi, comme OVH, a opté pour une communication très active pendant la crise (via différents canaux) et un retour détaillé – à froid – sous la forme d’un post-mortem. Un exercice technique peu aisé, mais ô combien utile pour la communauté qui peut prendre ses dispositions pour éviter un drame du même genre. Cela permet également aux clients de travailler à leurs propres solutions de sauvegardes/replis qu’ils ont – ou non – mises en place.
La panne de Gandi – qui a touché 414 clients hébergés sur le site luxembourgeois – est presque un cas d’école sur ce dernier point, et l’occasion de rappeler qu’il faut toujours disposer de sauvegardes, dans des lieux différents et vérifier que l’on est bien en mesure de les restaurer dans un délai convenable en cas de problème.
Une unité de stockage tombe en panne… et c’est le drame
Tout commence le 8 janvier 2020 à 14h51 UTC (15h51 en France) : « une de nos unités de stockage utilisées pour nos services d’hébergement hébergés à LU-BI1 (Luxembourg) est tombée en panne ». Jusque-là, rien de bien exceptionnel, ce sont malheureusement des choses qui arrivent. Une minute plus tard, une « procédure de basculement » est mise en place.
À 16 h par contre, la situation s‘aggrave : « la procédure habituelle ne permet pas la récupération du service, le pool est FAULTED, indiquant une corruption des métadonnées ». Gandi utilise le système de fichiers ZFS avec un triple miroir : « Cela signifie que nous pouvons perdre jusqu’à deux tiers des disques sur l’ensemble de l’unité ».
Comme avec un RAID sur un NAS, cela protège donc – dans une certaine mesure – de pannes sur les disques, mais pas sur l’unité en elle-même. La société rappelle au passage que « ZFS permet aux clients de faire des snapshots qui sont des images instantanées de leur disque à un moment donné. Il permet aux clients de revenir en arrière en cas d’erreur, comme la suppression d’un fichier, par exemple ».
Une importation est lancée, mais elle prendra des jours
Puisque la procédure automatique ne fonctionne pas, une équipe est dépêchée sur place à 17 h. Gandi pense alors que « le problème est peut-être lié à un problème matériel » ; un changement est effectué à 18 h, sans « aucune amélioration ».
L’équipe se décide alors à lancer une importation du « pool », une procédure qui finira par fonctionner… « mais lentement. À ce rythme, il faudra des jours », pense alors la société. Nous sommes toujours le 8 janvier et il est 18h30, la panne dure donc depuis déjà plus de 2h30. Avec le jeu des fuseaux horaires, l’équipe européenne de Gandi est rejointe par celle des États-Unis qui « jette un nouveau regard sur le problème », mais n’apportera finalement rien de plus.
Face à la lenteur de l’importation des données, la société décide d’interrompre la procédure à 20 h « pour voir s’il y a un moyen de l’accélérer ». Elle fait chou blanc.
Une sauvegarde ? Quelle sauvegarde ?
À 21 h, l’importation est donc relancée, avec une première estimation du temps nécessaire : « comme les disques sont lus à 3 Mo/s, nous estimons la durée à 370 heures », soit un peu plus de quinze jours en gardant la même moyenne. Nous sommes toujours mercredi 8 janvier et Gandi doit faire face à un épineux problème : « nous n’avons aucune garantie sur la restauration des données ni sur la durée du processus ».
La société va alors contacter ses clients par email pour leur demander d’utiliser une de leurs sauvegardes… s’ils en disposent évidemment :
« Un incident est survenu sur une de nos unités de stockage au sein d’un de nos centres de données situé au Luxembourg. Malgré les systèmes de réplication mis en place et les efforts combinés de nos équipes toute la nuit, nous n’avons pu récupérer les données sur l’unité de stockage atteinte.
Nous nous excusons sincèrement pour le désagrément que cette situation a causé. Ce type d’incident est d’une rareté extrême dans l’industrie de l’hébergement web. Dans le cas où vous disposeriez de copies de sauvegarde de vos données, nous suggérons que vous en fassiez usage pour la remise sur pied de votre serveur sur un datacenter différent ».
Le corollaire est donc que Gandi ne dispose pas de sauvegarde en interne, ce qui a surpris certains clients. Dans son post-mortem, la société reconnaît qu’elle n’a visiblement pas été suffisamment claire sur ce point : « Gandi ne fournit pas, par contrat, de produit de sauvegarde pour les clients. Cela n’a peut-être pas été expliqué assez clairement dans notre documentation V5 ». Désormais, la page dédiée à la présentation des snapshots a changé.
Sauvegardes vs snapshots
Le 9 janvier les snapshots étaient présentés comme : « sauvegardant automatiquement les fichiers de votre site Web à un intervalle régulier, que vous pouvez utiliser pour ramener le code de votre site Web à une version précédente si nécessaire ».
Le mot sauvegarde a disparu et le message est désormais : « Les Snapshots créent un instantané des fichiers de votre instance à intervalles réguliers, permettant de revenir à une version antérieure de votre site web si nécessaire ». Un avertissement a été ajouté : « Un snapshot est hébergé sur le même disque que les fichiers de l’instance, il ne doit pas remplacer une politique de sauvegarde avec une copie complète des fichiers de votre site vers une destination distante ».
Version du 9 janvier puis celle du 28 janvier
La grogne était en effet palpable sur les réseaux sociaux, à l’image du mécontentement d’Andrea Ganduglia lorsque Gandi annonce qu’il n’est pas certain de pouvoir récupérer les données : « Donc vous avez perdu des données et interrompu nos services et maintenant, c'est notre travail de les récupérer depuis des sauvegardes ? Des snapshots sont-ils disponibles ? ».
Réponse de Gandi : « pas de snapshot », avant d’ajouter : « les snapshots ne sont pas des sauvegardes, donc oui ils sont sur la même unité ». L'hébergeur tente ensuite de se justifier, certainement pas de la meilleure des manières : « veuillez noter que cela pourrait arriver à n'importe quel hébergeur ». Un message maladroit, et ce n’était pas le seul, la société s’est en effet également excusée d’une réponse « surprenante » à l'un de ses clients.
Stephan Ramoin (PDG de Gandi) a reconnu que c’était une erreur, avant d’ajouter : « Perso, je préfère une boîte qui, sur Twitter (un média immédiat et où les gens font assez peu la part des choses) dit une connerie, mais le reconnait et fait ce qu'il faut, plutôt que le contraire. Et nous sommes en train de récupérer les données... ». Une histoire qui n’est pas sans rappeler la communication d’OVH et surtout d’Octave Klaba autour de l’incident de 2017.
Dans tous les cas, Gandi est conscient du problème puisque dans le billet de blog elle explique avoir « identifié des axes de progression en interne pour être encore plus fluide et réactive en quasi-temps réel ».
Le drame des mises à jour non faites
Revenons à l’importation des données lancée quelques heures après la panne. Pendant qu’elle suit son cours, l’équipe ne reste pas les bras croisés : elle plonge dans la documentation disponible et regarde le code pour tenter de trouver des pistes d’amélioration. « Nous identifions que nous pouvons modifier certains paramètres liés à l’importation zpool -fFX
Hélas, la version ZFS utilisée par Gandi « est trop ancienne et le code n’implémente pas ces options ». Le lendemain (jeudi 9 janvier) à 16 h, Gandi tente une « transplantation » afin de mettre en place les pistes d’amélioration identifiées : « nous décidons d’utiliser une version récente de ZFS on Linux. Une équipe se rend sur place, nous avons déjà un serveur configuré pour utiliser ZOL [ZFS on Linux, ndlr]. Nous préparons un échange du serveur qui gère le JBOD avec celui qui utilise ZOL ».
C’est un succès puisque, une heure plus tard l’équipe redémarre « l’import en utilisant zpool import -fFX
Le transfert ne se passe « évidemment » pas comme prévu
À 20 h, l’importation est terminée et Gandi réalise alors un snapshot global, puis le copie dans une autre unité de stockage « au cas où ». La panne dure maintenant depuis près de 30 h. La suite a aussi été le théâtre de quelques surprises : « nous rencontrons quelques erreurs lors de la copie des données, nous devons donc procéder manuellement […] Nous transférons le snapshot avec un script. Nous estimons que cela prendra 33 heures », à ajouter aux 30 h déjà écoulées.
Finalement 24 h plus tard le transfert est terminé, mais mauvaise nouvelle : « il manque beaucoup de snapshots. Les dépendances entre les snapshots et leurs origines empêchent beaucoup de transferts. Nous devons supprimer beaucoup de cibles de destination pour les retransférer ». C’est donc reparti pour un tour... et il faudra attendre 14 h le dimanche 12 janvier pour que le transfert manuel soit effectué. À 21h25, le test d’intégrité est « ok ».
Les équipes ont certainement poussé un « ouf » de soulagement, même si tout n’était pas terminé. Gandi se coordonne pour une mise en ligne des données le lundi 13 janvier à partir de 8h00, mais sans préciser si elles étaient toutes revenues ou si quelques pertes étaient à déplorer. 1h30 plus tard, elles sont effectivement en ligne et à 10h30 les instances PAAS sont redémarrées. Cinq jours plus tard, l’incident était donc enfin terminé.
Que retenir de ce post-mortem ?
Une question reste en suspens : pourquoi l’unité de stockage est tombée en panne ? Mystère et boule de gomme : « Nous n’avons pas d’explication claire du problème, seulement des théories. Nous pensons que l’incident est peut-être dû à un problème matériel lié à la mémoire vive du serveur ».
Dans tous les cas, l’erreur humaine a été exclue après consultation des logs et des historiques de commandes. Mais finalement, peu importe la cause première de cette panne, on juge surtout une société sur sa capacité à restaurer ses services le plus rapidement possible, idéalement de manière quasi invisible pour ses clients. Gandi fait amende honorable et reconnaît que « le principal problème est la durée de l’incident ».
Ce point découle de plusieurs facteurs, dont un manque de mise à jour : « La version de ZFS que nous utilisons sur ce filer n’implémente pas l’option permettant d’éviter un scan complet du pool ». Une mise à jour était en cours chez Gandi, mais cette « unité fait partie du dernier lot à migrer vers une version plus récente ».
Gandi prévoit évidemment de mettre à jour l’ensemble des unités de stockage restantes, une opération prévue « au cours de l’année 2020 » et aussi de « documenter avec précision la procédure de récupération des données en cas de corruption des métadonnées ».
Côté utilisateur, rappellons qu'il est important de toujours disposer de sauvegardes de ses données, peu importe finalement les promesses de l’hébergeur. Ne jamais mettre tous ses œufs dans le même panier prend tout son sens ici. Si 414 clients « seulement » ont été impactés, cette histoire doit être un coup de semonce pour l’ensemble des internautes.
Le 29 janvier 2020 à 14h20
Gandi revient sur sa longue panne de début janvier, qui rappelle l’importance des sauvegardes
-
Une unité de stockage tombe en panne… et c’est le drame
-
Une importation est lancée, mais elle prendra des jours
-
Une sauvegarde ? Quelle sauvegarde ?
-
Sauvegardes vs snapshots
-
Le drame des mises à jour non faites
-
Le transfert ne se passe « évidemment » pas comme prévu
-
Que retenir de ce post-mortem ?
Commentaires (73)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 29/01/2020 à 14h35
#1
Je trouve que l’homme sur l’ilustration a un faux air de Gordon Ramsay. " />
(Avec le côté “panique en salle serveur” de la news c’est plutôt raccord, vous m’direz " />)
« comme les disques sont lus à 3 Mo/s, nous estimons la durée à 370 heures »
ça laisse songeur comme chiffre. Une idée de pourquoi c’est si lent (mode dégradé ou truc du genre) ?
Le 29/01/2020 à 15h00
#2
Le 29/01/2020 à 15h05
#3
C’est un peu comme le principe d’avoir un NAS avec un RAID5, si tu perds un hdd, tu gères, si tu crames la carte mère du NAS, tu perds tout … ya toujours moyen de reconstruire la grappe mais pareil, tu galères 3 jours minimum.
… Ca me fait penser que faut qu je pense à répliquer le mien …
Le 29/01/2020 à 15h08
#4
Si j’ai bien compris la news ça venais du scan d’intégrité en parallèle des données transféré.
D’ou l’echange avec un serveur gérant l’option pour éviter ça
Le 29/01/2020 à 15h17
#5
y a plus de stockage sur bande de nos jours ?
Le 29/01/2020 à 15h20
#6
Le 29/01/2020 à 15h31
#7
Très interessant merci !
Le 29/01/2020 à 15h34
#8
Pour moi la plus grosse erreur est d’avoir décrit les snapshots avec le mot “sauvegarde”, finalement.
Ensuite, on pourrait se demander s’il n’aurait pas été normal d’avoir un backup, pas comme service au client (puisque visiblement ce n’est pas un truc prévu), mais comme sécu interne pour la disponibilité en cas de crash… Comme toujours, un arbitrage coût/risque, jamais simple.
Mais bordel les équipes on dû bien suer pendant des heures, et lire des docs pointues quand on est dans le speed c’est toujours éprouvant " />
Le 29/01/2020 à 15h35
#9
Le 29/01/2020 à 15h38
#10
Le 29/01/2020 à 15h40
#11
Le 29/01/2020 à 15h49
#12
Le 29/01/2020 à 15h50
#13
Le 29/01/2020 à 16h10
#14
Le 29/01/2020 à 16h18
#15
Le 29/01/2020 à 16h36
#16
Tout le monde s’occupe de sauvegarde en calculant les plages de sauvegarde de jour de nuits etc …
C’est bien mais l’important est la restoration et le temps que ça met
Demandez à 100 ingé systèmes combien de temps ils faut pour recréer un raid5 sur leur baie de disques quand une des gamelles est morte
95% ne le savent pas car ils n’ont jamais testé, ils ne savent pas combien de temps met le technicien pour changer la gamelle , et combien de temps la bécane a besoin pour reconstruire le Raid , pourtant ils sont exposés pendant la reconstruction.
Pourtant les vendeurs de grosses baies ( Hitachi, IBM , EMC etc … ) insistent beaucoup sur le fait qu si on met des gamelles tro volumineuses , il faut des heures pour reconstruire le RAID.
Been there, done that " />
Le 29/01/2020 à 16h50
#17
Intéressant ce retour d’expérience sur zfs, le meilleur filesystem.
Le 29/01/2020 à 16h53
#18
ZFS c’est pas mal
Mais Murphy dans une salle, ça aide pas " />
Le 29/01/2020 à 17h09
#19
Le 29/01/2020 à 17h17
#20
Putain ce que tu as raison… Tu vends un SLA à 99% parce que le client vuet pas dépenser plus. Et en cas de prob tu dois réagir en mode SLA 99.9999% " />
Le 29/01/2020 à 17h28
#21
J’ai eu à peu près la même chose sur un…
AS400, restauration de la bande de 48h, à coup de console “Minitel” avec des commandes presques bien documentées…
Bah 2 jours d’indisponibilité hein juste pour le délais de restauration…" />
Ne parlons pas des saisies perdues dans l’intervalle qu’il faut refaire, soit environ une bonne semaine pour retrouver un fonctionnement normal….
un truc comme ça, c’est un coup à demander un presta hébergement en saas. " />
Le 29/01/2020 à 17h41
#22
Le 29/01/2020 à 17h43
#23
Le 29/01/2020 à 18h29
#24
meme à 133Mo/s (débit brut moyen d’un hdd moderne, certifié par mon doigt mouillé ©), copier un 8To c’est plus de 16h …
alors quand tu rajoutes les opé de parité, checksum … on arrive facilement à un compte en jour
Le 29/01/2020 à 18h47
#25
Le 29/01/2020 à 18h48
#26
Secteur bancaire ?
Le 29/01/2020 à 21h21
#27
Le 29/01/2020 à 22h08
#28
Le 29/01/2020 à 23h13
#29
Mes 2 centimes pour ceux que ça pourrait intéresser :
je fais de la prod internalisée, et sur une baie ISCSI moyenne gamme 24 disques SAS 900G en RAID 6 + hot spare j’ai eu un temps de reconstruction sur le spare de 27 heures.
Depuis on est passé en stockage distribué.
Et là, tu as les financiers qui te demandent pourquoi tu veux autant de machines …
La plaie pour faire comprendre à un monsieur michu que c’est plus cher qu’un disque USB 2 To de supermarché.
Le 30/01/2020 à 06h20
#30
Le 30/01/2020 à 06h20
#31
Le 30/01/2020 à 06h52
#32
Le 30/01/2020 à 07h19
#33
Enfin ça dépend surtout avec quoi tu fais ton RAID 5.
FreeNAS (qui utilises aussi ZFS d’ailleurs) si ta carte mère lâche, tu fout les disques dans une vieille tour, tu boots et tu importes le pool, c’est ultra rapide.
Après oui, j’ai jamais non plus été fan des NAS “clef en main” qui sont très bien pour leur simplicité, mais quand tu as une problème matériel autre qu’un disque, ça pique généralement " />
Le 30/01/2020 à 07h23
#34
J’ai justement vu un reportage sur les câbles sous marins https://www.youtube.com/watch?v=iMAThVcqzuk ) où le mec te dit clairement qu’il règle le problème sans stresser, car le stress empêche la concentration " />
Le 30/01/2020 à 07h25
#35
Le 30/01/2020 à 07h30
#36
Surtout qu’ils ont pas pris en compte la vérification qui est faites et qui prends des plombes et impossible à skip avec leur version.
Le 30/01/2020 à 07h40
#37
C’est du classique ça, en terme de perte tu as beaucoup, beaucoup plus débile, comme le mec qui à perdu sa baie à cause de l’alarme incendie. Ben oui, les vibrations de l’alarme qui gueule, les disques ont pas aimé " />
Perso j’ai un RAID 10 avec 4 disques différents, de constructeur différent et avec un nombre d’heure différent. Et je swap de temps à autre avec un cinquième pour continuer à alterner. Bon après j’ai évidemment des sauvegardes aussi.
Le 30/01/2020 à 07h41
#38
Le 30/01/2020 à 07h53
#39
FreeNAS n’aime pas du tout les cartes RAID de toute façon, c’est même déconseillé, FreeNAS doit avoir accès direct aux disques.
Donc un carte RAID physique, avec chiffrement ou non est de toute façon à oublier pour FreeNAS, sauf si tu cherches les problèmes " />
Mais pour d’autre NAS ou système de stockage qui utilise une carte RAID physique la question se pose oui.
Le 30/01/2020 à 08h13
#40
Le 30/01/2020 à 08h45
#41
Le 30/01/2020 à 09h34
#42
Les grosses banques c’est pas des AS400 ce sont généralement des mainframes Z en z/OS
Et les baies de disques sont souvent en RAID5 en duplication synchrone sur un autre site et en duplication asynchrone sur le 3 ème site( 30 minutes le plus souvent)
les backups/sauvegardes se font sur 2 des 3 sites
Le 30/01/2020 à 10h07
#43
Tu n’as ces vitesses là qu’en début de disaue, quand il est quasi-vide. Aucun DD plein à 80% ne va te proposer ces débits là
Le 30/01/2020 à 10h08
#44
Secteur des loisirs ;)
Le 30/01/2020 à 10h10
#45
Exactement mais bon au moins ça évitera à l’équipe l’infra de se prendre des scud.
Le 30/01/2020 à 10h21
#46
Il existe de très grosses baies dont les controllers font du stripping , et la vitesse d’un seul HDD ne représente rien
Le 30/01/2020 à 10h25
#47
Le 30/01/2020 à 10h45
#48
C’est bien ce que je disais, un DD ne fourni pas ce débit. Si tu fais du stripping, ça n’est plus un disque dur seul… KP2 parlait de disques seuls atteignant ces débits, pas de grappes (en stripping ou non)
Le 30/01/2020 à 11h53
#49
Depuis quand la vitesse dépends du remplissage ? À part si tu fragmentes à mort, mais normalement on utilise plus de FS qui fragmente à ce point de nos jours… après évidemment la fin de disque est toujours plus lente que le début, mais ça reste assez élevé.
Le 30/01/2020 à 11h56
#50
Je suis d’accord " />
Mais tu parles de hardware stripping , moi je pensais plus à du data stripping ( avec le hard qui va bien) genre VSAM KSDS ou LDS ou la notion de fichier sur ton raid est caduque c’est du fichier sur plusieurs raids permettant plusieurs opérations d’I/O simiultanées sur le même fichier.
et les perfs n’ont alors rien à voir avec un raid0 ou truc du genre.Enrhumé le Raid " />
C’est pour cela que quand on réfléchit à du disaster recovery , il faut penser temps de restore.
Hélas le data stripping n’est réservé qu’aux très riches ( les banques principalement) et qu’à des plateformes spécifiques
Le 30/01/2020 à 13h26
#51
Personnellement, je ne mélange jamais les fabricants de disque ou les types de disques au sein d’une grappe RAID. À mon humble avis, cela a revient à chercher les coups.
Bien au contraire, il est plus que pertinent de s’assurer que les firmwares des disques sont identiques et à jour en fonction du firmware de l’unité de stockage (NAS/SAN).
Concernant le niveau de RAID, sur le matériel professionnel, IBM interdit l’usage de RAID 5 à partir d’une certaine taille de disque (de mémoire > 2 TB) et force RAID 6 pour des grappes constituées de “gros” disques. En outre, ces unités de stockage sont de toute façon mirrorées (RAID 6 + 1).
Pour info, la reconstruction d’une grappe RAID 5 avec des disques de 4 TB peut prendre plus de 24 heures sur du matériel professionnel (SAN).
Ayant déjà fait l’expérience de perdre plusieurs disques en l’espace de quelques jours voire quelques heures, sur des NAS, je fais systématiquement des réplications du NAS de backup sur un deuxième/troisième NAS de backup (backup du backup), ce qui me permet, par la même occasion d’avoir un jeu de données “off-site”.
Il faut toujours garder à l’esprit la règle 3-2-1 et être très parano en ce qui concerne la gestion des données.
Il faut également toujours optimiser les stratégies sur la base des restaurations et non pas sur la base des sauvegardes.
Il faut toujours vérifier les procédures de restauration et s’exercer régulièrement !!!
Le 30/01/2020 à 14h10
#52
Un sacré paquet d’heures pour l’avoir déjà vécu en temps que particulier " /> (donc pas d’urgence comme au boulot…)
Le 30/01/2020 à 14h10
#53
Le 30/01/2020 à 14h22
#54
C’est marrant, parce que généralement, on conseil justement de ne pas prendre les disques d’un même lot justement car ils ont tendance à lâcher avec le même nombre d’heure d’utilisation.
Après j’ai effectivement des sauvegardes géographiquement externe au cas où.
Le 30/01/2020 à 14h45
#55
C’est la densité d’écriture qui est différente à l’extérieur par rapport à l’intérieur
( pas tout à fait depuis que les disques durs existent " />)
In the begining " />
il y avait le CAV ( constant Angular Velocity ) et donc il y avait le même nombre de secteurs sur chaque piste. Docn en clair il fallait souvent attendre un tour pour aller chercher le secteur suivant.
Puis plus tard: on a inventé le ZBR ( Zone Bit Recording) .. en clair comme il a plus de place sur les pistes extérieures ( le fameux 2piR ) on s’est dit que en fonction de la zone ( extérieure ou intérieure) il fallait
mettre plus de secteurs sur les pistes extérieures.
Les chances de trouver tes secteurs seront plus grandes à chaqyue tour et les chances de les trouver sur moins de pistes seront plus grandes, d’oû un moinde nombre de seek ( déplacement des tètes de lecture )
et voila
C’était ma minute historique " />
Le 30/01/2020 à 15h44
#56
Le 30/01/2020 à 15h48
#57
Le 30/01/2020 à 15h51
#58
Le 30/01/2020 à 16h10
#59
J”a
Le 30/01/2020 à 17h33
#60
ah ben mon premier message est parti tout seul " />
Sauf que j’aurais du dire “data stripping par méthode d’accès”
Dans ce que tu décris , le fichier sort ( ou entre) de la mémoire du système sur une fibre ( ou un cable) et une seule et se répartit sur les disques grace au controlleur de RAID.
Dans ce dont je parle, les données sortent de la mémoire du système sur plusieurs fibres à la fois et arrivent sur plusieurs controlleurs à la fois. ( les controlleurs continuent de faire leur répartition tranquilou)
Cela permet de s’affranchir de la limitation de la fibre unique entre CPU et controlleur
Vas regarder ce qu’est un VSAM linear ou KSDS en data stripping ( c’est pas du xfs ou du NTFS " /> )
Quant à ce dont tu parles plus loin cela ressemble à du RAID1 soft qui écrit sur des controlleurs différents.( j’irais pas jusqu’à dire comme sur un windows mais presque ) ou alors du mirroring classique, remote synchro ( PPRC du XRC du Netapp du HTC mirror par exemple) ce qu’on fait classiquement entre 2 sites s’ils ne sont pas trop éloignés ou dans la même salle si on est un peu kamikaze " />
Le 30/01/2020 à 17h45
#61
Le 30/01/2020 à 17h48
#62
Le 30/01/2020 à 18h30
#63
Ben c’est quoi comme OS et comme baies de disques ?
du Z avec des Ficon 16s ?
ça m’interesse
Merci
Le 30/01/2020 à 19h02
#64
https://www.acronis.com/fr-fr/articles/backup-rule/
( t’en a d’autres que acronis mais c’est la même règle " /> )
https://www.acronis.com/fr-fr/articles/backup-rule/
Le 30/01/2020 à 21h51
#65
Je ne te suis pas, c’est quoi ton histoire de tranches ?
Et en pratique, sur des baies pas ridicules (genre EMC), accédées par plein de VM, on a de très beaux débits en linéaire sur les RAID.
Les tranches, c’est l’histoire de l’allocation dynamique des volumes SAN sur les disques. J’ai travaillé sur deux SAN (Storwize) configurés pour allouer lors de la première écriture, par pistes (track) de 128 ou 256ko de mémoire.
Le résultat, c’est que si on a plusieurs VM sur des volumes stockés sur le même RAID, on crée une fragmentation.
Je suis arrivé après coup, et sans formation, donc j’ai compris cela un peu tard… Déjà il m’a fallu réagir que le SAN était sur alloué (plus de taille de volume déclarée que de place disque réelle) - ça a failli nous exploser à la figure…
Pour les débits, je suis bien d’accord, j’ai vu un server SQL qui tenait le coup uniquement grâce au SAN (serveur 32 bits, 2Go de RAM pour SQL server, mais un volume transféré avec le SAN de plus de 60Go par jour, pour 10Go de base de données gérées…). Le 300Mo soutenu en lecture, c’était largement possible. Mais pas tout le temps et uniquement sur les disques rapides et le cache SSD, pas sur la partie lente. Et comme on ne contrôle pas directement où sont stockées les données…
Le 30/01/2020 à 21h58
#66
Rien à voir avec le remplissage donc. En fonction du partitionnement, et des technologies (LVM, chiffrement, etc), et même simplement du placement physique des données, on peut avoir des perfs variables. C’est avant tout la position de lecture/écriture qui importe. C’est assez rare de remplir simplement son disque du début à la fin linéairement, et encore plus rare de faire le contraire en faisant du ménage.
Mais oui, en effet, la différence entre le début (extérieur) et la fin d’un (intérieur) d’un disque est de plusieurs dizaines de Mio/s (quasiment 30 sur le mien il me semble).
Le 30/01/2020 à 22h13
#67
Le 31/01/2020 à 09h51
#68
Le 31/01/2020 à 13h23
#69
Le 31/01/2020 à 17h22
#70
Ce que tu dis n’est pas faux, mais en pratique de toutes façons, à partir du moment où une baie est utilisée par plein de VM, il y a des accès dans tous les sens et les têtes de lecture passent leur temps à se balader (déjà rien qu’avec une base de données), et on constate que les performances restent intéressantes (j’ai été épaté de voir ça sur une baie EMC avec 200-300 VM dessus, pas toutes super actives mais quand même). Je pense que les disques ont peu l’occasion de faire des accès linéaires (sur plusieurs Mo d’un coup) dans ce genre de cas, et ce qui aide ce sont les caches à tous les niveaux (RAM des VM, RAM des contrôleurs - même si ça parait léger vu les débits desservis, réordonnancement par les contrôleurs et autres NCQ, read-ahead, etc.).
Le 02/02/2020 à 13h21
#71
Le 02/02/2020 à 15h39
#72
Il y’a déjà eu plusieurs cas où le deuxième disque de la même série lâche 1 semaine après, surtout que tu lui met le stress de la reconstruction dans la tronche juste après que le premier lâche.
Le 03/02/2020 à 15h01
#73
Possible mais il y a quand même un côté récurrent « j’ai entendu dire que » qui fait que ça fait quelque temps que je me demande si c’est si vrai, surtout que les vendeurs de baies ne font pas forcément ça me semble.