Le manuel du parfait plombier VSAN (maj continue)

Dernière mise à jour : 18/02/2021

Depuis que VSAN est arrivé sur nos infrastructures de production et que, par le truchement de quelques incidents, nous avons un peu progressé dans la connaissance et la maîtrise de cette technologies je vous propose de recenser les différentes infos et commandes utiles qui nous servent de plus en plus au quotidien. Je ferai évoluer ce billet spécifique au fur et à mesure de nos découvertes ! Evidemment, si vous avez des hints & tips à rajouter, n’hésitez pas non plus à me contacter directement ou a ajouter des commentaires à ce billet.

La liste des mises à jour se trouve en fin de billet. Ajoutez-le à vos favoris, au cas où !

Comment qu’il torche le petit cluster ?

J’ai eu l’occasion pendant la grosse mise à jour de mon vLab perso sur vSphere 7, d’avoir ponctuellement des pb de négociation sur mes liens ethernet. Dans la pratique c’était assez difficile de vraiment vérifier en live, en dehors de l’usage des tests de performance disponibles via l’interface html de vSphere… jsuqu’à ce que je découvre que l’outil “iperf” était intégré aux distributions ESXi 6.x/7.x ! Mon tour n’a fait qu’un sang ^^. Dans la pratique, cette outil permet de faire des tests temps réels de débit sur vos interfaces réseau. Sont usage est extrèmement simple : vous mettez en serveur en écoute et vous lancer un transfert bulk en mode client depuis un autre vers l’adresse cible. L’adresse étant souvent liée à un vmk précis, vous pouvez faire des tests dans tous les sens. Exemple : j’ai deux ESXi qui sont au sein d’un cluster VSAN et je veux tester les débits actuels entre les deux machine :

Pour obtenir les débits dans le sens “serveur cible -> serveur source”, on va lancer iperf en mode serveur sur le serveur source, après avoir temporairement désactivé le pare-feu intégré de ESXi (ou avoir positionné l’ouverture du port iperf) :

D’après ce que j’ai compris, le vmkkernel interdit l’utilisation de iperf par défaut iperf en mode serveur, on doit donc d’abord copier l’exécutatble sous un autre nom pour pouvoir activer ce mode. Ensuite coté “serveur source”, vous lancez iperf en mode client en pointant l’ip du “serveur cible”.

Le transfert dans le sens cible-> source commence. Toutes les secondes vous voyez un état du transfert en cour. Si vous voulez tester votre full-duplex, faites l’opération dans l’autre sens. Les options de ligne de commande sont extrêmement simples et se comprennent assez facilement je pense ;)

N’oubliez pas ensuite de réactiver le pare-feu ou refermer le port ouvert précédemment.

Comment qu’il va le petit cluster ?

Pour ceux qui ne sont pas encore en vSphere 6.7, aller voir rapidement l’état de votre cluster VSAN est plutôt très lourd, via le client Flash. Un méthode, de mon point de vue, beaucoup plus efficace est de passer par une petite session ssh sur un serveurs ESXi :

Cette commande, lorsqu’elle est lancée, réalise en même temps un refresh et vous donne l’état global de votre VSAN à l’instant T. Si tout est “green” (Moultipass … désolé ^^), c’est que tout va bien, si vous avez du “red” ou du “yellow”, vous devez avoir des alertes équivalentes dans votre interface vSphere et vous pouvez, dans la foulée utilisez cette commande pour en savoir un peu plus sur l’alerte :

Sur l’exemple ci-dessus, vous avez le détail du métrique “Disk format version” en erreur. Vous noterez que vous devez indiquer le nom exact du métrique dans la commande pour obtenir le résultat. Ces commandes peuvent aussi vous aider à récupérer rapidement des informations sur la configuration de votre environnement. Exemple suivant :

A la suite d’un problème sur votre VSAN ayant entraîné la perte temporaire d’un noeud ou une phase de maintenance d’un d’entre eux, par exemple, vous pouvez monitorer la reconstruction/resynchronisation sur chaque host :

A noter tout de même que la commande est “local” au nœud sur lequel vous vous trouvez, et pas cluster-wide, contrairement aux commandes précédentes.

Y va pas bien le petit cluster ?

Si vous êtes phase de remplacement d’un disque et que vous préférez la ligne de commande à l’interface web, vous pouvez piloter l’extraction du disque et sa ré-insertion après son remplacement. Pour se faire, vous avez trois groupes de commandes qui vont vous aider : “esxcli vsan”, “esxcfg-mpath” et “esxcfg-scsidevs”. Pour obtenir la liste (sur la machine sur laquelle vous êtes logguée) des disques VSAN configurés :

Chaque disque est identifié via son nom “hardware”, de type naa.XXXXXX, ainsi que son UUID VSAN, du type “52003dad-00fb-8539-9d6b-eca71b7f64a8”. Pour obtenir ses spécifications physiques, on peut utiliser esxcfg-scscidevs :

De même, on peut également récupérer son emplacement “physique” via esxcfg-mpath :

Vous noterez les informations sur la ligne “Adapter:” indiquant son identifiant SCSI. Enfin, il vous reste à vérifier sur l’iDrac/ILO ou tout autre interface de gestion hardware de votre serveur la correspondance de localisation de cette “target” sur le fond de panier.

Une fois le disque identifié, vous pouvez normalement, le supprimer/ré-inserer dans la configuration de VSAN via des commandes de type “esxcli vsan storage add” ou “esxcli vsan storage remove”. Cette commande accepte des noms de disque correspondant à leur “identité hardware”, c’est à dire du type “vmhba3:C0:T4:L0”. Dans le cas d’un cluster VSAN Full-Flash avec les options de réduction de données activées (Compression/Dédup), il vous faudra au préalable sortir tout le diskgroup dont fait partie le disque à remplacer. Dans ces conditions vous pouvez utiliser au préalable les commandes du type “esxcli vsan storage diskgroup mount/umount”. Pour ces cas d’usage, je ferai une mise à jour de ce billet avec des exemples concrets dès que j’aurais eu l’occasion de récupérer des traces de celles-ci. J’ai déjà eu l’occasion de les employer récemment, mais malheureusement, je n’ai pas eu la présence d’esprit de conserver les logs. En attendant, vous pouvez aller consulter le KB#2150567 chez VMware.

Pour récupérer l’ensemble des paramètres avancés de VSAN (ceux qui sont documentés, au moins ^^), il vous pouvez utiliser la commande esxcfg-advcfg :

… et pour récupérer la valeur d’un paramètre en particulier :

Pour connaître votre version de VSAN, au niveau de votre vCenter et sur chacun de vos ESXi, vous devez utiliser PowerCLI et une fonction spécifique “Get-VSANVersion” disponible sur le compte Github de VMware. Une fois importée, utilisez simplement celle-ci :

Si vous voulez voir lors d’un resync, la liste de objets en cours de consolidation :

… combien de volume vous reste-t-il à resynchroniser :

… mise à jour continue …
05/08/2018: Version initiale
24/09/2018: Récupérer/Modifier des paramètres avancés.
24/09/2018: Récupérer votre version de VSAN
23/04/2019 : Ajout des commandes de contrôle de resync
18/02/2021 : Usage de iperf, intégré à ESXi pour contrôler manuellement les débits entre serveurs.