Photo-2015-08-12-10-16-25_7286

ESXi Embedded host client v3.0

Une nouvelle version du fameux client html5 autonome pour ESXi sur Flings est disponible depuis Vendredi dernier.

Parmi les nombreuses nouveautés de cette version 3, on trouve notamment :
– Un outil dédié a la gestion des partitions
– La possibilité de générer un CSR et se faisant demander une certification officielle pour l’identité du serveur à une PKI externe
– Un outil de mise à jour automatique (plus besoin d’installer le .vib à la main)
– L’ajout de nouveaux indicateurs de supervision comme les IO et le réseau
– De nombreuses améliorations générales de l’interface elle-même
… et plus encore …

Alors ? Toujours besoin du client lourd pour vous connecter directement à un serveur ESXi selon vous ? ;)

Toutes les infos sont disponibles sur la page dédiée à ESXi Embedded host client :
https://labs.vmware.com/flings/esxi-embedded-host-client

Enfin, si vous souhaitez en savoir plus sur cet outil, rendez-vous sur ce précédent billet.

Photo-2015-08-12-10-16-25_7286

VMWare host client pour ESXi !

Depuis vSphere 5.5, VMWare encourage énormément le passage aux outils d’administration web mis à disposition. Le vSphere Web Client a malgré tout été relativement mal-aimé avant vSphere 6 à cause, principalement, de sa lourdeur générale, du manque d’intégration de l’ensemble des fonctions (Update Manager notamment … toujours pas sur vSphere 6.0 d’ailleurs !!) et du changement d’habitude qu’il induisait pour les administrateurs (organisation différente du client lourd historique, difficulté relative d’accès à certaines fonctions spécifiques). Depuis la mise à jour majeure de l’écosystème de virtualisation, le client web a repris des couleurs, mais il lui manque une fonction essentielle, surtout en cas de gros incident : il est dépendant du fonctionnement de vCenter. Impossible de se passer du client lourd pour se connecter en direct sur les serveurs ESXi, en dehors de la ligne de commande et du SSH, bien entendu.

Et bien, cette lacune importante est en passe d’être comblée ! Par l’intermédiaire de William Lam, éminnent ingénieur de VMware et auteur de l’incontournable blog Virtually Ghetto, j’ai appris hier soir la sortie d’un “host client” pour ESXi full html5 ! On avait connu cela à l’époque de ESXi 5.x déjà, mais le client se bornait principalement à de la consultation et à la manipulation de l’état des VMs (si mes souvenirs sont bons …). Je vous propose de découvrir cette nouvelle perle de Flings dans ce billet.

Lire la suite …

Photo-2014-12-01-17-15-15_6089

A propos du nombre de chemins maximum adressable par ESXi 5.5

Mise à jour le 15/04/2015 : suite à la sortie de vSphere 6.0, j’ai été refaire un tour dans le document “Configuration Maximums” de cette nouvelle version majeure. Malheureusement, pas de changement dans le nombre de chemins, ESXi n’en gère toujours “que” 1024 max.

English sum-up :
Some concerns regarding the maxmimum FC paths count under ESXi 5.5

En balayant ma timeline Twitter professionnelle cette après-midi, un tweet a attiré mon attention : il s’agissait d’une référence à ce billet fort intéressant racontant l’expérience récente d’un ingénieur système ayant été confronté très concrètement à une “limite hard” de ESXi 5.5, le nombre de chemins total adressable.

Si, en général, les limites ESX sont souvent considérées comme “lointaines” pour des productions généralistes et plutôt moyennes en terme de nombre de VM (ce qui est notre cas avec un peu plus de 1000 aujourd’hui), on imagine mal les atteindre si vite… et pourtant.

Le document officiel de VMWare présentant les bornes supérieurs des différents éléments techniques constituant une configuration ESXi est librement accessible ICI. Notamment, on y trouve la limite de chemins par device et par host. Aujourd’hui, la version actuelle est donc capable de gérer au plus 8 chemins différents et surtout pas plus de 1024 chemins au total.

