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) :

[root@zeus:~] esxcli network firewall set --enabled false
[root@zeus:~] cp /usr/lib/vmware/vsan/bin/iperf3 /usr/lib/vmware/vsan/bin/iperf3.srv
[root@zeus:~] /usr/lib/vmware/vsan/bin/iperf3.srv -s -B 172.16.16.101 -V
iperf 3.1.6
VMkernel zeus 7.0.1 #1 SMP Release build-17551050 Feb  1 2021 09:59:12 x86_64
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------

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 ».

[root@cronos:~] esxcli network firewall set --enabled false
[root@cronos:~] /usr/lib/vmware/vsan/bin/iperf3 -c 172.16.16.101 -V -t 5
iperf 3.1.6
VMkernel cronos.vlab 7.0.1 #1 SMP Release build-17551050 Feb  1 2021 09:59:12 x86_64
Control connection MSS 1448
Time: Thu, 18 Feb 2021 09:28:48 GMT
Connecting to host 172.16.16.101, port 5201
      Cookie: cronos.vlab.1613640528.447625.79e3a5
      TCP MSS: 1448 (default)
[  4] local 172.16.16.102 port 14468 connected to 172.16.16.101 port 5201
Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 0 seconds, 5 second test
iperf3: getsockopt - Function not implemented
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec   270 MBytes  2.27 Gbits/sec  8634728   0.00 Bytes
iperf3: getsockopt - Function not implemented
[  4]   1.00-2.00   sec   279 MBytes  2.34 Gbits/sec    0   0.00 Bytes
iperf3: getsockopt - Function not implemented
[  4]   2.00-3.00   sec   279 MBytes  2.34 Gbits/sec    0   0.00 Bytes
iperf3: getsockopt - Function not implemented
[  4]   3.00-4.00   sec   279 MBytes  2.34 Gbits/sec    0   0.00 Bytes
iperf3: getsockopt - Function not implemented
[  4]   4.00-5.00   sec   280 MBytes  2.34 Gbits/sec  4286332568   0.00 Bytes
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-5.00   sec  1.35 GBytes  2.33 Gbits/sec    0             sender
[  4]   0.00-5.00   sec  1.35 GBytes  2.33 Gbits/sec                  receiver
CPU Utilization: local/sender 12.2% (12.3%u/0.0%s), remote/receiver 0.3% (0.3%u/0.0%s)
snd_tcp_congestion newreno
rcv_tcp_congestion newreno
iperf Done.
[root@cronos:~]

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 :

[root@monbeaucluster-esx01:~] esxcli vsan health cluster list
Health Test Name                                    Status
--------------------------------------------------  ----------
Overall health                                      yellow (Cluster health issue)
Cluster                                             green
  ESXi vSAN Health service installation             green
  vSAN Health Service up-to-date                    green
  Advanced vSAN configuration in sync               green
  vSAN CLOMD liveness                               green
  vSAN Disk Balance                                 green
  Resync operations throttling                      green
  Software version compatibility                    green
  Disk format version                               yellow
Network                                             green
(...)
Data                                                green
  vSAN object health                                green
Limits                                              green
  Current cluster situation                         green
  After 1 additional host failure                   green
  Host component limit                              green
Physical disk                                       green
(...)
Performance service                                 green
(...)
[root@monbeaucluster-esx01:~]

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 :

[root@monbeaucluster-esx01:~] esxcli vsan health cluster get -t "Disk format version"
Disk format version        yellow

Checks format version of all in-use vSAN disks, expected format version is 5.
Ask VMware: http://www.vmware.com/esx/support/askvmware/index.php?eventtype=com.vmware.vsan.health.test.upgradelowerhosts

Detailed vSAN disks format status
vSAN host                             Disks with older format     Check Result     Recommendation
-----------------------------------------------------------------------------------------------------------------------------
monbeaucluster-esx03.intra.yoyodyne.fr     5/5                         yellow           On-disk format upgrade is recommended
monbeaucluster-esx01.intra.yoyodyne.fr     5/5                         yellow           On-disk format upgrade is recommended
monbeaucluster-esx02.intra.yoyodyne.fr     5/5                         yellow           On-disk format upgrade is recommended
[root@monbeaucluster-esx01:~]

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 :

