Dell Technologies VxRail: Hoher CPU-Konflikt auf NSX Edge Node.
Summary: Dell Technologies VxRail: Hoher CPU-Konflikt auf NSX Edge Node. Sie müssen herausfinden, was die hohe CPU-Auslastung auf dem nsx Edge Node verursacht.
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
Es gibt einen hohen CPU-Konflikt auf dem ESXi-Node, insbesondere beim NSX-Edge-Node.
Wenn Sie diesen Edge-Node starten und Equal Cost Multipath (ECMP) verwenden, wird der hohe CPU-Konflikt auf dem nächsten Edge-Node zusammen mit hohem Netzwerkdatenverkehr gefunden. Das Original ist wieder normal.
Vom Edge-Node selbst gibt es eine normale Last und es wird festgestellt, dass keine bestimmte Netzwerkerfassung gelöscht wird.
Wenn Sie diesen Edge-Node starten und Equal Cost Multipath (ECMP) verwenden, wird der hohe CPU-Konflikt auf dem nächsten Edge-Node zusammen mit hohem Netzwerkdatenverkehr gefunden. Das Original ist wieder normal.
Vom Edge-Node selbst gibt es eine normale Last und es wird festgestellt, dass keine bestimmte Netzwerkerfassung gelöscht wird.
Cause
Dies wird durch eine hohe CPU-Auslastung und auch hohen Netzwerkdatenverkehr über einige Edge-VNIC verursacht.
Vergleich der CPU-Auslastung:
Schlechter Edge
Cpu-Run%-Vergleich:
Schlechter Edge
Guter Edge
Vergleich der Netzwerkports für RX und TX:
Vergleich des Pakets pro Sekunde:
Schlechter Edge
Guter Edge
Es gibt einen hohen Netzwerkdatenverkehr mit einer bestimmten vnic auf dem Edge-Node. Eine bestimmte Anwendung, die ausgeführt wird und zu hohem Datenverkehr führt, wird auf der Edge-VM erfasst, die als Gateway fungiert.
Nachfolgend finden Sie die abschließenden Wireshark-Informationen.
Vergleich der CPU-Auslastung:
Schlechter 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 Guter 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
Cpu-Run%-Vergleich:
Schlechter 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
Guter 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
Vergleich der Netzwerkports für RX und 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
Vergleich des Pakets pro Sekunde:
Schlechter 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} ]},
Guter 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} ]},
Es gibt einen hohen Netzwerkdatenverkehr mit einer bestimmten vnic auf dem Edge-Node. Eine bestimmte Anwendung, die ausgeführt wird und zu hohem Datenverkehr führt, wird auf der Edge-VM erfasst, die als Gateway fungiert.
Nachfolgend finden Sie die abschließenden Wireshark-Informationen.
Resolution
So beheben Sie dieses Problem:
Verwenden Sie den folgenden Troubleshooting-Workflow, um die Ursache des Problems zu finden.
1. Aktivieren Sie den Edge Node Engineering-Modus, um die Systemlast zu erfassen und top mit dem Root-Modus auszuführen.
2. Erfassen Sie die Esxtop-Informationen über den ESXi-Node. Es ist am besten, das Ergebnis auf dem ESXi-Node, auf dem der normale Edge-Node ausgeführt wird, und dem ESXi-Node, auf dem der problematische Edge-Node ausgeführt wird, zu vergleichen.
3. Führen Sie Netzstatistiken für statistische Informationen aus. Überprüfen Sie die Statistiken der Paket-pro-Sekunde-Statistik in der Ausgabe und vergleichen Sie sie mit dem ESXi-Node, auf dem der normale Edge-Node ausgeführt wird.
4. Verwenden Sie die Wireshark-Netzwerksoftware, um zu bestimmen, welche Anwendung den meisten Datenverkehr erzeugt hat.
5. Geben Sie alle Informationen zum Collect.pcap-Paket in wireshark ein, um den Gesamtbericht in chronologischer Reihenfolge zu erzeugen. Ermitteln Sie den Port, von dem der Großteil des Datenverkehrs stammte, indem Sie seine Quell- und Ziel-IP-Adresse ermitteln.
6. In der ECMP-Umgebung ist ein gewisses Lastaufkommen vorhanden. Es wird mit ecmp-Hashing an einen Edge-Node angeheftet. Sie wird im Falle eines erneuten Ladens/erneuten Bereitstellens der ESG auf eine andere ESG verschoben. Danach meldet die ESG, auf die dieser Datenverkehr verschoben wird, eine hohe CPU-Auslastung.
Standardmäßig wird der Datenverkehr basierend auf dem internen Hashing-Algorithmus, der zwei Tupel (srcIP+dstIP) verwendet, auf alle ECMP-Paare verteilt. Dies bedeutet, dass der gesamte Port-TCP/1556-Datenverkehr nicht an einen bestimmten Edge angeheftet ist.
In unserem Fall wird ein stark belasteter Datenverkehr von Backups zwischen einem src und dst-IPs an diesen Edge angeheftet, was dazu führt, dass ESXi dieser ESG-VM mehr CPU-Zyklen für diesen Datenverkehr bereitstellt. Aus diesem Grund sehen wir eine hohe CPU-Auslastung auf ESXi-/vCenter-Ebene, aber im Gastbetriebssystem der ESG ist die CPU-Auslastung normal. Insgesamt ist dies also auch das erwartete Verhalten.
- Wenn eine bestimmte Anwendung erfasst wird, die hohen Netzwerkdatenverkehr auf einem bestimmten Port erzeugt, wenden Sie sich an das Anwendungsteam.
- Überprüfen Sie das Design der Netzwerkkomponenten, um zu vermeiden, dass große Mengen an Datenverkehr auf bestimmten Nodes erzeugt werden.
Verwenden Sie den folgenden Troubleshooting-Workflow, um die Ursache des Problems zu finden.
1. Aktivieren Sie den Edge Node Engineering-Modus, um die Systemlast zu erfassen und top mit dem Root-Modus auszuführen.
/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. Erfassen Sie die Esxtop-Informationen über den ESXi-Node. Es ist am besten, das Ergebnis auf dem ESXi-Node, auf dem der normale Edge-Node ausgeführt wird, und dem ESXi-Node, auf dem der problematische Edge-Node ausgeführt wird, zu vergleichen.
A. "esxtop" – Wird auf einem migrierten ESXi-Host ausgeführt.
B. "esxtop" mit "n" wird auf einem migrierten ESXi-Host ausgeführt.
C. "esxtop" pro CPU-Core-Daten unter Verwendung der aktuellen GID der problematischen VM. Rufen Sie den GID-Wert ab, drücken Sie "E" und geben Sie die GID-Nummer ein.
D. Überprüfen Sie alle Daten zu dieser bestimmten Edge-VM.
B. "esxtop" mit "n" wird auf einem migrierten ESXi-Host ausgeführt.
C. "esxtop" pro CPU-Core-Daten unter Verwendung der aktuellen GID der problematischen VM. Rufen Sie den GID-Wert ab, drücken Sie "E" und geben Sie die GID-Nummer ein.
D. Überprüfen Sie alle Daten zu dieser bestimmten Edge-VM.
3. Führen Sie Netzstatistiken für statistische Informationen aus. Überprüfen Sie die Statistiken der Paket-pro-Sekunde-Statistik in der Ausgabe und vergleichen Sie sie mit dem ESXi-Node, auf dem der normale Edge-Node ausgeführt wird.
'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. Verwenden Sie die Wireshark-Netzwerksoftware, um zu bestimmen, welche Anwendung den meisten Datenverkehr erzeugt hat.
Eine. Rufen Sie auf der ESXi-Host-Shell die Switchport-Details der ESG-VM mit dem Befehl "net-stats -l " ab. Notieren Sie sich den Switchport der VNIC der betreffenden Edge-VM. Auf diese Weise können Sie wissen, welche Art von Datenverkehr durch diese vnic fließt.
B. Führen Sie die Paketerfassung für alle zugehörigen Switchports nacheinander für eine Minute durch und speichern Sie sie in einer PCAP-Datei. Ändern Sie die gemäß Ihrer Konfiguration.
pktcap-uw --switchport --capture VnicTx,VnicRx -o /vmfs/volumes//.pcap
5. Geben Sie alle Informationen zum Collect.pcap-Paket in wireshark ein, um den Gesamtbericht in chronologischer Reihenfolge zu erzeugen. Ermitteln Sie den Port, von dem der Großteil des Datenverkehrs stammte, indem Sie seine Quell- und Ziel-IP-Adresse ermitteln.
6. In der ECMP-Umgebung ist ein gewisses Lastaufkommen vorhanden. Es wird mit ecmp-Hashing an einen Edge-Node angeheftet. Sie wird im Falle eines erneuten Ladens/erneuten Bereitstellens der ESG auf eine andere ESG verschoben. Danach meldet die ESG, auf die dieser Datenverkehr verschoben wird, eine hohe CPU-Auslastung.
Standardmäßig wird der Datenverkehr basierend auf dem internen Hashing-Algorithmus, der zwei Tupel (srcIP+dstIP) verwendet, auf alle ECMP-Paare verteilt. Dies bedeutet, dass der gesamte Port-TCP/1556-Datenverkehr nicht an einen bestimmten Edge angeheftet ist.
In unserem Fall wird ein stark belasteter Datenverkehr von Backups zwischen einem src und dst-IPs an diesen Edge angeheftet, was dazu führt, dass ESXi dieser ESG-VM mehr CPU-Zyklen für diesen Datenverkehr bereitstellt. Aus diesem Grund sehen wir eine hohe CPU-Auslastung auf ESXi-/vCenter-Ebene, aber im Gastbetriebssystem der ESG ist die CPU-Auslastung normal. Insgesamt ist dies also auch das erwartete Verhalten.
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.