Pourquoi OVH mise sur OpenZFS

Temps de lecture estimé : 10 minute(s)

*Attention, ce contenu a été publié il y a 3 années. Il n'est peut-être plus d'actualité.*

Les 19 et 20 octobre derniers s’est tenu l’OpenZFS Developer Summit à San Francisco. Utilisé jusque-là de façon relativement discrète par les acteurs IT, OpenZFS fête ses dix ans et son adoption s’amplifie. En témoigne le recours à cette technologie open source pour stocker les douze pétaoctets de rushes du film Gravity (1), ou encore son intégration à la dernière release d’Ubuntu, en tant que file system natif. OVH, qui a commencé à utiliser OpenZFS en 2009, a envoyé au Developer Summit deux représentants de son équipe Storage. Pour prendre connaissance des annonces, mais également pour proposer une contribution au projet : « Live migration with Zmotion ». Explications et tour d’horizon des présentations à retenir avec François Lesage et Alexandre Lecuyer, ingénieurs stockage.

L’OpenZFS Developer Summit de San Francisco a rassemblé une centaine de développeurs, venus du monde entier.
L’OpenZFS Developer Summit de San Francisco a rassemblé une centaine de développeurs, venus du monde entier.

OVH propose un patch pour migrer des données sans downtime

OpenZFS est issu du projet ZFS commandité par Sun Microsystems (racheté par Oracle en 2009). Il en est devenue un dérivé (fork) en 2005, porté par une communauté indépendante qui rassemble notamment des anciens de Sun.
En dehors de Netflix, qui exploite OpenZFS pour sa plateforme Titan (2), peu d’acteurs IT importants revendiquent l’utilisation d’OpenZFS, dont la fiabilité est pourtant désormais éprouvée.
Les fabricants spécialistes du stockage « traditionnel » proposent des solutions propriétaires performantes et robustes, qui ont l’avantage indéniable de rassurer les utilisateurs sur la pérennité de leurs données. « L’inconvénient, avance François, c’est le prix à payer. Ces systèmes tournent sur du matériel spécifique, ce qui fait flamber le coût du gigaoctet, et ils 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. » Compatible avec des machines standards (architecture x86), OpenZFS permet de réduire drastiquement le coût du stockage. En outre, le code étant ouvert, OVH a pu l’adapter, l’améliorer. « Dix ans après le lancement du projet, la stabilité d’OpenZFS est très satisfaisante, poursuit François. Son système de vérification d’intégrité des données, qui empêche toute corruption silencieuse des fichiers, est parmi les plus efficaces. Et par ailleurs, la couverture fonctionnelle d’OpenZFS est très riche : snapshot, stockage chaud comme froid… »
En 2007, OVH a délaissé EXT3 au profit de ZFS . Puis s’est intéressé dès 2009 à OpenZFS. Les premiers projets en production sous OpenZFS ont vu le jour fin 2011 et cette technologie est aujourd’hui sous-jacente à un grand nombre de services d’OVH.com : e-mails, hébergement web, VPS Classic, NAS-HA, Dedicated Cloud, Backup Storage, etc. « À cette époque, la technologie était déjà mature, et l’expertise que nous avons acquise sur cette technologie nous permettait de rivaliser en efficacité avec les systèmes de stockage propriétaires ». Cette expérience d’OpenZFS, c’est justement ce que sont venus partager François et Alexandre à San Francisco. « Notre présentation technique portait sur la migration de données sous OpenZFS. Notre activité d’hébergeur nous conduit à allouer et désallouer sans discontinuer des espaces de stockage (zpools), ce qui occasionne des problématiques de fragmentation. Pour cette raison notamment, nous devons régulièrement réaliser des migrations de données. OpenZFS ne permet malheureusement pas de réaliser ces opérations sans downtime, du fait de certaines contraintes liées à l’emploi de NFS dans nos infrastructures. Nous avons cherché, au moyen d’essais successifs, à résoudre ce problème. » Le patch écrit par Alexandre, appelé « Zmotion », a été relu lors d’un atelier de la communauté, dont faisait partie Matt Ahrens (cofondateur du projet ZFS). Il a été proposé pour commit upstream et est d’ores et déjà disponible sur Github . « Nous pensons qu’il intéressera de grandes entreprises, car la problématique des migrations de données est un sujet de discussion récurrent sur la mailing-list communautaire », explique Alexandre.