[root@monbeaucluster-esx01:~] esxcli vsan health cluster get -t "vMotion: MTU check (ping with large packet size)"
vMotion: MTU check (ping with large packet size)        green
Performs a ping test with large packet size between all VMKernel adapters with vMotion traffic enabled.
Ask VMware: http://www.vmware.com/esx/support/askvmware/index.php?eventtype=com.vmware.vsan.health.test.vmotionpinglarge

Only failed pings
From Host     To Host     To Device     Ping result
--------------------------------------------------------

Ping results
From Host        To Host          To Device     Ping result
----------------------------------------------------------------
172.27.246.3     172.27.246.2     vmk3          green
172.27.246.3     172.27.246.1     vmk3          green
172.27.246.2     172.27.246.3     vmk3          green
172.27.246.2     172.27.246.1     vmk3          green
172.27.246.1     172.27.246.3     vmk3          green
172.27.246.1     172.27.246.2     vmk3          green
[root@monbeaucluster-esx01:~]

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 :

[root@monbeaucluster-esx10:~] esxcli vsan resync bandwidth get
   Rate: 47 Mbps
[root@monbeaucluster-esx10:~] esxcli vsan resync bandwidth get
   Rate: 31 Mbps
[root@monbeaucluster-esx10:~]

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 :

[root@monbeaucluster-esx10:~] esxcli vsan storage list
naa.5002538c40984016
   Device: naa.5002538c40984016
   Display Name: naa.5002538c40984016
   Is SSD: true
   VSAN UUID: 52003dad-00fb-8539-9d6b-eca71b7f64a8
   VSAN Disk Group UUID: 52181ada-93c3-c16c-e7ca-759d75b1a199
   VSAN Disk Group Name: naa.58ce38ee20193fa5
   Used by this host: true
   In CMMDS: true
   On-disk format version: 5
   Deduplication: true
   Compression: true
   Checksum: 215793655951040190
   Checksum OK: true
   Is Capacity Tier: true
   Encryption: false
   DiskKeyLoaded: false

naa.58ce38ee20193f71
   Device: naa.58ce38ee20193f71
   Display Name: naa.58ce38ee20193f71
   Is SSD: true
   VSAN UUID: 5200e4d8-9309-f802-2458-db875428351c
   VSAN Disk Group UUID: 5200e4d8-9309-f802-2458-db875428351c
   VSAN Disk Group Name: naa.58ce38ee20193f71
   Used by this host: true
   In CMMDS: true
   On-disk format version: 5
   Deduplication: true
   Compression: true
   Checksum: 3421492652471315550
   Checksum OK: true
   Is Capacity Tier: false
   Encryption: false
   DiskKeyLoaded: false

naa.58ce38ee20193fa5
(...)
[root@monbeaucluster-esx10:~]

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 :

[root@monbeaucluster-esx10:~] esxcfg-scsidevs -l -d naa.5002538c409833b0
naa.5002538c409833b0
   Device Type: Direct-Access
   Size: 1831420 MB
   Display Name: Local ATA Disk (naa.5002538c409833b0)
   Multipath Plugin: NMP
   Console Device: /vmfs/devices/disks/naa.5002538c409833b0
   Devfs Path: /vmfs/devices/disks/naa.5002538c409833b0
   Vendor: ATA       Model: MZ7LM1T9HMJP0D3   Revis: GC57
   SCSI Level: 6  Is Pseudo: false Status: on
   Is RDM Capable: true  Is Removable: false
   Is Local: true  Is SSD: true
   Other Names:
      vml.02000000005002538c409833b04d5a374c4d31
   VAAI Status: unknown
[root@monbeaucluster-esx10:~]

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

[root@monbeaucluster-esx10:~] esxcfg-mpath  -l -d naa.5002538c409833b0
sas.5d0946603d316800-sas.500056b3c77984c6-naa.5002538c409833b0
   Runtime Name: vmhba3:C0:T4:L0
   Device: naa.5002538c409833b0
   Device Display Name: Local ATA Disk (naa.5002538c409833b0)
   Adapter: vmhba3 Channel: 0 Target: 4 LUN: 0
   Adapter Identifier: sas.5d0946603d316800
   Target Identifier: sas.500056b3c77984c6
   Plugin: NMP
   State: active
   Transport: sas
   Adapter Transport Details: 5d0946603d316800
   Target Transport Details: 500056b3c77984c6
