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 !
Dans la pratique, ce bug se traduit donc par des alertes dans la section “Health” du cluster VSAN :
Tel que décrit dans le KB#2151992, on nous apprend qu’il s’agit d’un bug spécifique à VSAN 6.6 et 6.6.1, ou plutôt, de mon point de vue, une conséquence de la fameuse limitation à 200 echo-reply par seconde maximum. “It’s not a bug, it’s a feature” comme disent nos confrères anglophones :) . Dans la pratique, ce comportement ne se manifeste que sur les clusters de plus d’une dizaine de nœuds environ. En effet, les tests de ping sont réalisés en parallèle par chaque ESXi (contactant quasi en même temps, l’ensemble de ses copains). Si on fait un rapide calcul, on se rend vite compte qu’au delà de 10 nœuds et suivant le timing, on peut tomber à plus de 200 echo-reply pour chaque host dans la même seconde.
Actuellement la seule issue pour avoir un Health Check parfait, c’est de rendre silencieux ces checks : ils sont bien réalisés, mais ils ne remontent pas comme incident dans la console VMware. Pour le moment ça évite d’avoir des warnings persistants, même si la solution me parait un peu limite en l’état : si ces checks sont là, c’est qu’ils ont un intérêt, notamment pour mesurer la latence et la disponibilité des liens entres les serveurs …
Dont acte, j’ai suivi la procédure à appliquer pour museler les 4 checks “ping”, à savoir :
– Le check ping sur le segment VSAN avec des paquets standards de MTU 1500
– Le check ping sur le segment VSAN avec des des jumbo frames de MTU 9000
– Le check ping sur le segment VMotion avec des paquets standards de MTU 1500
– Le check ping sur le segment VMotion avec des des jumbo frames de MTU 9000
Pour se faire, je me suis connecté via “Ruby vSphere Console”, aka RVC et j’ai appliqué les configs :
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
root@vcsa [ ~ ]# rvc administrator\@vsphere.local@localhost Install the "ffi" gem for better tab completion. password: ************** 0 / 1 localhost/ > vsan.health.silent_health_check_configure -a smallping /localhost/DCxxxxx/computers/MONBEAUCLUSTER Successfully add check "vSAN: Basic (unicast) connectivity check" to silent health check list for MONBEAUCLUSTER > vsan.health.silent_health_check_configure -a largeping /localhost/DCxxxxx/computers/MONBEAUCLUSTER Successfully add check "vSAN: MTU check (ping with large packet size)" to silent health check list for MONBEAUCLUSTER > vsan.health.silent_health_check_configure -a vmotionpingsmall /localhost/DCxxxxx/computers/MONBEAUCLUSTER Successfully add check "vMotion: Basic (unicast) connectivity check" to silent health check list for MONBEAUCLUSTER > vsan.health.silent_health_check_configure -a vmotionpinglarge /localhost/DCxxxxx/computers/MONBEAUCLUSTER Successfully add check "vMotion: MTU check (ping with large packet size)" to silent health check list for MONBEAUCLUSTER > root@vcsa [ ~ ]# |
Ensuite, on relance un un check complet via le bouton “Retest” et … Ô magie, tout est ok (on s’en serait douté ceci dit ^^) :
Sachez que lorsque le bug sera résolu, il vous suffira de réintégrer ces checks dans la console en utilisant l’option “-r” au lieu de “-a” dans les commandes RVC, tout simplement.
1 thought on “Alertes “ping” sur votre VSAN 6.6 : je vous demande de vous arrêter !”