OpenZFS : pourquoi cette technologie de stockage open source continue-t-elle de séduire ?

Temps de lecture estimé : 14 minute(s)

Les 24 et 25 octobre derniers s’est tenu le 5e OpenZFS Developer Summit à San Francisco, avec le soutien d’OVH. OpenZFS, qui fête ses 12 ans, est une technologie que nous exploitons à grande échelle depuis 2011, pour le stockage des données de l’hébergement web, des e-mails, VPS, NAS HA, du Private Cloud ou encore du Backup Storage. François Lesage et Alexandre Lecuyer, ingénieurs stockage chez OVH, ont naturellement fait le déplacement en Californie pour échanger avec la communauté OpenZFS à propos du futur de la technologie.

Les 24 et 25 octobre derniers s’est tenu le 5e OpenZFS Developer Summit à San Francisco, avec le soutien d’OVH.

Filesystem VS object storage : pourquoi avons-nous besoin des deux ?

À l’heure où l’on ne jure plus que par l’object storage (OpenStack Swift, Ceph…), il peut sembler surprenant de constater la vivacité de la communauté qui s’active autour d’OpenZFS et continue à en étendre les fonctionnalités, année après année. À première vue, l’object storage a tout pour plaire : distribué, donc hautement disponible et scalable à l’infini, mais aussi économique, puisqu’il s’appuie sur du matériel standard (serveurs dotés d’une architecture x86 et disques durs classiques). La force du système repose alors sur le (grand) nombre de machines, davantage que sur la puissance et la capacité unitaire de chaque élément de la grappe. On gomme ainsi les effets palier, qui rendent les filesystems coûteux en raison de la nécessité de provisionner, pour augmenter les capacités de stockage, de nouveaux châssis dotés de disque de grande capacité, lesquels mettront un certain temps avant d’être remplis et donc rentabilisés (scale up).

Reste que, par l’utilisation massive du sharding (distribution des fichiers entre plusieurs nœuds du cluster, voire des différents blocs/segments d’un même fichier), l’object storage offre des latences qui n’égalent pas celles d’un filesystem traditionnel, hébergé en local ou sur un NAS. Si bien que pour certains usages, par exemple les systèmes de gestion de base de données (SGBD) constamment sollicités par de multiples opérations de lecture/écriture, l’object storage ne convient pas – raison pour laquelle les infrastructures entièrement basées sur le public cloud recourent pour les bases de données au stockage local au sein de la VM ou via un blockstorage, ou encore à un service de Database as a service.

À l’inverse, l’object storage convient parfaitement pour stocker et servir des fichiers lourds, photos ou vidéo par exemple. La latence sera alors compensée par une vitesse de téléchargement accélérée par le design distribué de l’object storage (plusieurs machines seront mises à contribution en parallèle pour servir le fichier). En outre, un système de cache peut être placé en amont, pour servir instantanément les fichiers les plus demandés.

Enfin, s’il est possible de coder un système de fichier (filesystem) virtuel par-dessus un object storage (ce qui est en réalité souvent le cas, puisque beaucoup d’applications sont conçues pour fonctionner avec un filesystem), une technologie telle qu’OpenZFS offre des fonctionnalités que n’offrent pas les solutions d’object storage – revers de la médaille de leur extrême simplicité.

Ainsi, la réputation d’OpenZFS doit beaucoup à des fonctionnalités avancées telles que la réplication, la déduplication, la compression, la possibilité de créer des clones (des snapshots du système, modifiables), le partage de données entre différents systèmes, le verrouillage des données dans le cas d’un cluster dont les composants doivent être synchronisés en temps réel, ou encore la protection et correction des données, avec un système de vérification d’intégrité qui empêche toute corruption silencieuse des fichiers. Le tout avec des performances et une stabilité inégalée lorsque la technologie est opérée à grande échelle, comme c’est le cas chez OVH. Certains prêtent d’ailleurs à l’acronyme ZFS la signification « Zettabyte File System ». Une unité de mesure qui paraissait folle dans les années 2000… et sera bientôt usuelle pour des opérateurs comme OVH (trois lettres auxquelles on prête aussi plusieurs significations apocryphes… mais gardons-nous de dissiper le mystère).

