ZFS vs RAID matériel : Qui vous protège quand le contrôleur ment ?

Les défaillances de stockage ne se manifestent que rarement par un effet hollywoodien. En production, les pires échecs sont polis : un contrôleur qui dit « tout va bien », un système de fichiers qui renvoie les mauvais octets avec l’assurance d’un voyant, une reconstruction qui « s’est terminée avec succès » tout en brûlant silencieusement vos disques restants. Si vous avez exploité des flottes assez longtemps, vous apprenez que l’ennemi réel n’est pas le disque mort que l’on voit — c’est le composant qui ment tout en continuant à servir des E/S.

C’est le cœur du débat ZFS vs RAID matériel. Pas « lequel est le plus rapide dans un benchmark », mais : quand la réalité diverge de ce que rapporte votre pile de stockage, qui le remarque en premier, qui peut le prouver et qui peut réparer sans supposer ? Nous allons aborder cela comme de l’ingénierie de production, pas comme une religion : ce que chaque pile gère bien, où elle échoue, et ce que vous devriez réellement faire un mardi à 2 h du matin quand le tableau de bord est vert et que la base de données crie.

Le mensonge : comment le stockage vous trompe

« Le contrôleur ment » ne signifie pas qu’il est malveillant. Cela signifie que la pile logicielle à laquelle vous faites confiance reçoit une histoire rassurante qui ne correspond pas à la réalité physique des octets sur plateaux ou cellules flash. Cela peut arriver de plusieurs façons :

Corruption silencieuse : de mauvaises données, grande confiance

La corruption silencieuse se produit lorsqu’une lecture renvoie un bloc qui n’est pas ce que vous avez écrit, et personne ne s’en plaint. Elle peut provenir de câbles défaillants, d’expandeurs SAS limites, de bugs de firmware, d’erreurs DRAM dans un contrôleur, d’écritures mal dirigées, ou d’un média renvoyant des données périmées dans des conditions rares. Votre application obtient des octets. Ils sont juste mauvais.

Voici pourquoi c’est si pénible en exploitation : un checksum au niveau application est rare, et même lorsqu’il existe (pensez : certaines bases de données), il peut ne détecter la corruption que lorsqu’il relit cette page — des semaines plus tard. Pendant ce temps, des sauvegardes peuvent conserver la version corrompue. C’est le scénario cauchemardesque : la seule copie « bonne » a été remplacée.

Le paradoxe du cache d’écriture

Le cache d’écriture peut rendre un baquet de stockage héroïque jusqu’au moment où il perd l’alimentation et recompose l’histoire. Si un contrôleur acquitte une écriture avant qu’elle ne soit solidement sur un média non volatile, vous avez échangé latence contre vérité. Les caches protégé par batterie (BBWC) et par flash (FBWC) réduisent ce risque, mais le diable est dans les détails : santé de la batterie, vieillissement des condensateurs, politiques de firmware, et paramètres « temporaires » qui deviennent permanents parce que personne ne veut redémarrer pour les remettre en place.

Blague n°1 : Un contrôleur RAID avec write-back et sans protection d’alimentation, c’est comme un conférencier motivant — beaucoup d’assurance, peu de responsabilité.

La spirale de reconstruction

Quand un disque lâche dans un RAID5/6, les reconstructions sollicitent les disques survivants par des lectures soutenues. C’est là que des secteurs latents se manifestent. L’array peut passer de « dégradé mais OK » à « dégradé puis illisible » au pire moment. ZFS a sa propre version (resilver), mais elle se comporte différemment quand elle sait quels blocs sont réellement en usage.

Faux positifs et faux négatifs dans les rapports d’état

La santé du disque, la température, les compteurs d’erreurs et la prédiction de panne — ce ne sont pas tant des vérités objectives que des interprétations spécifiques au fournisseur des attributs S.M.A.R.T. et des logs d’erreurs de lien. Le RAID matériel ajoute une couche : parfois vous ne pouvez pas voir les vrais S.M.A.R.T. du disque sans faire des acrobaties propres au contrôleur. Cela peut donner l’impression que votre supervision palpe le pouls du patient à travers un manteau d’hiver.

Faits et historique : pourquoi cela continue d’arriver

Le stockage est assez ancien pour avoir des traditions, et certaines sont… formatrices. Quelques points de contexte qui comptent dans des designs réels :

1. Le RAID est né à une époque de disques chers et de cycles CPU bon marché. Les idées initiales de RAID (fin des années 1980) supposaient qu’on échangerait des disques supplémentaires contre la fiabilité tout en gardant des performances acceptables.
2. Le « write hole » est un problème connu du RAID depuis des décennies. La parité peut être incohérente après une perte de courant si la pile n’a pas de protections.
3. ZFS (milieu des années 2000) a été conçu autour des checksums de bout en bout. Le principe : le stockage doit détecter la corruption au niveau du système de fichiers, et non faire confiance aveuglément aux couches inférieures.
4. Les taux d’erreurs de lecture irrécupérables (URE) sont devenus pertinents avec l’augmentation de la taille des disques. Plus les disques sont gros, plus la reconstruction lit d’octets et augmente la probabilité de tomber sur une URE — surtout avec des disques grand public.
5. Les caches d’écriture sont passés de « boost optionnel » à « requis pour une latence décente ». Avec des charges E/S aléatoires (VM, bases de données), le caching est devenu central et non plus accessoire.
6. Les contrôleurs ont un firmware, de la DRAM et parfois une logique boguée. Le RAID matériel n’est pas « pur hardware » ; c’est un système embarqué avec ses propres modes de défaillance.
7. Les systèmes de fichiers faisaient historiquement confiance à la couche bloc. Les piles traditionnelles supposaient qu’une lecture renvoie ce qui a été écrit. Cette hypothèse est aujourd’hui régulièrement fausse dans de grandes flottes.
8. Les serveurs commodity + JBOD ont changé l’économie. Il est devenu pratique d’exécuter du stockage défini par logiciel où le CPU hôte gère parité/checksums et les disques sont « idiots ».
9. NVMe a réduit certains problèmes et en a introduit de nouveaux. La latence plus faible et moins d’intermédiaires aident, mais les problèmes de firmware, de protection contre la perte d’alimentation et les bizarreries de namespace subsistent.

