Le culte de ZFS

Il est assez courant que les milieux informatiques développent une certaine mentalité de secte ou de “fanboy”. Ce qui provoque cette réaction envers les technologies et les produits, je ne le sais pas tout à fait, mais que cela se produise est indéniable. Un domaine où je n'aurais jamais pensé voir cela se produire est celui des systèmes de fichiers – l'un des composants système les plus “sous le capot” et un composant qui, jusqu'à récemment, ne recevait littéralement aucune attention, même dans des milieux assez techniques. Avouons-le, ne pas comprendre quand quelque chose provient d'Active Directory plutôt que de NTFS est presque universel. Les systèmes de fichiers sont, tout simplement, ignorés. Depuis la sortie de Windows NT 4 et l'époque où NTFS était la seule option viable, l'idée qu'un système de fichiers n'est pas un composant intrinsèque d'un système d'exploitation et qu'il pourrait exister d'autres options pour le stockage des fichiers s'est presque entièrement estompée. C'est-à-dire, jusqu'à récemment.

La seule communauté où, dans une certaine faible mesure, cela ne s'est pas produit était la communauté Linux, mais même là, Ext2 et ses descendants ont si complètement conquis les esprits que, bien qu'ils aient été largement disponibles, les systèmes de fichiers alternatifs ont été relégués au second plan et seul XFS a reçu une quelconque attention, historiquement, et même lui en a reçu très peu.

Là où un comportement véritablement étrange s'est produit, plus récemment, c'est autour du système de fichiers ZFS d'Oracle, développé à l'origine pour le système d'exploitation Solaris et la plateforme de stockage ouverte X4500 “Thumper” (initialement sous l'égide de Sun avant le rachat par Oracle). À l'époque (il y a neuf ans) où ZFS est sorti, les systèmes de fichiers concurrents étaient pour la plupart mal préparés à gérer les grandes grappes de disques qui devaient être constituées dans les années à venir. ZFS était conçu pour les gérer et a inauguré l'ère des systèmes de fichiers à grande échelle. Comme la plupart des systèmes de fichiers de l'époque, ZFS était limité à un seul système d'exploitation et, bien que largement considéré comme un grand bond en avant dans la conception des systèmes de fichiers, il n'a produit que peu de remous dans le monde du stockage et encore moins dans le monde des “systèmes”, où même les administrateurs Solaris l'ont généralement considéré comme un simple sujet de curiosité pendant assez longtemps, choisissant pour la plupart de s'en tenir à l'éprouvé UFS qu'ils utilisaient depuis de nombreuses années.

ZFS était, en vérité, un système de fichiers révolutionnaire et j'en étais, et j'en reste, un grand partisan. Mais il est très important de comprendre pourquoi ZFS a fait ce qu'il a fait, quels sont ses objectifs, pourquoi ces objectifs étaient importants et comment cela s'applique à nous aujourd'hui. La complexité de ZFS a engendré beaucoup de confusion et de malentendus quant à la manière dont le système de fichiers fonctionne et au moment où il est approprié de l'utiliser.

Les principaux objectifs de ZFS étaient de créer un système de fichiers capable de bien s'adapter à de très grandes grappes de disques. Au moment de son introduction, l'échelle que ZFS était capable d'atteindre était inédite dans les autres systèmes de fichiers, mais il n'y avait aucun besoin concret qu'un système de fichiers puisse croître à ce point. Le temps que le besoin se fasse sentir, de nombreux autres systèmes de fichiers tels que NTFS, XFS, Ext3 et d'autres avaient évolué pour répondre à ce besoin. ZFS a certes mené la charge vers la gestion de systèmes de fichiers plus grands, mais a été rejoint par bien d'autres peu après.

