IMG_3160

Bug VSAN : le patch est disponible !

EDIT: Dell EMC n’a pas traîné à annonce la disponibilité prochaine de VxRail 4.5.225 qui contiendra, entre autres, le fameux patch. Merci à Noham, Didier et David pour les infos concordantes.
EDIT2 : Voici les release notes de la build 225 de VxRail, à consulter ici (pour les clients Dell EMC).

Tout le monde l’attendait impatiemment depuis quelques jours, il est là, disponible, maintenant, le fameux patch qui corrige les problèmes de corruptions VSAN dans certaines conditions particulières (voir mes deux billets à ce sujet, ici et plus récemment ici). Son détail est décrit dans le KB#58853 pour la 6.5 et dans le KN#58849 pour la 6.7. Par ailleurs, le KB “historique” KB#58715 a été complété par des informations concernant le patch en question.

Si vous êtes sur du VSAN ready node, aucune raison de ne pas préparer une maintenance spécifique ASAP. Si vous êtes sur VxRail, l’ETA a été publié auprès des clients hier soir et on devrait avoir des nouvelles, j’espère, assez rapidement. Dans l’intervalle, ouvrez un case chez Dell EMC, pourquoi pas :)

Pour rappel, le suivi live des patchs des différentes build d’ESXi : pour la 6.5 ici, pour la 6.7 ici.

IMG_2769

Point de situation sur le bug resync/extend/resync de VSAN 6.6+

EDIT du 16/10/2018 : on vient d’avoir la confirmation que les corruptions peuvent aussi survenir lors que l’on réalisé un expand sans que celui ne déclenche l’ajout d’un component.

Mon précédent billet sur le sujet faisait état d’un bug sur les dernières versions de VSAN à partir de la 6.6.0 pouvant, dans certaines conditions, mener à des corruptions de données sur certaines VMs “à risque”. L’heure est venue, je pense de faire le tour de la question après pas mal de rebondissement depuis quelques jours.

Il a été difficile d’arriver à obtenir des informations claires pendant cette période et le caractère éminemment critique de ce bug (la corruption de données étant, sans doute, le pire scénario pour un constructeur ou un éditeur de solutions de stockage quel qu’il soit) a forcément généré pas mal d’anxiété parmi les clients de VMware et Dell EMC ayant des productions sur ces versions. la récente communauté VMUG France a été particulièrement active à cette occasion et a d’ores et déjà prouvé, s’il en était encore besoin, tout son intérêt, notamment pendant ces périodes tendues.

Je vous propose donc un nouveau billet précis et donnant des informations vérifiées et confirmées par le support VMware.

Lire la suite …

IMG_3160

VSAN 6.6/6.7 : attention aux extensions de vmdk sur vos VM (maj)

EDIT5 du 27/09/2018 : J’ai créé un autre article qui fait un point de situation global.

Bonsoir à tous !

Ca fait plaisir de vous retrouver après plus de 15 jours d’absence. La cause : un début de rentrée assez dingue pour ce qui me concerne. Cela explique, sans l’excuser, le désert de news sur vBlog, alors que l’actualité est pourtant riche en ce moment (VMUGFR, retour sur les annonces du VMworld 2018 de Las Vegas, quelques REX sur des gros incidents récents sur notre prod etc. …).

Je rouvre les vannes techniquement en vous faisant part d’une alerte sur laquelle tous les admins VSAN devraient être vigilants. A l’occasion du reboot VMUG France qui s’est tenu hier matin à Paris (c’était génial, mais je vous ferai un billet spécial ce week-end), j’ai eu l’occasion d’échanger avec des éminents collègues au sujet de nos productions respectives et ils m’ont fait part d’un bug bien inquiétant rencontré depuis plusieurs semaines chez eux. Il porte sur des cas spécifiques de corruption de données sur leurs environnements Exchange tournant sur VSAN, précisément. VMware est bien entendu sollicité et en cours de qualification/caractérisation actuellement.

Oops, même si ce n’est pas une généralité (cela n’a rien de systématique), la corruption de données n’est jamais à prendre à la légère sur un support de stockage, quel qu’il soit. Voici quelques détails des conditions particulières pouvant conduire à cette extrémité.

Lire la suite …

IMG_1995

Quotidien VxRail : retrouver des nodes disparus (les pauvres)

EDIT : Apparemment, ce n’est pas encore réglé en 4.5.210 , merci à Maxime (Twitter: @mhercelin) pour l’info !
EDIT2 : Je viens de recevoir une confirmation que les dernières versions (je n’ai pas le build exact) de VxRail intègrent bien la correction de ce bug, bonne nouvelle ! Par contre, il faut bien vérifier les numéros de build des iDrac aussi. Contactez la hotline Dell EMC pour le demander de faire le ménage et de mettre tout à niveau

Depuis plus de deux ans maintenant, nous investissons massivement dans VxRail, la solution hyper-convergé de Dell EMC. Il nous est arrivé pas mal de misères, surtout assez récemment avec les plateformes hardware. J’en ai d’ailleurs pas mal parlé à l’occasion de plusieurs billets sur le sujet. Heureusement, tout cela est désormais du passé ?

