050718_EC_numbers_feat

Faut-il suivre les best practices VMware ?

Depuis quelques mois maintenant, notre direction informatique est en effervescence. L’arrivée des fameux “GHT”, que le monde de la santé connait bien, n’est pas étrangère à cet état de fait. Cela m’a conduit à plusieurs reprise d’apporter des conseils (dans la mesure de mes moyens évidemment ^^) et/ou des éclairages sur des choix de nouveaux investissements, des avis ou des bilans sur des infrastructures existantes, voire présenter nos propres choix internes et les valoriser.

A ces occasions, viennent régulièrement sur la table des échanges autour de l’optimisation des environnements virtualisés : “combien de VMs par host”, “combien de VM par datastore”, “taille des datastores”, “doit-on tuner ESXi ou tout laisser par défaut” etc etc.. Ces questions sont difficiles car, comme tout architecte ayant pas mal “bourlingué”, pour moi, la réponse simple est toujours “ça dépend”. Certains pensent, à tord à mon avis, qu’une production bien “tunée” un jour, va le rester pendant 4/5 ans. L’expérience nous a montré à mainte reprises chez nous, que ce n’était jamais le cas et le maître mot ici reste le suivi et l’adaptation.

Vous le savez sans doute si vous me suivez régulièrement, j’essaye toujours de creuser a minima chaque technologie dans laquelle nous investissons pour avoir une idée précise de son potentiel et réagir le plus vite possible à des changements non anticipés (qui sont toujours au coin de la rue …). Cela passe par une lecture plus ou moins assidue des guides et “best practices” associés mais aussi à travailler un peu certaines variables d’ajustement potentielles, à la lumière de ces lectures.

Aujourd’hui, je souhaitais refaire un petit focus sur quelques unes des questions, souvent considérées comme fondamentales, qui reviennent le plus souvent autour de VMware vSphere et vous donner mon analyse et ma vision sur celles-ci. Je n’ai pas la prétention d’avoir évidemment raison quel que soit l’environnement et qu’il faille appliquer à la lettre mes recommandations, mais ce petit bilan est tout de même étayé par plus de 15 ans de virtualisation maintenant, doublé d’échanges réguliers et fructueux avec de nombreux ingénieurs brillants de partenaires intégrateurs, voire de VMware elle-même (lors de mes participations aux VMworld notamment).

Allons-y !

Lire la suite …

IMG_2420

vRealize Operations 6.7, partie 2 : au quotidien

Après un premier billet consacré aux grandes nouveautés et orientations de vROps 6.7, sorti il y a quelques semaines, cet article sera quant à lui dédié à son usage quotidien : comment nous en servons-nous, quels dashboards sont les plus utilisés et quelques exemples de tableaux de bord construits spécifiquement chez nous pour du suivi ou du diagnostic.

Ce billet est bien entendu à mettre en perspective avec les autres que j’ai pu rédiger sur d’autres produits, DCScope, SexiGraf en tête, mais aussi le plus récent sur Grafana. Sachez que j’utilise de toutes façons l’ensemble des approches de ces outils pour me faire une idée précise “des choses de la production”.

Lire la suite …

IMG_2418

TIP : Déplacer un groupe de VMs via PowerCLI

Histoire de convaincre ceux (sans doute rares désormais) qui n’ont pas encore franchi le pas de “PowerCLI”, l’interface de pilotage de vSphere via PowerShell, je vous propose en cette après-midi ensoleillé de découvrir un petit script simple et pragmatique pour déplacer “par paquet” une liste de VMs. Rien de révolutionnaire ici, mais plutôt un moyen beaucoup plus efficace de faire ce genre d’opérations courantes (notamment pendant des phases de migration d’environnement) que via l’interface graphique.

On y va ?..

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_2264

Quand les serveurs de Tesla toussent, la flotte s’enrhume ?

Aujourd’hui, Dimanche, et même si le sujet est un peu “décalé” par rapport à ceux que je traite sur ce blog, je ne peux pas résister à l’envie de vous parler d’une expérience récente avec un service connecté, celui de Tesla.