Parce que ZFS est né dans le monde de Solaris où, comme tous les systèmes UNIX sur gros matériel, il n'existe pas de RAID matériel, il fallait recourir au RAID logiciel. Solaris avait toujours disposé d'un RAID logiciel sous la forme de son propre sous-système. La décision a été prise de construire une nouvelle implémentation de RAID logiciel directement dans ZFS. Cela permettrait de simplifier la gestion grâce à un jeu d'outils unique, à la fois pour la couche RAID et pour le système de fichiers. Cela n'a introduit aucun changement ni avantage significatif à ZFS, comme on le croit souvent, cela a simplement déplacé l'interface de la couche RAID logiciel, qui passait d'un jeu de commandes distinct à une partie du jeu de commandes ZFS.

L'implémentation du RAID par ZFS a introduit des bandes de largeur variable dans les niveaux de RAID à parité. Cette innovation a comblé un risque mineur du RAID à parité connu sous le nom de “write hole” (trou d'écriture). Cette innovation était très appréciable mais est arrivée très tard, car l'ère du RAID à parité fiable commençait à toucher à sa fin et le problème du write hole était déjà considéré comme un risque de “bruit de fond” non évoqué des grappes à parité, car il n'était généralement pas considéré comme une menace du fait de son élimination grâce à l'utilisation de caches de grappe sauvegardés par batterie et, à peu près à la même époque, de caches de grappe non volatils – évitez la perte d'alimentation et vous évitez le write hole. ZFS devait traiter ce problème car, en tant que RAID logiciel, il était plus exposé au write hole que ne l'est le RAID matériel, parce qu'il n'y a aucune possibilité de cache protégé contre la perte d'alimentation – le RAID matériel offre la possibilité d'une couche supplémentaire de protection contre les coupures de courant pour les grappes.

La véritable “innovation” que ZFS a réalisée par inadvertance, c'est qu'au lieu de simplement implémenter les niveaux de RAID habituels que sont les niveaux 1, 5, 6 et 10, il a au contraire “rebaptisé” ces niveaux selon ses propres conventions de dénomination. Le RAID 5 est connu sous le nom de RAIDZ. Le RAID 6 est connu sous le nom de RAIDZ2. Le RAID 1 est simplement connu sous le nom de mise en miroir. Et ainsi de suite. Cela a été largement considéré comme ridicule à l'époque et inutilement déroutant mais, en fin de compte, cette confusion est devenue la pierre angulaire du renouveau de ZFS bien des années plus tard.

Il convient de noter que ZFS a plus tard ajouté la première implémentation en production de l'industrie d'un système RAID 7 (alias RAID 7.3) à triple parité et l'a rebaptisé RAIDZ3. Cet ajout ultérieur est une innovation importante pour les grappes à grande échelle qui ont besoin d'une capacité maximale tout en restant extrêmement sûres mais sont prêtes à sacrifier les performances pour y parvenir. Cela demeure une fonctionnalité unique de ZFS mais une fonctionnalité rarement utilisée.

Dans l'esprit de l'effondrement de la pile de stockage et de l'utilisation d'un jeu de commandes unique pour gérer tous les aspects du stockage, les fonctions de gestion de volumes logiques ont également été intégrées à ZFS. On croit souvent à tort que ZFS a introduit la gestion de volumes logiques dans certains milieux, mais presque toutes les plateformes d'entreprise, y compris AIX, Linux, Windows et même Solaris lui-même, disposaient déjà de la gestion de volumes logiques depuis de nombreuses années. ZFS ne faisait pas cela pour introduire un nouveau paradigme, mais simplement pour consolider la gestion et regrouper les trois couches de stockage clés (RAID, gestion de volumes logiques et système de fichiers) en une seule entité qui serait plus facile à gérer et pourrait assurer des communications intrinsèques de haut en bas de la pile. Il y a des avantages et des inconvénients à cette méthode et l'avis du secteur reste non formé près d'une décennie plus tard.

