Gandi revient sur sa longue panne de début janvier, qui rappelle l’importance des sauvegardes

Gandi revient sur sa longue panne de début janvier, qui rappelle l’importance des sauvegardes

Ceinture, Bretelle, Parachute !

Avatar de l'auteur
Sébastien Gavois

Publié dans

Internet

29/01/2020 12 minutes
73

Gandi revient sur sa longue panne de début janvier, qui rappelle l’importance des sauvegardes

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.

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.

À 16h 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 à 17h. Gandi pense alors que « le problème est peut-être lié à un problème matériel » ; un changement est effectué à 18h, 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 à 20h « pour voir s’il y a un moyen de l’accélérer ». Elle fait chou blanc. 

Une sauvegarde ? Quelle sauvegarde ?

À 21h, 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 ». 

Snapshots GandiSnapshots Gandi
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 . Nous décidons de modifier certaines valeurs ».

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) à 16h, 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 avec la possibilité maintenant d’éviter le scan complet du pool ». Dans son billet de blog, Gandi détaille les variables et paramètres utilisés pour ceux que cela intéresse. 

Le transfert ne se passe « évidemment » pas comme prévu

À 20h, 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 30h. 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 30h déjà écoulées.

Finalement 24h 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 14h 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.

Écrit par Sébastien Gavois

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

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 ?

Le brief de ce matin n'est pas encore là

Partez acheter vos croissants
Et faites chauffer votre bouilloire,
Le brief arrive dans un instant,
Tout frais du matin, gardez espoir.

Commentaires (73)


Je trouve que l’homme sur l’ilustration a un faux air de Gordon Ramsay. <img data-src=" />



(Avec le côté “panique en salle serveur” de la news c’est plutôt raccord, vous m’direz <img data-src=" />)





« 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) ?









WereWindle a écrit :



ça laisse songeur comme chiffre. Une idée de pourquoi c’est si lent (mode dégradé ou truc du genre) ?



C’etait peut être une vielle baie de stockage, en SCSI-1 <img data-src=" />



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 …


Si j’ai bien compris la news ça venais du scan d’intégrité en parallèle des données transféré.

&nbsp;D’ou l’echange avec un serveur gérant l’option pour éviter ça&nbsp;


y a plus de stockage sur bande de nos jours ?








Monsieur le Chat a écrit :



y a plus de stockage sur bande de nos jours ?





A mon avis c’est un peu compliqué sur ce genre de système qui met à disposition des instances. Après ça peut toujours se faire mais par contre c’est du “froid”. Tu n’auras qu’un état à un moment précis. Dans le cas présent on est revenu au moment du crash (si j’ai bien tout lu).



Très interessant merci !


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 <img data-src=" />








recoding a écrit :



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 <img data-src=" />





clairement. Déjà qu’à tête reposée c’est pas l’extase <img data-src=" />









WereWindle a écrit :



ça laisse songeur comme chiffre. Une idée de pourquoi c’est si lent (mode dégradé ou truc du genre) ?







Certainement qu’il y avait un calcul de signature d’intégrité de chaque bloc qui ralentissait considérablement le système.







Shadowman_2k3 a écrit :



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.







Non, si ton RAID est intègre, tu peux le remettre en service très rapidement. Il devra tout de même être revérifié par le système (avec des perfs moins bonnes) mais ça tournera.







Monsieur le Chat a écrit :



y a plus de stockage sur bande de nos jours ?







Les bandes c’est bien pour conserver des données froides… Là, c’est du chaud.

Et puis vu les volumes, c’est plus simple de dupliquer les baies et tout synchro sur disque.









Monsieur le Chat a écrit :



y a plus de stockage sur bande de nos jours ?





si mais c’est contraignant









recoding a écrit :



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 <img data-src=" />







Le plus gros problème dans ce genre de cas, c’est de savoir que le moindre truc que tu lances va mettre des heures et des heures. Et que si ça foire, ça prend de nouveau une plombe pour tester un autre truc…

C’est vraiment chiant car t’as tout le monde sur le dos pendant ce temps là : les clients, la direction, les chefs, etc qui sont tous sur les dents et te demandent des points d’étape sans arret.

Disclaimer : Je ne fais pas partie de Gandi, je ne parle que de mon expérience de type qui fait de la prod et qui a déjà été confronté à ce genre de problème









