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 :
shapingwan

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 :
storage1

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 :
storage2

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).