Niveau : intermédiaire

ZFS est un système de fichiers moderne (j'oserai le superlatif "révolutionnaire"), qui a été introduit pour la première fois en 2005 par la société Sun/Oracle sur OpenSolaris, puis par le projet Illumos sur FreeBSD en 2007.
Il a existé pendant un certain temps un port officieux pour Linux, qui a été officialisé en 2013. Toutefois, il reste encore en retard de plusieurs versions.

"Vous ne pourriez pas remplir un espace de données 128 bits sans faire bouillir les océans" - Jeff Bonwick, à propos de ZFS

Introduction à ZFS

J'en ai déjà un peu parlé dans mon premier article.
Vous pourrez trouver une présentation plus détaillée sur le site d'Oracle :
http://www.oracle.com/technetwork/server-storage/solaris11/documentation/oraclesolariszfsstoragemanagement-360232.pdf

Ce qu'il faut en retenir :
- une nouvelle organisation des données, comparable au RAID, mais différente (tout est géré au niveau logiciel)
- une nouvelle façon d'assurer l'intégrité des données
- pas de "corruption silencieuse" des blocs
- les données se "régénèrent" en cas de bloc défectueux
- adressage 128 bits :
    - 2⁴⁸ : le nombre de fichiers dans chaque système de fichiers ou dans un répertoire
    - 16 exbioctets : la taille maximum du système de fichiers ou d'un fichier
    - 2⁴⁸ : nombre de snapshots possible
- Storage Tiering (cache en RAM et sur disque SSD, données sur tous types de disques)
- déduplication (optionnelle)
- compression (optionnelle)
- haute disponibilité intégrée
- performances avantageuses (solutionne le "write hole" du RAID5, notamment)
- un seul défaut réellement significatif : la reconstruction d'une grappe ZFS est plus rapide que son équivalent RAID, lorsque qu'il y a peu de données sur la grappe, mais plus lente, lorsque la grappe est pleine (toutefois, le système peut continuer de fonctionner normalement en mode dégradé)

Bref, des fonctionnalités qui n'ont rien à envier aux meilleurs systèmes de stockage actuels.

Présentation des niveaux de cache ZFS

Il existe plusieurs niveaux de cache pour ZFS :
- ARC, stocké en RAM
- L2ARC (Level 2 ARC), stocké sur disque SSD, cache les opérations de lecture sur la grappe ZFS
- ZIL (ZFS Intent Log), aussi sur SSD, cache les opérations d'écriture sur la grappe ZFS

Par défaut, ZIL se trouve sur la grappe de stockage de masse (autant le désactiver dans ce cas). Lorsque le ZIL est activé et placé sur un disque SSD séparé, il faut parler de SLOG (Separate Intent Log).

Une opération de lecture consiste en la recherche successive d'un bloc dans le cache ARC, dans le L2ARC, puis dans la grappe ZFS, si la donnée n'était pas cachée.
Une opération consiste en l'écriture d'un bloc dans le cache ZIL / SLOG, persistant, ce qui permet d'acquitter l'opération au niveau système. Par la suite, lorsque la grappe sera disponible, le bloc sera transféré du ZIL vers la grappe ZFS. Pour résumer, les opérations d'écriture synchrones sont rendues asynchrones grâce à ZIL, ce qui permet d'améliorer les performances de la grappe.

La taille du cache ARC est paramétrable (d'une centaine de MO à plusieurs GO, si nécessaire).
Et les caches L2Arc et ZIL sont des partitions que l'on peut allouer optionnellement, pour améliorer les performances du système.

Pourquoi l'architecture pour l'écriture diffère de celle pour la lecture

On peut se poser cette question, lorsqu'on découvre ZFS.

Pour la lecture, il y a un cache de level 1 (ARC), un cache de level 2 (L2ARC), puis enfin le stockage de masse.
Pour l'écriture, il y a qu'un cache de level 2 (ZIL), et le stockage de masse.

La réponse est simple :
pour une lecture, si la donnée se trouve sur ARC, c'est qu'elle existe aussi sur L2ARC et le stockage de masse. Si le serveur plante, le contenu d'ARC sera effacé, puisqu'il est en RAM, mais ce n'est absolument critique, puisqu'il existe bien sur ARC2 et le stockage de masse.

Si on avait un cache de level 1, en RAM, pour l'écriture, ça serait par contre dramatique si le serveur venait à planter : les données n'auraient pas forcément le temps d'être écrites sur le cache de level 2, ZIL / SLOG, qui lui est persistant. Ca aboutirait à de la perte de données.

Donc pour l'écriture, ZFS passe directement au stockage "en dur" de level 2, sur un support persistant, sans utiliser la RAM, qui est volatile par nature.

Il est aussi important de noter que les besoins matériels ne sont pas les mêmes pour L2ARC et pour ZIL / SLOG.
Il est possible de mettre L2ARC sur un SSD bon marché, relativement rapide, MLC et surtout pas cher, puisqu'on peut se permettre de perdre les données. Au pire, les performances seront dégradées lorsque L2ARC tombera en panne.
Par contre, ZIL / SLOG est nécessaire à l'intégrité des données : il est fortement recommandé de le placer sur un SSD SLC, qui aura une meilleure durée de vie et supportera de nombreux cycles d'écriture, voire sur deux SSDs en mode mirroir, RAID 1.

Considérations sur le design d'un système de stockage ZFS

Il existe beaucoup de niveaux de RAID disponibles, l'équivalent du RAID1, du RAID5 (appelé RAID-Z), mais aussi du RAID6 (RAID-Z2 ou RAID-Z3, avec 2 ou 3 disques de redondance).

Il est possible d'ajouter des périphériques séparés pour le cache L2ARC et ZIL.
Mieux encore, il est possible d'ajouter plusieurs périphériques par type de cache !

Imaginons un serveur de stockage avec 36 baies :
- nous en allouons 2 (RAID1) pour le système
- 4 pour ZIL
- 8 pour L2ARC
- 20 disques mécaniques
- 2 disques de spare
Nous pouvons par exemple fait 4 pools (grappes), avec chacun 1 disque SSD pour le ZIL, 2 SSD pour le L2ARC, et 5 disques mécaniques pour le stockage.

Ce qui permet d'atteindre des performances MONSTRUEUSES en terme d'IOPS.

Je vous recommande la lecture du benchmark suivant :
https://blogs.oracle.com/brendan/entry/test
Les performances en IOPS ont été multipliées dans son cas par 8,3, et les temps de latence divisés par 20, grâce à L2ARC.
Le test a été fait dans des conditions idéales : la taille des données interrogées équivaut à la taille du L2ARC.

Toutefois, il est tout à fait courant d'obtenir en conditions réelles une multiplication des performances par 2 ou 3 par rapport à un système classique : sur un serveur de stockage, il y a toujours des données "chaudes", qui sont fréquemment interrogées, et des données "froides", qui ne sont presque jamais demandées.