darkbeast a écrit :



si mais c’est contraignant





<img data-src=" />

Y’a pas de solution idéale dans le stockage. Toutes les solutions ont des avantages, des inconvénients et un prix monstrueux qui fait pleurer le DAF.









WereWindle a écrit :



ça laisse songeur comme chiffre. Une idée de pourquoi c’est si lent (mode dégradé ou truc du genre) ?



Je ne sais pas si c’est la lecture ou l’écriture qui pose problème.

D’après l’article ils ont cherché une solution pour restaurer sans “scanner l’intégralité du pool”. Donc ce n’est pas une simple lecture - il ya avait un traitement lourd.



Ensuite, suivant le type de RAID, il y a des contraintes. JE vais illustrer sur ce que j’ai le plus pratiqué: RAID-5.



&nbsp;RAID-5 est très utilisé car économique en coût d’achat et ayant un bon compromis pour les perfs et la sécurité, mais en écriture il est mauvais: écrire sur 1 disque revient à écrire sur au moins 2 disques (selon le nombre de disques de parité) tout en lisant sur TOUS les disques de données (car la parité est calculée à partir de tous les disques).



Principe de raid 5:





  • &nbsp;parité = XOR entre tous les secteurs de données de même position

  • une donnée = XOR entre tous les secteurs de données (hormis le disque de la donnée) de même position et la parité

  • C’est basique, c’est simple, c’est génial.&nbsp;





    &nbsp;En pratique, quand on écrit une donnée on doit écrire la parité, qui elle découle de la lecture de tous les disques de données. Même avec des disques durs 15000 tours, ça fait beaucoup d’opération disque à attendre. De plus, il faut systématiquement attendre une lecture parallèle et 2 écritures (parallélisables aussi)

    &nbsp;Alors OK, les baies sont bourrées d’optimisations, de caches.. Mais les files d’écritures ont une longueur limite et les caches en cas d’écriture sont divisés par le nombre de disques (puisqu’ils lisent tous), donc en écriture soutenue, un RAID-5 s’écroule assez rapidement. Si en plus on lui demande de lire en parallèle pour contrôler quelque chose, c’est la cata. Et quand on a des baies, du SAN, on n’a pas forcément dédié une baie à un espace de stockage, donc on partage les ressources (un SAN, c’est comme un hyperviseur mais pour le stockage)

    Le problème de mon point de vue, c’est surtout la granularité de la sauvegarde: la sauvegarde de tout un système en même temps c’est simple, mais sans pouvoir restaurer morceaux par morceaux, cela force tous les utilisateurs à attendre que toute la sauvegarde soit restaurée pour continuer.









KP2 a écrit :



<img data-src=" />

Y’a pas de solution idéale dans le stockage. Toutes les solutions ont des avantages, des inconvénients et un prix monstrueux qui fait pleurer le DAF.







surtout le cloud, le “ouais c’est moins cher que du local, pas de backup….”. Et au bout de quelques mois tu pleures.



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 <img data-src=" />





Intéressant ce retour d’expérience sur zfs, le meilleur filesystem.


ZFS c’est pas mal

Mais Murphy dans une salle, ça aide pas <img data-src=" />








JoePike a écrit :



C’est bien mais l’important est la restoration et le temps que ça met







Restauration ET intégrité des données. <img data-src=" />



C’est souvent dans ces cas là qu’on se rend compte que les sauvegardes sont pourries, car les tests de restauration ne sont jamais faits.



Après, le plus gros problème reste l’éternel ratio coût/risque accepté par le client qui va évidemment vouloir un RTO/RPO de 3 secondes sans débourser plus d’un euro par mois pour ça. De souvenir d’ancienne vie, un client qui avait baissé ses exigences de durée d’indisponibilité face au coût engendré par la haute dispo et donc il tolérait contractuellement la perte de l’appli pendant 3 jours avec best effort pour remise en service.

Mais la moindre coupure de 10 minutes c’était cellule de crise, hurlements et panique pour rétablir dans la seconde avec limite menace de se prendre l’armée dans la tronche.



Dommage qu’un sujet aussi sensible ne soit que très rarement pris au sérieux.



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% <img data-src=" />


J’ai eu à peu près la même chose sur un…



&nbsp;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…<img data-src=" />