Le modèle de ZFS : vérité de bout en bout

ZFS est souvent décrit avec une certaine révérence, comme s’il était un système de fichiers magique qui vainc l’entropie. Ce n’est pas de la magie. C’est un ensemble de décisions de conception qui remontent la frontière de confiance et rendent l’intégrité vérifiable.

Checksums de bout en bout : le mécanisme central

Quand ZFS écrit un bloc, il calcule un checksum et le stocke dans des métadonnées (pas à côté du bloc au même endroit). Lorsqu’il lit, il vérifie. Si le checksum ne correspond pas, ZFS sait que les données sont incorrectes. C’est déjà un changement majeur : il ne s’agit plus de deviner si le disque a retourné le bon bloc.

Si la redondance existe (miroir, RAIDZ), ZFS peut lire une copie alternative et réparer la mauvaise (« auto-réparation »). C’est ce que les gens veulent dire quand ils disent que ZFS « protège contre la bit rot ». Plus précisément : ZFS détecte la corruption et, avec la redondance, peut corriger.

Copy-on-write et sémantique transactionnelle

ZFS n’écrase pas les blocs actifs sur place. Il écrit de nouveaux blocs, puis met à jour les pointeurs. Cela signifie que l’état sur disque est toujours cohérent du point de vue de ZFS : soit la transaction a commis, soit elle ne l’a pas fait. Ce design réduit significativement la corruption classique du système de fichiers après crash et interagit favorablement avec la vérification d’intégrité.

Ce n’est pas une panacée. Si un dispositif ment de manière cohérente (retourne de mauvaises données avec un checksum correspondant parce que la corruption a eu lieu avant que ZFS ne calcule le checksum, p.ex. corruption mémoire), vous pouvez toujours obtenir de mauvaises données. C’est pourquoi la RAM ECC et du matériel stable comptent dans des déploiements ZFS sérieux.

Scrubs : audits programmés de vérité

Un scrub n’est pas une « optimisation de performances ». C’est un audit d’intégrité : ZFS lit les données et vérifie les checksums, réparant à partir de la redondance quand c’est possible. Si vous voulez trouver la corruption silencieuse avant qu’elle ne devienne votre seule copie, les scrubs sont la méthode.

Opérationnellement, la nuance importante : les scrubs créent de la charge. Vous planifiez, surveillez, et vous ne les lancez pas en même temps que votre tâche mensuelle « réindexer tout » sauf si vous aimez le chaos.

Resilver vs rebuild : pas que de la sémantique

Lorsque vous remplacez un disque dans un miroir ZFS ou RAIDZ, ZFS resilver. Dans les miroirs, il peut copier seulement les blocs alloués plutôt que l’intégralité du périphérique brut, réduisant temps et usure. Avec RAIDZ, le comportement du resilver dépend des métadonnées et peut rester lourd, mais la propriété « seulement ce qui est utilisé » aide souvent, surtout avec une utilisation éparse.

ZFS n’est pas gratuit

ZFS coûte en CPU et mémoire. Il veut de la RAM pour l’ARC (cache) et les métadonnées. Il préfère la RAM ECC. Il exige que vous compreniez recordsize, volblocksize (pour les zvols), et l’interaction entre écritures synchrones et dispositifs SLOG. Vous pouvez absolument rendre ZFS lent en le mal configurant ; ZFS exécutera vos mauvaises idées avec un professionnalisme admirable.

Le modèle RAID matériel : abstraction et accélération

Le RAID matériel, c’est une autre approche : placer un contrôleur devant les disques, le laisser gérer la redondance et présenter au système d’exploitation un ou plusieurs volumes logiques qui ressemblent à des disques normaux. C’est séduisant parce que c’est simple au niveau OS : le serveur voit « /dev/sda », et la vie continue.

Ce que le RAID matériel fait bien

De bons contrôleurs avec une protection de cache adéquate peuvent fournir de fortes performances, surtout pour les petites écritures aléatoires. Ils déchargent le calcul de parité (moins important aujourd’hui avec des CPUs modernes) et cachent la complexité à l’OS. Dans certains environnements — surtout standardisés autour de contrats de support fournisseur — le RAID matériel est une forme familière et soutenable.

Ce que le RAID matériel vous cache

Cette abstraction a deux faces. Si le contrôleur mappe mal les blocs logiques aux blocs physiques, ou si son cache acquitte des écritures prématurément, l’OS et le système de fichiers peuvent ne pas le détecter. Les systèmes de fichiers traditionnels ne chiffrent généralement pas les blocs de données de bout en bout ; ils comptent sur l’honnêteté du périphérique bloc.