L'un des aspects les plus importants de cette consolidation de trois systèmes en un seul est que nous avons désormais un produit très déroutant à aborder. ZFS est un système de fichiers, oui, mais ce n'est pas uniquement un système de fichiers. C'est un gestionnaire de volumes logiques, mais pas uniquement un gestionnaire de volumes logiques. Les gens désignent ZFS comme un système de fichiers, ce qui est sa fonction principale, mais le fait qu'il soit bien plus qu'un système de fichiers peut prêter à grande confusion et rend les comparaisons avec d'autres systèmes de stockage difficiles. À l'époque, je crois que cette confusion n'avait pas été anticipée.

Ce qui a résulté de cette fusion déroutante, c'est que ZFS est souvent comparé à d'autres systèmes de fichiers, tels que XFS ou Ext4. Mais c'est déroutant, car ZFS est une pile complète tandis que XFS n'est qu'un aspect d'une pile. ZFS serait mieux comparé à MD (RAID logiciel Linux) / LVM / XFS ou à SmartArray (RAID matériel HP) / LVM / XFS qu'à XFS seul. Sinon, il apparaît que ZFS regorge de fonctionnalités dont XFS est dépourvu mais, en réalité, ce n'est qu'une victoire sémantique. La plupart des fonctionnalités souvent vantées par les défenseurs de ZFS n'ont pas vu le jour avec ZFS et étaient couramment disponibles avec les systèmes de fichiers alternatifs bien avant l'existence de ZFS. Mais il est difficile de comparer “votre système de fichiers fait-il cela” car la réponse est “non…. ce sont mon RAID ou mon gestionnaire de volumes logiques qui font cela.” Et en vérité, ce n'est pas ZFS le système de fichiers qui fournit RAIDZ, c'est ZFS le sous-système de RAID logiciel qui le fait.

Afin de gérer avec élégance de très grands systèmes de fichiers, des fonctionnalités d'intégrité des données ont été intégrées à ZFS, ce qui comprenait une somme de contrôle ou un contrôle de hachage à travers tout le système de fichiers, capable de tirer parti du RAID logiciel inclus pour réparer les fichiers corrompus. Cela était jugé nécessaire en raison de la taille anticipée des systèmes de fichiers ZFS à l'avenir. La corruption d'un système de fichiers est un phénomène rarement observé, mais à mesure que les systèmes de fichiers croissent en taille, le risque augmente. Cette fonctionnalité moins connue de ZFS est possiblement sa plus grande.

ZFS a également changé la manière dont sont gérées les vérifications de système de fichiers. En raison de l'hypothèse selon laquelle ZFS serait utilisé sur de très grands systèmes de fichiers, il existait une crainte réelle qu'une vérification de système de fichiers au démarrage puisse prendre un temps impossiblement long à s'achever, et une stratégie alternative a donc été trouvée. Au lieu d'attendre d'effectuer une vérification au redémarrage, le système exigerait l'exécution d'un processus de nettoyage (scrubbing) afin de réaliser une vérification similaire pendant que le système est en fonctionnement. Cela nécessite davantage de surcharge système pendant que le système est actif, mais le système est en mesure de se rétablir plus rapidement après un redémarrage inattendu. Un compromis, mais un compromis largement perçu comme très positif.

ZFS dispose de puissantes capacités de capture instantanée (snapshot) dans sa couche de volumes logiques et, dans sa couche RAID, a implémenté des mécanismes de mise en cache très robustes, faisant de ZFS un excellent choix pour de nombreux cas d'usage. Ces fonctionnalités ne sont pas uniques à ZFS mais sont largement disponibles dans des systèmes plus anciens que ZFS. Ce sont cependant de très bonnes implémentations de chacune et très bien intégrées du fait de la nature de ZFS.