Ne parlons pas des saisies perdues dans l’intervalle qu’il faut refaire,&nbsp; 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. <img data-src=" />








SebGF a écrit :



De souvenir d’ancienne vie, un client qui avait baissé ses exigences de durée d’indisponibilité face au coût engendré par la haute dispo et donc il tolérait contractuellement la perte de l’appli pendant 3 jours avec best effort pour remise en service.

Mais la moindre coupure de 10 minutes c’était cellule de crise, hurlements et panique pour rétablir dans la seconde avec limite menace de se prendre l’armée dans la tronche.



Dommage qu’un sujet aussi sensible ne soit que très rarement pris au sérieux.







En fait, personne ne comprend la notion de risque (et donc de SLA).

Et pas seulement en informatique…









fabcool a écrit :



un truc comme ça, c’est un coup à demander un presta hébergement en saas. <img data-src=" />







… qui ne sera pas forcément meilleur mais ce n’est plus mon problème <img data-src=" />



meme à 133Mo/s (débit brut moyen d’un hdd moderne, certifié par mon doigt mouillé ©), copier un 8To c’est plus de 16h …&nbsp;

alors quand tu rajoutes les opé de parité, checksum … on arrive facilement à un compte en jour








LordZurp a écrit :



meme à 133Mo/s (débit brut moyen d’un hdd moderne, certifié par mon doigt mouillé ©), copier un 8To c’est plus de 16h …







Un HDD entreprise, ça monte facile à 250-300Mo/s aujourd’hui mais bon, ça fait toujours un paquet d’heures de copie…



Secteur bancaire ?








SebGF a écrit :



….

Restauration ET intégrité des données. <img data-src=" />

….

.







<img data-src=" />

Mais bon une restauration de données pourries, perso j’appelle pas ça de la restauration

j’ai d’autres mots pour cela



Le GIGO principle en informatique existe depuis des années ( Garbage In Garbage Out ) et ça va durer encore longtemps.









KP2 a écrit :



Un HDD entreprise, ça monte facile à 250-300Mo/s aujourd’hui mais bon, ça fait toujours un paquet d’heures de copie…



Même quand tu atteins les limites du cache? Même&nbsp; en accès aléatoire?

J’ajoute que parfois on ajoute couche sur couche (SAN-RAID-Datastore de VM) et qu’au final, le système d’exploitation voit un beau disque tout lisse alors que derrière c’est tout un spaghetti, et l’OS a beau se croire hyper intelligent il fait tout de travers pour le SAN en bout de chaîne.



Imaginons une VM avec un disque en thin provisionning dans un datastore, lui-même servi sur un volume de SAN en dynamique qui alloue par tranche de 256k sur un RAID partagé, et qui a été écrit la 1ère fois en parallèle d’une machine au comportement similaire… Ben on se retrouve avec une espèce de fragmentation niveau SAN, que l’OS est totalement incapable de voir.

Et là, vive le tiering avec le SSD en tête pour rattraper la situation!



D’ailleurs, sur les grosses baies on est en tiering, ce qui fait que toute une grosse partie des données (les moins fréquemment utilisées) sont sur les disques lents.



C’est d’ailleurs un phénomène existant à plus faible échelle: quand on restaure de grosses bases (compta, RH), souvent la restauration est longue car le SAN dépose beaucoup sur le tier lent. Et la compta reste lente tant que le SAN ne passe pas un max de données vers le tier SSD (en cache SSD), soit souvent … une fois par semaine…&nbsp;



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








JoePike a écrit :



Le GIGO principle en informatique existe depuis des années ( Garbage In Garbage Out ) et ça va durer encore longtemps.







Ah, chez nous on a une version plus explicite de ce principe… SISO (Shit In, Shit Out). <img data-src=" />