Même lorsque le contrôleur se comporte bien, il peut obscurcir la santé des disques sous-jacents. Vous pourriez voir « logical drive optimal » pendant qu’un disque claque des erreurs média que le contrôleur remappe silencieusement. Ça semble utile jusqu’à ce que vous réalisiez que vous avez perdu la capacité de raisonner sur le risque. Vous volez aux instruments sans altimètre externe.

Patrol read, vérifications de cohérence et leurs limites

Les contrôleurs RAID d’entreprise ont souvent des « patrol read » ou vérifications de cohérence en arrière-plan. Ceux-ci peuvent détecter et parfois corriger des incohérences de parité. C’est une vraie valeur. Mais ce n’est pas la même chose que l’intégrité de bout en bout au niveau système de fichiers : le contrôleur peut valider des relations de parité sans savoir si les données elles-mêmes sont les bonnes pour ce bloc logique.

Le contrôleur est un ordinateur que vous avez oublié de patcher

Les pannes de RAID matériel ne sont pas toujours des pannes de disque. Les contrôleurs ont des bugs de firmware, des erreurs mémoire, des surchauffes, et parfois des interactions bizarres avec certaines révisions de firmware de disque. Si vous n’avez jamais vu un contrôleur se comporter différemment après une mise à jour de firmware, félicitations pour votre vie paisible — mais vous patchez peut-être pas assez vigoureusement.

Blague n°2 : La seule chose plus optimiste qu’un contrôleur RAID, c’est un plan de projet qui dit « pas de temps d’arrêt requis ».

Qui vous protège quand le contrôleur ment ?

Voici le cadre décisionnel que j’utilise en production : supposez que vous aurez éventuellement un composant qui vous dit « succès » alors que la réalité est « corruption ». Ensuite, concevez pour que une couche puisse le prouver.

Cas 1 : Le contrôleur retourne de mauvaises données à la lecture

• RAID matériel + système de fichiers traditionnel : probablement indétecté tant que les vérifications applicatives échouent (si elles existent). Le système de fichiers ne peut pas valider les blocs de données. Vos sauvegardes peuvent préserver la corruption.
• ZFS sur JBOD/HBA : mismatches de checksum détectés. Avec redondance, ZFS peut corriger et logger. Sans redondance, au moins vous savez que le bloc est mauvais plutôt que de servir silencieusement de mauvais octets.
• ZFS sur RAID matériel (volume logique unique) : ZFS peut détecter des mismatches, mais la correction est limitée si le volume RAID sous-jacent renvoie toujours les mêmes mauvaises données (pas de copies alternatives visibles par ZFS). Vous obtenez la détection sans auto-réparation, et le dépannage devient multi-couches.

Cas 2 : Le contrôleur ment sur la durabilité des écritures

C’est le problème du cache d’écriture. Si le contrôleur acquitte des écritures tôt puis les perd, vous pouvez obtenir une corruption du système de fichiers ou de l’incohérence applicative.

• RAID matériel : dépend entièrement de la politique de cache et de la protection contre la perte d’alimentation. Si BBWC/FBWC est sain et correctement configuré, vous êtes généralement OK. Sinon, vous pouvez perdre des écritures acquittées.
• ZFS : ZFS tient beaucoup aux écritures synchrones. Avec une configuration correcte, ZFS n’acquitte les écritures sync que lorsqu’elles sont en sécurité sur un stockage stable (ou sur un dispositif SLOG qui est sûr contre la perte d’alimentation). Mais ZFS ne peut pas vaincre un disque/contrôleur qui ignore les commandes de flush. Si vos appareils ignorent les flush, les garanties de ZFS sont affaiblies.

Cas 3 : Le contrôleur cache des erreurs disque jusqu’à ce qu’il soit trop tard

Le RAID matériel peut maintenir un ensemble « optimal » tout en remappant des secteurs et en gérant des erreurs média. Cela peut être bien — jusqu’à ce que vous réalisiez que plusieurs disques se dégradent. ZFS a tendance à faire remonter les erreurs bruyamment (erreurs checksum, erreurs de lecture, vdev dégradé), ce qui est irritant mais exploitable. En exploitation, je préfère la vérité bruyante à la fiction silencieuse.

La réponse pragmatique

Si votre question est strictement « qui vous protège quand le contrôleur ment », ZFS (avec accès direct aux disques via un HBA en mode IT) offre l’histoire la plus solide parce qu’il valide les données au niveau du système de fichiers et peut s’auto-réparer avec redondance.

Cela ne signifie pas automatiquement « n’utilisez jamais le RAID matériel ». Cela signifie : si vous choisissez le RAID matériel, vous devez accepter que vous externalisez la correction au contrôleur et vous avez besoin de contrôles opérationnels (monitoring batterie, patrol reads, cycle de firmware, vérification périodique) qui correspondent à ce niveau de confiance.

Trois mini-histoires du monde de l’entreprise

Mini-histoire n°1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne exploitait un cluster VM chargé sur un RAID10 matériel. C’était ennuyeux — dans le bon sens — pendant des années. Puis ils virtualisèrent quelques charges de bases de données plus lourdes et commencèrent à voir des pannes rares et aléatoires : un service plantait, une base de données signalait une page corrompue, puis tout revenait à la normale après un redémarrage. Territoire classique « rayons cosmiques », donc la première réponse fut d’accuser les applications.

