Ceux qui travaillent sur VPlex et qui suivent un peu les actualité des versions savent sans doute que depuis la 5.2, GeoSynchrony a introduit une nouvelle fonction permettant de vider le cache cohérent (qu’il soit local ou distribué) d’un LUN donné. L’objectif ici est de pouvoir utiliser directement des LUNs de type snapshot, sans être obligé, à chaque refresh ou revert, de les dé-configurer complètement puis de les provisionner à nouveau. Un gain de temps non négligeable et qui rend désormais cette fonctionnalité de nos baies de stockage particulièrement simple à travers VPlex.
Je vous propose de revenir sur un cas d’usage chez nous qui nous a donné l’occasion d’utiliser la commande en question sur VPlex : cache-invalidate.
Le Contexte
Nous avons actuellement un volume NTFS sur une machine de production dont on peut clairement dire qu’il représente une sorte de “climax” de tout ce qu’il ne faut pas faire quand on veut stocker du fichier en grande quantité. Je ne citerai par l’application concernée par respect pour les développeurs, mais honnêtement, ça me démange ^^. Retenez seulement que le volume en question dispose d’un seul répertoire où se trouvent des millions de fichiers pdf issus de numérisation de documents administratifs. Parmi ceux-ci, certains semblent corrompus et sont impossibles à copier ni même à sauvegarder (bloquant du même coup toute tentative de full backup, embêtant). Même le désormais célèbre DobiMiner se plante en essayant de les parcourir pour les répliquer sur notre Isilon (voir cet article).
Il nous a donc fallu faire des copies de sécurité en mode bloc de ce volume mais aussi travailler sur celui-ci pour essayer de le débugger tranquillement. Les snapshots se sont donc imposés à nous, évidemment. Pour le coup, je ne vous ferai pas l’affront de vous expliquer le principe du snapshot de LUN, mais comme je souhaitais le présenter à une VM dont l’infrastructure passe exclusivement par VPlex, j’en ai profité pour tester la fameuse fonction “cache-invalidate” présente sur notre cluster Métro et je m’en vais de ce pas détailler un peu la méthode que j’ai utilisé.
Pourquoi cette fonction cache-invalidate est nécessaire ?
Au coeur de la technologie VPlex se trouve un système très évolué de cache cohérent (distribué ou local suivant les cas) afin de maintenir une table dynamique du contenu des blocs lus/écrits au niveau de l’ensemble du cluster (pour en savoir plus, une vidéo très synthétique vous l’explique ici). Lorsque vous souhaitez par exemple rafraîchir un snapshot coté back-end (refresh ou revert, peu importe), vous devez donc avertir VPlex que les informations maintenues en cache pour la LUN ne doit plus être considéré comme reflétant le contenu réel des blocs sur disque et doit donc être vidé.
La stratégie consiste donc, dans l’ordre :
– à “démonter” le volume cible de la VM sur lequel il est connecté
– faire en sorte que l’OS, quel qu’il soit, ne produise plus aucune I/O sur ce volume (un passage en “offline” sur Windows, par exemple, suffira)
– indiquer à VPlex qu’il doit purger l’ensemble du cache du volume en question (via la commande “virtual-volume cache-invalidate”)
– réaliser l’opération sur le snapshot (refresh/revert)
– enfin, remonter le volume rafraîchi sur la VM originale
Pour la partie VNX, on réalise le refresh du snapshot en désactivant le LUN support et en rattachant une nouvelle session adaptée à celui-ci. Enfin, on réactive le LUN pour autoriser les I/O dessus.
Pas de surprise chez nous, la fonction cache-invalidate nous a permi de réaliser des diagnostics souhaités en toute sécurité, tout en assurant une protection minimum du volume, à défaut de pouvoir le sauvegarder totalement – pour l’instant -.
Et vous, avez-vous déjà exploré d’autres exemples vous ayant conduit à exploiter cette possibilité offerte par VPlex ?