(je l’ai surtout appris durant les projets basés sur de la SOA, ça se remarque très vite dans ce genre de domaine <img data-src=" /> )









brice.wernet a écrit :



&nbsp;RAID-5 est très utilisé car économique en coût d’achat et ayant un bon compromis pour les perfs et la sécurité, mais en écriture il est mauvais: écrire sur 1 disque revient à écrire sur au moins 2 disques (selon le nombre de disques de parité) tout en lisant sur TOUS les disques de données (car la parité est calculée à partir de tous les disques).





Sans compter le risque (qui peut être statistiquement très élevé) sur les volumes avec de gros disques durs en RAID 5 d’échec de la procédure de reconstruction / de corruption des données …

Vous savez le fameux : “Non-recoverable read errors per bits read” (je peux détailler plus au besoin) …



Et je ne parle même pas du fait que si une seconde unité tombe pendant la reconstruction, cela peut véritablement tourner à la catastrophe …



&nbsp;







JoePike a écrit :



ZFS c’est pas mal

Mais Murphy dans une salle, ça aide pas <img data-src=" />&nbsp;

&nbsp;



Malheureusement, Murphy s’invite souvent dans ce genre de cas. <img data-src=" />









Juju251 a écrit :



Et je ne parle même pas du fait que si une seconde unité tombe pendant la reconstruction, cela peut véritablement tourner à la catastrophe …&nbsp;





Genre…. il y a des gens qui s’amuseraient à mettre les même disque d’une même série de la même période sur la même grappe&nbsp;<img data-src=" />



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 <img data-src=" />


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 <img data-src=" />








crg a écrit :



La plaie pour faire comprendre à un monsieur michu que c’est plus cher qu’un disque USB 2 To de supermarché.



Exact. Il n’y a que quand tu gère/a géré du stockage que tu comprend pourquoi on n’alloue pas 1To par serveur. A 300€ le disque + l’augmentation du coût de maintenance annuelle + le fait que souvent tu doivent augmenter non pas 1 mais 3-6 disques pour étendre le stockage…



Les admins passent pour des pingres mais heureusement qu’ils sont là pour faire des garde-fous. Mais c’est vrai que quand tu accordes 50Go et qu’on te dit “c’est à peine 14 de mon iPhone” “comment on peut bosser avec aussi peu”, tu dois garder ton calme tant que tu n’as pas raccroché le combiné.





Juju251 a écrit :



Vous savez le fameux : “Non-recoverable read errors per bits read” (je peux détailler plus au besoin) …&nbsp;



Je ne l’avais pas celle là …

&nbsp;



Juju251 a écrit :



Et je ne parle même pas du fait que si une seconde unité tombe pendant la reconstruction, cela peut véritablement tourner à la catastrophe …&nbsp;



C’est tabou. On n’évoque pas cela. On fait des messes noires et des sacrifices pour ça n’arrive pas. On est donc paré.&nbsp;



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.


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é <img data-src=" />



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.








Shadowman_2k3 a écrit :



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 …&nbsp;







Kazer2.0 a écrit :



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.&nbsp;



&nbsp;Les NAS clé en main sont souvent construits sur du Linux (y compris les SAN à 30k€, qui sont des PC à l’intérieur, de bons gros i5/i7). Donc du moment qu’il n’y a pas de cryptage physique lié&nbsp; &nbsp;à la CM, tu as des chances de remonter le NAS sur un linux/BSD standard…

&nbsp;

Mais attention: il y a parfois des différences dans la prise en charge de la géométrie par les RAID des CM. En gros, un FreeNAS monté sur un RAID physique Intel redémarrera certainement sur un RAID physique Intel d’à peu près la même année/gamme. Et c’est déjà un import, la CM va normalement râler que le RAID ne vient pas de son système. Il y aura certainement une vérification au démarrage à minimum, peut-être une reconstruction.

Et l’importer sur un RAID d’une carte fille ou d’une carte mère avec contrôlleur RAID supplémentaire ou pour ARM/AMD ne sera pas forcément possible.

&nbsp;

Si le RAID est logiciel, c’est moins risqué pour la récupération (risque quasi nul je pense).



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 <img data-src=" />



Mais pour d’autre NAS ou système de stockage qui utilise une carte RAID physique la question se pose oui.








Kazer2.0 a écrit :



Mais pour d’autre NAS ou système de stockage qui utilise une carte RAID physique la question se pose oui.



Je ne sais pas si c’est une pratique généralisée à tous les constructeurs, mais j’ai eu 3 cartes RAID de modèles différents du même constructeur, sur une période de 15 ans, et les RAID 5 créés par chacune fonctionnaient directement avec les deux autres, dans tous les sens et sans délai de vérification/reconstruction.



Donc en cas de panne d’une carte, je n’ai apparemment qu’à racheter le modèle actuellement en vente de ce constructeur pour retrouver mon RAID, pas besoin de retrouver le même modèle que la carte qui vient de lâcher.



Il faut juste vérifier de temps en temps que le constructeur n’a pas coulé…









recoding a écrit :



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 <img data-src=" />





Ho lala cela a du être sacrément&nbsp; intense!!! Plus tard ça fait des souvenirs mais sur le moment ce n’est pas drôle du tout.



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


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à


Secteur des loisirs ;)