Ils remplacèrent la mémoire. Ils affinèrent l’hyperviseur. Ils ajoutèrent encore de la supervision. Le tableau de bord stockage restait vert : logical drive optimal, aucun disque en panne, cache sain. La mauvaise hypothèse était simple : « Si le contrôleur RAID dit qu’il est sain, les octets sont sains. »

La percée vint d’un test ennuyeux : ils prirent un jeu de données connu, l’écrivirent, calculèrent des checksums au niveau applicatif, puis le relurent de manière répétée sous charge. Une fois tous les quelques jours, un bloc revenait faux. Pas constamment faux — juste assez pour pourrir la semaine. Les logs du contrôleur n’indiquaient rien d’utile. Les S.M.A.R.T. des disques n’étaient pas visibles par le contrôleur dans leurs outils, et l’OS n’avait aucune visibilité sur les disques individuels.

Ils reproduisirent finalement le problème plus fréquemment en échangeant un câble SAS et en déplaçant l’array derrière un expandeur avec un port marginal. Le contrôleur relançait les lectures jusqu’à obtenir quelque chose et le renvoyait. De son point de vue, il avait satisfait la requête. Du point de vue de l’application, la réalité avait dérivé.

La correction n’a pas été « passer à ZFS » du jour au lendemain. La correction fut : exposer la vraie santé des disques, remplacer le chemin marginal, activer les patrol reads avec alerting, et mettre en place des checksums de bout en bout quand c’était possible. Plus tard, lors du renouvellement, ils migrèrent les charges les plus sensibles à l’intégrité vers des miroirs ZFS sur HBAs. La leçon n’était pas que le RAID est mal. C’était que les LEDs de santé ne sont pas des garanties d’intégrité des données.

Mini-histoire n°2 : L’optimisation qui s’est retournée

Une autre organisation avait l’habitude : tout problème de stockage était un problème de performance jusqu’à preuve du contraire. Ils faisaient tourner ZFS sur une étagère JBOD solide, mais une charge avait des pics de latence pendant les heures de pointe. Quelqu’un proposa un « correctif » simple : ajouter un SLOG rapide pour les écritures sync et régler quelques datasets sur sync=always « pour assurer », et quelques autres sur sync=disabled « pour accélérer ». Oui, les deux en même temps. Dans le même pool. En production.

Ils ajoutèrent un NVMe comme SLOG. C’était rapide. C’était aussi un NVMe grand public sans protection contre la perte d’alimentation. Dans des conditions normales, tout semblait fantastique. Les graphiques de latence se sont aplatis. L’optimisation fut déclarée gagnante et rapidement oubliée, ce qui finance la plupart des désastres.

Des mois plus tard, il y eut un événement d’alimentation qui ne déclencha pas correctement l’UPS — juste assez pour faire brown-out le serveur et le redémarrer. ZFS fit son travail et revint cohérent. Mais un ensemble de datasets « rapides » avec sync désactivé avait des écritures acquittées qui n’avaient jamais atterri. Le système de fichiers du VM survécut, mais la base de données à l’intérieur avait des transactions manquantes et un journal cassé. La cause racine n’était pas « ZFS est dangereux ». La cause racine était d’avoir utilisé les contrôles ZFS pour outrepasser la sémantique de durabilité sans comprendre la charge, plus avoir mis un dispositif non sécurisé dans le rôle où la protection contre la perte d’alimentation est cruciale.

Ce qu’ils changèrent ensuite fut agréablement peu glamour : ils arrêtèrent d’utiliser sync=disabled comme un levier de performance ; ils utilisèrent un SSD d’entreprise avec protection contre la perte d’alimentation pour le SLOG ; et ils créèrent une politique stipulant que tout changement de sync sur un dataset nécessitait un ticket avec plan de rollback.

Mini-histoire n°3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une équipe de services financiers avait une philosophie de stockage qui agaçait les gens : « Ne faites confiance à rien. Vérifiez régulièrement. » Ils exploitaient des miroirs ZFS pour les systèmes critiques et RAIDZ2 pour de grands dépôts. Chaque pool avait un programme de scrub et des alertes sur les erreurs de checksum, pas seulement sur les pannes de périphérique. Ils avaient aussi un exercice trimestriel : simuler un disque défaillant, le remplacer et confirmer le comportement de resilver et les alertes. Cela ressemblait à du travail administratif jusqu’à ce que ce ne le soit plus.

Un trimestre, le scrub rapporta un petit nombre non nul d’erreurs de checksum sur un vdev miroir. ZFS les répara automatiquement, mais la présence d’erreurs fut le signal. L’équipe traita les erreurs de checksum comme de la fumée : on ne les ignore pas parce que l’alarme « a géré le feu ». Ils extrayèrent les données SMART, virent des erreurs UDMA CRC croissantes sur un chemin de disque, et remplacèrent un câble SAS pendant une fenêtre planifiée.

Quelques semaines plus tard, la même baie subit un événement vibratoire (travaux de construction à proximité, le genre que les facilities jurent « ne pourrait pas poser de problème »). Un des disques du miroir perdit la connexion brièvement. Parce que le câble avait été remplacé, le miroir resta stable. L’événement fut une alerte unique et un bref resilver plutôt qu’un incident de plusieurs heures avec un pool dégradé et une direction paniquée.