[root@monbeaucluster-esx10:~]

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 :

[root@monbeaucluster-esx01:/var/log] esxcfg-advcfg -l | grep VSAN
/Misc/vsanWitnessVirtualAppliance [Integer] : Indicates a VSAN witness host running in a Virtual Appliance. VM services (create/register/power on) are blocked
/VSAN-iSCSI/iclCoalesce [Integer] : Try to coalesce PDUs before sending
/VSAN-iSCSI/iclPartialReceiveLen [Integer] : Minimum read size for partially received data segment
(...)
/VSAN/VsanSparseHeapSize [Integer] : Maximum heap size for VsanSparse snapshot consolidation buffers(in KiB)
/VSAN/VsanSparseRetainCacheOnSnapshots [Integer] : Try to retain VsanSparse in-memory cache content when taking VM snapshots
/VSAN/VsanSparseRetainCacheTTL [Integer] : Maximum time to retain VsanSparse in-memory cache content between snapshots, in seconds
/VSAN/DedupScope [Integer] : Dedup Scope for all-flash disk groups
/VSAN/AutoTerminateGhostVm [Integer] : Automatically terminate ghost vm(s) during network partition
/VSAN/DefaultHostDecommissionMode [String] : Default host decommission mode for this host
[root@monbeaucluster-esx01:~]

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

[root@monbeaucluster-esx01:/var/log] esxcfg-advcfg -g /VSAN/DefaultHostDecommissionMode
Value of DefaultHostDecommissionMode is ensureAccessibility
[root@selene-esx01:/var/log] esxcfg-advcfg -g /VSAN/ClomEnableInplaceExpansion
Value of ClomEnableInplaceExpansion is 1
[root@monbeaucluster-esx01:/var/log]

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 :

PS C:\> get-vsanversion -cluster monbeaucluster
VC Version: 6.6.1
Hostname                         Version
--------                         -------
monbeaucluster-esx06.yoyodyne.com 6.6.1
monbeaucluster-esx14.yoyodyne.com 6.6.1
monbeaucluster-esx12.yoyodyne.com 6.6.1
monbeaucluster-esx11.yoyodyne.com 6.6.1
monbeaucluster-esx13.yoyodyne.com 6.6.1
monbeaucluster-esx17.yoyodyne.com 6.6.1
monbeaucluster-esx07.yoyodyne.com 6.6.1
monbeaucluster-esx19.yoyodyne.com 6.6.1
monbeaucluster-esx15.yoyodyne.com 6.6.1
monbeaucluster-esx08.yoyodyne.com 6.6.1
monbeaucluster-esx16.yoyodyne.com 6.6.1
monbeaucluster-esx02.yoyodyne.com 6.6.1
monbeaucluster-esx10.yoyodyne.com 6.6.1
monbeaucluster-esx20.yoyodyne.com 6.6.1
monbeaucluster-esx03.yoyodyne.com 6.6.1
monbeaucluster-esx01.yoyodyne.com 6.6.1
monbeaucluster-esx05.yoyodyne.com 6.6.1
monbeaucluster-esx18.yoyodyne.com 6.6.1
monbeaucluster-esx04.yoyodyne.com 6.6.1
monbeaucluster-esx09.yoyodyne.com 6.6.1
PS C:\>

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