OpenZFS : des infrastructures sur site des entreprises au cloud

Il y a quelques années encore, les entreprises se tournaient quasi unanimement vers des solutions de stockage dont le hardware comme le software sont propriétaires. Des systèmes performants et robustes, qui ont l’avantage indiscutable de rassurer les utilisateurs et leur hiérarchie quant à la pérennité des données. Quand bien même le prix à payer est élevé. Aujourd’hui, la donne a changé. Des sociétés comme Facebook exploitent OpenZFS (et y contribuent, notamment pour améliorer les algorithmes de compression) et même des industries comme l’assurance, la banque ou encore le cinéma ont déployé des infrastructures de stockage fonctionnant avec cette technologie. D’une part cela réduit drastiquement les coûts, dans un contexte où la production de données explose. D’autre part, les systèmes propriétaires constituent de véritables boîtes noires, au sens où il n’est pas possible ni de savoir comment fonctionne le code, ni de le modifier soi-même. Or, le stockage est devenu une brique des infrastructures que l’on veut pouvoir adapter selon sa stratégie, ses besoins spécifiques. Le succès d’OpenZFS peut aussi se lire dans le fait d’être intégré par défaut à Ubuntu, depuis la version 16.04 sortie en 2016.

On voit donc de plus en plus d’entreprises remplacer leurs baies de stockage propriétaires par des plateformes sous OpenZFS sur site. La prochaine étape est dans doute de déporter tout ou partie de ce stockage dans le cloud, c’est-à-dire chez un cloud provider tel qu’OVH, qui propose via son offre de NAS-HA de l’OpenZFS as a service.

De plus en plus d’entreprises remplacent leurs baies de stockage propriétaires par des plateformes sous OpenZFS.

ZFS et Open ZFS : vers la réconciliation ?

L’openZFS Developer Summit a été le théâtre d’une annonce plutôt inattendue de la part de Mark Maybee, architecte en chef de la technologie ZFS chez Oracle. Ce dernier a en effet déclaré vouloir réconcilier la technologie de stockage ZFS, dont Oracle a refermé le code peu après en avoir hérité lors du rachat de Sun en 2009, et sa branche libre, OpenZFS. Ceci pour mutualiser les efforts de développement et pérenniser la technologie en faisant de ZFS un composant upstream de Linux, et donc le fondement des systèmes de stockage, qu’ils soient de l’object storage ou non.

Malheureusement, il semble que ce projet ait du plomb dans l’aile, étant donné le licenciement récent de Mark Maybee par Oracle, si l’on en croit le compte Twitter de Bryan Cantrill :

L’OpenZFS Developer Summit a d’ailleurs montré qu’un certain nombre de sociétés développent aujourd’hui des services propriétaires sur la base d’OpenZFS, avec le risque de fork. Néanmoins, cet événement a surtout été l’occasion de découvrir des améliorations signifiantes de la technologie, des POC aussi surprenants que prometteurs… et d’imaginer, avec une certaine impatience, comment ces avancées pourraient être mises en application chez OVH. Un exercice auquel nous nous étions déjà prêté en 2015, alors que nous avions présenté à l’OpenZFS Developer Summit un patch pour migrer des données sans downtime.

Passage en revue des principales annonces de l’OpenZFS Developer Summit 2017

L’OpenZFS Developer Summit été l’occasion de découvrir des améliorations signifiantes de la technologie et d’imaginer comment ces avancées pourraient être mises en application chez OVH.

Amélioration de la sécurité


MMP : Safe « zpool import » for Clusters

