IMG_6437

Atlantis ILIO : une approche SDS radicale dédiée à l’optimisation des I/O

A l’occasion de mes pérégrinations de geek “professionnel” sur Internet, je suis tombé sur une nouvelle perle d’entreprise développant des produits full “Software Defined Storage”, Atlantis Computing.

Le concept de “Software Defined” génère énormément de bruit dans l’IT et de solutions “sur étagère” depuis quelques années, sous l’impulsion de la généralisation des environnements virtualisés en production critique. Ceci étant, sous ce terme valise très générique se cache en définitive des approches et des produits assez différents, depuis des agrégateurs de volumes en mode “commodity” comme ScaleIO ou RedHat Storage, jusqu’à des solutions complète de gestion du stockage piloté par logiciel comme ViPR.

La société Atlantis explore, quant à elle, le domaine de l’optimisation des performances du stockage et, dans une certaine mesure, son accélération. En particulier, le produit “Atlantis ILIO” est une solution livrée sous forme de virtual appliance s’intercalant de manière très ingénieuse entre le stockage primaire et les machines virtuelles tout en ayant pour ambition de réduire et optimiser drastiquement les I/O via des algorithmes avancés de traitement “inline”.

Lire la suite …

Photo-2014-06-10-10-44-04_5415

A propos des mises à jour disruptives d’XtremIO

Histoire de patienter avant la livraison – très attendue chez nous – de XIOS 3.0 sur XtremIO, fournissant, entre autres, la compression inline, je vous conseille d’aller encore une fois faire un tour chez VirtualGeek. Celui-ci nous fournit une analyse intéressante expliquant pourquoi le passage de XIOS 2.4 à XIOS 3.0 sur XtremIO sera disruptif et pourquoi, vraisemblablement, les prochaines ne le seront plus avant un bon moment.

Lire la suite …

2017-05-18 10-51-45 0248

XtremIO, du stockage très haut de gamme et très cher ? vraiment ?

68kNotre PoC arrive bientôt à son terme, mais nous ne pouvions pas passer à coté d’une simulation sur l’ensemble des facteurs de réduction de donnée disponibles et à venir sur XtremIO.

Protocle de test :

Pour pouvoir estimer les gains potentiels de l’algorithme qui sera implanté dans les X-Bricks, nous avons donc passé un outil dédié fourni par EMC. Celui-ci a été chargé de scanner l’ensemble des volumes déjà provisionnés sur la baie. L’opération à duré un certain temps car il s’agissait tout de même d’analyser environ 6 To (plusieurs heures de traitement parallèle). Accessoirement, on a pu constater aussi, par ce biais, tout le potentiel de la baie en montant, par moment, à plus de 98.000 IOps, avec seulement 2 VMs de traitement sur deux serveurs ESXi différents :) . Que personne ne viennent plus dire que la virtualisation ne sais pas faire de performance pure après ce genre de constatation !

Les rapports recueillis sont particulièrement détaillés et présentent les niveaux de compression attendus, en fonction de la taille des blocs (de 4k à 64k) pris en compte par l’algorithme – ce sera sans doute un paramètre d’initialisation sur le prochain firmware – . Au final, c’est une excellente surprise pour nous, car sur les 6 To analysés, on obtient un taux de compression moyen de plus de 45% !

Calculs savants…

Si l’on fait l’exercice de la multiplication, sur la base de 14,9 To utiles avec un niveau de déduplication relativement raisonnable de 2,5 our et un taux de compression de 45% : on obtient une surface moyenne de stockage de (14,9*2,5)*1,45 = 54 To théorique ! Le prix au Go est donc divisé par un facteur de 3,5 ! Une fois n’est pas coutume dans ce blog, risquons-nous à un calcul financier hypothétique (vous savez comme moi que les prix listes d’EMC ne valent rien ;) et vous ne saurez bien sûr pas combien EMC nous propose ses petits bijoux de technologie ;) ) : à 400 K€ la X-Brick pour 14,9 To, on est donc à 27000€ du To. Par contre, divisé par ce facteur moyen de 3,5, on tombe à seulement 7700€ du To, pas si éloigné des coûts habituels du To “performance” sur des baies de stockage classique.

Bien sûr tout cela n’est que “simulation”, mais malgré tout, en prenant des ratios conservateurs, on arrive tout de même à voir XtremIO sous un angle bien différent du segment habituel où on le place pour le moment, c’est à dire le très haut de gamme. Il faut bien entendu mettre cela en perspective de l’usage réel de ce type d’engin au sein de votre entreprise pour éviter la sur-qualité.

XtremIO, très bien et très cher ??

En résumé, XtremIO n’est, toutes proportions gardées bien sûr, pas si cher au regard de son potentiel et, finalement, de son coût au To une fois tous les algorithmes de réduction activés. Autant dire que je vous conseille vivement de déployer vos XtremIO avec la compression activée, dès qu’elle sera disponible ! Attention tout de même, EMC a annoncé que l’activation ne peut se faire que via une réinitialisation complète de la baie (avec destruction des données présentes).

2017-05-18 10-51-45 0248

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