[root@monbeaucluster-esx09:/var/log] esxcli vsan debug resync list
Group UUID                            Object UUID                           Component UUID                        To Host                            GB Left To Resync  Intent
------------------------------------  ------------------------------------  ------------------------------------  ----------------------------------  -----------------  ---------------
c97a1f5b-5e00-78aa-8d5a-246e969b6914  cd7a1f5b-6685-f1bc-fa0b-246e969b6914  6cd0be5c-b2b4-a7bd-1bce-246e969b6f4c  monbeaucluster-esx10.yoyodyne.com  151.93             Decommissioning
c97a1f5b-5e00-78aa-8d5a-246e969b6914  cd7a1f5b-6685-f1bc-fa0b-246e969b6914  * (all 1 components)                  --                                 151.93             --
c97a1f5b-5e00-78aa-8d5a-246e969b6914  * (all 1 objects)                     * (all 1 components)                  --                                 151.93             --
aaa39c5b-5628-6d44-3fda-246e969b6f4c  ada39c5b-7e73-12c4-a6f8-246e969b6f4c  6ad0be5c-34c9-24c9-4c20-246e969b7140  monbeaucluster-esx0.yoyodyne.com   72.69              Decommissioning
aaa39c5b-5628-6d44-3fda-246e969b6f4c  ada39c5b-7e73-12c4-a6f8-246e969b6f4c  * (all 1 components)                  --                                 72.69              --
aaa39c5b-5628-6d44-3fda-246e969b6f4c  * (all 1 objects)                     * (all 1 components)                  --                                 72.69              --
4a4ab85c-922c-5745-0acf-246e9698c2f0  4f4ab85c-b0ca-81a6-1d70-246e9698c2f0  72d0be5c-4e10-8a8d-bb50-246e9698c2f0  monbeaucluster-esx07.yoyodyne.com  42.33              Decommissioning
4a4ab85c-922c-5745-0acf-246e9698c2f0  4f4ab85c-b0ca-81a6-1d70-246e9698c2f0  * (all 1 components)                  --                                 42.33              --
4a4ab85c-922c-5745-0acf-246e9698c2f0  4f4ab85c-9e41-74ba-a490-246e9698c2f0  6fd0be5c-6e66-4f19-998b-246e9698c2f0  monbeaucluster-esx04.yoyodyne.com  34.54              Decommissioning
4a4ab85c-922c-5745-0acf-246e9698c2f0  4f4ab85c-9e41-74ba-a490-246e9698c2f0  * (all 1 components)                  --                                 34.54              --
4a4ab85c-922c-5745-0acf-246e9698c2f0  4f4ab85c-9e4b-8ce2-8b87-246e9698c2f0  6ad0be5c-3a8f-1c61-3fbf-246e9698c2f0  monbeaucluster-esx07.yoyodyne.com  35.79              Decommissioning
4a4ab85c-922c-5745-0acf-246e9698c2f0  4f4ab85c-9e4b-8ce2-8b87-246e9698c2f0  6ad0be5c-54fd-2061-a2d2-246e9698c2f0  monbeaucluster-esx02.yoyodyne.com  29.69              Decommissioning
4a4ab85c-922c-5745-0acf-246e9698c2f0  4f4ab85c-9e4b-8ce2-8b87-246e9698c2f0  * (all 2 components)                  --                                 65.48              --
4a4ab85c-922c-5745-0acf-246e9698c2f0  * (all 3 objects)                     * (all 4 components)                  --                                 142.36             --
34139a5b-84d4-e149-ff1e-246e969b6978  37139a5b-6c77-050a-0ee4-246e969b6978  6ad0be5c-60c0-91a3-36a2-246e969b6d54  monbeaucluster-esx02.yoyodyne.com  40.91              Decommissioning
34139a5b-84d4-e149-ff1e-246e969b6978  37139a5b-6c77-050a-0ee4-246e969b6978  * (all 1 components)                  --                                 40.91              --
34139a5b-84d4-e149-ff1e-246e969b6978  * (all 1 objects)                     * (all 1 components)                  --                                 40.91              --
bfe24d5b-30f9-7eaf-0f33-246e9698c2f0  c3e24d5b-7e33-51e0-dc54-246e9698c2f0  6ad0be5c-4ae2-8c74-9a3c-246e969b6d4c  monbeaucluster-esx01.yoyodyne.com  134.86             Decommissioning
bfe24d5b-30f9-7eaf-0f33-246e9698c2f0  c3e24d5b-7e33-51e0-dc54-246e9698c2f0  * (all 1 components)                  --                                 134.86             --
bfe24d5b-30f9-7eaf-0f33-246e9698c2f0  * (all 1 objects)                     * (all 1 components)                  --                                 134.86             --
[root@monbeaucluster-esx09:/var/log]

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

[root@monbueaucluster-esx09:/var/log] esxcli vsan debug resync summary get
   Total Number Of Resyncing Objects: 7
   Total Bytes Left To Resync: 507391160320
   Total GB Left To Resync: 472.54
[root@monbueaucluster-esx09:/var/log]

… 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.