VPlex, chronique d’une mise à jour : en route pour la 5.3

UPDATE : Si vous utilisez le snmp pour superviser votre VPlex, ATTENTION quand vous passez en 5.2. L’agent snmp est victime d’un bug de type “memory leak” et est complètement instable. Le support EMC m’a annoncé que ce bug était corrigé en 5.3. Ca tombe bien ;)

Malgré mes divers billets autour des annonces de mises à jour de GeoSynchrony, la criticité de nos environnements de production nous a, comme vous tous j’imagine, forcé à la prudence pour ce qui est de passer ces updates sur nos clusters.

Après pas mal d’échanges avec EMC, nous avons donc commencé notre périple 5.1 -> 5.3. Première question évidente : pourquoi passer par la 5.2 ? Les deux réponses essentielles sont : stabilité et jeunesse :) . En effet, autant la 5.2 a été patchée plusieurs fois et est très stable depuis quelques mois, autant la nouvelle 5.3, dispo depuis quelques semaines, paraissait vraiment trop neuve et sa peinture, pas tout à fait sèche. D’ailleurs EMC est souvent de bon conseil dans ces cas là et nous a enjoint à patienter quelques temps encore.

Pour autant, notre 5.1 et ses petits bugs non bloquants (les problèmes de password sur l’interface web, notamment …. pénible à souhait) commençait à nous peser. Nous avons donc lancé une procédure RCM pour la mise à jour intermédiaire estampillée “5.2 SP1 P1”. La mise à jour s’est très bien déroulée, avec une double bascule de liens FC sur nos machines de production, comme à l’accoutumée.

Après checkup de fin d’install, un petit parcours rapide montre des changements subtils d’interface web (le bug du password a d’ailleurs disparu, enfin !).

On note par exemple, dans l’onglet supervision, un navigateur “à onglets” assez pratique, permettant de segmenter les courbes par fonction ou par équipement :

Au niveau paramétrage et en particulier dans la partie “Storage Arrays”, il est désormais possible d’indiquer au VPlex que les LUNs mis à disposition des clusters font du thin provisionning, pour éviter des reconstructions sur la totalité de la volumétrie LUN en cas de rupture ponctuelle des mirroirs synchrones :

Autre évolution intéressante, la possibilité de supprimer toute référence à une ancienne LUN décommissionée (et qui apparait en erreur dans l’interface, même si elle a été correctement enlevée jusqu’à son “unclaim”). Auparavant, il fallait passer par la ligne de commande :

D’une manière générale, cette 5.2 est une maintenance release plus qu’une réelle grosse mise à jour, contrairement à la 5.3, dont j’avais listé les avancées notoires dans ce billet. La grande nouveauté de cette version est clairement la gestion des extensions dynamiques de virtual-volumes (prise en compte des extensions de LUNs online).

Prochain billet avec la 5.3 (la procédure RCM est en préparation).