NSX-T pour les nuls, partie 3 : voyage au pays des merveilles

Dans les deux premières parties de ma série « NSX-T pour les nuls », nous avons découvert d’abord comment installer le minimum vital pour un environnement fonctionnel. Je vous propose de découvrir dans cette troisième partie la création d’un segment « service », l’ajout d’un service DHCP à notre routeur TIER0 et enfin l’intégration d’une VM dans cet environnement.

Mise à jour VxRail 4.5 vers 4.7. Que s’est-il vraiment passé ?

(MultiEDIT en fin d’article) Et oui, j’ai été un peu trop optimiste sur ce coup là. Mon dernier billet de compte-rendu que vous pouvez lire ici-même semblait en témoigner, le chantier de mise à jour récente de notre gros cluster VxRail ne s’est, au final, et après plusieurs semaines, pas si bien passé que cela. Plutôt que mettre à jour l’article original, comme j’ai pas mal de choses à vous raconter, j’ai préféré en créer un nouveau. Le voici.

NSX-T pour les nuls, partie 2 : prenez la pilule rouge …

Après une première partie assez facile finalement, on va rentrer un peu plus dans le coeur du produit cette fois-ci en créant une petite topologie purement NSX-T avec de l’overlay, du edge node et du logical router. Super simple, vous allez voir. Quoi, vous n’êtes pas convaincu ? Prenez la pilule rouge et suivez-moi au fond du gouffre…

NSX-T pour les nuls, partie 1 : installation et découverte

Mesdames, messieurs, Oyé Oyé, après moult discussions et un petit sondage rapide complètement pas représentatif sur Twitter, il semble qu’entre une découverte de vRealize Network Insight et NSX-T, ce dernier l’emporte largement. Je vais donc commencer, dans la mesure de mes moyens comme toujours, de vous faire découvrir (presque en même temps que moi en fait), NSX-T 2.4, depuis son installation jusqu’à, j’espère, son exploitation au quotidien après quelques mois en production (d’ici fin 2019).

Projet NSX-T : Le design

Deuxième billet de ma série sur notre grand projet NSX-T, en cours actuellement (lire le premier ici). Au menu, aujourd’hui, je vous propose de vous présenter les choix d’implémentation décidés avec l’aide de VMware, des versions cibles ainsi que des chantiers « pré-requis » qui en découlent. C’est une étape crucial qui s’est jouée ces dernières semaines et nous avons, je crois, accouché d’un design qui correspond parfaitement à nos besoins.

vROps : devenez un super-héros des SuperMetrics

Lors d’une petite discussion sur le slack VMUG avec certains éminents collègues et compagnons de route, une demande spécifique d’un client a amené le collègue en question à se demander si, par le plus grand des hasards, un SuperMetric ne serait pas la solution. La question était pourtant, en apparence, simple : « je voudrais remonter le CPU moyen des VMs d’un dossier ». Je vous arrête tout de suite, ne cherchez pas, le metric en question n’existe pas dans vROps. Alors, pouvions-nous nous en sortir avec ces fameux SuperMetric, obscurs et pleins de promesses ?

Ne sous-estimez pas la consommation réseau de VSAN…

A l’occasion de la migration de l’ensemble de notre environnement Exchange (6 serveurs de production, 3 serveurs d’archive, quelques dizaines de To et pas moins de 16000 BALs, tout de même), j’ai été confronté, pour la première fois, à quelques limites de notre cluster VxRail principal, dit « le monstre », dont j’ai déjà longuement parlé depuis environ un an. Plus exactement, ce n’est pas le cluster VSAN lui-même qui a atteint ses limites, mais plutôt le réseau DataCenter sur lequel nous l’avons bâti !

Quand vCenter 6.0 se rebelle après une expiration de certificat…

Deux jours de galère, de lecture de KB divers zé variés, une douzaine de rollback de snapshots, pour tenter une douzaine de manipulations différentes et enfin, trouver la solution (temporaire). Voila en substance le bilan de l’expiration d’un certificat SSL sur un « vieux » vCenter 6.0 que nous gardons encore pour quelques machines spécifiques. Petit récit de la mésaventure de cette semaine !

VMSA-2018-0027, un patch critique pour les hyperviseurs VMware

Il y a quelques jours (le 31 Octobre), la société Chaitin Tech, spécialisée dans la sécurité, a annoncé qu’un de ses employés avait réussi à obtenir un accès au shell d’un ESXi en mode root depuis une VM hébergée sur celui-ci. Au delà de la performance technique, assez exceptionnelle il faut bien le dire (je n’ai pas de souvenir récent qu’il y ait déjà eu un tel exploit de découvert), cela signifiait pour nous tous un risque non négligeable de hacking pour nos hyperviseurs hébergeant des VMs exposées au 4 vents.