Ca y est ! Après vous avoir présenté il y a quelques jours notre déménagement prochain des ressources CIFS de nos VNX vers Isilon, notre premier volume (le plus gros !) vient d’être migré avec succès. L’opération globale s’est très bien passée sans quasiment aucun appel utilisateur. Laissez-moi vous conter plus en détail son déroulement. Vous allez voir, cela va vous donner envie comme une Feurari Rouge (private joke).
Préambule: Bonjour à tous ! Avant toute chose, pas d’inquiétude, je suis toujours online ^^. En effet, j’ai reçu récemment quelques emails et messages privés inquiets de ne plus voir de news ni de tweet de ma part depuis une vingtaine de jours. En fait, pour tout vous dire, les journées sont très courtes en ce moment pour deux raisons majeures : un déménagement personnel d’ici fin Mai et beaucoup, beaucoup de travail au sein de mon institution chérie. Mécaniquement, vBlog en pâtit un peu et j’en suis désolé !
Nonobstant, trêve de blabla, trêve de blabla: Depuis quelques années déjà, la plupart de nos ressources CIFS partagées sont hébergées par nos VNX7500 Unified, via l’adjonction de têtes NAS Celerra en 2014. Globalement, elles s’acquittent assez bien de cette tâche, même si l’interface d’admin Unisphere accuse le poids des années. En prévision de l’arrêt programmé de ces baies d’ici le début de l’année prochaine (fin de maintenance, 7 ans d’activité) et suite à de multiples problèmes récents d’espace disque nous avons décidé d’anticiper de quelques mois la migration des données “NAS” sur un autre support.
Petite chronique de cette grosse opération de migration …
Anachronique me direz-vous ? C’est sûr que par rapport à mes billets “habituels” plutôt tournés vers les nouvelles technologies et solutions avant-gardistes, ça parait un peu vieillot de parler de nos bons vieux NAS VNX. Maaaaais, vous le savez bien, quand on met en production une nouvelle infrastructure de stockage, il faut la garder et l’exploiter longtemps (au moins 4/5 ans en moyenne chez nous). Logique, dans ces conditions que l’on continue à apprendre sur ces équipements, n’est-ce pas :)
Je vous propose donc un petit tuto rapide qui vous permettra de renouveller/changer le certificat SSL de votre tête NAS VNX (Celerra pour les intimes) en deux temps, trois mouvements. L’opération est valable si vous disposez déjà en interne d’une PKI d’entreprise où si vous êtes capable de générer directement une CA pour l’occasion (il existe de nombreux exemple basés sur OpenSSL sur la toile).
La nouvelle gamme EMC “mid-market” Unity fait le buzz en ce moment : une toute nouvelle architecture, la compatibilité VVol, l’unification du code block/file et une toute nouvelle interface HTML5 pour gérer l’ensemble. Je vous ai d’ailleurs présenté rapidement l’aspect et l’ergonomie générale de ce nouveau Unisphere lors de mon billet sur l’installation de la VSA. Le fait est que ce nouvel outil de gestion est vraiment agréable et se défait enfin de la lourdeur de Java de la meilleure des manières.
Et j’ai une bonne nouvelle pour vous ! En prévision de prochains articles sur Unity VSA et à la faveur du parcours de l’ensemble de l’interface de gestion, je suis tombé sur un nouveau produit chez EMC, successeur du vénérable Unisphere Server que vous connaissez peut-être, il s’agit d’Unisphere Central. Même si ses fonctionnalités sont relativement limitées – pour l’instant – je vous conseille d’y jeter un œil car il vous donnera un avant-goût d’Unisphere HTML5 mais cette fois-ci avec vos propres baies de stockages historiques, VNX, VNX2, VNXe et même CX4.
Petit tour d’horizon en image…
Rappelez-vous, il y a quelques semaines, nous avions été victimes d’un incident majeur sur notre production VPlex/VNX à la suite d’opérations d’ajouts et suppressions de LUN sur notre environnement (voir ce billet). EMC vient de publier un KB spécifique sur ce sujet et rappelle les conditions, le comportement exact et les solutions de contournement en attendant des patchs spécifiques en cours de réalisation.
Pas encore de date officielle de release de ces correctifs, mais d’après les informations que j’ai pu avoir, la fenêtre de livraison serait autour de Juin prochain. Pour plus d’info, rendez-vous sur la page du KB#478940 chez EMC : https://support.emc.com/kb/478940
Rappelez-vous, il y a quelques jours, je vous racontais l’histoire de notre gros incident avec VPlex. Pour résumer, il s’est produit lors d’un phase de provisionnement de LUNs depuis nos VNX vers VPlex, couplé à une forte charge des baies en question. Le concours de plusieurs facteurs, expliqués dans le billet, nous avait conduit à perdre la visibilité de tous nos datastores temporairement sur nos ESXi, avec les conséquences que vous imaginez.
Entre temps j’ai découvert un outil assez génial, SexiLog, qui m’a permis de monter des tableaux de bord quasi temps réel de la latence et des IOps de nos nombreux datastores et en particulier ceux de notre TIER2, servis par les VNX.
Or, nous avons enfin pu relancer nos chantiers de migration, avec précaution évidemment ! Or, lors d’une opération de provisionning de LUN aujourd’hui, on a pu enfin constater DE VISU, l’impact d’une telle opération avec SexiLog !
Comme quoi, tout arrive… même l’improbable : nous avons connu notre premier incident “VPlex” il y a une petite semaine ! Et encore, pour parler d’incident, il faudrait parler de réel bug logiciel, ce qui n’est à proprement parler pas le cas, on va le voir. Nous avons subi récemment un incident majeur sur notre environnement de production TIER2. Plus exactement : nous avons connu une perte temporaire de presque la totalité de nos liens FC à nos datastores TIER2 pendant une trentaine de secondes. Les impacts sur nos VM ont été assez importants évidemment et je vous laisse à votre imagination pour le détail ;) . Ceci étant, tout est rentré dans l’ordre assez rapidement (sous moins de 2 heures au total) et malgré quelques soucis applicatifs détectés au fil de l’eau pendant encore quelques heures supplémentaires, plus de peur que de mal. Comme quoi, toute la couche SAN de VMWare est tout de même extrêmement robuste.
Mais que s’est-il donc passé pendant ces 30 secondes fatidiques ?
Il était une fois …
Si vous disposez, comme nous, d’une ou plusieurs baies VNX Unified disposant d’une tête NAS Celerra en plus de la partie Block classique, vous avez sans doute déjà été confronté quelques fois à une certaine pollution des alertes au sein d’Unisphere par des tonnes de messages provenant de la partie NAS. Même si la supervision de la partie File est importante, personnellement je trouve que ces alertes sont beaucoup trop verbeuses et surtout ne sont pas du même niveau de criticité que pour la partie Block.
Pour autant, je vous conseille de garder cette petite astuce dans vos “tips & tricks” de production, pour le cas où. Allons-y :)
Depuis le mois de septembre, EMC a alerté de nombreux clients au sujet de problèmes de stabilité des VNX1/2 lors de mises à jour de leur code. Comme déjà évoqué ici et ici, l’affaire est relativement complexe et assez lourde à gérer. Et comme si cela ne suffisait pas, un nouvel ETA, le numéro 207784, est sorti le 10 Novembre dernier concernant, encore une fois, un souci dans la gestion du VAAI sur ces mêmes baies.
Je ne saurais que trop vous conseiller, si vous n’avez pas encore été contacté, de créer un SR auprès d’EMC pour pouvoir procéder rapidement à ces mises à jour. Prenez le temps de les faire car les risques sont réels. De plus EMC recommande de passer ces patchs même si vous êtes sous VPlex.
Pour plus d’info, rendez-vous sur le site du support, à cette adresse :
https://emc–c.na5.visual.force.com/apex/KB_ETA?id=kA37000000002YT
Après la mise à jour de nos VPlex en 5.4 sp1p1 ainsi que nos XtremIO en 4.0.1-7 en Septembre dernier, nous avions prévu d’upgrader aussi nos VNX7500 au dernier FlareCode et code Celerra en date histoire que tout notre back-end soit bien à jour pour la fin de l’année. C’est un cycle que l’on essaye d’appliquer tous les ans, au minimum, afin de correctement entretenir tout notre réseau de stockage (y compris les switchs FC bien sûr).
Malheureusement, il semble que le flarecode dont nous partons, le 5.32.000.5.215 ait pas mal de bugs bien ennuyeux, notamment lorsque VPlex est impliqué dans la chaine de stockage ce qui est notre cas. Plus précisément, deux ETA critiques sont dans la balance aujourd’hui. Voyons cela de plus prêt.