Par curiosité, et aussi titillé par cette limite “pas si élevée” finalement, j’ai utilisé mes merveilleux (^^) scripts de sélection de chemin dont je vous ai parlé ce week-end, pour savoir à combien nous en étions. Quelle ne fut pas ma surprise de constater que les machines les plus exposées en matière de devices géraient déjà plus de 730 chemins différents !

En effet, nous utilisons beaucoup les Raw Device Mappings, ce qui augmente significativement le nombre de devices d’un ESXi, évidemment. A raison de 8 chemins par device à cause de notre set-up VPlex en cross-connect, il va donc falloir être particulièrement vigilant et faire dans le “développement durable” en matière de publication de devices sur nos fermes de production…

A toutes fins utiles, je vous conseille donc, comme moi, de faire le point sur vos chemins ESXi. La commande est simple et réalisable via l’interface CLI en SSH :
esxcfg-mpath -L | wc -l

Vous obtiendrez en retour le nombre de chemins déclarés, à comparer au fatidique et – pour le moment, en attendant ESXi 6.0 – définitif 1024 ;)

Sources :
– Ce billet chez “MindTheVirt” http://www.mindthevirt.com/esxi-fibre-channel-configuration/
– Le KB VMWare qui explique le problème http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1020654
– Le PDF de référence contenant l’ensemble des limites d’ESXi 5.5 http://www.vmware.com/pdf/vsphere5/r55/vsphere-55-configuration-maximums.pdf
– Le PDF de référence contenant l’ensemble des limites de vSphere 6.0 https://www.vmware.com/pdf/vsphere6/r60/vsphere-60-configuration-maximums.pdf

Photo-2014-06-10-11-05-42_5420

Scripts de gestion des chemins FC sous ESXi avec VPlex

English sum-up :
Some shell scripts to statically select a preferred path within all FC paths availables on an ESXi connected via VPlex metro.

MAJ 30 Novembre 2014 : quelques corrections de bug dans les scripts (test de connexion notamment).

Je vous en avais parlé il y a quelques mois (voir ce billet), nous n’utilisons pas – encore – PowerPath VE pour nos serveurs ESXi et nous travaillons donc avec le MPIO intégré en mode “Fixed/Preferred” de VMWare. Pour le coup, cela nous oblige à sélectionner “à la main” des chemins préférés correspondant bien au cluster local de chaque ESXi dans notre infra VPlex Metro. Pour plus de précision à ce sujet, je vous renvoie une seconde fois au billet précédent sur ce sujet.

Nos scripts historiques étaient certes très précis et fonctionnaient bien, mais il leur manquait une qualité importante : la vitesse ! En effet, pour parcourir l’ensemble des devices FC d’un ESXi, vérifier les chemins préférés et les modifier éventuellement, cela prenait du temps… beaucoup de temps, via les commandes esxcfg-XXX et esxcli. Désormais, il n’est pas rare d’avoir, pour un ESXi donné, quasiment une centaine de devices différents. Au final, cela représentait des heures de parcours sur l’ensemble de nos machines.

Il fallait accélérer tout cela et c’est désormais chose faite ! Vous allez le voir dans la suite, les nouveaux “turbo-scripts” sont beaucoup plus rapides (une à deux minutes par serveur disposant de plusieurs dizaines de device), mais il a fallut sacrifier un peu les tests préalables et l’inspection de chaque device, l’un après l’autre. La nouvelle méthode traite tous les devices en une seule fois, sans vérifier si toutes les commandes sont couronnées de succès. Ceci étant, l’expérience nous a montré que dans l’ensemble, toute cette mécanique fonctionnait globalement très bien et de manière fiable. La confiance aidant, voici donc le résultat : des scripts simples, efficaces, rapides et directement “publiables” sur ce blog car extrèmement génériques (contrairement aux précédents).

Lire la suite …

unnamed

VPlex/VE : GA, enfin :)

Bonjour à tous,

Il y a quelques semaines je vous avais annoncé la disponibilité prochaine de VPlex/VE, la nouvelle itération de EMC VPlex en environnement full virtuel. Désormais, les documentations sont disponibles sur le site du support EMC et nous pouvons donc commencer à tester tout cela ! Dans son ensemble, VPlex/VE reprend bien entendu tous les concepts qui ont fait le succès de VPlex.

