Les systèmes de fichiers récents des années 2005-2010 comme ZFS et Btrfs, ainsi que les gestionnaires de volumes, apportent de profonds changements dans la manière de penser et de concevoir le système de stockage. Les deux fonctionnalités phare qui font une apparition récente sont la déduplication et le snapshot, elles n’ont rien à voir et pourtant je considère que le snapshot permet de se passer de déduplication dans plusieurs cas de figures.

Sommaire

Un point sur les systèmes de fichiers récents

Avant 2000

Les termes « système de fichiers » et « récent » semblent presque incompatibles, tellement le paysage du système du fichier a une tendance générale à stagner à travers les évolutions technologiques logicielles et matérielles que l’on constate par ailleurs. Depuis Windows XP les utilisateurs de la firme de Redmond ont le choix d’utiliser NTFS comme amélioration logique à FAT32, mais le remplaçant est apparu plus tôt que le remplacé (1993 contre 1996) ! Sous MacOS on utilise HFS. Et sous Linux, on utilise depuis toujours ext2/3/4 (1993-2008) et XFS (pré-2000). Rien de nouveau au soleil.

Parmi ces dinosaures du filesystem, la fonctionnalité la plus novatrice est probablement la journalisation de ext3/4 et XFS, et qui permet de vérifier un lecteur plus rapidement après une coupure brutale, en somme rien que nous n’avions déjà en l’an 2000.

Après 2000 et les années 2010

Pendant cinq ans plus rien, puis en 2006 un projet qui apporte enfin du nouveau, le gestionnaire de volumes qu’est LVM. Ce composant intermédiaire se positionne entre le ou les disques durs et le système de fichiers, afin d’assouplir les cas d’utilisation. On peut enfin créer une partition (volume logique) qui s’étend sur plusieurs disques durs (à la JBOD), la redimensionner facilement, et même faire persister cette partition malgré le remplacement programmé de certains disques durs. Une fonctionnalité remarquable de LVM est le snapshot, qui permet de retrouver un volume logique tout entier tel qu’il était à une date donnée, et quelque soit le système de fichiers utilisé par dessus. LVM est encore en développement actif à ce jour, et présente de nombreux avantages dans des environnements modernes comme les systèmes de stockage ou les serveurs de virtualisation.

LVM a été écrit dans la plus pure tradition Linuxienne qui veut que chaque composant doit faire un minimum de choses, mais le faire bien en coopération avec d’autres composants complémentaires. La conjonction de Linux, mdadm et LVM et ext4 tient la route et procure de nombreux avantages. Oui mais voilà, cela devient un peu compliqué, et une philosophie alternative propose un paradigme différent : le regroupement dans le système de fichiers de tout ce qui touche à l’agrégation de disques durs (RAID), la gestion des volumes (LVM) et du système de fichiers tel qu’on le connaissait. Le système de fichiers ainsi obtenu aura une vision globale de tout le système de stockage depuis l’adressage matériel jusqu’aux fonctionnalités les plus avancées comme le cryptage ou la compression. Cela est particulièrement pratique pour gérer l’auto-guérision (auto-healing) du système de fichiers en cas de bloc illisible, ou encore la copy-on-write (CoW) utilisée par le principe du snapshot. Pour les SSD, c’est encore plus facile de remonter la commande TRIM entre le filesystem et le contrôleur disque.

L’avenir du système de fichiers sera dans le tout-en-un, en dépit de ce que la philosophie Linux nous a appris. Ou quand le whole system design remplace le small is beautiful.

 

La déduplication, une fonctionnalité très alléchante

La déduplication est une fonctionnalité incroyable, qui permet de comparer tous les fichiers du système de fichier afin d’identifier les blocs communs qu’il sera possible de ne stocker qu’une seule fois sur le périphérique. C’est en fait un dédoublonnage en mode blocs. Si vous stockez plusieurs fois un même fichier de 1 Mo, l’espace consommé sera de 1 Mo. Si vous stocker un fichier texte de 1 Mo, et que vous en créez une copie dans laquelle vous rajoutez 500 Ko de données, l’espace consommé sera de 1,5 Mo et non pas 1 Mo + 1,5 Mo.

Imaginez un peu le pouvoir de la déduplication chez Dropbox, où tous les utilisateurs stockent des fichiers parfois téléchargés sur le web (pdf, jpg, mp3, …) et donc identiques entre plusieurs comptes, les gains de place peuvent être absolument énormes. Et les économies aussi. Sur une grosse infrastructure de sauvegarde d’entreprise, vous pouvez vous permettre de sauvegarder tous les C:\Windows de vos postes de travail, ces répertoires seront tellement proches entre eux que le surcoût de stockage sera infime.

Oui mais voilà, la déduplication a un coût énorme, il faut très généreusement lotir ses serveurs en mémoire si on veut des performances correctes. La raison est simple : le système doit stocker en mémoire l’ensemble des hash des blocs du système de fichier, afin de les comparer entre eux. Ma compréhension de la déduplication se limite à ZFS puisque c’est la seule option que j’ai pu tester, mais je ne conçois pas un système de déduplication qui mette ce principe en défaut. Espérons que le temps me fasse mentir.

La page de référence ZFS sur Ubuntu.com indique tristement « la déduplication ne vaut presque jamais le coup, eu égard à la faible performance ». Je voudrais tout de même modérer ces propos, car il existe des solutions propriétaires type EMC, et même des produits commerciaux ZFS basés sur Solaris ou FreeBSD, qui tiennent la route.

Plus encore, la déduplication supprime toute redondance naturelle qui consiste à stocker un même fichier à plusieurs endroits du plateau magnétique. Donc le moindre secteur défectueux pourra impacter plusieurs fichiers à la foi. On n’a rien sans rien.

 