&nbsp;


Exactement mais bon au moins ça évitera à l’équipe l’infra de se prendre des scud.


Il existe de très grosses baies dont les controllers font du stripping , et la vitesse d’un seul HDD ne représente rien








Inodemus a écrit :



Donc en cas de panne d’une carte, je n’ai apparemment qu’à racheter le modèle actuellement en vente de ce constructeur pour retrouver mon RAID,&nbsp;

Il faut juste vérifier de temps en temps que le constructeur n’a pas coulé…





Dans le même constructeur, ça se tient avec ce que j’évoquais plus haut. Le hic, c’est si ton constructeur est racheté aussi, notamment par IBM ou autre.

Chez IBM tout est taggé: sache que tu ne mets pas dans un SAN IBM un disque qui ne fasse pas partie des modèles reconnus et des firmwares reconnus de ce modèle. Le disque est rejeté. La mise à jour des disques et firmwares reconnus est dans les mises à jour que tu n’obtiens que si tu payes toujours la maintenance.



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)


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


Je suis d’accord <img data-src=" />

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 <img data-src=" />

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





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 &gt; 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”.

&nbsp;

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


Un sacré paquet d’heures pour l’avoir déjà vécu en temps que particulier <img data-src=" /> (donc pas d’urgence comme au boulot…)








Br31zh a écrit :



Depuis quand la vitesse dépends du remplissage ?.







Depuis que les disques durs existent. Et sans parler de fragmentation (qui renforce ce problème). Simplement parceque la vitesse d’ écriture ou lecture n’est pas la même sur les pistes vers le bord extérieur que vers le bord intérieur, près de ‘axe de rotation.



Typiquement, au-delà de 70-80% de remplissage, les vitesses d’écriture en particulier s’éffrondrent vitesse grand V.



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


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 <img data-src=" />)

In the begining <img data-src=" />

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 <img data-src=" />








LordZurp a écrit :



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





Je te rejoins, mais je ne crois pas que les calculs de parité prennent beaucoup de temps, vu les performances d’un CPU en Go/s de “XOR” par rapport à la vitesse de lecture d’un disque dur. Même sur un petit Celeron “U” à 1,8 GHz, un hash MD5 va à 300 Mo/s (avec les données déjà dans la mémoire cache).

C’est plutôt de lire tous les disques en même temps, pas linéairement, en faisant un peu de traitement (rechercher les transactions).







KP2 a écrit :



Un HDD entreprise, ça monte facile à 250-300Mo/s aujourd’hui mais bon, ça fait toujours un paquet d’heures de copie…





Là c’est vraiment récent, j’étais plutôt resté sur du 200 Mo/s pour un disque, ce qui est déjà pas mal, puisqu’ensuite les baies agrègent ça du fait des RAID.







brice.wernet a écrit :



Même quand tu atteins les limites du cache? Même en accès aléatoire?





Non il parle en linéaire, sinon en aléatoire un disque dur classique est assez mauvais en comparaison.

Quelles limites du cache ?

Effectivement sur mes disques durs grand public, j’ai déjà des débits linéaires entre 150 et 200 Mo/s, en lecture ou écriture (je parle de vraies copies de fichiers).







brice.wernet a écrit :



Imaginons une VM avec un disque en thin provisionning dans un datastore, lui-même servi sur un volume de SAN en dynamique qui alloue par tranche de 256k sur un RAID partagé, et qui a été écrit la 1ère fois en parallèle d’une machine au comportement similaire… Ben on se retrouve avec une espèce de fragmentation niveau SAN, que l’OS est totalement incapable de voir.





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.







Meptalon a écrit :



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à





Ce n’est pas une question de disque vide ou plein, mais plutôt de l’endroit du disque accédé ; effectivement, en fin de disque (au centre) le débit est nettement moindre, on perd au moins un bon tiers. Le remplissage du disque dépend du choix du filesystem.







JoePike a écrit :