Ajout de sécurités pour éviter l’importation d’un même pool sur deux machines, ce qui peut casser le pool.
Application possible chez OVH : sécuriser la bascule d’un datastore à l’autre en cas de défaillance hardware (dans le cadre de l’offre Private Cloud). Dans le cas où la coupure des liens SAS n’est pas possible matériellement, ce pourrait être une alternative.

DRAID : une alternative au RAIDZ

Intel propose une alternative à RAIDZ (le dispositif de RAID natif d’OpenZFS). L’avantage principal est d’accélérer énormément la vitesse de reconstruction d’un pool après une panne de disque(s). La contrainte est que le DRAID utilise un peu plus de place (il y a du padding pour que les données et la parité arrivent toujours sur les mêmes disques). C’est un très gros développement, qui touche à sa fin et devrait être commité d’ici peu.
Application possible chez OVH : ce sera sans doute très intéressant dans le cadre des pools de backup, ainsi que pour les sites miroirs mis à disposition par OVH (voir encadré en fin d’article). L’idée est qu’en reconstruisant un disque plus rapidement,  nous sommes en situation de risque potentiel moins longtemps. Le patch est déjà disponible sur le wiki du projet.

Amélioration de la vitesse de reconstruction d’un disque (resilver)

Reconstruction plus rapide d’un disque après un remplacement, en générant des IO séquentielles plutôt qu’aléatoires. Une file des écritures nécessaires est générée et triée par emplacement sur le disque (offset). De cette façon, les opérations d’écriture nécessitent moins de déplacements de la tête de lecture sur le disque et la reconstruction est accélérée. La redondance est retrouvée plus rapidement. La date de publication du patch n’a pas été annoncée.

Storage pool checkpoint

Permet de faire un checkpoint d’un pool entier, y compris de ses propriétés.
Application possible chez OVH : amélioration de la sécurité avant une opération à risque pour le pool, avec la possibilité d’un rollback à l’échelle si une migration se passe mal.

Amélioration de la performance


ZStandard compression

OpenZFS permet d’appliquer une compression aux fichiers stockés, avec plusieurs algorithmes au choix, offrant un gain jusqu’à 80 % d’espace suivant le type de fichier. ScaleEngine, en collaboration avec Facebook, a développé un nouvel algorithme de compression très rapide, comme LZ4, mais avec une efficacité de compression proche de gzip.
Application possible chez OVH : optimisation des pools de backup, en contrepartie d’une surconsommation de ressource CPU.

Fast Clone Deletion

Accélération de la suppression des clones (snapshots modifiables), via la création d’une liste des blocks utilisés par un clone, pour ne pas avoir à tous les parcourir.
Application possible chez OVH : cloner les VM du Private Cloud (OpenZFS étant la technologie utilisée pour les datastore) avec intégration VAAI.

Faster allocation with the log spacemap

Si ZFS doit allouer/désallouer de l’espace un peu partout sur un disque, cela génère beaucoup d’IO : à chaque région du disque correspond une space map. Si les opérations de lecture/écriture sont réalisées sur beaucoup de régions, cela génère beaucoup d’IO aléatoires.
L’idée est de garder l’information en RAM, et d’écrire un log unique pour toutes les spacemap, qui servira uniquement à se récupérer en cas de crash. La mise à jour des spacemaps sur disques est faite ainsi : une spacemap est mise à jour à chaque transaction group (TXG).
Application possible chez OVH : amélioration des performances, surtout lors de suppression massives de données. Le patch n’est pas encore disponible. Probablement courant 2018.

iFlash: Dynamic adaptive L2ARC caching
Sur une plateforme OpenZFS, il est possible d’utiliser un disque SSD pour faire du cache et accélérer les opérations d’IO. La contrainte est que la taille de cet espace de cache, ainsi que celle du ZIL (ZFS Intent log, qui est le cache pour les écritures synchrones pour simplifier), doivent être définies par avance pour chacun des clients de la plateforme. Un fabricant de baie de stockage a réalisé un développement propriétaire permettant une allocation dynamique de cet espace de cache sur le disque flash.
Potentiellement très intéressant pour OVH, car on a le même use case sur NAS, mais c’est un développement propriétaire basé sur une version de ZFS de 2013.

