Dell Technologies VxRail : Conflit d’accès au processeur élevé sur le nœud edge NSX.
Summary: Dell Technologies VxRail : Conflit d’accès au processeur élevé sur le nœud edge NSX. Besoin de déterminer ce qui est à l’origine de l’utilisation élevée du processeur sur le nœud edge nsx. ...
This article applies to
This article does not apply to
This article is not tied to any specific product.
Not all product versions are identified in this article.
Symptoms
Il existe un conflit d’accès au processeur élevé sur le nœud ESXi, en particulier avec le nœud edge NSX.
Si vous démarrez ce nœud Edge et qu’il utilise equal cost multipath (ECMP), le conflit d’accès élevé au processeur se trouve sur le nœud de périphérie suivant, ainsi que le trafic réseau élevé. L’original est à nouveau normal.
À partir du nœud de périphérie lui-même, il y a une charge normale et aucune capture réseau spécifique n’est trouvée.
Si vous démarrez ce nœud Edge et qu’il utilise equal cost multipath (ECMP), le conflit d’accès élevé au processeur se trouve sur le nœud de périphérie suivant, ainsi que le trafic réseau élevé. L’original est à nouveau normal.
À partir du nœud de périphérie lui-même, il y a une charge normale et aucune capture réseau spécifique n’est trouvée.
Cause
Cela est dû à une utilisation élevée du processeur et à un trafic réseau élevé via certaines cartes réseau de périphérie.
Comparaison de l’utilisation du processeur:
Bord défectueux
Comparaison du pourcentage d’exécution du processeur:
Bord défectueux
Bon edge
Comparaison des ports réseau pour RX et TX:
Comparaison du package par seconde:
Bord défectueux
Bon edge
Le trafic réseau est élevé par rapport à une carte réseau spécifique sur le nœud de périphérie. Une application spécifique qui s’exécute, entraînant un trafic élevé, est capturée sur la machine virtuelle de périphérie qui agit en tant que passerelle.
Vous trouverez ci-dessous les dernières informations wireshark.
Comparaison de l’utilisation du processeur:
Bord défectueux
xxx 27 454.64 471.21 43.19 2307.95 7.32 13.72 334.52 2.67 0.00 0.00 0.00 Bon edge
xxx 27 240.09 225.96 20.80 2507.98 6.72 8.39 443.93 1.71 0.00 0.00 0.00
Comparaison du pourcentage d’exécution du processeur:
Bord défectueux
ID GID NAME NWLD %USED %RUN %SYS %WAIT %VMWAIT %RDY %IDLE %OVRLP %CSTP %MLMTD %SWPWT
16580792 16580792 xxx 27 454.64 471.21 43.19 2307.95 7.32 13.72 334.52 2.67 0.00 0.00 0.00
Bon edge
ID GID NAME NWLD %USED %RUN %SYS %WAIT %VMWAIT %RDY %IDLE %OVRLP %CSTP %MLMTD %SWPWT
10908367 10908367 xxx 27 240.09 225.96 20.80 2507.98 6.72 8.39 443.93 1.71 0.00 0.00 0.00
Comparaison des ports réseau pour RX et TX:
PORT-ID USED-BY TEAM-PNIC DNAME PKTTX/s MbTX/s PSZTX PKTRX/s MbRX/s PSZRX %DRPTX %DRPRX 50331714 2666974:xxx.eth2 vmnic2 DvsPortset-1 519615.172729.88 688.00 128623.96 694.32 707.00 0.00 0.00 50331715 2666974:xxx.eth1 vmnic3 DvsPortset-1 76622.01 523.06 894.00 230747.221126.70 640.00 0.00 0.00 50331716 2666974:xxx.eth0 vmnic6 DvsPortset-1 51422.12 168.87 430.00 312557.221691.50 709.00 0.00 0.00
PORT-ID USED-BY TEAM-PNIC DNAME PKTTX/s MbTX/s PSZTX PKTRX/s MbRX/s PSZRX %DRPTX %DRPRX 50331744 1752165:xxx.eth2 vmnic3 DvsPortset-1 42856.22 238.49 729.00 50329.21 262.45 683.00 0.00 0.00 50331745 1752165:xxx.eth1 vmnic7 DvsPortset-1 22069.93 91.24 541.00 20044.33 96.35 630.00 0.00 0.00 50331746 1752165:xxx.eth0 vmnic2 DvsPortset-1 27771.00 169.72 801.00 23548.13 144.95 806.00 0.00 0.00
Comparaison du package par seconde:
Bord défectueux
"rxqueue": { "count": 4, "details": [
{"intridx": 0, "pps": 30175, "mbps": 203.9, "errs": 0.0},
{"intridx": 1, "pps": 17175, "mbps": 61.1, "errs": 0.0},
{"intridx": 2, "pps": 15626, "mbps": 51.4, "errs": 0.0},
{"intridx": 3, "pps": 14596, "mbps": 57.4, "errs": 0.0} ]},
"txqueue": { "count": 4, "details": [
{"intridx": 0, "pps": 121634, "mbps": 828.2, "errs": 0.0},
{"intridx": 1, "pps": 105483, "mbps": 708.5, "errs": 0.0},
{"intridx": 2, "pps": 137687, "mbps": 1087.9, "errs": 0.0},
{"intridx": 3, "pps": 116488, "mbps": 831.6, "errs": 0.0} ]},
Bon edge
"rxqueue": { "count": 4, "details": [
{"intridx": 0, "pps": 22388, "mbps": 115.1, "errs": 0.0},
{"intridx": 1, "pps": 54248, "mbps": 497.1, "errs": 0.0},
{"intridx": 2, "pps": 67004, "mbps": 650.2, "errs": 0.0},
{"intridx": 3, "pps": 22688, "mbps": 118.8, "errs": 0.0} ]},
"txqueue": { "count": 4, "details": [
{"intridx": 0, "pps": 21222, "mbps": 125.0, "errs": 0.0},
{"intridx": 1, "pps": 46125, "mbps": 384.3, "errs": 0.0},
{"intridx": 2, "pps": 22771, "mbps": 131.7, "errs": 0.0},
{"intridx": 3, "pps": 29040, "mbps": 162.0, "errs": 0.0} ]},
Le trafic réseau est élevé par rapport à une carte réseau spécifique sur le nœud de périphérie. Une application spécifique qui s’exécute, entraînant un trafic élevé, est capturée sur la machine virtuelle de périphérie qui agit en tant que passerelle.
Vous trouverez ci-dessous les dernières informations wireshark.
Resolution
Pour résoudre ce problème :
Utilisez le workflow de dépannage suivant pour trouver la cause de votre problème.
1. Activez le mode d’ingénierie des nœuds de périphérie pour capturer la charge du système et l’exécuter en haut avec le mode racine.
2. Capturez les informations esxtop sur le nœud ESXi. Il est préférable de comparer le résultat sur le nœud ESXi qui exécute le nœud de périphérie normal et le nœud ESXi qui exécute le nœud edge problématique.
3. Exécutez net stats pour obtenir des informations statistiques. Vérifiez les statistiques de paquet par seconde sur la sortie et comparez-les au nœud ESXi qui exécute le nœud Edge normal.
4. Utilisez le logiciel réseau Wireshark pour déterminer quelle application générait le plus de trafic.
5. Placez toutes les informations du package collect.pcap dans wireshark pour générer le rapport global dans l’ordre chronologique. Renseignez le port d’où provient la majeure partie du trafic en identifiant son adresse IP source et cible.
6. Un certain trafic de charge est présent dans l’environnement ECMP. Il est épinglé à un nœud de périphérie à l’aide du hachage ECMP. Il est déplacé vers un autre ESG en cas de rechargement/redéploiement d’ESG. Ensuite, ESG sur lequel ce trafic est déplacé commence à signaler une utilisation élevée du processeur.
Par défaut, le trafic est distribué entre toutes les paires ECMP en fonction de son algorithme de hachage interne qui utilise deux tuples (srcIP+dstIP). Ainsi, tout le trafic TCP/1556 du port n’est pas épinglé à un bord spécifique.
Dans notre cas, un trafic de sauvegardes intensif entre une adresse IP src et dst est épinglé à cette périphérie, ce qui oblige ESXi à fournir plus de cycles de CPU à cette machine virtuelle ESG pour ce trafic. C’est pourquoi nous constatons une utilisation élevée du CPU au niveau d’ESXi/vCenter, mais dans le système d’exploitation invité d’ESG, l’utilisation du processeur est normale. Dans l’ensemble, il s’agit également du comportement attendu.
- Si une application spécifique est prise en compte pour générer un trafic réseau élevé sur un port spécifique, contactez l’équipe chargée des applications.
- Passez en revue la conception des composants réseau afin d’éviter de générer de grandes quantités de trafic sur des nœuds spécifiques.
Utilisez le workflow de dépannage suivant pour trouver la cause de votre problème.
1. Activez le mode d’ingénierie des nœuds de périphérie pour capturer la charge du système et l’exécuter en haut avec le mode racine.
/home/secureall/secureall/sem/WEB-INF/classes/GetSpockEdgePassword.sh edge-xx (edge-xx could be found on nsx manager GUI) logon console of edge node with admin->enable>debug engineeringmode enable->st en->
2. Capturez les informations esxtop sur le nœud ESXi. Il est préférable de comparer le résultat sur le nœud ESXi qui exécute le nœud de périphérie normal et le nœud ESXi qui exécute le nœud edge problématique.
A. « esxtop »: exécutez sur l’hôte ESXi migré.
B. « esxtop » suivant « n » - exécutez sur l’hôte ESXi migré.
C. « esxtop » par données de cœur de processeur à l’aide du GID actuel de la machine virtuelle problématique. Obtenez la valeur GID, appuyez sur « E » et saisissez le numéro GID.
D. Passez en revue toutes les données relatives à cette machine virtuelle edge spécifique.
B. « esxtop » suivant « n » - exécutez sur l’hôte ESXi migré.
C. « esxtop » par données de cœur de processeur à l’aide du GID actuel de la machine virtuelle problématique. Obtenez la valeur GID, appuyez sur « E » et saisissez le numéro GID.
D. Passez en revue toutes les données relatives à cette machine virtuelle edge spécifique.
3. Exécutez net stats pour obtenir des informations statistiques. Vérifiez les statistiques de paquet par seconde sur la sortie et comparez-les au nœud ESXi qui exécute le nœud Edge normal.
'net-stats -A -t WwQqihVvh -i 5 -n 2' - run on the migrated ESXi host and got following high figure
"txqueue": { "count": 4, "details": [
{"intridx": 0, "pps": 121634, "mbps": 828.2, "errs": 0.0},
{"intridx": 1, "pps": 105483, "mbps": 708.5, "errs": 0.0},
{"intridx": 2, "pps": 137687, "mbps": 1087.9, "errs": 0.0},
{"intridx": 3, "pps": 116488, "mbps": 831.6, "errs": 0.0} ]},
4. Utilisez le logiciel réseau Wireshark pour déterminer quelle application générait le plus de trafic.
Un. Sur le shell de l’hôte ESXi, obtenez les détails du switchport de la machine virtuelle ESG à l’aide de la commande « net-stats -l ». Notez le port de commutation de la carte réseau de la machine virtuelle de périphérie concernée. Cela vous permet de savoir quel type de trafic transite par cette carte réseau.
B. Effectuez la capture de paquets pour tous les ports de commutation associés une par une pendant une minute et enregistrez-la dans un fichier .pcap. Modifiez les en fonction de votre configuration.
pktcap-uw --switchport --capture VnicTx,VnicRx -o /vmfs/volumes//.pcap
5. Placez toutes les informations du package collect.pcap dans wireshark pour générer le rapport global dans l’ordre chronologique. Renseignez le port d’où provient la majeure partie du trafic en identifiant son adresse IP source et cible.
6. Un certain trafic de charge est présent dans l’environnement ECMP. Il est épinglé à un nœud de périphérie à l’aide du hachage ECMP. Il est déplacé vers un autre ESG en cas de rechargement/redéploiement d’ESG. Ensuite, ESG sur lequel ce trafic est déplacé commence à signaler une utilisation élevée du processeur.
Par défaut, le trafic est distribué entre toutes les paires ECMP en fonction de son algorithme de hachage interne qui utilise deux tuples (srcIP+dstIP). Ainsi, tout le trafic TCP/1556 du port n’est pas épinglé à un bord spécifique.
Dans notre cas, un trafic de sauvegardes intensif entre une adresse IP src et dst est épinglé à cette périphérie, ce qui oblige ESXi à fournir plus de cycles de CPU à cette machine virtuelle ESG pour ce trafic. C’est pourquoi nous constatons une utilisation élevée du CPU au niveau d’ESXi/vCenter, mais dans le système d’exploitation invité d’ESG, l’utilisation du processeur est normale. Dans l’ensemble, il s’agit également du comportement attendu.
Affected Products
VxRail Appliance Family, VxRail Appliance SeriesArticle Properties
Article Number: 000202066
Article Type: Solution
Last Modified: 16 May 2023
Version: 3
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.