Voir la présentation « Live Migration with Zmotion » par OVH :

Visionnez également cette présentation sur SlideShare : slideshare.net/ovhcom/live-migration-of-openzfs-datasets-with-zmotion

9 contributions qui vont rendre OpenZFS encore meilleur

« D’une manière générale, les présentations des différents contributeurs étaient d’un très haut niveau technique, rapportent François et Alexandre. Elles constituent autant de promesses de fantastiques progrès pour OpenZFS, dont les utilisateurs vont pouvoir bénéficier à court, moyen et long termes. » Passage en revue des 9 contributions qui vont rendre OpenZFS encore plus puissant.

1- Compressed ARC (Adaptive Replacement Cache)
OpenZFS fonctionne avec un système de cache à deux niveaux (ARC et L2ARC), dans lequel sont stockées les données les plus fréquemment accédées. Le premier niveau de cache puise ses ressources dans la RAM, tandis que le second niveau est hébergé sur des disques — le plus souvent des SSD. La contribution de George Wilson (société Delphix) a pour but de rendre possible la compression/décompression à la volée des fichiers présents dans le premier niveau de cache, en RAM. Un fichier .txt verrait par exemple la place qu’il occupe dans le cache réduite par trois (pas de compression possible en revanche pour les formats déjà compressés, tels que le .jpeg). Résultat : il deviendrait possible d’accroître les performances du cache à coût constant. Disponibilité dans OpenZFS : court terme.

2 – Discontiguous caching with ABD
Le système de cache propre à OpenZFS, ARC, a un fonctionnement redondant avec le cache des OS, par exemple Page cache sur Linux. Cela signifie qu’un fichier est doublement mis en cache actuellement : une fois dans le cache d’openZFS et une seconde fois dans le cache de l’OS. Il en résulte une perte d’espace dans la RAM. La contribution de David Chen (société OSNexus) vise à permettre à openZFS d’exploiter les mécanismes de cache standard des OS. Disponibilité dans OpenZFS : moyen terme.

3 – Persistent L2ARC
Le mécanisme de cache de second niveau d’OpenZFS est particulièrement sophistiqué. Le choix des données mises en cache (sur des disques SSD le plus souvent, la production étant hébergée sur des disques à plateau moins rapides) est le fruit du travail de deux algorithmes concurrents, qui décident conjointement et en temps réel de la meilleure stratégie de conservation des données en fonction des requêtes effectuées. Ce mécanisme de cache a un point faible : en cas de reboot, le cache doit être reconstruit. Cette opération peut durer plusieurs heures (jusqu’à 24h dans le cas du cache d’un filer utilisé pour l’hébergement web/mutualisé d’OVH.com), avant de retrouver des performances maximales. La contribution de Saso Kiselkov (société Nexenta) permet de le conserver, ce cache chaud, même après redémarrage, en modifiant son format. Disponibilité dans OpenZFS : court terme sur Illumos.

4 – Writeback cache
L’idée de la contribution d’Alex Aizman (société Nexenta) est de mettre en place un mécanisme de mémoire tampon en écriture, distinct des volumes de logs dédiés. Par exemple, en cas de burst d’input, les données sont écrites sur un disque SSD, ou une carte PCI, puis déchargées de manière asynchrone sur le pool de disques à plateau. Disponibilité dans OpenZFS : inconnue.

5 – Compressed Send and Receive
La contribution de Dan Kimmel (société Delphix) consiste à envoyer directement le flux de données compressées lors d’un backup ou d’une migration. Cela permet de supprimer l’étape de décompression lors de l’envoi et de « recompression » lors de la réception. Résultat : la consommation de bande passante est réduite, le temps de backup accéléré et la sollicitation CPU pendant le backup est moindre. Disponibilité dans OpenZFS : court à moyen terme.

 

6 – Resumable ZFS send/receive
Cette contribution de Matthew Ahrens (société Delphix), présentée à Paris il y a six mois durant l’OpenZFS European Conference, rend possible la reprise d’un backup en l’état, en cas de coupure réseau durant le transfert des fichiers, ceci grâce à un token. Aujourd’hui, lorsqu’un backup subit une coupure, il est « redémarré » depuis zéro. Déjà disponible sur Illumos et FreeBSD, bientôt sur Linux.