À une époque, ZFS était open source et, durant cette ère, son code est devenu une partie des systèmes d'exploitation Mac OSX d'Apple et FreeBSD, parce qu'ils étaient compatibles avec la licence de ZFS. Linux n'a pas obtenu ZFS à cette époque en raison de difficultés liées à la licence. Si la licence de ZFS avait permis à Linux de l'utiliser sans entrave, le paysage de Linux serait vraisemblablement très différent aujourd'hui. Mac OSX a fini par abandonner ZFS, car on ne lui voyait pas assez d'avantages pour le justifier dans cet environnement. FreeBSD s'est accroché à ZFS et, au fil du temps, il est devenu le système de fichiers le plus populaire sur la plateforme, bien qu'UFS soit encore lourdement utilisé également. Oracle a fermé le code source de ZFS après le rachat de Sun, laissant FreeBSD sans mises à jour continues de sa version de ZFS, tandis qu'Oracle a poursuivi le développement de ZFS en interne pour Solaris.

Aujourd'hui, Solaris continue d'utiliser l'implémentation originale de ZFS, désormais avec plusieurs mises à jour depuis sa séparation d'avec la communauté open source. FreeBSD et d'autres ont continué d'utiliser ZFS dans l'état où il se trouvait lorsque le code a été fermé, n'ayant plus accès aux dernières mises à jour d'Oracle. Finalement, le travail de mise à jour de la base de code ZFS open source abandonnée a été repris et est désormais connu sous le nom d'OpenZFS. OpenZFS est encore balbutiant et n'a pas encore vraiment marqué de son empreinte, mais a un certain potentiel pour revitaliser la plateforme ZFS dans l'espace open source ; toutefois, à l'heure actuelle, OpenZFS accuse encore un retard sur ZFS.

Le développement open source de ces dernières années dans cet espace s'est davantage concentré sur le nouveau rival de ZFS, BtrFS, qui est développé nativement sous Linux et est bien pris en charge par de nombreux grands éditeurs de systèmes d'exploitation. BtrFS est très récent mais réalise des progrès majeurs pour atteindre la parité fonctionnelle avec ZFS sur les fonctionnalités implémentées, tout en nourrissant de grandes ambitions et, du fait de la nature fermée du code source de ZFS, il bénéficie d'une dynamique de marché. BtrFS a été lancé, comme ZFS, par Oracle et a été largement perçu comme la vision de l'avenir selon Oracle, étant un remplaçant de ZFS, y compris chez Oracle. À l'heure actuelle, BtrFS a déjà, comme ZFS, fusionné les couches du système de fichiers, de la gestion de volumes logiques et du RAID logiciel, implémenté la somme de contrôle pour l'intégrité du système de fichiers, s'adapte à une échelle encore plus grande que ZFS (même limite absolue mais gère davantage de fichiers), des captures instantanées en copie sur écriture (copy on write), etc.

ZFS était, sans aucun doute, un système de fichiers remarquable à son apogée et demeure un leader aujourd'hui. J'en étais un partisan en 2005 et j'y crois encore fortement. Mais il m'a attristé de voir la communauté autour de ZFS adopter une ferveur et un zèle qui ne lui rendent pas service et font presque paraître la mention de ZFS comme négative – ZFS étant si universellement choisi pour les mauvaises raisons : principalement la croyance que ses fonctionnalités n'existent nulle part ailleurs, que son RAID n'est pas soumis aux risques et aux limitations auxquels ces niveaux de RAID sont toujours soumis, ou qu'il a été conçu dans un but différent (principalement la performance) de celui pour lequel il a été conçu. Et lorsque ZFS est un bon choix, il est souvent mal implémenté sur la base d'hypothèses fausses.

ZFS, bien entendu, n'est pas à blâmer. Ni, pour autant que je puisse en juger, ses soutiens corporatifs ou ses développeurs open source. Là où ZFS semble avoir dévié, c'est au sein d'une communauté informelle et diffuse qui n'a découvert ZFS que récemment, croyant souvent qu'il était nouveau ou de “nouvelle génération” parce qu'elle ne l'a découvert que récemment. D'après ce que j'ai vu, ce n'est presque jamais par le biais des canaux Solaris ou FreeBSD, mais presque exclusivement par de plus petites entreprises cherchant à utiliser un “OS pour NAS” packagé comme FreeNAS ou NAS4Free, qui ne sont pas familières des OS UNIX. L'utilisation d'OS pour NAS packagés, principalement par des services informatiques qui ne possèdent ni de solides compétences UNIX ni de solides compétences en stockage et, par conséquent, peu d'exposition au monde plus large des systèmes de fichiers en dehors de Windows, et souvent peu ou pas d'exposition à la gestion de volumes logiques et au RAID, en particulier au RAID logiciel, semble conduire à une culture du “mythe” autour de ZFS, lui conférant un statut quasi incontestable et infaillible.

