Dell Technologies VxRail:NSXエッジ ノードでの高いCPU競合。
Summary: Dell Technologies VxRail:NSXエッジ ノードでの高いCPU競合。nsxエッジ ノードでCPU使用率が高くなる原因を把握する必要があります。
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
特にNSXエッジ ノードでは、ESXiノードでCPUの競合が高くなっています。
このEdgeノードを起動し、Equal cost multipath(ECMP)を使用している場合、CPUの高い競合が、高いネットワーク トラフィックとともに次のエッジ ノードで検出されます。元のファイルは再び正常に戻ります。
エッジ ノード自体からは、通常の負荷が発生し、特定のネットワーク キャプチャはドロップされません。
このEdgeノードを起動し、Equal cost multipath(ECMP)を使用している場合、CPUの高い競合が、高いネットワーク トラフィックとともに次のエッジ ノードで検出されます。元のファイルは再び正常に戻ります。
エッジ ノード自体からは、通常の負荷が発生し、特定のネットワーク キャプチャはドロップされません。
Cause
これは、CPU使用率が高く、一部のエッジvnicを介した高いネットワーク トラフィックが原因で発生します。
CPU使用率の比較:
エッジの不良
CPUラン%の比較:
エッジの不良
優れたエッジ
RXとTXのネットワーク ポートの比較:
1秒あたりのパッケージ数の比較:
エッジの不良
優れたエッジ
エッジ ノード上の特定のvnicに対して高いネットワーク トラフィックがあります。高トラフィックの原因となっている特定のアプリケーションが、ゲートウェイとして機能するエッジVMにキャプチャされます。
最後のwirehark情報を以下に示します。
CPU使用率の比較:
エッジの不良
xxx 27 454.64 471.21 43.19 2307.95 7.32 13.72 334.52 2.67 0.00 0.00 0.00 優れたエッジ
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ラン%の比較:
エッジの不良
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
優れたエッジ
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
RXと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
1秒あたりのパッケージ数の比較:
エッジの不良
"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} ]},
優れたエッジ
"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} ]},
エッジ ノード上の特定のvnicに対して高いネットワーク トラフィックがあります。高トラフィックの原因となっている特定のアプリケーションが、ゲートウェイとして機能するエッジVMにキャプチャされます。
最後のwirehark情報を以下に示します。
Resolution
この問題を解決するには、次の手順に従います。
次のトラブルシューティング ワークフローを使用して、問題の原因を特定します。
1.エッジ ノードのエンジニアリング モードを有効にして、システムロードをキャプチャし、rootモードで一番上に実行します。
2.ESXiノードに関するesxtop情報を収集します。通常のエッジ ノードを実行しているESXiノードと、問題のあるエッジ ノードを実行しているESXiノードの結果を比較することをお客様に最適です。
3.統計情報のネット統計を実行します。出力でパケット/秒統計の統計情報を確認し、通常のエッジ ノードを実行しているESXiノードと比較します。
4.Wiresharkネットワーク ソフトウェアを使用して、最も多くのトラフィックを生成しているアプリケーションを特定します。
5.収集した .pcap パッケージ情報をすべてwireharkに入れて、全体的なレポートを時系列で生成します。ほとんどのトラフィックが送信元IPアドレスとターゲットIPアドレスを判断して、送信元のポートを調べたりします。
6.一部のロード トラフィックは、ECMP環境の下に存在します。ECMPハッシュを使用してエッジ ノードに固定されます。ESGの再ロード/再導入が発生した場合は、別のESGに移動されます。その後、このトラフィックが移動されるESGは、高いCPU使用率のレポートを開始します。
デフォルトでは、トラフィックは内部ハッシュ アルゴリズムに基づいてすべてのECMPペア間で分散されます。このアルゴリズムは、2つのイプション(srcIP+dstIP)を使用します。これは、すべてのポートTCP/1556トラフィックが特定の1つのエッジに固定されていないためです。
この例では、srcとdst IP間のバックアップのトラフィックが大きく、このエッジに固定されるため、ESXiはそのトラフィックに対してこのESG VMにより多くのCPUサイクルを提供します。そのため、ESXi/vCenterレベルからCPUの利用率が高くなっていますが、ESGのゲスト オペレーティング システム内ではCPUの利用率は正常です。全体的に、これは予想される動作でもあります。
- 特定のポートで高いネットワーク トラフィックを生成している特定のアプリケーションが検出された場合は、アプリケーション チームにお問い合わせください。
- 特定のノードで大量のトラフィックを生成しないように、ネットワーク コンポーネントの設計を確認します。
次のトラブルシューティング ワークフローを使用して、問題の原因を特定します。
1.エッジ ノードのエンジニアリング モードを有効にして、システムロードをキャプチャし、rootモードで一番上に実行します。
/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.ESXiノードに関するesxtop情報を収集します。通常のエッジ ノードを実行しているESXiノードと、問題のあるエッジ ノードを実行しているESXiノードの結果を比較することをお客様に最適です。
A. 「esxtop」 - 移行されたESXiホスト上で実行します。
B。「esxtop」の後に「n」を指定 - 移行されたESXiホストで実行します。
C。問題のあるVMの現在のGIDを使用したCPUコア データあたりの「esxtop」。GID値を取得し、「E」を押してGID番号を入力します。
D。この特定のエッジVMに関するすべてのデータを確認します。
B。「esxtop」の後に「n」を指定 - 移行されたESXiホストで実行します。
C。問題のあるVMの現在のGIDを使用したCPUコア データあたりの「esxtop」。GID値を取得し、「E」を押してGID番号を入力します。
D。この特定のエッジVMに関するすべてのデータを確認します。
3.統計情報のネット統計を実行します。出力でパケット/秒統計の統計情報を確認し、通常のエッジ ノードを実行しているESXiノードと比較します。
'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.Wiresharkネットワーク ソフトウェアを使用して、最も多くのトラフィックを生成しているアプリケーションを特定します。
A。ESXiホスト シェルで、「net-stats -l」コマンドを使用してESG VMのスイッチ ポートの詳細を取得します。関係するエッジVMのvnicのスイッチポートをメモします。これにより、このvnicを介して流れているトラフィックのタイプを把握できます。
B. 関連するすべてのスイッチポートのパケット収集を1分間1つずつ実行し、.pcapファイルに保存します。セットアップに従ってを変更します。
pktcap-uw --switchport --capture VnicTx,VnicRx -o /vmfs/volumes//.pcap
5.収集した .pcap パッケージ情報をすべてwireharkに入れて、全体的なレポートを時系列で生成します。ほとんどのトラフィックが送信元IPアドレスとターゲットIPアドレスを判断して、送信元のポートを調べたりします。
6.一部のロード トラフィックは、ECMP環境の下に存在します。ECMPハッシュを使用してエッジ ノードに固定されます。ESGの再ロード/再導入が発生した場合は、別のESGに移動されます。その後、このトラフィックが移動されるESGは、高いCPU使用率のレポートを開始します。
デフォルトでは、トラフィックは内部ハッシュ アルゴリズムに基づいてすべてのECMPペア間で分散されます。このアルゴリズムは、2つのイプション(srcIP+dstIP)を使用します。これは、すべてのポートTCP/1556トラフィックが特定の1つのエッジに固定されていないためです。
この例では、srcとdst IP間のバックアップのトラフィックが大きく、このエッジに固定されるため、ESXiはそのトラフィックに対してこのESG VMにより多くのCPUサイクルを提供します。そのため、ESXi/vCenterレベルからCPUの利用率が高くなっていますが、ESGのゲスト オペレーティング システム内ではCPUの利用率は正常です。全体的に、これは予想される動作でもあります。
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.