ZIL Performance
Aujourd’hui, quand une application réalise un fsync(), toutes les écritures synchrones en attente doivent être écrites. Ce patch améliore la granularité et le parallélisme des écritures synchrones dans le ZIL. Le développement n’est pas terminé, mais cela devrait arriver upstream courant 2018.
Application possible chez OVH : amélioration des performances de pas mal de workload, notamment sur le Private Cloud, dont l’architecture avec deux datastores redondants nécessite beaucoup d’écritures synchrones.

 

Améliorations opérationnelles


« Oh Shift! » : changer l’allocation size
Aujourd’hui il est impossible de changer l’allocation size (alignement du pool) après sa création. Cela pose de gros problèmes de performance, dans le cas où, au sein d’un pool créé sur 512 bytes, des disques en panne sont remplacés par des disques 4K, qui font de l’émulation 512 bytes, à cause du read modify write. Le patch permettra d’aligner les écritures sur une taille supérieure, à chaud.
Application possible chez OVH : nous ne serons plus contraints de veiller à l’allocation size des disques lors des remplacements de disque, sans quoi pouvaient se poser des problèmes de performances.

RAID-Z expansion
Possibilité d’ajouter des disques à un vdev RAID-Z. Ça n’a l’air de rien, mais c’est une grande avancée : jusqu’à présent, ajouter un disque à un pool existant n’était pas simple. Ce développement est un (petit) pas vers plus de scalabilité.
Application possible chez OVH : limitée, car nous réalisons peu d’ajouts de disque a posteriori.

Accélération par 1000 de la vitesse de la déduplication

Ce projet consiste à changer le format sur disque de la table de déduplication pour limiter très fortement les opérations de lecture/écriture engendrées par la déduplication. Un log remplace la table de hachage. L’arbre est construit en RAM à partir du log sur disque quand le pool est importé. Si cela ne tient pas en RAM, la déduplication est désactivée pour les nouveaux blocs.
Intérêt pour OVH : autant le dire, la déduplication (optimisation des fichiers présents en doublon sur une infrastructure) n’est aujourd’hui pas utilisable. Trop instable et trop risqué à notre échelle. Si ce projet aboutit, un test pourrait être envisagé, mais cela nécessiterait des machines très bien dotées en RAM.

Open ZFS sur OS X et Windows 10 :
Un développeur a porté le code d’OpenZFS sous Mac OSX et … sous Windows 10 ! Jolie performance, mais nous ne voyons pas d’application chez OVH pour l’instant… 🙂


Les miroirs OVH : une utilisation typique d’OpenZFS pour du stockage massif

 

Depuis longtemps, OVH héberge ses propres sites miroirs, depuis lesquels il est possible de télécharger les distributions open source telles que Debian, Ubuntu ou encore Postfix, OpenCSW (il existe une centaine de miroirs au total). Maintenir ces sites est une façon de contribuer aux différentes communautés. En proposant des alternatives au site de téléchargement principal, cela soulage les serveurs de la communauté et allège les besoins en termes de ressources informatiques et bande passante. Et c’est également depuis ces sites miroirs que sont téléchargé.e.s les distributions et packages lorsque les utilisateurs de services OVH demandent leur pré-installation sur leurs machines.

Pour cela, nous stockons plus de 40 To sous OpenZFS, avec une triple réplication (pour disposer de copies géographiquement proches de nos datacenters et ainsi offrir des temps de téléchargement réduits). Sur cette plateforme de stockage, les snapshots sont intensivement utilisés pour mettre à disposition des images connues et testées, tout en proposant les dernières releases en temps réel.

Copywriter at OVH.