Cet engouement de type sectaire et l'incompréhension générale de ZFS conduisent souvent à des applications inappropriées de ZFS ou à un enchaînement de prises de décision fondées sur de mauvaises hypothèses qui peuvent fourvoyer très largement.

L'un des changements les plus stupéfiants dans cet espace est le changement d'allégeance, du RAID matériel vers le RAID logiciel. Traditionnellement, le RAID logiciel était un paria dans les milieux de l'administration Windows sans bonne raison – les administrateurs Windows et les petites entreprises, souvent peu familiers des plus grands serveurs UNIX, croyaient que le RAID matériel était omniprésent alors que, en réalité, les systèmes à plus grande échelle ont toujours utilisé le RAID logiciel. Le RAID matériel était, à l'échelle de presque toute l'industrie, considéré comme une nécessité et le RAID logiciel complètement évité. Ce même public, désormais confronté au mouvement du “culte de ZFS”, réagit maintenant exactement de manière opposée en croyant que le RAID matériel est mauvais et que le RAID logiciel de ZFS est la seule option viable. Le revirement est spectaculaire et aucune des deux approches n'est valable – le RAID matériel comme le RAID logiciel, et les deux dans de nombreuses implémentations, sont des options tout à fait valables et, même en utilisant ZFS, le recours au RAID matériel pourrait aisément être approprié.

ZFS est souvent choisi parce que l'on croit qu'il s'agit de l'option la plus performante en matière de systèmes de fichiers, mais cela n'a jamais été un objectif de conception clé de ZFS. Les fonctionnalités lui permettant de s'adapter à une si grande échelle et de gérer tant d'aspects différents du stockage rendent en réalité très difficile d'être hautement performant. ZFS, au moment de sa création, n'était même pas censé être aussi rapide que le vénérable UFS qui tournait sur les mêmes systèmes que lui. Cependant, cela est souvent secondaire par rapport au fait que la performance d'un système de fichiers est largement sans importance, car tous les systèmes de fichiers modernes sont extrêmement rapides et la vitesse d'un système de fichiers est rarement un facteur important – surtout en dehors des systèmes de stockage massifs et haut de gamme à très grande échelle.

Une étude intéressante de dix systèmes de fichiers sous Linux produite par Phoronix en 2013 a montré des différences massives entre les systèmes de fichiers selon la charge de travail, mais aucun vainqueur clair en ce qui concerne la performance globale. Ce que l'étude a démontré de manière concluante, c'est que faire correspondre la charge de travail au système de fichiers est le choix le plus important, que ZFS se situe du côté le plus lent de tous les systèmes de fichiers grand public, même dans ses implémentations plus modernes, et que choisir un système de fichiers pour des raisons de performance sans une compréhension très approfondie de la charge de travail aboutira à des performances imprévisibles – aucun système de fichiers ne devrait être choisi à l'aveugle si la performance est un facteur important. Malheureusement, parce que le test a été réalisé sous Linux, il manquait UFS, qui est souvent le concurrent clé de ZFS, en particulier sous Solaris et FreeBSD, et il manquait HFS+ de Mac OSX.