Rien dans cette histoire n’est glamour. C’est le point. La pratique qui les sauva fut un programme de scrub, des alertes traitant les erreurs de checksum comme actionnables, et des exercices réguliers qui tenaient le processus de remplacement net. En production, l’ennui est une fonctionnalité.

Tâches pratiques (commandes + interprétation)

Les commandes ci-dessous supposent Linux avec ZFS installé (OpenZFS), plus des outils courants. Ajustez les noms de périphériques et de pools. Chaque tâche inclut ce à quoi ressemble le « bon » et le « mauvais ».

Tâche 1 : Obtenir un instantané rapide de la vérité d’un pool ZFS

cr0x@server:~$ sudo zpool status -v
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 02:14:33 with 0 errors on Sun Dec 22 03:10:21 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            ata-SAMSUNG_SSD_1       ONLINE       0     0     0
            ata-SAMSUNG_SSD_2       ONLINE       0     0     0

errors: No known data errors

Interprétation : Regardez READ, WRITE et surtout CKSUM. Des erreurs de checksum non nulles signifient que ZFS a détecté une corruption à la lecture. Si la redondance existe, ZFS peut l’avoir réparée — enquêtez quand même sur le chemin (disque, câble, HBA, backplane).

Tâche 2 : Forcer un scrub et le surveiller sérieusement

cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub in progress since Mon Dec 23 01:00:02 2025
        312G scanned at 1.20G/s, 22.4G issued at 88.0M/s, 1.80T total
        0B repaired, 1.21% done, 05:40:11 to go

Interprétation : « Issued » vs « scanned » vous aide à comprendre le travail disque réel. Si la vitesse du scrub s’écroule, vous avez peut-être un disque malade ou un contrôleur goulot d’étranglement. Si un scrub trouve des erreurs, ne vous contentez pas de célébrer qu’elles ont été réparées — traitez-les comme un indicateur avancé.

Tâche 3 : Trouver les événements ZFS et l’historique des fautes

cr0x@server:~$ sudo zpool events -v | tail -n 30
Dec 23 01:10:44.123456  ereport.fs.zfs.checksum
        class = "ereport.fs.zfs.checksum"
        ena = 0x2c4b3c1f2b000001
        detector = (embedded nvlist)
        ...

Interprétation : Les événements ZFS fournissent des miettes de piste. Des événements checksum répétés liés à un vdev ou un device spécifique indiquent souvent un problème de chemin (câble/backplane) autant qu’un disque défaillant.

Tâche 4 : Confirmer ashift (alignement secteur) avant de le regretter

cr0x@server:~$ sudo zdb -C tank | grep -E "ashift|vdev_tree" -n | head
45:        vdev_tree:
78:            ashift: 12

Interprétation : ashift=12 signifie secteurs 4K. Un ashift mal aligné peut nuire définitivement aux performances ; vous ne pouvez pas le changer sans recréer des vdevs. Sur des disques SSD/modernes, ashift 12 (ou 13 pour 8K) est typique.

Tâche 5 : Vérifier les propriétés de dataset qui causent souvent une « latence mystère »

cr0x@server:~$ sudo zfs get -o name,property,value -s local,default recordsize,compression,atime,sync,logbias tank
NAME  PROPERTY     VALUE     SOURCE
tank  recordsize   128K      default
tank  compression  lz4       local
tank  atime        off       local
tank  sync         standard  default
tank  logbias      latency   default

Interprétation : Pour les images VM (zvols), vous vous souciez davantage de volblocksize que de recordsize. Pour les bases de données, recordsize peut importer. sync n’est pas un interrupteur anodin ; le changer modifie la sémantique de durabilité.

Tâche 6 : Inspecter les stats ARC pour voir si vous êtes lié par la mémoire

cr0x@server:~$ sudo arcstat 1 5
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
01:20:01   842    58      6    12    1    44    5     2    0   24G   32G
01:20:02   901    61      6    10    1    49    5     2    0   24G   32G

Interprétation : Des taux de miss élevés sous une charge de lecture soutenue suggèrent que l’ARC est trop petit ou que le working set est trop large. Cela ne prouve pas « acheter plus de RAM », mais c’est un indice fort. Ne confondez pas misses de cache et panne disque ; cela signifie juste que le système effectue de vraies E/S.

Tâche 7 : Pour la douleur des écritures sync, vérifiez si vous êtes réellement lié par sync

cr0x@server:~$ sudo zpool iostat -v tank 1 5
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        1.20T  600G     210   1800  45.2M  92.1M
  mirror-0  1.20T  600G     210   1800  45.2M  92.1M
    sda         -      -     105    900  22.6M  46.0M
    sdb         -      -     105    900  22.6M  46.0M

Interprétation : Surveillez les IOPS d’écriture et la latence (utilisez aussi iostat -x). Si les pics de latence coïncident avec des charges sync lourdes, un SLOG sûr peut aider — mais uniquement s’il a une protection contre la perte d’alimentation et si vous dimensionnez correctement les attentes.

Tâche 8 : Vérifier la santé des disques individuels (cas JBOD/HBA)

cr0x@server:~$ sudo smartctl -a /dev/sda | egrep -i "model|serial|reallocated|pending|crc|power_on|temperature"
Device Model:     ST12000NM0008
Serial Number:    ZJV123AB
Reallocated_Sector_Ct     0
Current_Pending_Sector    0
UDMA_CRC_Error_Count      12
Power_On_Hours            39120
Temperature_Celsius       41