Du passé ? Mmmmmhh, oui… et non. Certes, l’immense majorité des soucis initiaux ont été réglés et VxRail constitue désormais un pilier de production pour nous. Fiabilité de VSAN, performances à la hauteur, réduction de données dans la bonne moyenne, les résultats sont là en terme de service. Mais, malgré tout, il reste encore des petits ennuis ponctuels, qui, s’ils ne remettent plus en cause notre choix, sont quand même pénibles. L’un d’entre eux est lié à des bugs résiduels dans l’interfaces IPMI des iDrac sur plateforme Dell PowerEdge. En effet, de manière aléatoire, certains serveurs “disparaissent” de la console VxRail et ne sont de facto plus supervisés par le manager éponyme.

Maiiiis, il y a une solution assez simple pour remédier au problème, en attendant une prochaine release plus stable de ce point de vue. La voici !

Lire la suite …

18-03-26 16-55-35 1989

“Le monstre” VxRail est en production !

Après avoir expérimenté, puis déployé sur des cas d’usage précis, nous y sommes désormais, notre “TIER2” historique, un peu plus de 600 VMs de production institutionnelle, commence à migrer vers un nouveau cluster VxRail, dit “Le monstre” chez nous. Le chantier d’installation s’est déroulé parfaitement, sans retard ni gros problèmes techniques, entre le mois de Février et la fin du mois d’Avril. Il s’agit maintenant de réaliser la montée en charge, après la signature de la “Vérification d’Aptitude”.

Retour sur une épopée VxRail dont le commencement date du mois de Janvier 2016.

Lire la suite …

18-05-15 15-39-17 2372

Grafana, pour les gouverner tous

Le nerf de la guerre dans toute production informatique d’envergure, c’est la supervision. Vous le savez tous, rien n’est pire que d’être aveugle quand il s’agit de suivre et d’entretenir comme il se doit tous les composants qui participent au fonctionnement général de nos systèmes d’information. A l’opposé, il serait illusoire d’imaginer qu’un seul et même outil puisse couvrir tous les besoins en la matière : certains seront plus orientés “diagnostic temps réel” (comme VMware Log Insight, SexiLog par exemple), d’autres au contraire seront plus adaptés à un suivi moyen ou long terme, avec des courbes de tendances et/ou des outils de simulation de type “What If”. Enfin, suivant la diversité des équipements et constructeurs impliqués, on va plutôt privilégier “des intégrés” (comme vRealize Operations ou Turbonomics) ou se tourner vers de l’Open Source riche en plugins et très ouvert aux évolutions.

En somme, il n’y a pas de solution miracle et pour le coup, cela me pousse régulièrement à tester de nouveaux produits, histoire de voir si par hasard, l’herbe ne serait pas plus verte ailleurs … C’est là que démarre le sujet de ce billet.

A la suite de nombreux échanges avec mon pote Erwan Quelin, que j’ai connu il y a déjà plus deux ans à l’occasion du VMworld 2016, nous avons décidé de nous rencontrer pour démarrer une collaboration autour, au départ, de la supervision des baies Unity. Il se trouve en effet qu’Erwan venait de terminer le développement de la v1 de UnityMetrics, un outil open source capable d’interroger l’API REST d’une baie et d’en récupérer les divers points de supervision et les restituer au format “Telegraf” (j’y reviendrai).

Histoire de remettre cette initiative dans le contexte, les Unity disposent aujourd’hui, certes, d’un super outil “Cloud” géré par Dell EMC, CloudIQ. Malgré tout, je trouvais intéressant de conserver des metrics en local pour le capacity planning et de disposer d’une accessibilité plus directe par nos équipes de production. Il me fallait un framework adapté pour construire cela. D’autre part, je voulais depuis longtemps me mettre à Grafana… les planètes étaient donc parfaitement alignées pour travailler sérieusement et profiter de l’expertise d’Erwan sur ce sujet.

Dont acte, décision est prise de se voir… ce n’était que le début, tout de suite, la suite !

Lire la suite …

IMG_2239

Alertes “ping” sur votre VSAN 6.6 : je vous demande de vous arrêter !

J’en parlais la semaine dernière avec Noham de MyVMworld.fr lors un petit échange sur Twitter : notre tout nouveau cluster VxRail en cours de mise en production nous affiche régulièrement des alertes “Warning” lors de ses tests de santé. Noham évoquait à l’époque une limitation à 200 echo-reply par seconde maximum sur les ESXi qui pourrait être la cause de ce comportement.

Entre temps, le week-end est passé et Noham a sorti, avec un timing parfait un nouveau billet sur MyVMworld.fr revenant justement sur un certain nombre de points autour VxRail. En fin de billet, il a linké un KB spécifique qui parle précisément de ce bug VSAN (comme c’est curieux ^^).

Du coup, je me suis rué dessus pour vérifier si c’était applicable à notre monstre : la suite en image et en texte !

Lire la suite …

img_9631

VxRail et son adolescence tourmentée, VSAN et sa trentaine triomphante