Passer du RAID matériel au RAID logiciel comporte des risques supplémentaires, souvent imprévus, pour les services peu expérimentés en UNIX également. Bien que ZFS permette le remplacement à chaud (hot swap), on oublie souvent que le hot swap est avant tout une fonctionnalité du matériel, et non du logiciel, et il est également largement méconnu que le remplacement à l'aveugle (blind swapping, le retrait de disques durs sans les avoir d'abord mis hors ligne dans le système d'exploitation) n'est pas synonyme de hot swap, et cela peut conduire à des catastrophes pour les services passant d'une tradition de RAID matériel qui gérait pour eux de manière transparente la compatibilité, le hot swap et le blind swapping, à un système de RAID logiciel qui exige bien plus de planification, de coordination et de compréhension du système pour être utilisé en toute sécurité.

Une idée fausse moindre, mais néanmoins courante, à propos de ZFS, est qu'il s'agirait d'un système de fichiers en grappe (clustered) adapté à une utilisation sur des scénarios de DAS partagé ou de SAN à la OCFS, VxFS et GFS2. ZFS n'est pas un système de fichiers en grappe et partage les mêmes limitations dans cet espace que tous ses concurrents habituels.

ZFS peut être un excellent choix mais il est loin d'être le seul. ZFS s'accompagne d'importantes réserves, dont la moindre n'est pas les limitations de système d'exploitation qui lui sont associées, et bien qu'il présente de nombreux avantages, peu, voire aucun, ne sont propres à ZFS, et il est très rare qu'un service tire profit de chacun d'entre eux. Comme pour toute technologie, il y a des compromis à faire. Une taille unique ne convient pas à tous. La clé pour savoir quand ZFS est fait pour vous est de comprendre ce qu'est ZFS, ce qui est unique ou non en lui, quels sont ses objectifs de conception, comment comparer un système de stockage à un système de fichiers pur produit des résultats trompeurs et quelles limitations inhérentes y sont liées.

ZFS est une considération clé et le choix courant lorsque Solaris ou FreeBSD est le système d'exploitation retenu. À de rares exceptions près, le système d'exploitation ne devrait jamais être choisi pour ZFS, mais au contraire ZFS devrait être souvent choisi, mais pas toujours, lorsque le système d'exploitation est choisi. L'OS devrait dicter les choix de système de fichiers dans tous les cas, sauf les plus rares. Le choix du système d'exploitation est tellement plus important que le choix du système de fichiers.

ZFS peut être utilisé sous Linux mais n'y est pas considéré comme une option d'entreprise, davantage comme un système de loisir destiné à l'expérimentation, car aucun éditeur d'entreprise (tel que Red Hat, Suse ou Canonical) ne prend en charge ZFS sous Linux et parce que Linux dispose déjà d'excellentes alternatives. Un jour, ZFS pourrait être promu au rang de système de fichiers de première classe sous Linux, mais cela n'est pas attendu, car BtrFS est déjà entré dans le noyau principal (mainline) et a été inclus dans les versions de production par plusieurs grands éditeurs.

Bien que l'on rencontre ZFS dans la grande majorité des déploiements Solaris et FreeBSD, c'est principalement parce qu'il est passé à la position de système de fichiers par défaut et non parce qu'il est manifestement le choix supérieur dans ces cas ou qu'il a même été évalué de manière critique. ZFS est parfaitement bien adapté à un rôle de système de fichiers à usage général là où il est natif et pris en charge.

Quel est le principal cas d'usage de ZFS ?

L'objectif de conception et le principal cas d'usage de ZFS concernent les systèmes de stockage ouvert Solaris et FreeBSD, fournissant soit du stockage partagé à d'autres serveurs, soit servant de dépôts de données massifs pour des applications installées localement. Dans ces cas, l'accent que ZFS met sur l'évolutivité et l'intégrité des données prend vraiment tout son éclat. ZFS penche fortement vers les grands services et les services à l'échelle de l'entreprise et, de manière générale, s'éloigne de toute pertinence dans l'espace des petites et moyennes entreprises, où les compétences en Solaris et FreeBSD, ainsi que les besoins de stockage à grande échelle, sont rares.

Référence : http://www.phoronix.com/scan.php?page=article&item=linux_310_10fs&num=1