Interprétation : Les secteurs réalloués/pending sont des signes classiques de dégradation média. Les erreurs UDMA CRC impliquent souvent le chemin câble/backplane, pas le média. Si les CRC augmentent, remplacez le chemin avant de remplacer le disque.

Tâche 9 : Chercher des erreurs stockage au niveau du noyau auxquelles ZFS pourrait réagir

cr0x@server:~$ sudo dmesg -T | egrep -i "ata|sas|scsi|reset|timeout|I/O error" | tail -n 30
[Mon Dec 23 01:12:10 2025] sd 4:0:0:0: [sda] tag#32 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK
[Mon Dec 23 01:12:10 2025] blk_update_request: I/O error, dev sda, sector 123456789

Interprétation : Les timeouts et resets corrèlent fortement avec les erreurs de checksum et les vdevs dégradés. Si vous voyez des resets de lien fréquents, commencez par la couche physique : câbles, backplane, expandeur, firmware HBA.

Tâche 10 : Si vous êtes en RAID matériel, vérifiez l’état du cache/batterie (exemple avec storcli)

cr0x@server:~$ sudo storcli /c0 show
Controller = 0
Status = Success
Description = None

Product Name = RAID Controller
FW Package Build = 24.21.0-0123
BBU = Present

cr0x@server:~$ sudo storcli /c0/bbu show
BBU_Info:
  Battery State = Optimal
  Next Learn time = 2025-12-30 02:00:00

Interprétation : Si la BBU est absente, défaillante ou en cycle d’apprentissage, beaucoup de contrôleurs désactivent le write-back ou se comportent différemment. Le symptôme de performance apparaît souvent avant que quelqu’un ne regarde l’état de la BBU.

Tâche 11 : Sur RAID matériel, vérifier les compteurs d’erreurs des disques physiques

cr0x@server:~$ sudo storcli /c0/eall/sall show all | egrep -i "Drive|Media Error|Other Error|Predictive"
Drive /c0/e32/s0
Media Error Count = 0
Other Error Count = 14
Predictive Failure Count = 0

Interprétation : « Other Error » signifie souvent des problèmes de lien, timeouts ou aborts de commande. Un compteur en hausse est un canari. N’attendez pas le « Predictive Failure ». Ce signal est conservateur et parfois il arrive après que vous ayez déjà perdu patience.

Tâche 12 : Vérifier la politique de cache d’écriture sur RAID matériel

cr0x@server:~$ sudo storcli /c0/vall show | egrep -i "Cache|Write"
Cache Policy = WriteBack, ReadAdaptive, Direct, No Write Cache if Bad BBU

Interprétation : « WriteBack » n’est bon que si vous avez vraiment une protection d’alimentation et que la politique se comporte correctement quand la BBU est mauvaise. Si vous voyez « WriteThrough » de façon inattendue, attendez-vous à une douleur de latence. Si vous voyez « WriteBack » avec « Always Write Cache », soyez certain d’aimer vivre dangereusement.

Tâche 13 : Mesurer la latence réelle au niveau bloc

cr0x@server:~$ sudo iostat -x 1 5
Device            r/s   w/s  r_await  w_await  aqu-sz  %util
sda              95.0  820.0    2.10   18.40    4.20   98.0

Interprétation : Un w_await élevé et un %util élevé suggèrent que le périphérique est saturé ou en train de caler. Si c’est un disque virtuel RAID, souvenez-vous que vous voyez la personnalité du contrôleur autant que les disques.

Tâche 14 : Repérer un risque de write-hole en RAID de parité (vérification conceptuelle)

cr0x@server:~$ sudo storcli /c0/v0 show | egrep -i "RAID Level|Strip Size|Write Cache"
RAID Level = Primary-5, Secondary-0, RAID Level Qualifier-3
Strip Size = 256 KB
Write Cache = WriteBack

Interprétation : RAID5 + write-back peut être acceptable avec une protection d’alimentation adéquate. Sans elle, une coupure de courant peut laisser la parité incohérente. Le symptôme ultérieur est une « corruption du système de fichiers » qui semble être la faute du logiciel.

Feuille de route de diagnostic rapide

Voici la séquence « ne paniquez pas, ne théorisez pas » que j’utilise pour trouver rapidement le goulot ou le problème d’intégrité. L’objectif est de séparer les problèmes de latence, de débit et de correction, car ils se ressemblent quand les utilisateurs hurlent.

Première étape : établir si vous avez une urgence d’intégrité

1. ZFS : zpool status -v. Si CKSUM est non nul ou si le pool est dégradé, traitez cela comme priorité un. Consultez zpool events -v.
2. RAID matériel : état du contrôleur + compteurs d’erreurs des disques physiques. Ne vous arrêtez pas à « virtual drive optimal ». Regardez les erreurs média/other et la santé du cache/batterie.
3. Logs OS : dmesg -T pour timeouts, resets, erreurs I/O.

Deuxième étape : identifier le type de douleur (IOPS vs bande passante vs pics de latence)

1. Utilisation du périphérique bloc : iostat -x 1 pour voir les await times et le %util.
2. Vue ZFS périphérique : zpool iostat -v 1 pour voir quel vdev/disque est chaud.
3. Signes applicatifs : voyez-vous des commits lents (douleur d’écritures sync), des lectures lentes (miss cache / disque), ou des blocages périodiques (timeouts/resets) ?

