Nap's mini world

Intérêt de la dé-duplication

J’ai testé il y a quelques temps le filesystem lessfs (site officiel du projet). C’est un filesystem très simple à mettre en place, de type Fuse (donc en user space) qui permet de monter un espace de dé-duplication à la volée.  Cette fonctionnalité permet de gagner une place considérable lorsque l’on a des données qui se ressemble fortement.

Elle est complémentaire de la compression. Là où vous aller gagner sur un fichier avec la compression, si vous en avez deux, vous aller stocker deux fois la taille compressée. Avec une passe de dé-duplication avant, vous n’aurez qu’une fois chaque bloc, puis vous pouvez compresser ce qui reste.

Deux méthodes : bloc de taille fixe ou variable

Taille fixe

Les blocs justement. Dans lessfs, ce sont des blocs de taille fixe. Donc on applique un algorithme très simple :

• on coupe la donnée en bloc de NKo (prenons 4Ko)
• on fait un hash de chaque bloc
• si on a déjà un hash, on change le bloc par un simple pointeur vers le bloc déjà sauvegardé
• sinon on sauvegarde le bloc et son hash

Simple. Efficace? Pas si sûr. Bien entendu, si vous faites une copie d’un fichier, celle-ci ne va quasiment rien vous coûter. Mais faire des copies intactes de vos fichiers arrive parfois avec des sauvegardes, et encore…

Taille variable

Si l’on veut être plus efficace, il faut faire une recherche dans les données d’un bloc déjà vu. Mais là où avant on cherchait avec un début de bloc tous les 4Ko, là on cherche pour tous les octets. En effet, si vos blocs ne sont pas parfaitement alignés, vous ne reconnaîtrez pas votre bloc, car il a pris un simple offset de quelques octets!

Bien sûr, ce genre de recherche est bien plus couteux en terme de CPU, 4K calculs fois plus. (En fait u peu moins, dès que vous raccrochez un wagon de blocs déjà connu, un seul calcul suffit).

Exemple de gain

Un exemple?

J’ai codé rapidement un petit script en Python qui réalise ces deux types de dé-duplications :

• recherche des mêmes blocs de 4Ko avec recherche par fenêtre glissante
• recherche brut de frondrie, bloc de 4k

Voici les résultats sur un répertoire plein de fichiers de type office and co:

****** Stats Varible: Deplicated 342756761/465877423 = 73.00% Dedup+compress 426510002 =91.00%
****** Stats Fix: Deplicated 59596755/465877423 = 12.00% Dedup+compress 68349038 =14.00%

On a donc 73% de gain avec des tailles de blocs variables, 91% si on les compresse par dessus. La méthode fixe bourrine n’arrive elle qu’à un faible 12%.

Bon bah il faut demander à lessfs d’appliquer cet algo? Pas si simple, de un c’est ultra consommateur en CPU, donc il faut le faire en post-process, pas à la volée. Et surtout l’algo utilisé semble avoir été breveté par EMC… Et après ça qu’on vienne encore me sortir que les brevets sont fait pour protéger l’innovation…. l’investissement oui, l’innovation non…

Pour ceux qui ont la chance de ne pas habiter dans ce merveilleux pays des brevets logiciels, vous pouvez tester le script là.

Ca y est, l’auteur de Nagios a répondu à la lettre ouverte sur la mailing list ici. Réponse assez complète, mieux que la blague qu’il nous a sorti sur “nagios-drama”. Voici ce que l’on peut retenir de sa réponse :

1. il ne lâche pas la partie open source, les fond de XI permettrons de développer d’avantage la partie open source
2. XI n’est pas open source car il utilise des modules externes qui ne le sont pas
3. la commercialisation de Nagios va se développer
4. la gestion du trademark ne sera pas assouplie
5. c’est lui qui dirige depuis 11ans, ça ne va pas changer comme ça
6. le core est bien comme il est, pas besoin de changements, ou alors dans les addons

Bon le point 1 tant mieux, reste à le voir en action. Pour XI ok, de toute manière c’est son application, il n’a pas à justifier son choix de licence après tout. On voit mieux comment ça va s’articuler avec le point 3 : on est bien parti pour avoir une version Enterprise complète (XI) et une communautaire. Ca ressemble bien à Zenoss pour çe point là, espérons que le développement de la partie open source n’est pâtira pas.

Le point 4 est ce qu’il est, même si il protège un peu trop son trademark en ce qui concerne l’affaire nagios-fr/icinga au point de jouer contre son camp. Le point 5 bah pas grand chose à dire.

Le point 6 lui est plus discutable. Je suis d’avis que ce n’est pas le core qui est bien, mais les idées qui propose (la gestion de la configuration, le support des sondes de checks et de notification) mais son implémentation le limite à des environnements de taille moyenne : les petits environnements tournent en général sous Windows, là où Nagios ne tourne pas, et les grands on besoin de bien plus de performances que Nagios propose pour l’instant, et surtout a besoin d’une centralisation de certaines choses comme les notifications et d’une supervision distribuée et hautement disponible.

Au moins on sait où on va maintenant avec Nagios, on a les grandes lignes, le virage de la phase business (open source : dev, communauté puis business) est amorcé. Espérons qu’on ne tombe pas dans le ravin.