Dell Technologies VxRail: Hoog CPU-conflict op NSX edge-knooppunt.
Summary: Dell Technologies VxRail: Hoog CPU-conflict op NSX edge-knooppunt. U moet achterhalen wat de oorzaak is van het hoge CPU-gebruik op nsx edge-knooppunten.
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
Er is een hoog CPU-probleem op het ESXi-knooppunt, met name met het NSX edge-knooppunt.
Als u dit Edge-knooppunt opstart en het gebruikmaakt van Equal cost multipath (ECMP), wordt de CPU-hoge contentie gevonden op het volgende edge-knooppunt samen met veel netwerkverkeer. Het origineel is weer normaal.
Vanaf het edge-knooppunt zelf is er normale belasting en wordt er geen specifieke netwerkregistratie gevonden.
Als u dit Edge-knooppunt opstart en het gebruikmaakt van Equal cost multipath (ECMP), wordt de CPU-hoge contentie gevonden op het volgende edge-knooppunt samen met veel netwerkverkeer. Het origineel is weer normaal.
Vanaf het edge-knooppunt zelf is er normale belasting en wordt er geen specifieke netwerkregistratie gevonden.
Cause
Dit wordt veroorzaakt door hoog CPU-gebruik en ook veel netwerkverkeer via een edge-vnic.
VERGELIJKING VAN CPU-gebruik:
Slechte edge
VERGELIJKING VAN CPU-run%:
Slechte edge
Goede edge
Vergelijking van netwerkpoorten voor RX en TX:
Vergelijking van pakket per seconde:
Slechte edge
Goede edge
Er is veel netwerkverkeer op een specifieke vNIC op het edge-knooppunt. Een specifieke applicatie die veel verkeer veroorzaakt, wordt vastgelegd op de edge vm die fungeert als gateway.
Hieronder vindt u de laatste gegevens over wireshark.
VERGELIJKING VAN CPU-gebruik:
Slechte edge
xxx 27 454.64 471.21 43.19 2307.95 7.32 13.72 334.52 2.67 0.00 0.00 0.00 Goede 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
VERGELIJKING VAN CPU-run%:
Slechte edge
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
Goede 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
Vergelijking van netwerkpoorten voor RX en 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
Vergelijking van pakket per seconde:
Slechte edge
"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} ]},
Goede 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} ]},
Er is veel netwerkverkeer op een specifieke vNIC op het edge-knooppunt. Een specifieke applicatie die veel verkeer veroorzaakt, wordt vastgelegd op de edge vm die fungeert als gateway.
Hieronder vindt u de laatste gegevens over wireshark.
Resolution
Om dit probleem op te lossen:
Gebruik de volgende workflow voor probleemoplossing om de oorzaak van uw probleem te vinden.
1. Schakel de engineeringmodus van het edge-knooppunt in om de systeembelasting vast te leggen en de hoofdmodus uit te voeren.
2. Leg de esxtop-informatie over het ESXi-knooppunt vast. Het is het beste om het resultaat te vergelijken op het ESXi-knooppunt waarop het normale edge-knooppunt en het ESXi-knooppunt worden uitgevoerd waarop het problematische edge-knooppunt wordt uitgevoerd.
3. Voer netstatistieken uit voor statistische informatie. Controleer de statistieken van Packet per Second op de uitvoer en vergelijk dit met het ESXi-knooppunt waarop normaal edge-knooppunt wordt uitgevoerd.
4. Gebruik Wireshark-netwerksoftware om te bepalen welke applicatie het meeste verkeer genereerde.
5. Plaats alle informatie van het collect .pcap-pakket in wireshark om het algehele rapport in chronologische volgorde te genereren. Werk de poort uit waar het meeste verkeer vandaan kwam door de bron en het doel-IP-adres te achterhalen.
6. Sommige laadverkeer is aanwezig in de ECMP-omgeving. Het wordt vastgepind aan een edge-knooppunt met ECMP-hashing. Het wordt verplaatst naar een andere ESG in het geval van een herlaad/herimplementatie van de ESG. Hierna begint de ESG waarop dit verkeer wordt verplaatst, een hoog CPU-gebruik te rapporteren.
Verkeer wordt standaard verdeeld over alle ECMP-paren op basis van het interne hash-algoritme dat gebruikmaakt van twee tuples (srcIP+dstIP). Dit is zodat alle poort TCP/1556-verkeer niet aan één specifieke edge is vastgemaakt.
In ons geval wordt een zware hoeveelheid back-ups tussen een src en dst IP's vastgepind aan deze edge, waardoor de ESXi meer CPU-cycli levert aan deze ESG-VM voor dat verkeer. Daarom zien we een hoog CPU-gebruik vanaf het niveau van ESXi/vCenter, maar binnen het gastbesturingssysteem van de ESG is het CPU-gebruik normaal. Dus over het algemeen is dit ook het verwachte gedrag.
- Als een specifieke applicatie wordt vastgelopen bij het genereren van hoog netwerkverkeer op een specifieke poort, neemt u contact op met het applicatieteam.
- Bekijk het ontwerp van de netwerkcomponenten om te voorkomen dat grote hoeveelheden verkeer worden gegenereerd op specifieke knooppunten.
Gebruik de volgende workflow voor probleemoplossing om de oorzaak van uw probleem te vinden.
1. Schakel de engineeringmodus van het edge-knooppunt in om de systeembelasting vast te leggen en de hoofdmodus uit te voeren.
/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. Leg de esxtop-informatie over het ESXi-knooppunt vast. Het is het beste om het resultaat te vergelijken op het ESXi-knooppunt waarop het normale edge-knooppunt en het ESXi-knooppunt worden uitgevoerd waarop het problematische edge-knooppunt wordt uitgevoerd.
A. 'esxtop' - uitvoeren op gemigreerde ESXi-host.
B. 'esxtop' volgt met 'n' - uitvoeren op gemigreerde ESXi-host.
C. 'esxtop' per CPU-coredata met behulp van de huidige GID van de problematische VM. Krijg de GID-waarde, druk op 'E' en voer het GID-nummer in.
D. Controleer alle data met betrekking tot deze specifieke edge vm.
B. 'esxtop' volgt met 'n' - uitvoeren op gemigreerde ESXi-host.
C. 'esxtop' per CPU-coredata met behulp van de huidige GID van de problematische VM. Krijg de GID-waarde, druk op 'E' en voer het GID-nummer in.
D. Controleer alle data met betrekking tot deze specifieke edge vm.
3. Voer netstatistieken uit voor statistische informatie. Controleer de statistieken van Packet per Second op de uitvoer en vergelijk dit met het ESXi-knooppunt waarop normaal edge-knooppunt wordt uitgevoerd.
'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. Gebruik Wireshark-netwerksoftware om te bepalen welke applicatie het meeste verkeer genereerde.
A. Op de ESXi-hostshell kunt u de switchport-details van de ESG VM ophalen met de opdracht "net-stats -l". Noteer de switchport van de vNIC van de betreffende edge vm. Hiermee kunt u weten welk type verkeer door deze vnic loopt.
B. Voer de pakketregistratie uit voor alle gerelateerde switchports één voor één gedurende één minuut en sla het op in een .pcap-bestand. Wijzig de volgens uw installatie.
pktcap-uw --switchport --capture VnicTx,VnicRx -o /vmfs/volumes//.pcap
5. Plaats alle informatie van het collect .pcap-pakket in wireshark om het algehele rapport in chronologische volgorde te genereren. Werk de poort uit waar het meeste verkeer vandaan kwam door de bron en het doel-IP-adres te achterhalen.
6. Sommige laadverkeer is aanwezig in de ECMP-omgeving. Het wordt vastgepind aan een edge-knooppunt met ECMP-hashing. Het wordt verplaatst naar een andere ESG in het geval van een herlaad/herimplementatie van de ESG. Hierna begint de ESG waarop dit verkeer wordt verplaatst, een hoog CPU-gebruik te rapporteren.
Verkeer wordt standaard verdeeld over alle ECMP-paren op basis van het interne hash-algoritme dat gebruikmaakt van twee tuples (srcIP+dstIP). Dit is zodat alle poort TCP/1556-verkeer niet aan één specifieke edge is vastgemaakt.
In ons geval wordt een zware hoeveelheid back-ups tussen een src en dst IP's vastgepind aan deze edge, waardoor de ESXi meer CPU-cycli levert aan deze ESG-VM voor dat verkeer. Daarom zien we een hoog CPU-gebruik vanaf het niveau van ESXi/vCenter, maar binnen het gastbesturingssysteem van de ESG is het CPU-gebruik normaal. Dus over het algemeen is dit ook het verwachte gedrag.
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.