Depuis la mise à jour majeure de XIOS 2.0 vers 3.0 en Octobre 2014, nos briques XtremIO ronronnaient littéralement au sein de notre production. Malgré tout, et en attendant la prochaine disponibilité de XIOS 4.0, nous avions planifié une petite mise à jour mineure, recommandée par EMC, faisant passer notre firmware de la version 3.0.0-44 à là version 3.0.3-11. Cette nouvelle mouture apporte son lot de corrections de bug de fonctionnement et l’ajout (depuis la 3.0.2 en fait) de configuration XtremIO de 90 To basées sur 6 X-bricks de 15 To (en attendant “le monstre” de XtremIO 4.0 avec ses X-bricks de 40 To et 8 X-Bricks dans un cluster).
La campagne concerne nos deux X-Brick 15 To, qui devaient être mises à jour successivement mais séparées par au moins 24/48h, pour vérifier qu’il n’y ait aucune régression ou bug spécifique à notre production.
Lors de l’update du premier cluster, nous avons rencontré un souci lors du reboot des storage controlers (les controleurs ne revenaient pas online). Il y fallut qu’EMC intervienne sur place pour débloquer la situation. La cause de ce dysfonctionnement est due à un bug sur le noyau linux embarqué dans les machines. Si l’uptime est supérieur à 200 jours, le noyau se plante lors d’une tentative de reboot et cause un panic, interdisant le redémarrage à chaud et rendant le SC inaccessible. La seule option dans ce cas est de le redémarrer à froid (power off/on), ce qui explique pourquoi il a fallut envoyer quelqu’un sur place. D’autre part, la engineering team a également rencontré pendant cette opération un problème spécifique sur la configuration LAN Failover qu’il a fallut traiter.
Pour résumer, cette première update a été laborieuse, mais malgré tout sans aucune interruption de service (c’est l’essentiel) ; par ailleurs, la mobilisation d’EMC a été parfaite notamment vis à vis des escalades niveau 3 et de l’envoi de personnel sur site.
Evidemment, notre deuxième cluster est actuellement sous haute surveillance par EMC en prévision de sa mise à niveau (même firmware de départ et même uptime grosso modo) car vraisemblablement affecté par ces bugs. A l’heure ou j’écris ce billet, celui-ci n’est pas encore en 3.0.3 et nous travaillons avec le support RCM pour re-planifier cette mise à jour une fois que tous les checks et corrections auront permis de l’aborder de manière confiante ;) . Ceci étant, le risque d’une coupure de production est aujourd’hui très faible chez nous : d’une part, malgré les problèmes rencontrés nous n’avons jamais eu de coupure sur le premier cluster et d’autre part, actuellement l’ensemble de notre production TIER1 hébergée par XtremIO est mirrorée via VPlex, nous garantissant un accès continu aux données, même en cas de perte complète d’un des deux clusters.
Pour terminer, comme un petit billet sur vBlog n’en serait pas vraiment un sans un ou deux screenshots, voici donc quelques captures des étapes de mise à jour du premier cluster, vue de la XMS:
…à noter que le controleur restant reprend l’ensemble de la charge sans souci (on s’en doutait un peu …)
Je posterai ici même les conclusions de cette campagne quand la deuxième XtremIO sera mise à jour (avec les surprises et/ou les bonnes nouvelles associées, bien entendu). D’ici là, si EMC vous propose une mise à jour 3.x sur vos X-Bricks, demandez-leur de bien vérifier que vos machines ne sont pas exposées à ces difficultés !
MAJ du 27/07/2015 : La deuxième X-brick a été mise à jour avec succès ce Lundi. Comme on le pensait, elle souffrait effectivement des mêmes problèmes que la première. Par contre, EMC était au courant cette fois a parfaitement géré l’affaire. La mise à jour était terminée en début d’après-midi (démarrage à 10h30).