ZFS : présentation, philosophie, vocabulaire

On parle beaucoup de ZFS dans les tutos consacrés à FreeNAS mais souvent le système de fichier est mal connu, ou un peu obscur. Mais il ne le mérite pas ! Je vous propose donc un petit tour d’horizon pour essayer de mieux le connaître, aborder son fonctionnement ainsi que le  vocabulaire associé.

ZFS est un système de fichier relativement nouveau (introduit en 2005 par Sun) proposant une approche fondamentalement nouvelle de la gestion des données. C’est un système 128bits, donc aux limites pharaoniques, qui combine les fonctions de système de fichier et de gestionnaire de volume, ce qui le rend très puissant.

ZFS est donc aussi un gestionnaire de volume, en ce sens il doit pouvoir traiter directement avec les disques durs, comprenez sans autre interface. C’est à dire qu’une carte RAID « matériel » est non seulement totalement inutile mais en plus fortement déconseillée.

Sécurité des données avant tout

ZFS assure en permanence l’intégrité des données et du système de fichier même en cas de coupure électrique en cours d’écriture : soit vos données seront écrites, soit elles ne le seront pas mais il n’y aura jamais de corruption de fichiers à récupérer avec fsck ou chkdsk par exemple.

C’est le principe du copy-on-write : lors d’une écriture, les données à remplacer ne sont pas écrasées : elles sont réécrite à un autre endroit puis le système met à jour les pointeurs vers ces données en une seule opération.

Cela permet également de faire des snapshots, ou instantanés. Les snapshots sont une image du système de fichier à un instant donné permettant une restauration en cas de problème (suppression accidentelle de fichier, échec de mise à jour, etc). Avec ZFS la création d’une image est instantanée, les données modifiées étant écrite à un autre endroit il suffit de garder au fur et à mesure des modifications une trace, en l’occurrence un simple pointeur, vers les données d’origine.

Pour chaque bloc de données stocké, ZFS calcule également une checksum, somme de contrôle, stockée avec le pointeur vers ce bloc de données, cela permet de contrôler lors de la relecture qu’il n’y a pas eu de corruption sur le disque et de réparer le cas échéant si une copie de la donnée existe.

Un pool unique

ZFS est basé sur la notion de pool de stockage. Les autres systèmes de fichiers sont basés sur des partitions, des volumes, tout est cloisonné et difficilement extensible. ZFS agrège tous les disques ensembles pour créer un seul pool de stockage, une grosse entité, pouvant grossir à volonté, et ce pool abrite ensuite un ou plusieurs systèmes de fichiers que l’on nomme dataset et que l’on va pouvoir définir, supprimer, limiter, dimensionner à volonté sans se préoccuper de l’emplacement réel des données sur les disques physiques. Cela offre une flexibilité et une évolutivité bien plus grande.

Les vdev, point critique

On vient de voir qu’un pool (on dit parfois zpool) est constitué des disques dur, c’est en réalité un peu plus complexe et puissant que ça : un pool est en réalité constitué de un ou plusieurs vdev (pour virtual devices).

Les vdevs sont en quelque sorte des périphériques logiques regroupant un ou plusieurs disques durs physiques pouvant être organisés selon les schémas de RAID pour assurer la redondance en cas de panne d’un des disques. On trouve ainsi des vdevs mirror où les disques sont en RAID1, des vdevs RAIDZ avec une organisation équivalente au RAID5 (simple parité, autorise la panne d’un disque) et le RAIDZ2 (double parité équivalent au RAID6, autorise la panne de 2 disques). Il y a même un RAIDZ3 et des miroirs avec 3 disques ou plus pour les plus paranoïaques.

Les vdevs sont ensuite agrégés entre eux en stripe (équivalent d’un RAID 0) pour former le pool et donc leurs capacités s’additionnent. Il est conseillé d’agréger dans un pool uniquement des vdev de même capacité.

Plusieurs points clés sont à noter concernant les vdevs :

  • Il est impossible d’ajouter un disque à un vdev RAIDZ ou RAIDZ2
  • On peut agrandir un pool après sa création en ajoutant des vdevs
  • Il est impossible de retirer un vdev d’un pool.
  • Si un vdev est défaillant (ex : panne de 2 disques dans un RAIDZ), le pool complet est perdu

Ces quelques points clés font ressortir la nécessité d’être très attentif lors des manipulations diverses car par exemple ajouter un vdev constitué d’un disque unique à un pool contenant déjà un RAIDZ2, c’est l’assurance de tout perdre si le disque seul tombe en panne. Cela c’est déjà vu, et une fois l’erreur faite, impossible de la corriger sans supprimer et reconstruire le pool.

ZIL, ARC, L2ARC, Gniarck. Vive la RAM !

