Dans le domaine informatique, les besoins de stockage sont toujours plus importants, côté grand public et professionnel. Deux points sont à prendre en compte : une tolérance plus ou moins importante aux pannes et les niveaux de performances. Le RAID peut apporter des solutions sur les deux points.
Si les SSD ont le vent en poupe pour leurs débits (théoriques) et faible latence, les disques durs restent largement plus intéressants sur le rapport capacité/coût. On trouve en effet des HDD de 4 To aux alentours de 80 euros, et même des versions de 14 To à moins de 250 euros. Avec des SSD, les chiffres s’envolent, surtout si l’on prend du PCIe/NVMe.
Problème : avec une telle capacité, à la moindre défaillance du disque dur, ce sont autant de données qui s’envolent. Pour éviter de dépendre de la panne d'un ou plusieurs périphériques de stockage, une technologie de redondance née dans les années 90 est le plus souvent utilisée : le fameux RAID. Si son évolution est plutôt limitée, il en existe différents types, qui peuvent évoluer selon le nombre d'éléments et les constructeurs.
Avant de continuer, un point important à bien prendre en considération : le RAID n'est pas une solution de sauvegarde en tant que telle, c'est plutôt une protection contre la défaillance d'une (ou plusieurs) unité de stockage. Cette technologie peut néanmoins s’inscrire dans le cadre d’une stratégie globale de sauvegarde.
Le RAID en quelques mots
De manière simple, le RAID est une solution technique permettant de décorréler l'espace de stockage, tel qu'il est perçu par le système d'exploitation, des éléments physiques qui le composent (HDD, SSD, etc.). On peut ainsi comparer cela à de la virtualisation du stockage.
Avant de plonger dans les détails techniques, un peu de vocabulaire qui sera utile pour la suite. RAID signifie aujourd’hui Redundant Array of Independent Disks, soit un regroupement redondant de disques indépendants dans la langue de Molière.
Mais à ses débuts en 1987, RAID était l’acronyme de Redundant Arrays of Inexpensive Disks, soit regroupement redondant de disques peu onéreux. Comme nous l’avons expliqué dans notre Magazine #1, le coût du stockage ayant fondu comme neige au Soleil depuis, la notion de « peu onéreux » n’a plus grand intérêt.
- Composition, technologies et fonctionnalités : on vous dit tout du disque dur moderne
- L’extraordinaire évolution du stockage
C’est quoi une grappe ?
Lorsque l’on parle d’une grappe RAID, cela comprend l’ensemble des périphériques de stockage utilisés en RAID, et donc vue comme étant une seule entité de stockage par le système. La gestion du RAID peut être matérielle (avec une carte ou une puce dédiée par exemple) ou logicielle. Dans le grand public (carte mère, NAS, etc.) c’est souvent la seconde version qui est utilisée.
Une grappe RAID peut avoir plusieurs objectifs : améliorer les performances, augmenter la sécurité des données, ou bien les deux à la fois. Le choix des disques durs, du processeur, de la carte mère/contrôleur dédié et du type de RAID auront de forts impacts sur le résultat final.
Vocabulaire : avez-vous les bases ?
On parle aussi parfois de RAID semi-logiciel, semi-matériel ou pseudo-logiciel. Il s’agit en fait de ce que l’on trouve généralement sur les cartes mères et les NAS grand public. Le contrôleur intégré propose du RAID, mais il est géré de manière logicielle, et donc par le processeur de la machine. L’avantage du semi-matériel/logiciel géré par l’UEFI/BIOS de la machine est de pouvoir booter son système d’exploitation dessus.
Il est souvent question de tolérance de panne, une notion très importante. Il s’agit du nombre de périphériques de stockage que peut perdre une grappe sans compromettre l’intégrité des données. Par exemple, un RAID 5 a une tolérance d’un disque. Pour résumer, si vous avez quatre disques durs et que l’un rend l’âme, vous ne perdez aucune donnée.
C’est l’occasion de revenir sur un autre terme : le mode dégradé. Cela arrive en cas de panne, dans la limite de la tolérance permise par la grappe. Un disque dur est hors service, mais vous pouvez toujours accéder à vos données, avec des performances généralement en (fortes) baisses.
Lorsque vous changez le périphérique défectueux, vous pouvez alors lancer la reconstruction ; c’est-à-dire remettre en place la grappe RAID dans un mode sain. Cette étape peut être très (très) longue en fonction du type de RAID, du nombre de disques durs, de la quantité de données, etc.
RAID 0 = 0 sécurité, mais de bonnes performances
Pour commencer à illustrer le fonctionnement du RAID, prenons les deux modes de fonctionnement les plus simples : le stripping ou RAID 0, et le mirroring ou RAID 1. Dans les deux cas, il faut au minimum deux périphériques. Rappelez-vous dès maintenant d’une maxime à connaitre par cœur : RAID 0 = 0 sécurité !
Le RAID 0 consiste en effet à découper la lecture/écriture des données pour l'effectuer sur les différents périphériques en même temps, et ainsi accélérer le processus. Plus il y a d'éléments, meilleures seront les performances. Par exemple, pour lire ou écrire 100 Go de données avec deux disques durs en RAID 0, il faut lire ou écrire 50 Go sur chaque disque. Avec cinq disques en RAID 0, on passe à seulement 20 Go par disque.
La capacité de stockage est également très bonne puisqu'elle est égale à la somme des éléments. Mais cette solution a un inconvénient de taille : si une panne intervient sur l'un des périphériques, toutes les données sont perdues sans possibilité de les récupérer. Avec un RAID 0 de cinq disques de 4 To, la défaillance d’un seul disque entraine donc la perte des 20 To d’espace de stockage.
En RAID 1, chaque donnée est stockée sur les deux disques.
Crédits : Cburnett, CC BY-SA 3.0, via Wikimedia Commons
RAID 1 : à vous de décider du niveau de tolérance de panne
Le RAID 1 consiste de son côté à écrire/lire les mêmes données en simultané sur deux (ou plus) éléments. Ainsi, en cas de panne sur l'un, un autre peut être utilisé.
Les performances en écriture ne sont pas améliorées puisqu’il faut écrire la totalité des données sur l’ensemble des périphériques de la grappe, mais celles en lecture peuvent l’être. En effet, si l’on doit lire 100 Go de données sur cinq disques durs en RAID 1, on peut très bien lire 20 Go sur chacun.
Notez enfin qu’on parle parfois de duplexing en mode RAID 1, cela signifie que chaque périphérique a son propre contrôleur, ce qui ajoute un niveau de sécurité si un des contrôleurs venait à tomber en panne.
Quoi qu’il en soit, en RAID 1 la capacité totale de la grappe sera égale à celle du plus petit périphérique de stockage. Avec 2, 3, 4, 5 ou même dix disques durs de 4 To, la capacité totale sera de… 4 To. La sécurité procurée par le RAID 1 a donc un coût qui est loin d’être négligeable.
RAID 5 : un compromis, avec trois disques minimum
C'est là qu'intervient une solution intermédiaire : le RAID 5. Elle nécessite au moins trois périphériques, et consiste à accéder à tous ceux de la grappe en simultané. Durant la phase d'écriture, des bits de parité sont également stockés sur chaque élément. Ils permettront de reconstituer les données perdues en cas de problème sur un des périphériques de stockage.
Crédits : Cburnett, CC BY-SA 3.0, via Wikimedia Commons
Ainsi, on dispose de performances accrues, surtout en lecture, d'une protection en cas de panne, mais aussi d'une capacité de stockage qui n'est pas amputée de manière trop importante, puisque les bits de parités occupent toujours l'équivalent de la taille d'un élément de la grappe.
Avec des unités de même capacité, on perd donc l’équivalent d’un disque. Pour résumer, si on a « n » disques durs de « y » To, la capacité de la grappe en RAID 5 est de « (n-1) * y To ». Ainsi, avec trois disques durs de 4 To, la capacité accessible sera de 8 To, avec quatre HDD on passe à 12 To, etc.
Il existe néanmoins des inconvénients. Déjà, les performances en écriture ne sont pas exceptionnelles puisqu'il faut écrire les bits de parité en même temps que les données. Il faut également les calculer, ce qui peut avoir un impact dans le cas d’une solution logicielle avec un processeur un peu faiblard. En cas de panne d’un des périphériques, une fois l’unité remplacée, la reconstruction de la grappe peut prendre (beaucoup) de temps.
Ensuite, ce dispositif ne supporte que la perte d'un élément de la grappe. Si deux tombent en panne en même temps, la reconstitution des données ne sera pas possible. Mais il existe d’autres niveaux de RAID pour cela, notamment les RAID 6, 10, 50, 60… que nous verrons dans un prochain article.
Synology propose un « comparateur de RAID » permettant d’ajouter jusqu’à 12 unités de stockage et de choisir son niveau de RAID. Le simulateur donne alors l’espace disponible (en vert), l'espace utilisé pour la protection des données (en bleu) et enfin l’éventuel espace perdu (en gris).
Commentaires (66)
#1
Je lirais l’article en rentrant mais d’ors et déjà, j’adore le sous titre xD
#2
Mais attention au RAID5 à fuir comme la peste avec les disques durs supérieurs à 2To: la probabilité d’une erreur de lecture incorrigible (donnée fournie pour chaque disque, de 10^14 à 10^17 pour les meilleurs) est de plus de 30% (sur 6 disques) ! C’est terrible, car ça annule le bloc et là, on prie pour la localisation du bloc (sachant que souvent les contrôleurs disent “fuck you”).
C’est moins pareil avec les SSDs, mais ça craint quand même parfois du cul.
#2.1
Sur des NAS Qnap 6 et 8 baies, en 10 ans, j’ai déjà eu des problèmes de disques (gamme entreprise), mais pas de RAID. En tout cas, je n’en ai pas été notifié.
#2.2
On n’utilise pas de NAS QNAP, Syno ou autres marques de “particuliers / power users”, c’est soit du HPE ou du NETAPP, mais sur des HPE, tu peux avoir ce genre de messages avec du Raid 5 : https://content.spiceworksstatic.com/service.community/p/post_images/0000285472/5a30490f/attached_image/ProLiant350.png
Et pour parler du cas le plus courant, des vieux hyperviseurs avec beaucoup de VMs et bien les données prenaient vraiment un coup quand tu avais ce message après un rebuild qui ne marchait pas.
#2.3
Oui, c’est sur que sur matos d’entreprise les messages sont plus verbeux.
J’ai un DD actuellement (depuis quelques jours) mis en défaut pour des erreurs d’allocation…
Il va falloir que j’en commande un autre rapidement.
#3
Juste pour être clair sur le RAID5 en écriture: dans le cas de 4 disques, si on veut écrire un secteur sur le disque 1:
–> Avec des SSD, c’est rapide, mais on multiple les écritures.
–> Avec des disques durs, il faut bien s’imaginer qu’il va falloir attendre le plus lent des disques à chaque fois.
Le principe de base est très simple, c’est basé des propriétés du XOR (disque 4=disque 1 XOR disque 2 XOR disque 3 -> si on perd disque 4 on a toujours les données, si on perd disque 2, sa donnée c’est disque 4 XOR disque 3 XOR disque 1)
#4
C’est quoi RAID : c’est très utile en été, ça tue les moustiques.
Comment ça marche : enlever le bouchon, viser les moustiques, appuyer sur le spray
#5
Attention avec les RAID5 et 6 :
. https://www.zdnet.com/article/why-raid-5-stops-working-in-2009/
. https://www.zdnet.com/article/why-raid-6-stops-working-in-2019/
En entreprise (chez nous en tout cas), c’est full RAID 10 (ou raid 1), le RAID 6 on n’a jamais trop utilisé mais, le RAID 5 s’est souvent mal fini surtout sur des pools de stockages bien remplis.
#5.1
Le RAID 6 n’est pas mort. L’avantage du RAID 6, c’est qu’il peut supporter m disques défaillants sur n, avec m >= 2. On voit souvent que c’est limité à 2, mais c’est une erreur et cela peut aller bien plus loin !
Maintenant, c’est comme tout : il faut dimensionner son RAID en fonction des risques que l’on est prêt à accepter.
L’article de zdnet concernant le RAID 6, je le trouve bien incomplet, sur plusieurs points :
Là où l’article devient intéressant, c’est sur l’augmentation du risque et la probabilité croissante d’avoir des soucis, compte tenu que la taille des disques ne cesse d’augmenter (le To est la norme maintenant) de même que le nombre de disques par grappe.
Bref, pour un RAID 6, si on a peur, on peut limiter la taille de la grappe (soit vis-à-vis du nombre de disques, soit vis-à-vis de leur capacité), ou augmenter le nombre de disques de parité.
Et il ne faut pas oublier non plus que si les NAS gèrent de plus en plus de disques, il est tout à fait possible d’y avoir plusieurs grappes plus petites (réduisant ainsi les risques de défaillance par grappe). Et aujourd’hui, hormis des cas très spécifique, je ne vois guère d’intérêt à avoir une seule et unique grappe de 10To (pour reprendre l’exemple de zdnet).
Pour la reconstruction, j’en ai déjà eu 2 sur mon NAS “personnel” (bais 4 disque, RAID 6 avec 2 disques de parité). La reconstruction prend une nuit, les données restant toujours accessibles et le changement de disque défectueux se faisant à chaud.
Et pour la petite histoire, j’ai déjà eu un disque dur neuf refusé par mon NAS, au motif qu’il présentait des erreurs (remontées via SMART justement). Ce même disque, monté dans un PC classique, ne montrait aucun problème (à l’usage ou via SMART). Du coup, je m’en sers comme périphérique pour des données volumineuses et peu importantes (juste au cas où !)
#5.2
Chez nous on a fait pas mal de raid 5, jamais eu de soucis.
Par contre tous est supervisé et on ne laisse jamais traîner un disque hs.
Par contre on parle de disques ‘pro’, sas sur des cartes raid hp de bonnes factures.
On est loin des fonctionnalités des cartes grand public.
#6
En entreprise, tu as généralement des contrôleurs de malade, loin, très loin de ce qu’on trouve en grand public en termes de performances et fiabilité. En plus, en général chaque grappe est elle-même doublée pour les données actives dans une autre salle (pas forcément pour les données de backup)
Sans compter que les disques durs utilisés ne sont pas vraiment les mêmes (en tout cas niveau tarif :( )
Donc on peut se permettre le RAID 5.
Par contre, je suis d’accord: en 2,5ans d’admin, il y a eu plusieurs pannes disque, c’est très courant (4 baies d’une vingtaine de disques)
#6.1
Non et non.
Les contrôleurs de malade / disques de malades peuvent aussi avoir des bugs de malade (voir le dernier bug HPE avec les SSD qui s’effaçaient tous après X heures de fonctionnement).
Et croire que tout le stockage de toutes les entreprises est systématiquement doublé sur un autre site, c’est un beau rêve (mais ça reste un rêve et ça n’enlève pas les bugs de firmwares qui sont légion pour pourrir de la data).
Ce qui est systématique (et encore pas chez tout le monde selon certains articles qui passent) ce sont les sauvegardes qui permettent de récupérer les données malgré les problèmes sur le stockage.
#7
A noter que pour le raid, il y a un autre “mode” logiciel : utiliser un FS évolué genre zfs ou btrfs
La différence ici est qu’avec une somme de contrôle des blocs, ces systèmes peuvent détecter et corriger le bitrot, ce dont un controleur raid (ou un raid software) est totalement incapable.
Pour être clair, ces système n’ont d’interêt que si on a plusieurs disques. Ils gèrent eux même les fonctions raid
#8
Article très synthétique et intéressant, merci. J’attends impatiemment la suite ! 👍
#9
Le bug, c’est mettre un R devant le AID 0
#10
Tiens, je viens de me poser une question, il existe des algorithme de correction des erreurs comme le code de Hamming (dont le taux d’erreur est egal à la redondance : donc pas de perte d’espace plus que la perte acceptable). De tels algorithmes permettent de faire des sortes de RAID 6 tout en pouvant corriger des erreurs elle même accumuler ponctuellement (des fichiers corrompus).
Existe-t’il des RAID qui utilise de tels algo ?
#11
J’hésite à prendre chez Western cette fois et non plus Seagate. En gamme NAS ou Entreprise (mais l’écart de prix est faible entre les deux gammes).
J’ai l’impression que les Enterprise/Exos ne tiennent pas assez longtemps à mon goût.
#11.1
Ca peut servir ;)
#11.2
Oui, mais eux, ce sont des disques “ grand publique “. Je vise les gammes NAS ou entreprise.
Mais ça peut orienter un peu.
#11.3
A ma connaissance, ils utilisent des gammes de disques conçus pour les NAS et les serveurs. Pas du grand public.
Et après une vérification sur quelques références, il semblerait que ce soient bien des disques pour NAS et serveurs
#11.4
Effectivement, mais pour les Seagate, il y a des références en … DM…., qui si je ne me trompe pas, sont des gammes bureautique.
Mais effectivement, merci de m’avoir fait remarqué que c’était des gammes NAS/Entreprise.
#12
Ca dépend grandement de comment c’est implémenté. Si le disque renvoie bien une erreur, normalement le contrôleur devrait recalculer les données à partir des autres (donc les données sortent juste), et éventuellement réécrire plus tard sur le disque qui a merdé. Et même s’il se contente de balancer une erreur de lecture, ça remontera jusqu’à l’OS et soit l’OS soit l’utilisateur refera une tentative, qui passera.
Et je doute fort que ça invalide un bloc, le but du RAID est aussi que ça reste en ligne, et donc quand un disque merde, on fait avec les autres, on ne bloque pas les opérations, et on ne modifie jamais les données des autres disques tant qu’on n’a pas pu de nouveau accéder au disque foireux, qui est alors reconstruit depuis les autres et non l’inverse.
Pour ma part, j’utilise du RAID 5 au quotidien depuis 15 ans sur 4 disques de tailles grandissantes. J’ai connu plein de pannes de disques et de reconstructions partielles ou totales, mais je n’ai jamais eu de souci lié à ce taux d’erreur de lecture. Je ne dis pas que ça ne s’est jamais produit, mais que si ça s’est produit, mes contrôleurs s’en sont très bien sorti car je n’ai rien perdu et même rien vu.
Je ne suis pas d’accord, voir plus haut et le message de fdorin. Les RAID 5 ne s’auto-détruise normalement pas sur une erreur de lecture quand ils sont déjà au minimum de disque, au pire il s’arrêtent juste et si c’était juste une erreur passagère, on peut les redémarrer ensuite, même si c’était pendant une reconstruction.
En fait il y a plein de moyens de traiter les erreurs, mais entre ce qu’il est théoriquement possible de faire de mieux et ce qui est réellement implémenté, il peut y avoir un gouffre.
Mal fini à cause de quoi ? Je pense plutôt à des vraies pannes de disque survenant au mauvais moment, mais pas à des problèmes liés au taux d’erreur. Mais dis-moi si je me trompe.
#12.1
Tu me comprendras quand tu auras eu une LUN RAID 5 12 disques qui a eu la corruption en plein fichier de base de données…. : moteur crashé, VM en vrac, etc…. Ca s’appelle une mauvaise journée ^_^ (moi ça allait, j’étais le dépanneur hihihi)
Ces NAS gèrent le scrubbing pour lutter contre la corruption silencieuse, mais tu as eu de la chance si toutes tes reconstructions en 8 disques supérieurs à 2To ce sont toutes faites en Raid5. Sans scrubbing, elles auraient toutes chié.
On ne mets pas du RAID10 pour les mêmes raisons. D’ailleurs, en général, c’est du RAID01: un RAID0 de RAID1 (2 ou 3 disques selon le degré de parano): seuls 2⁄3 disques sont utilisés, ce qui permet un taux de réponse accru par rapport aux RAID5/6 qui nécessitent que la grappe complète soit prête. Pour optimiser cela, on fait aussi du RAID50/60 sur de grosses grappes (supérieures à 50 disques). Ca permet de taper les 1/2Go/s avec des disques durs 15Ktpm, et 6-7Go/s en SSD (oui, merci le cache contrôleur).
Les serveurs de bases de données Oracle / SQL Server gros modèles sont typiquement ainsi (on parle de 40 coeurs / 500Go+ de ram).
Oui, le RAID Logiciel existe. ZFS, LVM & Windows Storage Spaces en sont.
Par contre, tu as intérêt à ne pas avoir de gros besoins en performances si tu as de petites configurations: les canaux SATA/SAS sont saturés, la pile de gestion rends les autres process léthargiques, etc…
Bien dimensionné, ça marche, mais il faut dédier ces machines au stockage et rien d’autres, quelque-soit leur puissance (j’ai rendu anémique une machine à 30K€HT avec LVM ou Storage Spaces et une trentaine de disques).
#12.2
Merci pour le terme, je ne connaissais pas.
Oui, peut être de la chance. Mais c’est passé jusque là pour les reconstructions.
À voir avec le dernier disque qui est vraiment bien malade.
#12.4
Du Raid 5 à 12 disques, c’est du suicide, j’espère que celui qui avait cela à l’époque est en retraite maintenant pour pas que d’autres dépannent cela de nouveau.
Et, généralement, sur du RAID 60, sur les configurations de disques que l’on utilise (toujours moins de 24 par SAN) on tombe sur les mêmes capacités utilisables que le RAID 10 (sauf si nos calculs ont toujours été foireux, mais comme dit, on a eu tellement de soucis avec le RAID 5 que l’on a jamais utilisé autre chose que le 10 ensuite).
#12.3
Si, des problèmes liés aux taux d’erreurs, j’en ai parlé sur un autre commentaire (mais sur des gros volumes et avec énormément d’I/O pour du RAID 5).
Puis bon, maintenant, on met tout en full flash en raid 10, les performances n’ont rien à voir avec du RAID 5 et les problèmes potentiels sont tous évités.
#13
#13.1
C’est compté en disques pleins, pas en milliard d’octets (oui flemme).
Ca permet de se rendre compte de la probabilité d’une erreur irrécupérable sur un disque.
Sachant que :
Et qu’on multiplie par le nombre de disques dans la grappe ^_^
To / Taux d’erreur 10^14 10^15 10^16 10^17
2 To 17,59% 1,76% 0,18% 0,02%
4 To 35,18% 3,52% 0,35% 0,04%
6 To 52,78% 5,28% 0,53% 0,05%
8 To 70,37% 7,04% 0,70% 0,07%
10 To 87,96% 8,80% 0,88% 0,09%
12 To 105,55% 10,56% 1,06% 0,11%
14 To 123,15% 12,31% 1,23% 0,12%
16 To 140,74% 14,07% 1,41% 0,14%
18 To 158,33% 15,83% 1,58% 0,16%
Moi je refuse toujours le RAID5. Cette techno n’existe pas à mes yeux.
Je ne choisi pas ce que je dépanne….
Moi je les aurais mis en RAID01 double miroir: un RAID 0 de 4 groupes de RAID1 de 3 disques (en plus ça donne plus de patate hihihi), ou au pire en RAID6 avec un hotspare.
Les LOGs sont tout aussi critiques que la BDD:
C’est d’ailleurs pour ça que normalement, on fait 2 LUNs: une pour les logs, une pour la base (pour des raisons de performances).
Tant mieux si tu es passé entre les mailles du filet de Murphy.
Franchement, un disque dur entreprise en environnement entreprise, il n’a pas de défaut autre que sa fiche technique. Température, hygrométrie, ventilation… Tout cela est stable et contrôlé. Et on les arrête jamais.
Du coup, y’a que le Taux moyen de retour et taux d’erreur incorrigibles qui influencent le choix.
On s’en fout de savoir lequel des 2 est responsable de la panne. Tout ce qu’on sait, c’est qu’on doit mathématiquement minimiser le risque.
Et dans tous les cas, on sauvegarde au moins une fois par jour
Après ça n’est que mon avis, et il n’engage que moi ;)
#13.2
Une préférence te le RAID 6, parce que plus de redondance des données ?
#14
Je précise d’avance que monter des RAIDs n’est pas mon métier. Mais un RAID 5 avec 12 disques pour stocker des bases de données, c’est pas un peu… suicidaire ? Quand un disque plante (et ça viendra, forcément, surtout avec 12 disques), le risque est tellement grand que pendant la reconstruction, un autre disque puisse montrer des faiblesses (surtout s’ils sont de la même série !).
Je pose la question comme tu as l’air du métier ;)
Après, pour des données non critique… comme des logs (peu de réécritures, beaucoup d’ajouts), why not…
[edit]
Grillé par CR_B7, qui pense la même chose de moi semble-t-il
#15
Et comment tu sais que cette corruption venait du RAID, et plus spécifiquement du taux norm d’erreur de lecture et pas d’un réel défaut d’un disque ?
En plus les erreurs dues à ce taux peuvent tout aussi se produire sans RAID. M’est avis que si un contrôleur RAID amplifie ce problème, c’est qu’il est mal codé.
Merci pour le terme, je verrai à mettre ça en place dans le futur. Cependant j’en ai fait quelques unes des reconstructions avec des disques de 3 To depuis le temps, et elles ont toutes réussi. Jamais repéré d’erreur non plus en faisant des vérifications simples de temps en temps.
#16
Mon expérience s’arrête à un raid0 de SSD pour l’installation de Windows il y a quelques années quand les SSD n’avaient que quelques centaines de Mo/s en lecture/écriture, mais c’est génial de pouvoir lire les commentaires des experts du stockage sur NXI.
#17
Merci pour ton retour
J’aurais sans doute fait quelque chose de similaire, avec peut être une hésitation entre un RAID01 et donner directement l’ensemble des RAID1 à la BD
Entièrement d’accord. Sauf que je parlais pas de log de BD, mais de log tout court (dans ma tête, système de centralisation de log). Mais je suis passé un peu vite du coq à l’âne, je l’admet !
#18
Je n’y crois pas, les probabilités sont trop grandes. Et ce problème m’avait aussi interpellé avec l’augmentation des tailles de disques, car je sais aussi calculer les probabilités. Je m’étais demandé à l’époque comment ça allait se passer, mais finalement je trouve que ça se passe plutôt bien, autant hors RAID que dans un RAID. Par contre, je ne suis pas sûr de pourquoi ça se passe mieux que ça en a l’air, tu pourras peut-être m’éclairer.
Déjà, quand un bit est mal lu, est-ce que le disque renvoie une erreur ou est-ce qu’il renvoie un bit faux ? Je penche pour le premier cas, et il est facile à gérer soit par l’OS hors RAID (mais possible perte de données si réessayer échoue), soit par un contrôleur RAID correctement codé, et sans perte de données puisque recalcul depuis les autres disques. Le RAID devrait donc apporter une amélioration plutôt qu’une dégradation.
Si au contraire renvoie des données fausses, c’est plus embêtant car le contrôleur va s’en rendre compte, mais il va devoir choisir aléatoirement si c’est la donnée ou la parité qui est fausse, ce qui peut aboutir à une corruption. Mais la probabilité n’est alors augmentée par rapport à un disque seul que de maxi 20% pour un RAID5 de 5 disques, et seul le bit mal lu est affecté, pas la totalité du bloc.
#18.1
Un bit mal lu, c’est une erreur disque pour le contrôleur, qui retourne lui-même une erreur de lecture à l’OS si la redondance ne fait pas son taff. Si tu l’as sur un espace libre d’après l’OS, aucun souci. Si tu remplis tes disques toujours comme un salaud, les probabilités sont là.
Sauf les problèmes budgétaires
Il est facile de juger à postériori ;)
Les seules personnes qui faisaient du RAID60 font désormais du raid logiciel en ZFS/LVM/WSS ou du S3: ils faisaient ça parce qu’ils avait au moins 30 disques par serveur.
En RAID6, à partir de 6 disques, tu es gagnant par rapport au RAID10/01 en capacité (N-3: 2 disques de parité et un de hotspare). Surtout que sur des données critiques, on fait du RAID10 double miroir: 33% de l’espace disque utilisable.
Aujourd’hui, le seul cas où on fait du RAID5 sans sourciller, c’est en cas de clusters de serveurs où on veut limiter la maintenance. Vu qu’ils se répliquent en live, on estime à raison que c’est fiable et qu’on peut se permettre de baisser la fiabilité de la LUN de chaque serveur.
Par exemple, pour Exchange, Microsoft préconise même un JBOD ou RAID0 de 3 serveurs répliqués.
#18.2
Je ne vois pas dans l’avenir, donc je ne peux juger qu’à postériori
On ne fait que du RAID 10 basique, si les données sont réellement critiques, on ne compte pas sur du RAID pour en assurer la survie (réplication voir reprise auto + backup on-line / off-line entres autres).
#19
Je n’ai fait qu’un RAID0 de ma vie, avec deux disques durs de 100 Go, pour mettre l’OS dessus. Il est mouru un jour, comme je m’y attendais, par contre je n’avais pas anticipé que ça puisse se passer alors que j’étais à l’extérieur pour une LAN.
Du coup grosse galère pour trouver quelqu’un avec un CD d’install de Windows et les drivers pour mon matériel (pas d’Internet sur place). J’en ai plus refait depuis, et j’ai rajouté les CDs d’installation à mes bagages en LAN.
#20
Il te faut toujours au moins un disque de spare en secours, en plus de ton RAID. C’est ce qu’on fait nous au boulot.
#21
L’article explique certaines notions, mais me semble oublier un point clé : Le RAID ne sert que pour augmenter la disponibilité des données et pas leur intégrité, et souvent dans le monde des particuliers c’est moins utile qu’une bonne sauvegarde.
Je m’explique. Mes photos ou films de famille, je ne veux pas les perdre. Il est beaucoup plus important et plus utile pour moi d’avoir une sauvegarde sur un autre disque/PC, que de faire du RAID 1. Je peux attendre pour accéder à mes photos le temps de racheter un disque et restaurer ma sauvegarde dessus, mais je pense que perdre les données serait une catastrophe irrécupérable.
Les entreprises elles, font des sauvegardes (ou devraient le faire), et elles veulent aussi la disponibilité donc elles font aussi du RAID.
Mais je pense que c’est rare qu’un particulier ait vraiment besoin de la disponibilité apportée par le RAID, et qu’il vaut bien mieux commencer par la sauvegarde.
Autre point, le RAID matériel (via carte/contrôleur sur la carte) ne me semble pas optimum pour les particuliers. En cas de perte du contrôleur matériel, il faut souvent retrouver un contrôleur identique pour lire les données, alors qu’avec du RAID logiciel ce problème n’existe pas. Note : ce point a peut-être progressé avec la normalisation des solutions, des BIOS/UEFI…
De plus, les solutions avancées de gestion des volumes (Windows ou certains file systems Linux) proposent des équivalents au RAID, bien plus souples.
#21.1
Je suis bien d’accord. J’ai arrêté de faire du RAID sur mon NAS et je ne prévois pas de le refaire. Par contre, il faut deux sauvegardes mini dont une hors site.
#22
Comment récupérer les données d’un cluster en RAID 5 ?
Il y a quelques années, j’avais 3 disques de 3 TO en RAID 5, et un disque est mourru subitement. Confiant, j’achète un nouveau disque de même capacité et remplace (à froid) celui qui était défaillant. Je rallume le pc, confirme la reconstruction et là, c’est le drame. Ca a tout mélangé, haché, plus rien n’était lisible. En regardant les “secteurs” du cluster, je voyais des bouts du fichier avec du random en plein milieu (ou au début ou à la fin).
J’ai conservé les disques au cas où, un jour, je trouverais la solution miracle…
#23
OK merci pour la précision, dans ce cas le contrôleur devrait utiliser la redondance pour corriger l’erreur, voire réécrire sur le disque qui n’a pas répondu. Au pire s’il ne le fait pas (ce qui serait mal fichu), l’OS recevra une erreur et pourra réessayer. Mais c’est à quel moment que les données se corrompent ?
Si tu fais du RAID5 avec un disque de spare, autant presque faire du RAID6 à la place.
Il faut essayer de se renseigner avant, mais c’est pas facile. Pour ma part, mes volumes RAID ont toujours été lisibles par d’autres contrôleurs de la même marque, plus récents ou plus anciens. Mais je n’ai pas non plus essayé tous ceux de cette marque, et je connais un modèle d’une autre marque où même mettre à jour le BIOS du contrôleur l’empêchait de rouvrir tes volumes.
Je ne crois pas non.
#24
C’est la merde, il faudrait savoir ce qu’a fait le contrôleur et appliquer la logique inverse (en espérant qu’il n’ait pas écrasé des trucs). Il faudrait que tu retrouves tous les bouts d’un fichier pour comprendre comment il l’a mélangé, mais c’est vraiment pas gagné.
Ca me fait penser à la fois où j’avais effacé un volume RAID5 par erreur et où je ne connaissais pas l’ordre des 4 disques. J’ai pris un ordre au hasard, recréé le volume (sans formatage) puis regardé si j’arrivais à voir la partition, supprimé le volume, changé l’ordre, recommencé jusqu’à ce que j’arrive à monter le système de fichiers puis à lister le contenu du répertoire racine, puis jusqu’à ce que ce contenu soit correct. C’était un peu flippant mais finalement il n’y avait aucun risque tant qu’on n’écrivait rien.
#25
C’est fini cette longue litanie sur les erreurs dans la mémoire qui affecteraient tout RAID ZFS (limité par l’ECC, mais pas éradiqué)
Parce que on a quand même tendance à faire du FUD sur des incidents graves, sans compter les milliers de jours où tout se passe bien.
Le RAID, c’est la haute dispo. Le backup, c’est la sécurité.
Le RAID5, ça marche, ça pose des risques, mais qu’est-ce qui ne pose pas de risques sur des LUN de 12To?
La technique ne fait pas tout, l’architecture soft non plus. Il y a un moment où il faut jouer des 2.
Et surtout, il y a beaucoup de moments où le financier te dicte de mettre le RAID5, car c’est ce qui rentre dans le budget.
#26
L’implémentation n’est pas standard à ma connaissance. Ca dépend de l’équipement dans lequel c’était installé.
Pour ton problème, il faudrait:
Mais ça peut être beaucoup plus compliqué selon les stratégies d’allocation du contrôleur…
#27
Merci beaucoup Sébastien pour cet article !
Comme souvent, on en apprend encore plus dans les commentaires ! Merci à tous ceux qui y contribuent. :oui2:
)
(même si je ne comprends pas tout parce que je suis pas assez calé dans le domaine…
#28
Sympa l’article et également les commentaires toujours très intéressants.
Pour ma part, j’ai plutôt fait du Raid5 mais il y a des sauvegardes externes tous les soirs. Pour le moment, j’ai eu quelques disques qui ont lâché mais jamais de souci à retrouver un Raid5 fonctionnel, suis je super chanceux !? Je ne sais pas. En tout cas, c’était avec des NAs de 4 ou 5 disques 3 à 4 To (Thecus, Qnap, Synology).
Le Nas me sert pour un premier backup donc si cela venait à lâcher, pas de grosses pertes. Sur le serveur, c’est raid 1+0 et raid 1. Déjà eu des couacs mais cela se reconstruit assez vite…
#29
Je me sentais confiant dans mon Syno à 4 Hdd dans leur système hybrid (SHR) “équivalent” à du RAID 5, mais avec tout ce que je lis là dans les commentaires, ça m’inquiète !
J’avais pris la peine de prendre des disques NAS (WD RED de mémoire, tous dans une série différente), pour éviter une possible panne au même moment, et jusque-là, aucune panne ni alerte.
Je vais me re-pencher sur la fiabilité du truc…
#30
Le RAID 0 c’est pire que 0 sécurité, on multiplie les chances de pannes en additionnant celles de chaque disque physique.
A quand un article sur les filesystem modernes qui gèrent cela de façon bien plus souple ? BTRFS, et surtout ZFS…
etc…
Quand on y goute, le RAID 0, 1, 0+1, 5, 6 ou 10 semble d’un autre age !
J’avais écrit un petit billet au sujet de ZFS: https://medium.com/@cq94/zfs-vous-connaissez-vous-devriez-1d2611e7dad6
#31
Merci pour ce très bon résumé !
#32
Merci à vous 2 !
#33
#34
Il y a juste un petit hic :
https://linux.developpez.com/actu/290040/Linus-Torvalds-n-utilisez-pas-ZFS-jusqu-a-ce-que-j-aie-une-lettre-officielle-d-Oracle-signee-par-son-conseil-ou-par-Larry-Ellison-qui-nous-y-autorise-et-precise-que-le-produit-final-est-sous-GPL/
#35
Le problème de licence concerne avant tout la redistribution du pilote, avec des acteurs comme Ubuntu qui se trouvent trop cools pour faire du dkms ( système qui recompile le pilote automatiquement à chaque mise à jour du noyau, utilisé pour les pilotes proprio des cartes graphiques et réseau par exemple ) et du coup préfèrent jouer avec une interprétation capillotractée de la licence GPL pour livrer directement le pilote binaire déjà compilé et lié.
Bref un précédent dangereux pouvant nuire gravement aux licenses GPL si la faille se confirme. Malheureusement, aucun acteur n’a porté plainte contre Canonical pour confirmer ou infirmer la validité du prétexte utilisé et crée un précédent dangereux en l’absence de critères d’ (in)validité de l’approche.
Si un utilisateur final décide d’intégrer ZFS pour son usage, pas d’ambiguïté: il en a de toutes façons parfaitement le droit.
Reste que si on veut rester clean avec ZFS, il y a un OS presque parfait pour ça: FreeBSD… d’expérience, hormis une situation problématique que j’ai rencontré avec Infiniband il y a quelques années, c’est une plateforme formidablement stable pour le stockage que je recommande en lieu et place de solutions GNU/Linux pour en environnement de stockage d’entreprise.
#36
C’est assez dingue, c’est clairement un pb de contrôleur, car il y’a toutes les infos pour que ça se passe bien :
A priori ça pourrait être transparent (si correctement implémenté par le contrôleur / OS), l’effet amplificateur, est que les bons secteurs des autres disques ne sont alors plus utilisés, car il y’a au moins un disque avec ce secteur défectueux.
À te lire, j’ai l’impression qu’à la première erreur, tout le disque est marqué HS, et que la grappe doit être entièrement reconstruite ; là effectivement, c’est catastrophique, il faut relire / recalculer toutes les sommes de contrôles, ce qui induit un stress énorme sur des disques dont l’un montre déjà un signe de faiblesse !
#36.1
Le problème c’est la seconde erreur: celle qui suit celle qui n’a pas été prévisible. Il faut tout faire pour l’éviter. Le RAID6 (double parité) permet une seconde chance, et c’est la troisième qui devient critique. En RAID6 triple parité ou en RAID1 double miroir, c’est la 4ième qui le devient.
Si le problème apparait dans une section de données critiques, c’est le logiciel qui se plante. Un Windows qui râle, on s’en fout. Une base de données qui se crashe, c’est pas la même… En pleine journée, une base de données de production à restaurer, c’est que la production est arrêtée ! Et ça ça ne doit pas arriver, ça coût des dizaines de milliers d’euros par heure sans…. (si ce n’est plus)
#37
Il ne faut pas s’arrêter des exemples catastrophiques. Dans la majorité des cas, ça fonctionne parfaitement du premier jour jusqu’à remplacement de la baie.
ZFS et LVM sont ce que l’on trouve sur des contrôleurs SAN. C’est un niveau supplémentaire d’abstraction/virtualisation du stockage.
Mais une bonne partie des fonctionnalités n’empêche pas de reposer sur un RAID (soft/hard).
Attention aussi: autant BTRFS peut être considéré comme un FS comme un autre, autant ZFS peut mener à de grosses consos de RAM: je préfère utiliser ZFS sur un serveur de stockage, mais pas sur un serveur applicatif. Par contre, BTRFS sur un applicatif, je n’ai rien contre.
Bref, dire que ZFS ringardise le RAID, c’est un peu comme dire que la gestion des noms de domaines rend vieillots les plans d’adressage IP. En fait, ce n’est pas tout à fait la même chose…
Mais je suis d’accord sur un point: mettre un RAID et utiliser directement le volume RAID tout entier, c’est le niveau 0 du stockage. Avoir une couche d’abstraction, de création de volumes différents par dessus le stockage physique, c’est un niveau très intéressant (quand tu te retrouves avec des volumes dédiés à plusieurs machines très similaires, mais que ces volumes ont des parties dédupliquées… miam)
#38
Pour moi le problème n’est pas la.
Ses est sous une licence à la noix, propriété de oracle.
Oracle est connue pour être franchement tordu.
Du coup pour linus soit Zfs rentre dans les clous au niveau licence, soit il vaut mieux ne pas trop l’intégrer
#38.1
La licence est une chose, l’entreprise en est une autre… s’il faut critiquer une entreprise à l’heure actuelle, c’est Canonical qui s’obstine en maintenant son approche consistant à livrer le pilote binaire directement et qui crée une situation affaiblissant la licence du kernel. Pour le coup Oracle n’y est pour rien, le seul reproche qu’on pourrait leur faire c’est leur choix de licence pour leur logiciel, mais cela ne serait pas très correct pour le coup, mais ce n’est pas très pertinent face à Canonical qui méprise les techniques standard pour résoudre le problème en faveur d’une approche contraire à la licence GPL2.
#39
Je ne suis pas forcément fan des trucs qui font tout en un seul bloc, sans forcément pour autant avoir de raison objective à donner. J’ai l’impression que ça risque de faire tout pas forcément bien, et qu’en cas de problème je ne pourrai rien faire d’autre face à un truc aussi compliqué que lancer l’outil de réparation en priant, alors que m’attaquer à la couche plus simple qui déconne me paraîtrait plus faisable. On peut par exemple faire des trucs avec mdadm pour récupérer un RAID en étant sûr d’être non destructif, et on peut éventuellement aussi s’aider d’un éditeur hexa.
Pour cette raison je n’ai jamais voulu toucher à l’équivalent Windows de LVM et RAID (en plus que ce soit proprio), je ne sais juste pas du tout ce qu’il fait, alors que sur un RAID5 je comprends mieux ce qui se passe, même si les détails d’implémentation vont varier d’un contrôleur à l’autre.
Je suis en train de me construire un NAS Linux, et je pensais partir sur du mdadm + LUKS + btrfs/zfs, ce qui me permet quand-même de profiter de la plupart des fonctionnalités de btrfs/zfs. Cependant, après lecture de ton billet (merci d’ailleurs), je ferai des tests avec ZFS seul pour comparer et voir un peu comment ça marche.
Je dirais plutôt que c’est différent, c’est l’éternel débat monolithique vs modulaire qui s’applique partout en informatique.
Et sinon, quelqu’un aurait un petit avis comparatif à donner entre BTRFS et ZFS ?
#40
Tu noteras que c’est linus thorvalds, qui demande de ne pas l’utiliser.
Pas canonical…
#41
A un tel niveau d’impact, si une haute disponibilité n’a pas été mise en place, c’est qu’il y a un problème bien en amont dans le PCA et/ou PRA.
#42
2 disques en erreur sur le même secteur c’est extrêmement improbable (on parle toujours des erreurs de lecture tous les 10^14 ?).
Ah ben oui, dans cette situation il ne faut pas faire du RAID5. Mais de là à dire que le RAID5 est à bannir sans préciser le moindre contexte, c’est un peu exagéré.
#42.1
Je ne parle pas “predictive failure” qui est le meilleur des cas. Je parle décès de disque, point.
Ton disque meurt (100% inaccessible), une reconstruction qui se déclenche puis une erreur de tête (10^14) dans une donnée critique lors de la reconstruction. Ben tu l’as dans le cul. La probabilité est donc de la lecture uniquement, puisque l’autre disque est déjà mort. Ca s’appelle avoir les fesses qui claquent pendant la reconstruction.
Et exagéré…. Tu verras bien le jour où t’y auras droit…
#43
Linus Torvalds a demandé de ne pas l’utiliser avec linux( ce qui est à mon sens un peu abusif), et a rappelé l’évidence de l’incompatibilité de la licence pour intégrer ZFS officiellement au noyau …
La FSF et la Software Freedom Conservancy on demandé de ne pas distribuer le pilote binaire précompilé (une approche DKMS n’aurait pas posé de problème de licence du tout)… Canonical n’en a rien eu a cirer et a préféré surfer sur une interprétation assez “originale” de la licence GPL soutenant que l’accès au code sous une autre licence que GPL est suffisant pour fournir les binaires sous GPL.
Au final on est juste dans un flou qui, s’il perdure pourrait créer un précédent qui affaiblirait les licences GPL2 et 3 ainsi que leurs dérivés, ce qui est très mauvais pour l’écosystème du libre.
On peut aussi supposer que si ni la Linux Foundation ni la SFC n’ont attaqué Canonical en justice, c’est peut-être par peur que ce contournement de licence ne soit acté comme valide devant un tribunal.
Bref on a peut-être besoin d’une GPL4, mais dans ce cas, le noyau linux, qui est coincé éternellement en version 2, n’en bénéficiera et restera vulnérable.
#44
Tu l’as dans le cul pour cette donnée, pas pour tout le RAID si le contrôleur est bien fait. OK ça peut faire des dégâts suivant l’importance de cette donnée, mais c’est une question de contexte après, comme je l’ai dit on ne fait pas du RAID5 quand c’est hyper-uber-méga-important-et-cher de ne rien perdre.
Par ailleurs le RAID reste en ligne même si la reconstruction échoue à cause d’une erreur de lecture, on peut toujours copier tout le reste ailleurs.
C’est exagéré de généraliser à tous les contextes, perdre un secteur sur mon RAID5 une fois tous les 10 ans (à la louche, car pour l’instant je n’ai rien perdu) me fera plus ou moins chier mais ne me changera pas la vie et ne me coûtera pas cher, et j’ai plein de données de grande taille mais facilement retrouvables, donc dans mon contexte, c’est adapté. Quelqu’un d’autre l’a dit, on choisit ses solutions de stockage en fonction de l’importance des données.
Et la double panne, j’ai déjà eu, sur un RAID5 tout neuf, un disque qui meurt puis un autre (totalement morts, pas des erreurs de lecture). Je les stresse au début pour voir s’il n’y a pas une faiblesse déjà présente à l’achat, donc je n’avais pas encore de réelle donnée dessus.