Concernant les plateformes supportées, VPlex/VE ne s’appuie, pour le moment, que sur VMWare ESXi 5.x (5.0/5.1/5.5). Il est compatible avec Powerpath/VE 5.9 ainsi que via MPIO VMWare classique. Le périmètre du support production couvert aujourd’hui s’appuie sur une ferme de serveurs ESXi configurés en stretched clusters entre les deux sites “en mode Metro”. Voici le schéma proposé dans le white paper EMC :

Capture

VPlex s’appuie donc sur 4 vDirecteurs, répartis sur 4 hyperviseurs, sur chaque site. La fourniture des storage-volumes est pour le moment exclusivement assuré par le biais du protocole iSCSI (pas de RDM ou même un VMDK en direct). Comme pour son grand frère physique, chaque cluster (1 par site, donc) est géré par une management station :

Capture

EMC insiste sur le fait que le stretched cluster VMWare ne doit être constitué que de liaisons IP dont la latence RTT (aller/retour) est inférieure à 10 millisecondes. Chaque directeur doit en outre être hébergé par un ESXi différent, pour assurer le niveau de disponibilité équivalent à un VPlex physique.

Cette infrastructure, relativement complexe à mettre en oeuvre malgré tout, permet d’utiliser les distributed devices spécifiques à la technologie d’EMC VPlex Metro sans avoir besoin d’une solution physique dédiée plus traditionnelle. On imagine donc que chaque cluster vPlex est client de baies iSCSI, mais présente également ce stockage en iSCSI aux serveurs sur lesquels ils ont eux-même hébergés. On peut imaginer qu’un stockage local sur chaque ESXi pourrait être dédié à l’hébergement des vDirecteurs et des management consoles, le reste des datastores partagés sur le cluster VMWare étant, précisément, fourni par ces même directeurs à travers des connexion iSCSI. Dans ces conditions, EMC annonce que la latence globale des accès au stockage primaire sera augmentée, par rapport à un accès direct, bien évidemment.

Si je dispose d’assez de temps cet été, je vais essayer de préparer un PoC dédié pour évaluer le potentiel réel de VPlex/VE, ne serait que, dans notre cas spécifique, pour disposer d’une plateforme de test/bac à sable VPlex.

Pour ceux qui ont un accès au support EMC, voici le lien vers le whitepaper EMC VPlex/VE.

unnamed

Bug iso “HP” d’ESXi 5.5 : Unable to connect to the MKS …

Une petite info en ce début d’année concernant la distribution HP de ESXi 5.5. Nous avons été confronté récemment à des soucis de connexion aux consoles locales de nos machines virtuelles sur certains serveurs ESXi 5.5.

Après investigation, il s’avère qu’un service spécifique aux ISO HP, “hp-ams”, a visiblement des fuites mémoires, dans la version 5.5 build 1331820 (ce service HP “Agentless Management Service” assure la supervision hardware de la machine depuis un serveur Insight Manager). Pour corriger le problème, connectez-vous à votre serveur ESXi sous SSH (en activant préalablement cet accès depuis la configuration sécurité, si ce n’est pas déjà fait) et arrêtez ce service. Si vous l’utilisez, vous pouvez au moins le relancer, quitte à le faire régulièrement, en attendant un correctif de la part de VMWare ou HP. A priori, le support VMWare a annoncé travailler dors et déjà à un correctif qui devrait être intégré lors de la publication de l’update1 de ESXi 5.5 (qui ne devrait pas tarder, normalement).

A suivre !

unnamed

Accélerer le boot de vos ESXi 5.x (maj)

MAJ du 14/05/2013 : petite précision sur les locks SCSI associés.

Si vous utilisez beaucoup les Raw Device Mappings, ou RDM dans le jargon VMWare, vous avez sans doute noté un ralentissement notoire de vos ESXi lors de reboot pour maintenance ou mises à jour diverses. En fait, ce ralentissement est dû au polling de toutes les LUNs RDM, notamment pour détecter d’éventuels VMFS, qui peut être ralenti à cause de locks SCSI (notamment les RDM utilisés par des clusters MSCS).

Lire la suite …