Troisième étape : valider les hypothèses de cache et durabilité

1. ZFS : vérifiez la propriété sync, la présence d’un SLOG et si le dispositif SLOG est sûr (protection perte d’alimentation). Confirmez que vous n’avez pas « résolu » la latence en désactivant la durabilité.
2. RAID matériel : confirmez le comportement du write-back et ce qui se passe quand la BBU est mauvaise ou en apprentissage. Vérifiez si la politique de cache a changé après un événement.

Quatrième étape : localiser le domaine de faute

1. Un seul disque avec des erreurs en hausse ? Remplacez le disque ou le chemin.
2. Plusieurs disques avec erreurs CRC/lien ? Suspectez HBA/backplane/expander/câblage.
3. Une seule charge lente ? Suspectez les propriétés du dataset, recordsize/volblocksize, patterns sync, fragmentation, ou les schémas d’E/S de l’application.

Erreurs courantes, symptômes, corrections

Erreur 1 : Faire tourner ZFS sur RAID matériel en attendant l’auto-réparation

Symptôme : ZFS signale des erreurs de checksum mais ne peut pas les réparer ; les erreurs réapparaissent sur les mêmes blocs logiques.

Pourquoi : ZFS voit un seul périphérique logique ; il peut détecter la corruption mais n’a pas de copie alternative à lire si le volume RAID renvoie les mêmes mauvaises données.

Correction : Préférez HBAs/JBOD pour que ZFS gère la redondance. Si vous devez utiliser RAID matériel, préférez au minimum un miroir de volumes logiques et traitez-le comme un risque en couches.

Erreur 2 : Considérer sync=disabled comme un réglage de performance

Symptôme : Après un crash/event d’alimentation, les bases de données montrent des transactions manquantes ou des journaux corrompus malgré une importation « propre » du pool.

Pourquoi : ZFS a acquitté des écritures qui n’étaient pas durables.

Correction : Gardez sync=standard sauf si vous comprenez pleinement la charge et acceptez le risque. Utilisez un SLOG d’entreprise pour les charges sync intensives.

Erreur 3 : Ignorer les erreurs de checksum parce que « ZFS les a réparées »

Symptôme : Erreurs de checksum occasionnelles pendant les scrubs ; plus tard vous voyez un disque lâcher ou un vdev se dégrader.

Pourquoi : Le problème sous-jacent (câble, HBA, disque) s’aggrave.

Correction : Traitez les erreurs de checksum comme des déclencheurs d’enquête hardware. Vérifiez SMART, remplacez les câbles suspects, mettez à jour le firmware HBA.

Erreur 4 : Ne pas surveiller la santé du cache/batterie RAID

Symptôme : Régression soudaine de latence après maintenance ; le contrôleur passe silencieusement en write-through.

Pourquoi : BBU en cycle d’apprentissage ou en échec, changement de politique.

Correction : Alertez sur l’état de la BBU et la politique de cache. Planifiez des cycles d’apprentissage. Confirmez les paramètres de cache après les mises à jour de firmware.

Erreur 5 : Utiliser RAID5 pour de grands disques sans plan de risque de reconstruction

Symptôme : Erreur d’un second disque pendant la reconstruction ; l’ensemble devient irrécupérable ou passe en lecture seule.

Pourquoi : La reconstruction lit d’énormes quantités de données ; les erreurs latentes apparaissent.

Correction : Utilisez RAID6/RAIDZ2 ou des miroirs pour les grands disques et les données critiques. Gardez des hot spares, surveillez les taux d’erreurs et testez les temps de reconstruction.

Erreur 6 : Croire que « défaillance de disque » est le seul problème

Symptôme : Timeouts I/O aléatoires, resets de lien, erreurs CRC, mais les disques passent les tests « OK ».

Pourquoi : Problèmes de chemin : câblage, backplane, expandeur, alimentation, incompatibilités de firmware.

Correction : Remplacez méthodiquement les composants du chemin et surveillez les compteurs d’erreurs. Ne tirez pas sur les disques d’abord.

Listes de vérification / plan étape par étape

Étape par étape : choisir entre ZFS et RAID matériel (version production)

1. Définissez la panne que vous ne pouvez pas tolérer. Est-ce un temps d’arrêt, une corruption de données, ou un effondrement des performances pendant la reconstruction ?
2. Décidez où vous voulez la vérification d’intégrité. Si vous voulez des checksums de bout en bout et l’auto-réparation au niveau système de fichiers, planifiez ZFS avec accès direct aux disques.
3. Décidez qui possède la sémantique de cache. RAID matériel : le contrôleur la possède. ZFS : l’hôte la possède, mais les appareils peuvent toujours mentir sur les flushes.
4. Choisissez la redondance selon la mathématique de reconstruction, pas la superstition. Miroirs pour la performance et une récupération rapide ; RAIDZ2/RAID6 pour l’efficacité de capacité avec meilleure tolérance que la parité simple.
5. Planifiez la supervision avant le déploiement. ZFS : alertez sur erreurs de checksum, pools dégradés, scrubs lents. RAID : alertez sur l’état BBU, politique de cache, erreurs media/other, résultats de patrol read.
6. Planifiez des exercices de récupération. Entraînez-vous à remplacer un disque, importer des pools, vérifier des données et chronométrer les resilvers/rebuilds.

Étape par étape : positionner un nouveau pool ZFS en toute sécurité