Il existe de très grosses baies dont les controllers font du stripping , et la vitesse d’un seul HDD ne représente rien





Ben rien que du RAID miroir ou 56 ça fait du stripping, en pratique.







Br31zh a écrit :



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





Si tu testes le tien (facile avec un “dd” avec “skip” sous Linux pour la lecture seule), tu verras que ça baisse pas mal, même si on reste au-dessus des 100 Mo/s.







Erwannys a écrit :



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.



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.





Effectivement, avec certaines marques de baies, comme EMC, c’est eux qui fournissent les disques, et je ne crois pas qu’ils s’amusent à mélanger les séries.







Kazer2.0 a écrit :



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.





Je me demande si ce n’est pas une légende, même si on lit ça régulièrement. C’est comme les gens en 2019 qui t’expliquent qu’il ne faut pas mettre de swap sur un SSD car ça va l’user (alors qu’en pratique avant d’user un SSD, il y a de la marge, il sera remplacé avant).










JoePike a écrit :



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.

[..]

Hélas le data stripping n’est réservé qu’aux très riches ( les banques principalement) et qu’à des plateformes spécifiques





Pour moi ton commentaire est fumeux, déjà le “data stripping” ça veut juste dire “répartition des données par bandes/blocs” (en résumé). Et sur un RAID on accède à des blocs à la base, pas à des fichiers (ça c’est l’OS quand il monte le filesystem sur le RAID, qui est présenté comme un medium à accès bloc).



Ça dépend de ton OS et ton matériel, j’ai une connaissance hébergeur qui fait du RAID sur plusieurs boîtiers physiques, reliés en SAS/e-SATA (je ne sais plus exactement) au serveur, chaque bloc est dupliqué sur 2 boîtiers (en fait 3, il fait du triple miroir), chaque boîtier ayant plusieurs disques. Ça permet de pallier la perte d’un boîtier, carrément.









fabcool a écrit :



Exactement mais bon au moins ça évitera à l’équipe l’infra de se prendre des scud.







On est d’accord <img data-src=" />



J”a


ah ben mon premier message est parti tout seul <img data-src=" />



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 <img data-src=" /> )



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 <img data-src=" />








JoePike a écrit :



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.





Tu as mal lu. Chaque boîtier est relié par sa propre connexion au serveur. La bande passante totale est énorme en fait (je crois qu’avec sa config on arrive à un total de 48 Gb/s).

Et il n’y a pas de contrôleur RAID, c’est l’OS et le filesystem (ZFS) qui gère l’aspect RAID, ici en triple miroir. Pour ce spécialiste, ça fait longtemps que les cartes RAID ne sont plus utiles (il en a utilisé dans le temps), surtout vu l’efficacité et les fonctions avancées qu’offre ZFS, dont un rebuild d’autant plus rapide que le volume n’est pas rempli.









crg a écrit :



La plaie pour faire comprendre à un monsieur michu que c’est plus cher qu’un disque USB 2 To de supermarché.



Je veux bien le croire (je ne bosse pas dans ce domaine), déjà que j’ai l’impression d’être un extra-terrestre quand j’indique que j’utilise du RAID 1 pour mes données sur mon PC de bureau … (+ des disques de sauvegarde, hein, pas fou <img data-src=" />).







Erwannys a écrit :



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



Qu’est-ce que tu appelles Règle 3-2-1 ?

Perso, je suis parano en matière de stockage de données (et des mots de passe, mais c’est un autre sujet).

Je pars du principe que si un truc merde, il est très probable qu’un problème quasi-simultané survienne aussi …

Au hasard : Un disque qui pète et une connexion en rideau alors qu’il faut aller chercher les données sur le Cloud …



Ben c’est quoi comme OS et comme baies de disques ?

du Z avec des Ficon 16s ?



ça m’interesse

Merci


https://www.acronis.com/fr-fr/articles/backup-rule/

( t’en a d’autres que acronis mais c’est la même règle <img data-src=" /> )

https://www.acronis.com/fr-fr/articles/backup-rule/




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.&nbsp;

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…


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.



&nbsp;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).








JoePike a écrit :



https://www.acronis.com/fr-fr/articles/backup-rule/

( t’en a d’autres que acronis mais c’est la même règle <img data-src=" /> )

https://www.acronis.com/fr-fr/articles/backup-rule/





Okay. ^^

Je ne connaissais pas l’intitulé de cette règle. ^^



Merci ! ;)









JoePike a écrit :



Ben c’est quoi comme OS et comme baies de disques ?

du Z avec des Ficon 16s ?





Sauf erreur de ma part, c’est du FreeBSD, sur lequel ZFS est natif et dispose de toutes les fonctionnalités avancées. Les boîtiers je ne saurais te préciser, ce sont des boîtiers passifs avec des SAS expanders.







brice.wernet a écrit :



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.





Par définition, le RAID crée de la fragmentation (que ce soit le stripping ou le RAID 5 ou 6). Mais ce n’est pas forcément un problème si les données sont lues linéairement, un RAID 5 ça délivre plus de bande passante qu’un disque isolé.







brice.wernet a écrit :



Pour les débits, je suis bien d’accord, j’ai vu un server SQL qui tenait le coup uniquement grâce au SAN [..] Le 300Mo soutenu en lecture, c’était largement possible.





Ben oui, sinon on n’utiliserait pas de baies si ça avait des mauvaises performances :-) .







