Optimisation des facteurs de réduction de la donnée : le cas de VPlex + XtremIO

A l’occasion de notre PoC XtremIO, nous avons récemment travaillé avec EMC sur l’optimisation du facteur de dé-duplication des machines virtuelles afin de tirer le maximum de notre future acquisition potentielle. On le sait depuis longtemps, l’alignement des systèmes de fichiers internes aux VM peuvent avoir une influence non négligeable sur le niveau de performance des accès disques. De manière corollaire, cet alignement a aussi une influence sur le niveau de dé-duplication. Il est donc nécessaire, si ce n’est pas déjà fait, de bien faire à attention à ces alignements avant de migrer des ensembles virtualisés sur XtremIO.

D’autre part, pour profiter au maximum de la dédup, on peut s’appuyer également sur des fonctions de “nettoyage” des espaces internes des VMs. En effet, vous savez sans doute que lorsque l’on demande la suppression d’un fichier d’un filesystem quel qu’il soit, en général, celui-ci procède juste à la suppression de la référence de ce fichier dans la table d’allocation. Les données effectives du fichier ne sont pas touchées et restent donc en l’état sur les disques (et donc, restent considérées comme “utilisées” pour le stockage sous-jacent). Du coup, mécaniquement, vous ne récupérez pas l’espace initialement alloué par l’hyperviseur, qui n’est pas informé que la machine libéré de la place sur disque.

Pour résoudre ce problème, il s’agit de faire en sorte que toute la chaine de liaison soit avertie que certains blocs de données ont effectivement été libérés. Dans notre cas, il en existe 3 :
– L’Hyperviseur VMWare (ESXi)
– Le VPlex
– La baie de stockage, XtremIO

Si l’on reste sur de l’optimisation d’espace disque au sein des VMFS de notre ensemble VMWare, les méthodes existent. Elles sont relativement simple, mais souvent en partie manuelles. Il existe des KB décrivant ces processus, mais le principe est toujours le même :
– Remplir les espaces réellement libérés dans les filesystems des VM par des “Zéros” (l’outil sdelete sur Windows fait cela très bien et online, coté Linux on pourra utiliser zerofree ou sfill)
– Déménager la VM sur un VMFS formatté avec une taille de bloc différente, ou, machine virtuelle éteinte, utiliser sur chaque VMDK la commande vmkfstools -K (KB#2004155)

Concernant l’espace de stockage primaire, là, c’est plus compliqué et cela dépend du type de baie utilisée. Pour le cas d’XtremIO, il est nécessaire d’utiliser une fonction spécifique de ESXi, unmap, qui permet d’indiquer réellement à la baie la liste des blocks libres. Cette fonction parcours l’ensemble du vmfs fourni en argument (commande “esxcli storage vmfs unmap” sous VMA ou directement via la console d’un ESXi).

Pour le cas de VPlex, sur le firmware 5.2sp2p1 dont nous disposons en production aujourd’hui, la question est vite règlée dans le sens ou la commande unmap n’est pas supportée ! Du coup, l’optimisation des taux de dé-duplication d’un ensemble VPlex/XtremIO n’est possible que lors du “premier remplissage” en ayant déjà effectué un chantier d’optimisation amont (au sein des VMs). Nous avons interrogé EMC sur ce point précis pour savoir si cette fonction était prévue sur VPlex et si oui, à quelle échéance.

D’une manière général, je pense qu’il ne faut pas sous-estimer ces chantiers préalables à un passage sur une baie dont la fonction de réduction de données est un des critères majeurs. Il s’agira donc de commencer par “faire du ménage” sur nos VMs de production, dans la mesure du possible, avant de migrer celles-ci sur des ensemble XtremIO.

Sources : VMWare KB#2004155