7 – Parity Declustered RAID-Z/Mirror
Cette contribution d’Isaac Huang (société Intel) s’appuie sur des recherches poussées en mathématiques appliquées pour rendre la reconstruction d’un RAIDZ (le nom du type de RAID propre à OpenZFS) plus rapide en cas de perte d’un disque. Le volume des disques augmentant, le procédé de resilvering d’un RAIDZ prend parfois plusieurs jours, et il peut arriver qu’un second disque du RAIDZ tombe en panne alors que la reconstruction n’est pas achevée. Il y a alors un risque important de perdre des données. En optimisant la distribution des blocs de données sur les disques, ce projet – à l’état de R&D – permettrait de réduire considérablement le temps nécessaire à la reconstruction d’un RAID.

8 – Dedup Ceiling
La déduplication des données existe depuis longtemps dans OpenZFS. Dans les faits, elle est très peu utilisée, parce qu’elle peut s’avérer risquée lorsque l’on manipule un grand nombre de fichiers. La table de correspondance est stockée dans la RAM et, lorsque celle-ci devient trop volumineuse, le temps de réponse du système de déduplication augmente très fortement.
La contribution de Saso Kiselkov (société Nexenta) vise à stocker cette table de correspondance sur un disque dédié et à pouvoir en prédéfinir la taille maximale. Résultat : la déduplication des fichiers deviendrait enfin utilisable !
L’impact pour OVH, à l’échelle de l’hébergement web/mutualisé, pourrait être considérable. Les fichiers qui composent l’ossature de WordPress, par exemple, y sont répliqués des millions de fois. La déduplication permettrait un gain d’espace très important. Disponibilité dans OpenZFS : moyen terme.

9 – SPA Metadata Allocation Classes
La contribution de Don Brady (société Intel) est l’occasion de rappeler que le cœur d’OpenZFS est un object storage, rendu utilisable à la manière d’un file system, en s’appuyant sur les métadonnées des objets pour reconstituer une arborescence. Certains objets stockés sont donc des fichiers, tandis que d’autres sont des métadonnées (UNIX, ACL….). Et ces objets sont indistinctement mélangés sur le pool ZFS. Le travail de Don Brady a pour objectif de rendre possible l’organisation des objets suivant leur nature, et par exemple d’assigner les objets qui sont des métadonnées à des disques SSD, pour augmenter les performances du pool. Par ailleurs, il propose de pouvoir associer des devices (disques SATA, SSD, MVNe…) à certains types de métadatas. Disponibilité dans OpenZFS : inconnue.

(1) twitter.com/allanjude/status/656152029820243968
(2) slideshare.net/Docker/dockercon-sf-2015-reliablilty-shippin (slide 18)


Zoom sur le système de cache ARC d’OpenZFS

par Rémy Vandepoel, architecte systèmes chez OVH

ZFS, et OpenZFS utilisent deux algorithmes différents pour placer, ou non, un objet/fichier dans l’ARC (le cache stocké en RAM).
Il s’agit du MRU et MFU, signifiant respectivement Most Recently Used et Most Frequently Used.
Ces deux algorithmes permettent d’optimiser le temps de réponse pour les objets les plus récents et le plus demandés en utilisant et s’appropriant la quasi totalité de la RAM disponible sur le serveur.
La performance n’en sera que meilleure, d’autant plus que le système coordonne leur utilisation pour préférer, en fonction des situations, l’un ou l’autre et les pondérer.
De nombreuses statistiques sont disponibles, à l’aide de l’utilitaire kstat
Notamment les variables zfs::arcstats:hits et zfs::arcstats:misses, qui permettent de jauger l’utilisation du contenu mis en cache.

# kstat -p zfs:0:arcstats:hits zfs:0:arcstats:misses
zfs:0:arcstats:hits 51250034196
zfs:0:arcstats:misses 5983583701

Ici, on a par exemple un hitrate de ~89 %.
ie: Seuls 11 % des fichiers sont accédés sur disque, et non via le cache en RAM.

On peut également comparer les réponses faites par les deux algorithmes :

kstat -p zfs:0:arcstats:mfu_hits zfs:0:arcstats:mru_hits
zfs:0:arcstats:mfu_hits 28694504638
zfs:0:arcstats:mru_hits 11647492315

Tip: toutes les statistiques sont disponibles en utilisant `kstat -pn arcstats`

Copywriter at OVH.