Ce qu’il ne faut jamais dédupliquer

En généralisant l’usage de la déduplication, on pourrait être amené à pratiquer le scénario suivant : je stocke les sauvegardes de mes serveurs (en mode fichiers) dans le répertoire /data/20170112.serveur, puis le lendemain je recommence dans /data/20170113.serveur , et ainsi de suite, en comptant sur la déduplication pour ne pas consommer d’espace supplémentaire dans /data , ou très peu.

Que suis-je en train de faire ? Je demande au serveur de comparer les moindres blocs de mes sauvegardes datées entre elles pour les dédoublonner. C’est une opération extrêmement coûteuse, un vrai gâchis de ressources.

En réalité je dédoublonne les répertoires par date, ce qui revient à demander au serveur de snapshoter mon arborescence a posteriori ! Nous arrivons à l’idée principale de cette article : préférer le snapshot plutôt que le dédoublonnage par date.

 

Le snapshot, ce que j’appelle la déduplication « par construction »

Ce que j’appelle la déduplication par construction, c’est le stockage du même répertoire à des dates différentes, en mutualisant les blocs des fichiers entre eux afin de consommer un minimum d’espace disque. Le terme « par construction » fait référence au coté instantané et atomique du snapshot, la logique de déduplication se trouve dans l’ordre des snapshots et non plus dans une déduplication gérée par le système de fichiers. C’est le rêve de tout administrateur système : pouvoir remonter le temps sans faire exploser la consommation en stockage.

Avec la déduplication, comme on l’a vu plus haut, cela fonctionnera au prix d’une consommation énorme en ressources.

Mais le snapshot est déjà fait pour stocker un répertoire à différentes dates, on à tout à y gagner ! L’opération de snapshot est très rapide car c’est très facile à réaliser pour un système de fichiers récent. Il lui suffit de dupliquer ses meta-data de fichiers et non pas ses fichiers.

Scénario n°1 : entre un système de fichiers ext4 et Btrfs

Imaginons le cas de figure suivant : mon serveur web héberge un site dans /var/www/site1  sur un disque ext4. Pour bénéficier des bienfaits du snapshot sur mon disque de sauvegardes /data équipé de Btrfs, je synchronise mes sites dans /data/backup/site1/synchro . Le dossier /data/backup/site1/synchro  n’est pas comme les autres, c’est un subvolume (Btrfs) ou un filesystem (ZFS). Maintenant je n’ai plus qu’à le snapshoter tous les jours dans /data/backup/site1/snapshots/20170112.

Récapitulatif :

  • Sur le disque de production, dans /var/www/site1 , je stocke mon site internet sur une partition ext4 pour des raisons de performances et de fiabilité.
  • Sur le disque de sauvegarde, dans /data/backup/site1/synchro , il y a la synchro exacte de /var/www/site1 .
  • Sur le disque de sauvegarde, dans /data/backup/site1/snapshot/20170112 , il y a l’état de  /data/backup/site1/synchro  à une date précise.

Dans le scénario ci-dessus, les snapshots prendront moins d’une seconde, une simple formalité pour le système de fichiers. J’aurai conservé énormément de fichiers identiques sans jamais souffrir de surconsommation sur mon petit disque de 1 To, et sans jamais faire tourner mon CPU à 100%.

La limite de ce système, c’est que la copie des fichiers entre la source ext4 et la cible Btrfs n’est pas une copy-on-write. Par conséquent, dès que je synchronise un fichier modifié entre la source et la cible avec rsync par exemple, un nouveau fichier temporaire est créé avec un nouvel inode, puis rempli et renommé avec le nom original. La conséquence de cela est que le coût d’un fichier snapshoté est le volume dudit fichier en entier. C’est encore jouable avec de tous petits fichiers, pour sauvegarder par exemple /etc  ou /var/www . Mais pour sauvegarder des images disques ou des grosses bases de données, cela consommera trop d’espace disque.

Scénario n°2 : snapshot sur le même système de fichiers

Pour parfaire l’exemple d’utilisation du snapshot Btrfs, il faut que les snapshots se situent sur le même système de fichiers que les données originales. Aucun répertoire n’a donc besoin d’être synchronisé et il suffit de snapshoter un subvolume Btrfs dans un autre subvolume. Éventuellement, la commande cp --reflink  est capable de pratiquer des copy-on-write également.

Pour externaliser le stockage des snapshots, il existe des solutions avec ZFS, mais je n’en connais pas à ce jour avec Btrfs.

Ce que ne me permettra jamais le snapshot, c’est de mutualiser les blocs de mes fichiers entre deux arborescences de sauvegardes qui proviennent de sources différentes (exemple : site1 et site2). Pour ce faire, la déduplication reste la seule solution.

Conclusion

J’espère que mon titre provocateur ne fera pas bondir les aficionados de la dédup qui ne jurent que par elle, et passent des nuits à tuner leur pool ZFS pour en tirer les meilleures performances possibles. Bien-entendu on ne peut pas remplacer la déduplication par le snapshot tout le temps, mais uniquement dans certains cas de figure comme par exemple les snapshots datés.

Ce sont en réalité deux fonctionnalités différentes, dont le point commun est de dédoublonner les blocs entre plusieurs fichiers. La déduplication le fait a priori tandis que le snapshot le fait a posteriori.

Néanmoins je suis sincère dans mon constat : le snapshot va prendre un essor bien plus important que la déduplication dans les années à venir. C’est une technologie mature qui reste encore sous-utilisée eu égard aux services qu’elle rend.