Br31zh a écrit :



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





Il faut compter en relatif, et là on parle de ralentir de 100 % à ~60 %, souvent. J’ai un de mes disques par exemple qui passe de 170 à 100 Mo/s entre le début et proche de la fin.









OlivierJ a écrit :



Par définition, le RAID crée de la fragmentation (que ce soit le stripping ou le RAID 5 ou 6). Mais ce n’est pas forcément un problème si les données sont lues linéairement, un RAID 5 ça délivre plus de bande passante qu’un disque isolé.&nbsp;



&nbsp;Et c’est là que le bât blesse: avec tous les niveaux de virtualisation (OS, datastore, SAN), c’est linéaire mais à “trous”: les datastores sont stockés sur des pistes dans l’ordre, mais pas consécutives. Pire encore avec le thin provisioning sur les VM: les trous sont multipliés. Par exemple, un cas pourri serait si une appli est stockée sur le même volume SAN que le serveur BDD, et que tout soit en provisionnement à l’écriture:

* l’appli reçoit une charge de travail fichier -&gt; provisionnement d’une piste

* la BDD enregistre des données&nbsp; -&gt; provisionnement d’une piste

-&gt; la BDD est stockée une piste sur 2



Après, si tu as du tiering, c’est potentiellement masqué/temporaire.



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








OlivierJ a écrit :



Sauf erreur de ma part, c’est du FreeBSD, sur lequel ZFS est natif et dispose de toutes les fonctionnalités avancées. Les boîtiers je ne saurais te préciser, ce sont des boîtiers passifs avec des SAS expanders.



….

.









Ben je suis assez surpris

On parle d’un procédé de striping à la sortie du CPU qui est utilisé depuis plus de 20 ans et dont le principal

avantage est de faire plusieurs I/O parralèles sur des tuyaux différents et des controlleurs différents.

Et la tu décris un striping qui semble similaire (sauf que c’est du ZFS) qui part sur des SAS expanders avec des boitiers passifs ( à titre perso j’avoue ne pas savoir ce qu’est un boitier passif).

Ce qui me gêne c’est que si on utilise des expanders, on utilise moins de tuyaux sur le chemin complet vers les disques, ce qui fait baisser les performances et éliminer une partie des bienfaits de la séparation des I/O en particulier sur ce genre de striping.( les expanders sont indolores dans les configs classiques sans striping niveau OS)



entre parenthèse ( cela n’a rien à voir avec les perfs) mais il est amusant de constater une similarité avec l’article sur GANDI, c’est du Nexenta/FreeBSD , ZFS Triple miroir ( ça fait joli du point de vue marlketing)



Moi ce que je retiens de cet incident, c’est qu’il ne semble pas exister de copies synchrones de baies sur un autre site ni de sauvegardes sur un autre site et qu’ls n’avaient aucune idée du temps que ça allait prendre pour se récupérer.

S’il y a le feu sur le site , une inondation, ou un crash d’avion ou je ne sais quoi, ce sera même motif même punition (bien pire en fait)



Les PCO et les PRA ne sont pas des affaires simples mais c’est pour ça qu’on est payé si cher pour les pondre et les implémenter <img data-src=" />.






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.


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.