Je vous avais fait part il y a quelques temps de mon “rognotudju” au sujet d’un de nos clusters VxRail, victime d’une panne hardware qui n’en finissait pas et sur laquelle le support Dell EMC avait été franchement mauvais. Depuis, ce souci a été enfin résolu, courant Janvier 2018 (quand même, plus de 3 mois elapsed …) et tout fonctionne bien depuis, ouf.

Sauf que, entre temps, c’est un nouveau cluster flambant neuf chez nous, équipé de 6 Noeuds full-flash Dell PowerEdge, qui nous a encore réclamé une attention de tous les instants.

Petit récit à la Dallas de cette épopée…

Lire la suite …

17-12-01 15-06-55 1565

Rognotudju du Vendredi : Allo, le support VxRail ?

EDIT du 04/12/2017 à 10h25 : Quelques précisions concernant la panne et les nouveaux délais … buarh.

Hé oui… désolé pour Dell EMC, ça tombe encore sur vous, mais vous cherchez un peu par moment, aussi, hein, en même temps ! Après le joli troll du service logistique en Mars/Avril dernier, c’est désormais du coté du support VxRail que ça se passe. Le 10 Octobre dernier, nous avons eu un gros incident sur l’un de nos clusters : un des nœuds a perdu d’un coup tout ses disques VSAN. Oops ! Bon, déjà quand un comportement de ce type se produit, a priori, comme ça, à vue de nez, en mode intuition, avez la réserve nécessaire … on s’imagine que ça sent quand même pas mal le problème hardware, un fond de panier en vrac, par exemple ou carte SAS plantée. Ceci étant, le SR est ouvert et le travail de collecte et de diagnostic commence de la part de la hotline.

En terme de fonctionnement, pas d’impact majeur, grâce au FTT1 appliqué sur l’ensemble des machines virtuelles, mais assez sérieux pour que nous suivions le call de près, même si par définition, un VxRail, ça s’installe … et ça s’oublie ou presque, en théorie du moins. De plus, comme cela ne concernait que les disques du nœud, la partie Hyperviseur pur continuait à marcher. Nous avions donc un compute opérationnel mais un VSAN sur 2 pattes au lieu de trois, pas si gênant que cela vu le workload hébergé sur ce VxRail : des machines de Test/Pré-production.

Maintenant, comme vous pouvez le constater, nous sommes le 1er décembre et le noeud n’est toujours pas remplacé. Pendant ces derniers 50 jours, nous avons eu droit à des tonnes de tests sur VSAN, des bascules diverses, des reboots, sessions Webex, des visites sur site de nos chers collègues d’EMC Nantes (qui font ce qu’ils peuvent pour nous aider) et j’en passe. Aujourd’hui, le nouveau noeud de remplacement (ENFIN ! c’était si dur de le changer plus tôt en se posant un peu moins de questions métaphysiques sur l’univers et tout le reste ?) est chez nous depuis 10 jour, à la louche, mais toujours pas branché et pas de news récente… désespérant :(

Alors, bon, je veux bien être early adopter sur des workload non critiques, mais faut pas pousser le bouchon un peu trop loin Michael…

Bonne fin de Vendredi et bon week-end à tous !

EDIT : L’aventure continue ! En fait, j’avais effectivement oublié, comme me l’ont justement rappelé mes collègues de la production, que ce n’était pas le noeud seul, mais carrément tout le fond de panier qu’il fallait changer (oops !). On vient de nous annoncer qu’en plus le nouveau chassis ne sera pas disponible avant la mi-décembre. Et bien sûr, il va falloir arrêter tout le bouzin pour pouvoir réinsérer les noeuds dans le nouveau hardware… chouette !

photo-2016-11-21-17-40-16_9642

VxRail ou l’art difficile de faire du plug’n play

Je vous ai conté à plusieurs reprises ici notre volonté d’investir en 2016 dans VxRail. L’objectif était à l’époque de pouvoir réellement confronter cette plateforme Hyper-Convergée à la situation d’une production réelle (en prévision d’un investissement éventuel beaucoup plus massif en 2018). Cela s’est traduit à l’époque par l’acquisition de deux clusters VxRail séparés : un cluster 3 Noeuds autonome pour héberger notre “pré-production” et un cluster 2×3 Noeuds en mode stretched pour absorber l’ensemble de nos “machines d’administration” (rendez-vous dans la section VxRail de ce blog pour plus d’info).

Même si l’architecture VxRail est, au départ, basée sur un regroupement de logiciels issus du même éditeur, VMware en l’occurence, placé sur une plateforme hardware industrielle, il ne faut pas sous-estimer la difficulté pour un constructeur, fut-il EMC, de produire et assurer la maintenance de tels environnements. On imagine souvent, à tord, qu’il s’agit juste de monter un bundle, y affecter une ligne de support dédié et “zou, on peut faire du business”. Non, définitivement, l’affaire n’est pas si simple.

Preuve en est, appuyée par notre propre expérience récente de client VxRail, que cet exercice reste un travail complexe et de longue haleine.

Lire la suite …