Mise à jour : après contact auprès de la team XtremIO, les fonction de refresh et revert sur les snapshots ne sont effectivement pas encore supportées, mais sont dans la roadmap XtremIO 4.0. A suivre !
Article original : Si vous me suivez depuis quelques semaines, vous savez sans doute que nous venons d’acquérir deux X-brick XtremIO que nous souhaitons intégrer à notre production en utilisant notre VPlex, afin disposer de toutes les fonctions de Disaster Recovery que nécessite notre institution. Chaque X-brick sera donc située dans une salle informatique différente, la réplication temps réelle étant assurée par VPlex Metro (en production depuis plus de 2 ans, désormais).
Intrinsèquement, toute cette architecture est parfaitement saine et performante, à même d’assurer notre production dite TIER1 dans les meilleures conditions. Pour autant, la couche VPlex introduit toujours une complexité supplémentaire, voir même quelques difficultés pour utiliser certaines fonctions bien pratique, mais n’étant pas VPlex “aware” pour le moment ou tout simplement pas supportées (je pense en particulier à la fonction “UNMAP”, voir ce billet).
En travaillant sur les fonctionnalités de snapshot d’XtremIO, j’ai donc imaginé les nombreux scénarios de production qui pourraient énormément bénéficier de l’Xtrem agilité de la baie en la matière. Aujourd’hui, nous n’utilisons que très ponctuellement les systèmes de snapshot de nos baies de stockage, principalement pour des raisons historiques. Il me paraissait logique de profiter d’un changement majeur d’infrastructure pour remettre cette fonction dans l’esprit de tous mes collègues ingénieurs et susciter, si ce n’est son usage plus systématique, du moins cette curiosité nécessaire à l’amélioration continuelle de nos outils et services !
Or, je suis confronté à un problème : malgré toutes mes recherches (documentation d’admin, blogs divers et variés), je n’ai pas vu de fonction intégrée permettant de faire un “refresh” ou un “revert” d’un snapshot en cours. L’objectif étant, bien entendu, de conserver tout le provisionning du snapshot jusqu’aux serveur l’utilisant (zoning éventuel, connexion “scsi”, identité logique etc. …), sans être obligé de casser toute la chaîne. C’est d’autant plus important lorsque le snapshot en question passe par un VPlex. A ce titre, d’ailleurs, la version 5.2 a ajouté une fonction parfaitement adaptée aux “refresh de snap”, c’est la possibilité, pour un virtual volume donné (ou même tout un consistency group) d’invalider le cache cohérent correspondant. En effet, en cas de revert ou refresh d’un snap back-end, il faut absolument indiquer au VPlex de repartir de zéro en terme de cache, sans quoi, vous obtenez à coup sûr une dé-cohérence de votre cache par rapport aux données rafraîchies présentées par le snap.
Même sans aller jusqu’à une intégration VPlex d’un volume de type snapshot (on peut se poser la question de l’utilité réelle d’une telle configuration, d’ailleurs), même via une connexion directe, il semble que, dès qu’on souhaite récupérer un snapshot “à jour” par rapport à la LUN source, nous soyons obligés de supprimer complètement le volume du host, supprimer l’ancien snapshot, recréer un nouveau snapshot copie du LUN de prod à l’instant T, le re-présenter au serveur et, enfin seulement, le reconnecter via une redécouverte du volume.
Pour le moment, je n’ai donc pas de solution et c’est assez frustrant. Si vous avez des pistes, je suis preneur, bien entendu !
A ce sujet : un billet détaillant avec précision le fonctionnement des snapshots sur XtremIO.