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.
En substance, ce changement de firmware modifie très profondément la structure interne des métadatas et de leur distribution. Ce faisant, EMC a choisi de rendre cette évolution majeure “radicale”. En effet, il vous faudra entièrement reformatter votre cluster XtremIO. Certes, avec les outils puissants de virtualisation ou par VPlex, on peut désormais déménager assez facilement une production d’un équipement de stockage à un autre, mais cela n’en demeure pas moins une opération lourde et nécessitant forcément un espace de manœuvre temporaire permettant d’accueillir ces volumes. C’est cela qui nous a conduit à attendre la livraison de ce nouveau code sur nos XtremIO fraîchement installés avant de les mettre en production.
En filigranne, il faut comprendre aussi que la logique d’XtremIO actuelle veut qu’il n’existe “aucune tâche de fond réelle” hormis les nécessaires checks réguliers et reconstructions inhérents à toute baie de stockage. En effet, toute l’activité IO de la baie se veut “inline” (dédup, zéro, compression) et surtout prédictible en terme de latence. Partant de ce principe, impossible de mettre en place un module quelconque assurant en arrière plan une réorganisation quelconque (par exemple une compression a posteriori) de l’espace de stockage et ses métadatas associées. Je vous renvoie pour plus d’explications à certains billets de ce blog et en particulier celui concernant le traitement des bloc “zéro”, qui en dit long sur la philosophie d’XtremIO.
Enfin, l’article de VirtualGeek donne quelques informations, sans vraiment les dévoiler totalement, sur la roadmap XIOS et indique que les prochaines itérations seront, sauf “accident”, non disruptives. Une bonne nouvelle pour ceux qui espèrent à terme une souplesse comparable au monde Clariion / VNX.
L’article : http://virtualgeek.typepad.com/virtual_geek/2014/09/on-disruptive-upgrades.html