Il y’a de ces moments où même les choses les plus simples deviennent des montagnes. Que ça soit les vmotions qui entraînent une foule d’arrêt sur plusieurs VM, une lenteur généralisée et surtout une quantité anormale de bande passante moyenne dans tout un DC, même un simple vmotion d’une machine de 8go de ram, provoque des centaines de gigs de trafic sur toutes les zones du réseau.
On voit ici la même VM utilisé dans plusieurs vmotion les uns à la suite des autres. Je rappelle, la VM est configurée avec 8Go de ram.
Comme raconté dans un billet précédent, nous avons, dans ce DC, plusieurs milliers de serveurs Vmware ESXi 5.5 et 6.
Nous avons sniffé tous les vlan. Pas tant de broadcast que ça, simplement beaucoup de traffic. J’ai installé Sexigraf pour monitorer nos serveurs vSAN mais cet outil offre aussi une belle fenêtre sur toutes les facettes de notre environnement. Grâce à lui, on est en mesure de voir qu’avant la semaine derniere nous avions une bande passante moyenne de 1.8GB/s sur tout notre réseau et qu’ensuite, la moyenne monte à plus de 5GB/s…
Avant:
Après:
De plus, sur tous les hosts, on voit la quantité de « paquet receive error » monter en flèche et ne jamais redescendre. Sauf sur certaines machines, qui, elles, sont derrière des VDS configurées pour les Jumbo Frames (MTU9000).
Voyez les graphiques suivants.
MTU 1500: Le trafic et les erreurs montent en flèche.
MTU 9000: On voit le traffic augmenter, mais les erreurs toujours à 0.
Il est intéressant de remarquer que même sur le serveur avec le MTU de 9000, le traffic a augmenté de beaucoup. Il n’y a aucune erreur, mais on voit la bande passante en forte hausse. Nous nous attardons donc à essayer de comprendre qu’est-ce qui consomme autant de ressources sur notre réseau. On commence à sniffer avec tcpdump directement sur les ESX. Vmk0, vmk1. On cherche les erreurs sur les vmnic0 et vmnic1. On utilise wireshark sur un portgroup constitué d’un trunk de tous les VLANs. Rien de bien valable.
On prend ensuite un châssis de blade complètement vide de VM et on lance un graphique de performance en temps réel. Un à un, on supprime les VLAN des switches force10. On voit ainsi les erreurs et le trafic diminuer. On se rend bien compte que ce n’est pas sur un seul VLAN mais bien sur tous les réseaux que le trafic est présent. On décide alors d’utiliser un serveur ESX derrière une Vds en jumbo frames. Cette idée nous sauvera. A force de chercher, on remarque énormément de broadcast de taille de 9000 qui viennent de MAC adresse dont on ne trouve pas la provenance. On a beau chercher dans tous nos vCenters, on ne les trouve pas. Par contre, on se rend compte que les MAC commencent toutes par “00:50:56″ (mac de vmware) et les 3 dernières paires de caractères sont les mêmes que les vmk des serveurs physiques. On détient alors une piste. En faisant une petite recherche sur le web avec ces nouvelles infos, on arrive sur cette entrée de blog qui nous donne la clé pour nous sortir de notre malheur : (http://blog.chrischua.net/2015/05/22/receive-packet-errors-with-vds-health-check-and-jumbo-frames/)
Bref, on se rend compte qu’à la date ou les problèmes ont commencés nous avions activé le Health Check sur les Vds pour valider les configurations réseaux de nouveaux châssis. Et sur nos multiples VDS, le service était encore activé sur deux d’entre-elles… Aussitôt désactivé, aussitôt les problèmes réglés. On fait quelques tests de vmotions et comme à l’habitude, aucun impact ne se fait sentir.
Je ne crois pas qu’on réactivera le health check de sitôt, même en suivant les points de l’article de Chris Chua. Chat échaudé craint l’eau froide… et chaude.