1. Utilisez un HBA en mode IT (pass-through). Évitez les volumes RAID.
2. Créez le pool avec l’ashift correct pour votre média.
3. Activez compression=lz4 pour la plupart des charges générales.
4. Mettez atime=off sauf si vous en avez vraiment besoin.
5. Définissez des datasets pour différentes charges ; ne mettez pas tout dans un seul dataset.
6. Planifiez des scrubs et alertez sur les erreurs de checksum.
7. Validez les sauvegardes par des tests de restauration, pas par optimisme.

Étape par étape : exploiter le RAID matériel sans se leurrer

1. Vérifiez que le cache d’écriture est protégé (BBWC/FBWC) et que la politique désactive write-back quand la protection est mauvaise.
2. Activez patrol read/vérifications en arrière-plan et alertez sur leurs résultats.
3. Exposez les stats des disques physiques à la supervision (erreurs media, other, température).
4. Maintenez une discipline de lifecycle firmware (contrôleur, backplane/expander si applicable, disques).
5. Testez les temps de reconstruction et l’impact sur les performances dans une fenêtre de maintenance avant d’en avoir besoin en incident.

FAQ

1) ZFS élimine-t-il le besoin de RAID matériel ?

Pour la plupart des déploiements ZFS, oui : vous voulez généralement un accès direct aux disques via un HBA pour que ZFS gère la redondance et l’intégrité. Le RAID matériel peut être utilisé dans des environnements avec des exigences strictes de support fournisseur, mais il ajoute une couche qui peut obscurcir la vérité des disques.

2) ZFS est-il sûr sans RAM ECC ?

ZFS tourne sans ECC, et beaucoup l’utilisent. Mais si vous concevez pour « qui vous protège quand quelque chose ment », l’ECC réduit la probabilité que la corruption mémoire se transforme en checksums valides mais erronés ou en problèmes de métadonnées. Pour les systèmes critiques, l’ECC est un réducteur de risque pratique.

3) Le RAID matériel peut-il détecter la corruption silencieuse ?

Il peut détecter certaines incohérences (mismatch de parité, mauvais secteurs) via patrol reads et vérifications de cohérence, mais il ne fournit généralement pas la validation de bout en bout des données utilisateurs au niveau système de fichiers. Sans checksums de bout en bout au-dessus du contrôleur, vous pouvez ne pas détecter des données « lisibles mais incorrectes ».

4) ZFS au-dessus d’un volume RAID matériel unique est-ce une bonne idée ?

C’est généralement un compromis : ZFS peut détecter la corruption mais peut ne pas pouvoir la corriger, et vous compliquez le dépannage. Si vous devez le faire, préférez des volumes logiques en miroir et soyez sérieux sur la supervision du contrôleur.

5) Quelle redondance devrais-je utiliser : miroirs, RAIDZ1/2/3, RAID5/6 ?

Pour les systèmes critiques avec des exigences de latence, les miroirs sont souvent les plus prévisibles. Pour les jeux de données volumineux, RAIDZ2 (ou RAID6) est un compromis courant. La parité simple (RAIDZ1/RAID5) devient de plus en plus risquée avec de grands disques et des temps de reconstruction longs.

6) Les scrubs ZFS sont-ils la même chose que les patrol reads RAID ?

Ils se ressemblent mais ne sont pas identiques. Un scrub ZFS vérifie les données contre des checksums au niveau système de fichiers et peut réparer à partir de la redondance. Le patrol read se concentre sur la cohérence drive/array au niveau contrôleur et peut ne pas valider que les octets sont les « bons » pour votre application.

7) Pourquoi je vois des erreurs de checksum alors que SMART semble ok ?

Parce que les erreurs de checksum peuvent provenir du chemin (câbles, HBA, expandeur, backplane) et d’incidents de lecture transitoires, pas seulement du média en lui-même. Aussi, SMART n’est pas un parfait prédicteur ; certains disques échouent « soudainement » avec peu d’avertissement SMART.

8) Quelle est la façon la plus courante dont les équipes stockage perdent accidentellement la durabilité ?

Désactiver la sémantique sync (ZFS sync=disabled) ou compter sur write-back sans protection d’alimentation fiable. Les deux rendent les benchmarks beaux et les post-mortems coûteux.

9) Si ZFS détecte une corruption, cela signifie-t-il que mes données sont déjà perdues ?

Pas nécessairement. Avec la redondance, ZFS peut souvent corriger la copie mauvaise automatiquement. Mais la détection signifie qu’un élément de la chaîne est peu fiable, donc vous devez enquêter avant que la prochaine erreur n’affecte la dernière copie saine.

Conclusion

Quand le contrôleur ment, le gagnant est la pile qui peut prouver le mensonge et récupérer sans supposer. Les checksums de bout en bout de ZFS et l’auto-réparation (avec redondance adéquate et accès direct aux disques) en font une réponse forte contre la corruption silencieuse et le mauvais comportement des couches inférieures. Le RAID matériel peut être rapide et simple opérationnellement, mais son abstraction peut aussi devenir un bandeau — surtout si votre supervision s’arrête à « logical drive optimal ».

Le conseil pratique n’est pas « ZFS bon, RAID mauvais ». C’est : décidez où réside la vérité, surveillez cette couche agressivement, et évitez les optimisations de performance qui troquent la durabilité à moins que vous n’achetiez consciemment ce risque. Le stockage n’a pas besoin de votre foi. Il a besoin de votre vérification.