De retour de Rennes après une très belle soirée entre amis Vendredi (à faire de l’Astronomie tout en buvant du bon vin, le bonheur, en somme ^^), j’arrive en fin d’après midi dans mes pénates et branche la Tesla, qui criait famine après pas mal de Km parcourus ces dernières 24h. Comme je le fais souvent, je contrôle de temps en temps que tout se passe bien après quelques heures, via l’application iOS. Tiens ? Bizarre, pas de connexion. Pour autant, la voiture est connectée au Wifi et tout va bien du coté du Net. Certes, ponctuellement cela peut arriver, mais là, même après plus d’une heure, toujours pas d’accès aux paramètres de la voiture à distance.

Je vous passe les détails de la soirée, mais force est de constater vers 23h, après pas mal d’échanges sur les forums ad-hoc, que quasi tous les propriétaires de Tesla en sont au même point : impossible de se connecter à distance avec des impacts divers. Au final, il faudra attendre le début de matinée, ce Dimanche, pour retrouver une connectivité partielle et laborieuse/lente, quand elle aboutit.

Au delà du petit dérangement personnel occasionné (c’est fou comme on s’habitue au confort de ce genre de fonction), Que s’est-il passé et quels ont été les réels impacts de cette panne ? Prenons-nous au jeu et imaginons …

Lire la suite …

Image 007

Easyvirt DCScope v6 en avant-première

Bonjour à tous ! Vous le savez sans doute maintenant, nos chouchous de la Nantes’tech, Easyvirt, qui, au passage, étaient présent au dernier VMug Nantes, travaillent d’arrache-pied à améliorer continuellement leur produit phare, DCScope, si bien que son cycle de mise à jour est relativement rapide avec une version majeure tous les 8/10 mois environ. Et justement, Martin et son équipe m’ont encore fait l’honneur tout récemment de tester en avant-première leur nouvelle version “v6” qui devrait arriver en GA dans les prochains jours. Pour ceux qui n’ont pas eu l’occasion de lire mes précédents billets sur cet excellent produit de monitoring et capacity planning d’environnements vSphere, rendez-vous tout de suite ici et ici) avant de lire la suite. S’t’un’ordre !

Inutile de vous rappeler tout le bien que je pense de la société et de son produit phare, évidemment. Alors, ne traînons pas : petit tour d’horizon de DCscope v6 en mode “primeure”, pour ce printemps 2018 !

Lire la suite …

IMG_2240

vSphere/VSAN 6.7 sont annoncés !

C’est le buzz de cette après-midi : la nouvelle itération vSphere et, se faisant, VSAN sont de sortie sur la toile, vCenter 6.7 et ESXi/VSAN 6.7 ! Pour l’instant, on trouve surtout des infos sur VSAN en fait, avec un article de Duncan Epping dédié à consulter d’urgence ici ainsi qu’un article sur Virtual Blocks (chez VMware), à lire ici.

Je reviendrai sur les grosse évolutions de VSAN dans un article dédié dès que j’aurai eu un peu de temps pour décortiquer tout ça, mais si je devais résumer très rapidement : interface HTML5 pour VSAN (whooo !), de grosses améliorations coté stretched clusters et des optimisations diverses coté moteur.

A l’heure ou j’écris ces lignes, pas de téléchargement à se mettre sous la dent mais ça devrait arriver bientôt. Je vous propose de mettre à jour ce billet au fur et à mesure que tout cela se met en place concrètement.

Updates live :
La home page vSphere est à jour : https://blogs.vmware.com/vsphere/launch
– Nouveau billet de blogs.vmware.com sur les évolutions du jeu d’APIs REST de vCenter 6.7, ici.
– Nouveau billet de blogs.vmware.com sur vSphere 6.7 ici !
– La documentation technique de VSAN 6.7, par le menu, ici.
– Tous les liens vSphere 6.7 : téléchargement, release notes etc. par William, évidemment ^^, ici.
– Nouveau billet de Cormac Hogan sur vSphere/VSAN 6.7 (un must-read, comme toujours), ici.
NDLR :
– Rien que ça, déjà : nouvelles fonctions dispo dans le client HTML5 : Update Manager, Content Library, vSAN, Storage Policies, Host Profiles, vDS Topology Diagram, Licensing.
– Au sujet de VSAN 6.7, en vrac : le moteur vROps pour les stats VSAN au sein de vCenter 6.7, la couche iSCSI sait discuter “en mode cluster” (RAC, MCSC etc.), support des devices gérant des blocs de 4K, Adaptive Resync etc.

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 …