Et pour clôturer le point vocabulaire, voici 3 acronymes courants : ARC, L2ARC et ZIL. Il s’agit des caches utilisés par ZFS pour son fonctionnement dans le but d’accélérer la lecture et l’écriture de et vers le pool.

ARC signifie « Adaptive Replacement Cache » et L2ARC « Level 2 ARC » ce sont les caches de lecture. L’ARC est situé dans la RAM du NAS et est constitué d’un subtil équilibre, dépendant de vos propres habitudes, entre les données récemment lues et les données régulièrement lues. Ainsi pour vous servir un fichier auquel vous est accédez tous les jours encore plus vite, ZFS le stocke dans la RAM et vous envoie directement le contenu de la mémoire quand vous accédez à ce fichier au lieu d’aller le lire dans le pool.

Le L2ARC a le même principe de fonctionnement mais en utilisant un disque dur dédié, évidemment pour avoir un avantage il faut qu’il soit rapide, c’est pourquoi on utilise généralement un SSD. Pour notre usage sur FreeNAS à la maison d’hébergement de document, de streaming vidéo vers les télévisions, etc… l’intérêt est maigre voir nul, on en restera donc là.

Le ZIL (ZFS Intent Log) est utilisé pour sa part afin d’optimiser les performances en écritures. A la base, là encore ZFS utilise la RAM : lors d’une écriture vers le pool, les données sont d’abord écrite en RAM, regroupées puis écrites simultanément dans le pool quand ZFS trouve du temps libre (attention : temps libre à l’échelle de l’ordinateur ce n’est pas dans une heure ou deux…). Tout ceci sauf quand on lui demande expressément d’assurer l’écriture sur le disque dur et de rendre compte à la fin, c’est ce que l’on appelle une écriture synchrone, et ça permet au processus qui l’a faite de s’assurer que sa demande ne sera pas envoyée en RAM et puis perdu si il y a une coupure de courant dans la seconde qui suit. C’est très pratique pour une base de donnée ou l’enregistrement de virements bancaires.

Pour assurer les écritures synchrones sans attendre que les disques du pool soient disponibles, on peut là aussi ajouter un SSD rapide qui s’appelle donc le ZIL et sur lequel sont enregistrées ces transactions avant d’être transférées dans le pool ultérieurement. En cas de coupure de courant, il est toujours possible de finaliser ces écritures à la reprise. Astucieux, mais là non plus à domicile ce n’est pas très utile.

Ce que l’on peut quand même conclure de ce point c’est que plus il y a de RAM et plus ZFS fonctionne mieux. On voit également rapidement que la RAM peut être un point critique, en effet autant l’intégrité des données est assurée sur les disques, autant en cas de corruption en RAM, ZFS ne voit rien et peut écrire une donnée corrompue => C’est pour cela que la RAM ECC (et donc carte mère la gérant et processeur adapté) sont conseillés pour une sécurité maximale des données.
Le risque est faible mais non nul d’avoir des données corrompues suite à une erreur en RAM et encore plus faible mais toujours non nul de perdre le pool de données complet en cas de corruption en RAM suivie d’écriture si ces données concernent la structure du pool lui-même.

Le risque est faible mais à priori plus important que sur les systèmes de fichiers classiques car la RAM est bien plus utilisée, notamment en cache d’écriture. A vous de choisir de faire avec ou non.

Pour ma part, j’ai jugé ce risque acceptable et ai choisi de la RAM standard pour mon premier NAS, testée toutefois pendant 36h consécutives avec MemTest86, aucune erreur n’étant acceptable.

Quelques ressources pour approfondir

Pour terminer, si vous êtes curieux voici quelques ressources pour aller plus loin avec ZFS :

En Français d’abord, pas énormément d’infos mais 2 liens :

Et puis en anglais, beaucoup plus de documentation disponible, voici une sélection de 3 liens :


Vous avez aimé ? N'hésitez pas à partager :
Facebook Twitter Google+ Mail

Une réflexion au sujet de « ZFS : présentation, philosophie, vocabulaire »

  1. Bonjour,

    au sujet de la RAM, le risque de défaillance est est autnt sur la qualité de la RAM que sur les rayons recus.

    En effet, une RAM qui ne tourne que qqs heures recevra des doses de rayon qui génèreront peut etre des erreurs corigées/ignorées par l’OS.
    L’exposion d’un serveur 24/7 sera plus exposé au risque (de même qu’aux défaillances liées au heures d’usages).
    Tout n’est que statistique, mais pas seulement de défaut interne aux chips ;).
    https://fr.wikipedia.org/wiki/M%C3%A9moire_%C3%A0_code_correcteur_d%27erreurs

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *