Il existe une règle dans ZFS qui ressemble à une superstition jusqu’à ce que vous ayez vu un pool traîner pendant un long resilver pendant que votre téléphone d’astreinte chauffe : les vdevs sont l’unité de redondance, de performance et de regret. Vous pouvez remplacer des disques. Vous pouvez ajuster des datasets. Vous pouvez ajouter des vdevs. Mais une fois que vous choisissez une topologie de vdev, vous avez pratiquement choisi la personnalité du pool pour le reste de sa vie.
Ce n’est pas un avertissement théorique délivré derrière un tableau blanc. C’est une vérité apprise à la dure en production, dans des centres de données où le stockage « doit juste fonctionner » et dans des clouds où il « doit juste coûter moins cher ». ZFS fera exactement ce que vous lui avez dit de faire — brillamment, sans relâche, et sans la moindre compassion pour vos hypothèses erronées.
La règle qu’on enfreint une fois
La règle est simple : Ne créez jamais un pool sans pouvoir expliquer—à voix haute—comment vous l’étendrez, le remplacerez et survivrez à un long resilver sans parier l’entreprise.
En pratique, cette règle se résume aux décisions sur les vdevs :
- La redondance vit à l’intérieur d’un vdev. Un pool est « aussi redondant que son vdev le moins tolérant aux pannes », et il échouera si n’importe quel vdev de premier niveau échoue.
- La performance s’agrège à travers les vdevs. Plus il y a de vdevs, plus il y a généralement d’IOPS et de parallélisme ; des vdevs RAIDZ larges ne se comportent pas comme « plus de plateaux = plus de vitesse » de la façon dont beaucoup l’imaginent.
- L’expansion est additive par vdev. Vous pouvez ajouter des vdevs à un pool. Historiquement vous ne pouviez pas les supprimer (et même si certaines fonctionnalités récentes existent dans des cas spécifiques, vous devriez planifier comme si la suppression ne faisait pas partie du cycle de vie).
- La réparation (resilver) se fait par vdev et par périphérique. Des vdevs plus larges impliquent plus de disques participants, plus de temps sous stress, et souvent plus d’exposition à une seconde panne avant d’être de nouveau en sécurité.
Voici la phrase que j’utilise quand quelqu’un propose une topologie « créative » pour sauver une réunion budgétaire : ZFS est un système de fichiers avec des opinions, et sa plus forte opinion est que la topologie est le destin.
Blague #1 (courte et pertinente) : Le moyen le plus rapide d’apprendre la conception des vdevs ZFS est d’en construire un mauvais — parce que ZFS s’assurera que vous vous en souveniez.
Les vdevs comme modèle mental : la topologie prime sur les réglages
Si vous avez géré des contrôleurs RAID, vous êtes habitué à penser en termes de « groupe RAID » et de « LUN ». ZFS écrase ces idées. Un pool est construit à partir de vdevs ; les datasets résident sur le pool ; ZFS répartit les écritures entre les vdevs pour équilibrer l’espace et la performance.
Ce qu’est réellement un vdev
Un vdev est un périphérique virtuel qui fournit du stockage à un pool. Ce vdev peut être :
- un disque unique (pas de redondance ; ne faites pas ça en production à moins d’accepter explicitement de le perdre),
- un mirror (deux disques ou plus, copies des données),
- un groupe RAIDZ (parité simple, double, triple : raidz1/2/3),
- un vdev spécial (métadonnées et/ou petits blocs sur un média plus rapide),
- un log (SLOG) pour accélérer les écritures synchrones,
- un cache (L2ARC).
Seuls certains de ces éléments contribuent à la capacité principale (vdevs de données et vdevs spéciaux, selon la configuration). Et seuls certains d’entre eux sont requis pour que le pool continue de fonctionner.
Pourquoi le vdev est le domaine de défaillance
Si vous construisez un pool à partir de quatre mirrors, vous pouvez perdre un disque dans chaque mirror et continuer à fonctionner. Si vous construisez un pool à partir de deux vdevs raidz2, vous pouvez perdre deux disques dans le même vdev (pas n’importe où dans le pool) et continuer. Ce détail de « où tombent les pannes » est ce qui ruine des maths de feuille de calcul qui semblaient pourtant correctes.
Opérationnellement, vous ne choisissez pas où les disques vont tomber en panne. Vous choisissez le rayon d’explosion quand ils le font.
Pourquoi le vdev est l’unité de performance
ZFS stripe les écritures à travers les vdevs, pas à travers des disques individuels. Un pool avec plus de vdevs tend à fournir plus d’IOPS parce que ZFS peut émettre plus d’IO indépendants en parallèle. C’est pourquoi « un énorme RAIDZ2 de 12 disques » déçoit souvent par rapport à « six paires en miroir », même si les deux utilisent 12 disques.
Un vdev RAIDZ peut fournir un bon débit séquentiel, mais l’IO aléatoire et la latence se comportent différemment. Un vdev mirror peut souvent satisfaire les lectures depuis n’importe quel disque et gérer les petites écritures aléatoires sans surcharge de parité. RAIDZ doit faire des calculs de parité et des schémas read-modify-write pour les petites mises à jour. ZFS atténue une partie de cela avec copy-on-write et les transaction groups, mais vous ne pouvez pas optimiser vos problèmes hors des lois de la physique.
Le piège du « on peut ajouter des vdevs »
Oui, vous pouvez étendre un pool en ajoutant des vdevs. Cela ressemble à la liberté. Le piège est que vous ne pouvez pas (pratiquement) « rééquilibrer » les données comme les gens l’imaginent depuis les systèmes distribués. ZFS allouera les nouvelles écritures aux nouveaux vdevs, mais les données existantes restent là sauf si elles sont réécrites. Votre dataset chaud de l’année dernière reste sur le vdev de l’année dernière à moins que vous ne le migriez activement.
De plus, une fois que vous ajoutez un vdev, le pool dépend désormais de ce vdev pour toujours. Si vous ajoutez un vdev « temporaire » à disque unique pour tenir la semaine, vous venez de créer un point de défaillance permanent. Cette semaine devient un an. Elle devient toujours un an.
Faits intéressants et contexte historique
L’ingénierie du stockage regorge de folklore. Voici des éléments concrets de contexte qui rendent les règles des vdevs ZFS moins arbitraires :
- ZFS a été conçu chez Sun avec l’intégrité de bout en bout comme objectif central, pas comme un ajout. Les checksums sur chaque bloc ne sont pas une fonction ; c’est une vision du monde.
- RAIDZ existe parce que le RAID-5/6 traditionnel a un problème de « write hole » (perte de courant pendant les mises à jour de stripe pouvant laisser la parité incohérente). Le modèle transactionnel copy-on-write de ZFS évite cette classe de corruption.
- Le « disque de 1 To » qui a rendu le RAID-5 effrayant est devenu des « disques de 18 To » qui l’ont rendu existential. À mesure que les disques ont grossi, les fenêtres de rebuild/resilver ont augmenté, et la probabilité de rencontrer une erreur pendant le rebuild n’a plus été négligeable.
- Les scrubs ZFS ne sont pas une hygiène optionnelle ; ce sont la façon de transformer la corruption silencieuse en corruption détectée et corrigée. Sans scrubs, vous pariez sur vos sauvegardes et votre chance contre la détérioration des bits.
- Les disques à secteurs 4K ont rendu l’alignement (ashift) une décision permanente. Des pools mal alignés peuvent subir une perte de performance silencieuse qui dure toute la vie du pool.
- Les gens « réparaient » la latence avec le cache d’un contrôleur RAID puis découvraient qu’ils avaient construit une machine à corruption quand les unités de batterie vieillissaient. ZFS a poussé le caching dans l’OS et rendu explicite le comportement en cas de perte de puissance.
- OpenZFS est devenu un écosystème multi-OS, ce qui explique les différences de paramètres par défaut, d’outils et de flags entre plateformes. Les règles des vdevs restent obstinément cohérentes.
- dRAID existe en grande partie pour réduire le temps et le risque de rebuild à grande échelle en distribuant la capacité de secours et en accélérant le remplacement/resilver, surtout dans de grands groupes de type RAIDZ.
- Les vdevs spéciaux sont plus récents mais opérationnellement dangereux quand on les comprend mal : si vous placez les métadonnées sur un vdev spécial et que vous le perdez, le pool peut être effectivement perdu même si les disques de données sont corrects.
Mirrors, RAIDZ, dRAID et vdevs spéciaux : vrais compromis
Mirrors : ennuyeux, rapides, et coûteux (dans le bon sens)
Les mirrors sont la recommandation par défaut pour les charges mixtes car ils se comportent bien sous aléa, échouent de façon prévisible, et resilver relativement vite (surtout avec le support de resilver séquentiel et si le pool n’est pas complètement plein). Les mirrors offrent aussi davantage de vdevs pour le même nombre de disques, ce qui signifie plus de parallélisme.
Mais les mirrors vous coûtent en capacité brute : les mirrors deux voies coupent l’espace utilisable à peu près en deux. Les mirrors trois voies sont l’option « je ne veux plus jamais en parler » pour les systèmes critiques, au prix des deux tiers de la capacité brute.
RAIDZ : efficacité de capacité avec des réserves sur la performance
RAIDZ est séduisant quand vous avez besoin de capacité et que votre charge est plus séquentielle ou orientée vers de grands blocs. RAIDZ2 est souvent la base pour des pools nearline ou « chers à reconstruire ». RAIDZ1 est encore utilisé dans certains endroits, mais c’est de plus en plus une décision de risque plutôt qu’une décision purement technique.
Les deux grands pièges opérationnels avec RAIDZ sont :
- La latence des petites écritures aléatoires, surtout sous charge, parce que les mises à jour de parité ne sont pas gratuites.
- Les longs resilvers à mesure que les disques grossissent, et la réalité inconfortable que le resilver met sous tension les disques restants alors que vous êtes déjà en état dégradé.
La largeur d’un RAIDZ compte. Des vdevs RAIDZ très larges peuvent paraître excellents sur un graphique de capacité puis vous punir avec des fenêtres de rebuild et des latences de queue imprévisibles au pire moment.
dRAID : la réponse pour les grands châssis
dRAID (distributed RAID) est conçu pour les grands pools où les temps de rebuild classiques de RAIDZ deviennent inacceptables. En distribuant la parité et l’espace de secours sur de nombreux disques, il peut réduire le temps nécessaire pour restaurer la redondance après une défaillance et réduire l’inefficacité du « hot spare qui reste inactif jusqu’à la catastrophe ».
Ce n’est pas une baguette magique. Vous devez toujours comprendre les domaines de défaillance, le niveau de parité et le workflow opérationnel pour le remplacement. Mais si vous construisez de grandes étagères JBOD et que vous tenez au temps de resilver, dRAID mérite une considération sérieuse.
Vdevs spéciaux : le multiplicateur de performance avec des tranchants vifs
Les vdevs spéciaux peuvent stocker les métadonnées (et éventuellement les petits blocs) sur du stockage plus rapide comme des SSD. Bien faits, ils transforment les performances des métadonnées du système de fichiers, les traversées d’annuaires et les charges de petits fichiers. Mal faits, ils peuvent créer un nouveau domaine de panne plus petit qui fait tomber tout le pool.
Règle générale : si un vdev spécial contient des métadonnées, traitez-le comme un vdev de données de première classe avec redondance. Mettez-le en miroir. Surveillez-le. Remplacez-le de façon proactive.
SLOG et le malentendu sur les écritures sync
SLOG n’est pas un cache d’écriture. C’est un périphérique de log séparé utilisé uniquement pour les écritures synchrones. Si votre charge est majoritairement asynchrone (commun pour de nombreuses applications), un SLOG peut ne rien changer. Si votre charge est synchrone (bases de données, NFS avec sync, certains schémas de stockage VM), un bon SLOG peut réduire la latence de façon spectaculaire—à condition qu’il soit sûr en cas de perte d’alimentation et rapide à faibles profondeurs de file.
Blague #2 (courte et pertinente) : Acheter un SLOG pour une charge async, c’est comme installer un aileron de course sur une camionnette de livraison—ça change l’apparence, pas le temps au tour.
Trois mini-récits du monde de l’entreprise
1) Incident causé par une mauvaise hypothèse : « On pourra toujours l’enlever plus tard »
L’entreprise était en pleine migration. Un SAN legacy était en cours de retrait, et un nouvel appliance ZFS (whitebox, conception compétente) avait été construit pour prendre le relais. L’équipe stockage avait dimensionné le pool de façon conservatrice : vdevs mirror, bonne surveillance, tests de restauration. Puis le planning a glissé.
Une équipe produit est arrivée avec un nouveau dataset qui ne rentrait pas. La solution la plus simple à court terme semblait inoffensive : ajouter un gros disque unique comme vdev « temporaire » jusqu’à ce que les achats se fassent. Le pool l’a accepté. Le dataset est arrivé. La crise est passée. Tout le monde est retourné à ses vrais métiers.
Six mois plus tard, le « disque temporaire » était toujours là. Il ne figurait pas dans le plan de remplacement initial. Il ne figurait pas dans le tableau qui suivait les dates de garantie. Il n’était pas non plus en miroir. Un matin, il a commencé à renvoyer des erreurs de lecture. ZFS a fait ce que ZFS fait : il a marqué le vdev comme faulted, et tout le pool est tombé car un pool ne peut pas survivre à la perte d’un vdev de premier niveau.
Le postmortem fut sombre non pas parce que la panne était exotique, mais parce qu’elle était ennuyeuse. La mauvaise hypothèse n’était pas « les disques tombent en panne ». C’était « on peut facilement annuler les changements de topologie ». Ils ont fini par faire une migration d’urgence hors du pool, sous pression temporelle, vers la capacité disponible. L’impact business n’est pas venu du disque mort ; il est venu de la décision topologique qui avait fait d’un disque unique une dépendance du pool.
La correction fut simple mais douloureuse : reconstruire le pool correctement et remigrer les données. La leçon est restée : il n’existe pas de vdev de premier niveau temporaire.
2) Optimisation qui a échoué : « Un large RAIDZ est plus simple »
Une autre organisation avait un nouveau cluster d’analytique. Ils effectuaient de grands scans séquentiels la nuit, mais le jour c’était interactif : dashboards, requêtes ad-hoc, et beaucoup de petites IO aléatoires. Quelqu’un a proposé un unique large vdev RAIDZ2 pour maximiser l’espace utilisable et simplifier la gestion. Moins de vdevs, moins de pièces en mouvement, un seul ensemble de disques de parité. Le plan paraissait propre.
Lors du premier test de charge, le débit séquentiel fut excellent. Tout le monde a célébré. Puis la production est arrivée. Les requêtes diurnes ont commencé à montrer des pics de latence en long tail. Pas une lenteur constante—pire. Toutes les quelques minutes, quelque chose plantait suffisamment pour déclencher les timeouts applicatifs. Les graphiques de stockage semblaient « corrects en moyenne », c’est ainsi que les problèmes de stockage se cachent dans les tableaux de bord d’entreprise.
La cause racine n’était pas mystérieuse. C’était le décalage entre la charge et le comportement des vdevs. Le large groupe RAIDZ2 avait un bon débit mais peinait avec les IO mixtes et petites sous concurrence. Le pool n’avait qu’un vdev de données, donc ZFS avait peu d’endroits où planifier du travail en parallèle. Ajoutez un pool modérément plein, une certaine fragmentation au fil du temps, et la latence interactive est devenue moche.
Ils ont essayé le classique : ajuster recordsize, changer la compression, plus de RAM, même un L2ARC. Les améliorations furent marginales parce que la limitation principale était structurelle. Finalement ils ont reconstruit en plusieurs vdevs mirror et le problème a disparu. L’« optimisation » a échoué parce qu’elle optimisait le mauvais indicateur—les To utilisables—au détriment de l’indicateur ressenti par les utilisateurs : la latence p99.
La morale discrète : la simplicité est excellente, mais un pool à vdev unique est rarement simple en production.
3) Pratique ennuyeuse mais correcte qui a sauvé la mise : « Scrubs, spares et discipline de remplacement »
Celle-ci n’apparaît jamais dans les slides d’architecture parce qu’elle n’est pas sexy. Une entreprise de taille moyenne utilisait ZFS pour du stockage VM avec des vdevs mirror, une utilisation de capacité conservatrice, et une cadence : scrubs mensuels, alertes sur erreurs de checksum, et une politique de remplacement de tout disque qui présentait des erreurs répétées même s’il n’était pas complètement mort.
Un trimestre, un lot de disques a commencé à montrer des problèmes intermittents de lecture. Pas assez pour déclencher une panne immédiate, mais assez pour accumuler des erreurs de checksum. Les scrubs l’ont détecté tôt. L’équipe n’a pas bataillé avec les disques. Ils les ont remplacés de manière ordonnée, un membre de mirror à la fois, pendant les heures ouvrables, alors que le pool était sain.
Plus tard cette année-là, un incident d’alimentation a frappé une autre baie. Les systèmes ont récupéré, mais le même pool qui avait vu des disques fragiles aurait été dans un état dangereux si ces disques marginaux étaient encore présents. Au lieu de cela, le pool est revenu propre. Aucun vdev dégradé. Aucun resilver d’urgence sur des médias déjà malades. La réponse incident fut presque ennuyeuse : vérifier l’état, vérifier le calendrier de scrub, passer à autre chose.
La pratique qui les a sauvés n’était pas un paramètre de tuning astucieux. C’était de la discipline opérationnelle : scrubs, surveillance et remplacement proactif. En stockage, l’ennuyeux est une fonctionnalité.
Tâches pratiques : commandes + interprétation
Voici les tâches que j’exécute réellement en production quand je valide une conception de vdev, diagnostique des problèmes, ou nettoie après qu’un incident ait mal tourné. Les commandes supposent OpenZFS sur un système de type Linux ; adaptez les noms de périphériques et de pool en conséquence.
Task 1: Inspecter la topologie du pool (le sérum de vérité)
cr0x@server:~$ sudo zpool status -v
pool: tank
state: ONLINE
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
raidz2-1 ONLINE 0 0 0
ata-WDC_1 ONLINE 0 0 0
ata-WDC_2 ONLINE 0 0 0
ata-WDC_3 ONLINE 0 0 0
ata-WDC_4 ONLINE 0 0 0
ata-WDC_5 ONLINE 0 0 0
ata-WDC_6 ONLINE 0 0 0
errors: No known data errorsInterprétation : Identifiez les vdevs de premier niveau (mirror-0, raidz2-1). Le pool échoue si n’importe quel vdev de premier niveau échoue. Les types de vdevs mixtes sont autorisés mais peuvent créer des performances inégales et un comportement d’expansion maladroit.
Task 2: Obtenir capacité et fragmentation en un coup d’œil
cr0x@server:~$ zpool list -o name,size,alloc,free,capacity,health,fragmentation
NAME SIZE ALLOC FREE CAPACITY HEALTH FRAG
tank 100T 72T 28T 72% ONLINE 31%Interprétation : Une capacité au-delà d’environ 80% et une fragmentation croissante sont une recette fréquente pour des plaintes de latence, surtout sur RAIDZ. La fragmentation n’est pas intrinsèquement mauvaise, mais elle corrèle avec des difficultés d’allocation et une amplification IO.
Task 3: Montrer ashift (alignement des secteurs) par vdev
cr0x@server:~$ sudo zdb -C tank | egrep -i 'vdev|ashift' | head -n 30
vdev_tree:
type: 'root'
id: 0
guid: 123456789
children[0]:
type: 'mirror'
id: 0
ashift: 12
children[1]:
type: 'raidz'
id: 1
ashift: 12Interprétation : ashift=12 means 4K sectors. ashift est effectivement permanent pour ce vdev. Si vous avez accidentellement construit avec ashift=9 sur des disques 4K, vous pouvez observer une amplification d’écriture persistante et de mauvaises performances.
Task 4: Identifier les datasets avec sync activé (pertinence SLOG)
cr0x@server:~$ zfs get -r -o name,property,value sync tank
NAME PROPERTY VALUE
tank sync standard
tank/vm sync always
tank/backups sync disabledInterprétation : Si des datasets importants sont sync=always, un SLOG approprié peut avoir de l’importance. Si la plupart sont standard et que vos applis n’émettent pas d’écritures sync, un SLOG ne fera rien.
Task 5: Confirmer recordsize et volblocksize
cr0x@server:~$ zfs get -o name,property,value recordsize tank
NAME PROPERTY VALUE
tank recordsize 128K
cr0x@server:~$ zfs get -o name,property,value volblocksize tank/vm-zvol
NAME PROPERTY VALUE
tank/vm-zvol volblocksize 16KInterprétation : recordsize compte pour les systèmes de fichiers ; volblocksize compte pour les zvols et n’est pas trivial à changer après création. Les incompatibilités peuvent créer des overheads read-modify-write et de mauvais comportements de compression.
Task 6: Observer l’IO et la latence en temps réel par vdev
cr0x@server:~$ sudo zpool iostat -v tank 2
capacity operations bandwidth
pool alloc free read write read write
-------------------------- ----- ----- ----- ----- ----- -----
tank 72T 28T 120 800 15M 110M
mirror-0 1.2T 0.8T 90 500 12M 60M
ata-SAMSUNG_SSD_1 - - 45 250 6M 30M
ata-SAMSUNG_SSD_2 - - 45 250 6M 30M
raidz2-1 70T 27T 30 300 3M 50M
ata-WDC_1 - - 5 50 0.5M 8.5M
...Interprétation : Si un vdev est saturé ou montre un travail disproportionné, vous avez trouvé votre goulot d’étranglement. Les pools ne « moyennent » pas magiquement un vdev lent ; ils se mettent en file d’attente derrière lui quand les allocations y arrivent.
Task 7: Vérifier les compteurs d’erreur et repérer un disque « mourant silencieusement »
cr0x@server:~$ sudo zpool status tank
pool: tank
state: ONLINE
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
mirror-1 ONLINE 0 0 0
ata-WDC_7 ONLINE 0 0 12
ata-WDC_8 ONLINE 0 0 0
errors: No known data errorsInterprétation : Des erreurs CKSUM sur un périphérique sont souvent du câblage, du contrôleur, ou le disque lui-même. « No known data errors » signifie que ZFS a corrigé ce qu’il pouvait, mais votre matériel envoie de mauvaises données. Ne normalisez pas les erreurs de checksum.
Task 8: Effacer les erreurs transitoires après réparation matérielle (seulement après preuves)
cr0x@server:~$ sudo zpool clear tankInterprétation : Effacer les erreurs masque l’historique. Faites-le après avoir remplacé un câble/HBA/disque et que vous souhaitez confirmer que le problème est parti. Si les erreurs reviennent, vous êtes toujours dans le rayon d’explosion.
Task 9: Remplacer un disque défaillant dans un mirror
cr0x@server:~$ sudo zpool offline tank ata-WDC_7
cr0x@server:~$ sudo zpool replace tank ata-WDC_7 /dev/disk/by-id/ata-WDC_NEW_7
cr0x@server:~$ sudo zpool status tank
pool: tank
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-1 ONLINE 0 0 0
replacing-0 ONLINE 0 0 0
ata-WDC_7 OFFLINE 0 0 0
ata-WDC_NEW_7 ONLINE 0 0 0 (resilvering)
ata-WDC_8 ONLINE 0 0 0
errors: No known data errorsInterprétation : Utilisez des chemins de périphérique stables (by-id). Surveillez le resilver. Si le resilver prend anormalement longtemps, vérifiez l’utilisation du pool, la contention IO, et si vous tombez sur un périphérique lent.
Task 10: Surveiller la progression et le débit du resilver
cr0x@server:~$ sudo zpool status tank
scan: resilver in progress since Tue Dec 24 10:12:03 2025
3.20T scanned at 540M/s, 1.10T issued at 185M/s, 72T total
1.10T resilvered, 1.53% done, 4 days 10:21:19 to goInterprétation : « Scanned » vs « issued » vous informe sur le throttling et la contention IO. Si « issued » est bas, le pool est trop occupé ou un vdev/périphérique est lent. Pendant un resilver, votre marge de redondance est réduite ; considérez cela comme un incident jusqu’à sa fin.
Task 11: Lancer un scrub et comprendre son coût
cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ sudo zpool status tank
scan: scrub in progress since Tue Dec 24 12:00:00 2025
9.80T scanned at 1.1G/s, 2.40T issued at 270M/s, 72T total
0B repaired, 3.33% done, 0 days 18:10:40 to goInterprétation : Les scrubs consomment de l’IO. Planifiez-les, mais ne les sautez pas. Un scrub qui trouve des erreurs de checksum n’est pas de la « malchance » ; c’est un système d’alerte précoce qui fait son travail.
Task 12: Afficher le ratio de compression et confirmer que vous ne vous illusionnez pas
cr0x@server:~$ zfs get -o name,property,value,source compression,compressratio tank
NAME PROPERTY VALUE SOURCE
tank compression zstd local
tank compressratio 1.72x -Interprétation : La compression peut être un multiplicateur de capacité et parfois un gain de performance, mais elle change les schémas d’écriture et l’utilisation CPU. Si compressratio est ~1.00x, vous n’en tirez pas grand-chose.
Task 13: Identifier les charges lourdes en métadonnées (candidats vdev spécial)
cr0x@server:~$ zfs get -o name,property,value primarycache,secondarycache tank/home
NAME PROPERTY VALUE
tank/home primarycache all
tank/home secondarycache all
cr0x@server:~$ sudo zpool iostat -v tank 2 | head -n 20Interprétation : Si votre charge est des parcours d’annuaires, de petits fichiers et un churn de métadonnées, le problème peut être la latence sur les IO de métadonnées. Les vdevs spéciaux peuvent aider, mais seulement s’ils sont conçus avec redondance et surveillés comme si votre travail en dépendait (parce que c’est le cas).
Task 14: Vérifier la santé de l’ARC et si vous manquez de mémoire
cr0x@server:~$ grep -E 'c_min|c_max|size|hits|misses' /proc/spl/kstat/zfs/arcstats | head
c_min 4 8589934592
c_max 4 68719476736
size 4 53687091200
hits 4 2147483648
misses 4 268435456Interprétation : L’ARC est votre premier cache. Si les misses sont élevés et la latence mauvaise, vous pourriez être lié IO ou simplement sous-cache. N’achetez pas immédiatement des SSD ; vérifiez si de la RAM est la mise à niveau de performance la moins chère.
Mode opératoire de diagnostic rapide
Ceci est le flux « vous avez 15 minutes avant que le canal incident ne fonde ». L’objectif est d’identifier si le goulot est la topologie, un périphérique spécifique, le comportement sync, la pression de capacité ou quelque chose en amont.
Premier : Le pool est-il sain et déjà dégradé ?
cr0x@server:~$ sudo zpool status -x
pool 'tank' is healthySi ce n’est pas sain : arrêtez de faire semblant que c’est un « problème de performance ». Les pools dégradés se comportent différemment, les resilvers se concurrencent avec la charge, et le risque est élevé.
Second : Un vdev ou un disque est-il lent ou en erreur ?
cr0x@server:~$ sudo zpool iostat -v tank 1
cr0x@server:~$ sudo zpool status tankCe que vous recherchez : un périphérique avec beaucoup moins de bande passante, des erreurs élevées, ou un vdev prenant des opérations disproportionnées. Un seul disque défectueux peut tirer un vdev RAIDZ entier dans l’enfer de latence.
Troisième : Êtes-vous contraint par la capacité (espace ou fragmentation) ?
cr0x@server:~$ zpool list -o name,capacity,fragmentation
NAME CAPACITY FRAG
tank 89% 54%Interprétation : Forte capacité plus forte fragmentation est un moteur classique de blocages d’allocation. La « solution » n’est rarement un sysctl. C’est généralement « ajouter des vdevs, libérer de l’espace, ou migrer. »
Quatrième : Payez-vous pour des écritures sync ?
cr0x@server:~$ zfs get -r sync tank | head
cr0x@server:~$ sudo zpool status tank | egrep -i 'logs|log'Interprétation : Si sync est activé et que vous n’avez pas de SLOG (ou un mauvais), la latence peut grimper sur des charges fsync-intensives. Si sync est désactivé partout, ne poursuivez pas des fantômes de SLOG.
Cinquième : L’ARC fait-il son travail, ou lisez-vous constamment depuis le disque ?
cr0x@server:~$ awk '{print $1,$3}' /proc/spl/kstat/zfs/arcstats | egrep 'hits|misses'
hits 2147483648
misses 268435456Interprétation : Un taux de miss croissant sur une charge de lecture peut indiquer une pression mémoire ou que le working set est plus grand que l’ARC. Cela peut aussi indiquer que votre pattern IO est intrinsèquement non-cacheable (grands scans).
Sixième : Confirmez la charge et adaptez-la à la topologie
Cette partie est humaine, pas une commande. Posez :
- Est-ce majoritairement du petit IO aléatoire (VMs, bases de données) ? Les mirrors tendent à gagner.
- Est-ce majoritairement du grand IO séquentiel (sauvegardes, médias) ? RAIDZ peut convenir.
- Mélangeons-nous des charges riches en métadonnées avec du stockage en masse ? Envisagez des vdevs spéciaux—avec prudence.
- Avons-nous récemment ajouté un nouveau vdev et attendu que les anciennes données se rééquilibrent ? Elles ne l’ont pas fait.
Erreurs fréquentes : symptômes et corrections
Mistake 1: Ajouter un vdev à disque unique « temporairement »
Symptôme : Le pool devient à un disque de la panne totale ; plus tard, un disque tombe et tout le pool s’effondre.
Correction : Ne le faites pas. Si c’est déjà fait : migrez les données, reconstruisez le pool correctement, migrez de retour. Si vous devez ajouter de la capacité en urgence, ajoutez un vdev redondant (mirror ou RAIDZ) qui respecte vos exigences de durabilité.
Mistake 2: Construire un gigantesque RAIDZ et s’attendre à des IOPS de mirror
Symptôme : Bons benchmarks séquentiels, latence p95/p99 catastrophique sous charge mixte ; « le débit moyen semble correct. »
Correction : Redessinez avec plus de vdevs (souvent des mirrors) ou plusieurs vdevs RAIDZ de largeur sensée. Arrêtez d’essayer de tuner autour d’un désaccord topologique.
Mistake 3: Ignorer ashift et l’alignement de secteur
Symptôme : Latence d’écriture chronique et débit inférieur aux attentes, surtout sur SSD ; pas d’erreurs évidentes.
Correction : Vérifiez ashift avec zdb -C. Si c’est incorrect, la vraie correction est reconstruire/migrer. Vous ne pouvez pas fiablement « corriger » ashift en place.
Mistake 4: Traiter les vdevs spéciaux comme un cache
Symptôme : Perte du pool ou risque de corruption sévère après la défaillance du vdev spécial ; les métadonnées deviennent indisponibles alors que les disques de données sont sains.
Correction : Mettez en miroir (ou protégez autrement) les vdevs spéciaux. Surveillez-les comme des vdevs de données. Utilisez des SSD haute endurance. Planifiez les remplacements.
Mistake 5: Acheter un SSD bon marché pour le SLOG
Symptôme : La latence des écritures sync ne s’améliore pas, ou s’aggrave ; des blocages occasionnels ; le périphérique s’use rapidement.
Correction : Utilisez un périphérique avec protection contre la perte de puissance et faible latence. Confirmez que votre charge utilise des écritures sync. Validez avec la latence applicative, pas seulement les compteurs ZFS.
Mistake 6: Faire tourner le pool trop plein
Symptôme : Les écritures se bloquent, les temps de scrub/resilver explosent, la fragmentation augmente, et des « bizarreries aléatoires » apparaissent sous charge.
Correction : Gardez une marge d’espace libre. Ajoutez des vdevs avant d’atteindre la falaise. Si vous êtes déjà plein, migrez les données froides ou étendez immédiatement.
Mistake 7: Mélanger des tailles de disques et espérer des résultats gracieux
Symptôme : Les mirrors gaspillent la capacité, les vdevs RAIDZ se limitent au plus petit disque, l’expansion devient confuse.
Correction : Gardez les membres de vdev uniformes quand c’est possible. Si vous devez mélanger, faites-le intentionnellement et documentez comment cela affecte l’espace utilisable et la stratégie de remplacement.
Mistake 8: Confondre « zpool add » avec une mise à niveau
Symptôme : Quelqu’un ajoute un vdev en s’attendant à ce que le RAIDZ existant s’élargisse ; plus tard il réalise que la topologie est maintenant mixte pour toujours.
Correction : L’expansion en ajoutant des vdevs n’est pas la même chose que changer la forme d’un vdev. Planifiez la largeur des vdevs dès le départ ; utilisez des vdevs additionnels pour la croissance.
Listes de contrôle / plan étape par étape
Étape par étape : Concevoir un pool que vous ne détesterez pas
- Écrivez la charge en une phrase : « stockage VM avec écritures aléatoires », « cible de sauvegarde avec écritures séquentielles », « répertoires NFS avec churn de métadonnées », etc.
- Choisissez votre tolérance aux pannes : combien de disques peuvent tomber dans le même vdev sans outage ? Choisissez mirror/raidz2/raidz3 en conséquence.
- Choisissez la largeur des vdevs intentionnellement : n’utilisez pas simplement « tous les disques dans un groupe ». Préférez plus de vdevs à des vdevs très larges pour des charges IOPS-intensives.
- Décidez comment vous étendrez : « ajouter une autre paire mirror par trimestre », ou « ajouter un autre vdev raidz2 de 6 disques », etc.
- Décidez comment vous remplacerez les disques : noms by-id, fenêtres de maintenance, spares en stock, procédure documentée.
- Réglez ashift correctement avant de créer le pool. Traitez-le comme permanent.
- Planifiez scrubs et surveillance : cadence de scrub, seuils d’alerte (erreurs de checksum, resilvers lents), et qui est pagé.
- Gardez une marge : définissez un plafond de capacité qui déclenche l’expansion avant l’effondrement des performances.
- Testez le comportement dégradé : simulez un disque offline et observez l’impact applicatif ; validez le temps de resilver sous charge représentative.
Étape par étape : Validation pré-vol avant d’engager des données
- Confirmer la topologie et la redondance.
- Confirmer ashift.
- Confirmer les propriétés des datasets pour l’usage prévu (recordsize, compression, atime, sync).
- Exécuter un test de charge représentatif incluant IO mixte et mesurer la latence tail.
- Retirer un disque (ou le mettre offline) en staging et observer le resilver et l’application.
Checklist opérationnelle : lorsqu’un disque lâche
- Confirmer l’état du pool (
zpool status). - Identifier le disque physique exact (mapping by-id, emplacement châssis).
- Vérifier si le pool est déjà en scrub/resilver.
- Réduire la charge évitable si possible ; resilver sous saturation étend votre fenêtre de risque.
- Remplacer le disque en utilisant des chemins stables ; surveiller le resilver jusqu’à la fin.
- Après la fin, lancer un scrub si vous avez une raison de douter de l’intégrité des données.
FAQ
1) Quelle est vraiment la « règle unique » sur les vdevs ?
Concevez les vdevs comme si vous alliez être coincé avec eux pour toujours—parce que c’est le cas. Vous pouvez ajouter des vdevs, mais vous ne pouvez pas annuler facilement une mauvaise décision de vdev de premier niveau sans migrer les données.
2) Est-ce acceptable de mélanger mirrors et RAIDZ dans un même pool ?
C’est autorisé, et parfois pratique (par exemple, ajouter un vdev spécial ou ajouter un mirror pour augmenter les IOPS). Mais les topologies mixtes peuvent créer des performances inégales et un comportement d’allocation déroutant. Si vous le faites, documentez pourquoi et comment vous allez étendre de façon cohérente à l’avenir.
3) Pourquoi plus de vdevs aident-ils généralement la performance ?
ZFS planifie les IO à travers les vdevs de premier niveau. Plus de vdevs signifie plus de files indépendantes et plus de parallélisme. Un seul vdev large peut devenir un goulot unique pour l’IO aléatoire et la latence.
4) Dois-je utiliser RAIDZ1 ?
Uniquement si vous avez accepté explicitement le profil de risque et la fenêtre de rebuild pour la taille de vos disques et votre charge, et si vous avez de solides sauvegardes. Pour de nombreux déploiements modernes de gros disques, RAIDZ2 est le baseline plus défendable.
5) L’ajout d’un vdev rééquilibre-t-il les données existantes ?
Non. Les nouvelles allocations préféreront le nouveau vdev en fonction de l’espace libre et du weighting, mais les anciens blocs restent généralement où ils sont. Si vous avez besoin que les données bougent, vous devez les réécrire (send/receive, réplication, ou migration au niveau applicatif).
6) Ai-je besoin d’un SLOG ?
Seulement si votre charge émet des écritures synchrones et que vous tenez à la latence sync. Confirmez avec les paramètres dataset sync et le comportement applicatif. Si vous en avez besoin, utilisez un périphérique protégé contre la perte de puissance.
7) Les vdevs spéciaux sont-ils sûrs ?
Ils sont sûrs quand ils sont traités comme des composants critiques et redondants. Ils sont dangereux quand on les traite comme un cache qu’on peut perdre. Si les métadonnées résident là, leur perte peut être catastrophique.
8) Quel est un calendrier de scrub sensé ?
La pratique commune est mensuelle pour de nombreux pools, parfois plus fréquente pour les environnements à haut risque. La bonne réponse dépend de la capacité, de la charge et de la rapidité à laquelle vous voulez faire ressortir les erreurs latentes. La mauvaise réponse est « jamais ».
9) Pourquoi mon resilver met-il une éternité ?
Causes communes : forte utilisation du pool, charge de production lourde, disques lents ou marginaux, problèmes de contrôleur, ou un vdev RAIDZ très large. Vérifiez zpool status (issued vs scanned), zpool iostat -v, et les compteurs d’erreurs matérielles.
10) Quelle est la stratégie d’expansion la plus sûre ?
Ajoutez des vdevs qui correspondent à votre profil existant de redondance et de performance, gardez la largeur des vdevs cohérente, et étendez avant d’atteindre les falaises de performance liées à la forte utilisation. Si vous devez changer le profil, planifiez une migration plutôt qu’un bricolage improvisé.
Conclusion
La conception des vdevs ZFS n’est pas un art obscur. Elle est juste impitoyable. Le système de fichiers acceptera volontiers votre « disque temporaire », votre RAIDZ trop large, votre vdev spécial sous-protégé, et votre ashift mal aligné — puis il exécutera ces décisions en production à grande échelle, sous stress, à 3 h du matin.
Si vous ne retenez qu’une chose : les vdevs ne sont pas un détail de configuration ; ce sont le contrat que vous signez avec votre futur vous. Signez quelque chose avec lequel vous pouvez vivre : une redondance que vous pouvez expliquer, des performances que vous pouvez prédire, une expansion que vous pouvez exécuter, et des pratiques opérationnelles ennuyeuses qui vous tiennent à l’écart des appels d’incident où le stockage est techniquement « correct » mais que l’entreprise brûle.