Dell Technologies VxRail: Alta contención de CPU en el nodo perimetral de NSX.
Summary: Dell Technologies VxRail: Alta contención de CPU en el nodo perimetral de NSX. Es necesario averiguar qué está causando el alto uso de cpu en el nodo edge de 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
Hay una alta contención de CPU en el nodo ESXi, específicamente con el nodo perimetral de NSX.
Si inicia este nodo perimetral y utiliza múltiples rutas de igual costo (ECMP), la alta contención de CPU se encuentra en el siguiente nodo perimetral junto con el alto tráfico de red. El original vuelve a la normalidad nuevamente.
Desde el nodo perimetral en sí, hay una carga normal y no se encuentra ninguna captura de red específica descartada.
Si inicia este nodo perimetral y utiliza múltiples rutas de igual costo (ECMP), la alta contención de CPU se encuentra en el siguiente nodo perimetral junto con el alto tráfico de red. El original vuelve a la normalidad nuevamente.
Desde el nodo perimetral en sí, hay una carga normal y no se encuentra ninguna captura de red específica descartada.
Cause
Esto se debe al alto uso de CPU y también al alto tráfico de red a través de algún vnic de borde.
Comparación de uso de CPU:
Borde defectuoso
Comparación del porcentaje de ejecución de CPU:
Borde defectuoso
Buen borde
Comparación de puertos de red para RX y TX:
Comparación de paquete por segundo:
Borde defectuoso
Buen borde
Hay un alto tráfico de red contra un vnic específico en el nodo perimetral. Una aplicación específica que se ejecuta y causa un alto tráfico se captura en la máquina virtual perimetral que actúa como puerta de enlace.
A continuación, se muestra la información final de wireshark.
Comparación de uso de CPU:
Borde defectuoso
xxx 27 454.64 471.21 43.19 2307.95 7.32 13.72 334.52 2.67 0.00 0.00 0.00 Buen borde
xxx 27 240.09 225.96 20.80 2507.98 6.72 8.39 443.93 1.71 0.00 0.00 0.00
Comparación del porcentaje de ejecución de CPU:
Borde defectuoso
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
Buen borde
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
Comparación de puertos de red para RX y 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
Comparación de paquete por segundo:
Borde defectuoso
"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} ]},
Buen borde
"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} ]},
Hay un alto tráfico de red contra un vnic específico en el nodo perimetral. Una aplicación específica que se ejecuta y causa un alto tráfico se captura en la máquina virtual perimetral que actúa como puerta de enlace.
A continuación, se muestra la información final de wireshark.
Resolution
Para resolver este problema:
Utilice el siguiente flujo de trabajo de solución de problemas para encontrar la causa del problema.
1. Habilite el modo de ingeniería del nodo perimetral para capturar la carga del sistema y ejecutar en la parte superior con el modo raíz.
2. Capture la información de esxtop sobre el nodo ESXi. Lo mejor es comparar el resultado en el nodo ESXi que ejecuta el nodo perimetral normal y el nodo ESXi que ejecuta el nodo perimetral problemático.
3. Ejecute estadísticas netas para obtener información estadística. Compruebe las estadísticas de paquetes por segundo en la salida y compárelas con el nodo ESXi que ejecuta el nodo perimetral normal.
4. Utilice el software de red Wireshark para determinar qué aplicación estaba generando la mayor cantidad de tráfico.
5. Coloque toda la información del paquete .pcap en wireshark para generar el informe general en orden cronológico. Solucione el puerto del que provenía la mayor parte del tráfico mediante la identificación de su dirección IP de origen y destino.
6. Parte del tráfico de carga está presente en el ambiente ECMP. Se ancla a un nodo perimetral mediante hash de ECMP. Se transfiere a otro ESG en caso de que se vuelva a cargar o volver a implementar ESG. Después de eso, el ESG al que se transfiere este tráfico comienza a informar un alto uso de CPU.
De manera predeterminada, el tráfico se distribuye entre todos los pares de ECMP en función de su algoritmo de hash interno que utiliza dos tuplas (srcIP+dstIP). Esto es para que todo el tráfico TCP/1556 del puerto no esté anclado a un borde específico.
En nuestra instancia, un tráfico de respaldos de gran impacto entre src e IP de dst se ancla a este borde, lo que hace que ESXi proporcione más ciclos de CPU a esta VM de ESG para ese tráfico. Es por eso que vemos una alta utilización de CPU desde el nivel de ESXi/vCenter, pero dentro del sistema operativo huésped de ESG, la utilización de CPU es normal. En general, este también es el comportamiento esperado.
- Si se detecta una aplicación específica que genera un alto tráfico de red en un puerto específico, póngase en contacto con el equipo de aplicaciones.
- Revise el diseño de los componentes de red para evitar la generación de grandes cantidades de tráfico en nodos específicos.
Utilice el siguiente flujo de trabajo de solución de problemas para encontrar la causa del problema.
1. Habilite el modo de ingeniería del nodo perimetral para capturar la carga del sistema y ejecutar en la parte superior con el modo raíz.
/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. Capture la información de esxtop sobre el nodo ESXi. Lo mejor es comparar el resultado en el nodo ESXi que ejecuta el nodo perimetral normal y el nodo ESXi que ejecuta el nodo perimetral problemático.
A. "esxtop": se ejecuta en el host ESXi migrado.
B. "esxtop" siguiente con "n": se ejecuta en el host ESXi migrado.
C. "esxtop" por datos principales de CPU mediante el GID actual de la VM problemática. Obtenga el valor de GID, presione "E" e ingrese el número de GID.
D. Revise todos los datos relacionados con esta vm perimetral específica.
B. "esxtop" siguiente con "n": se ejecuta en el host ESXi migrado.
C. "esxtop" por datos principales de CPU mediante el GID actual de la VM problemática. Obtenga el valor de GID, presione "E" e ingrese el número de GID.
D. Revise todos los datos relacionados con esta vm perimetral específica.
3. Ejecute estadísticas netas para obtener información estadística. Compruebe las estadísticas de paquetes por segundo en la salida y compárelas con el nodo ESXi que ejecuta el nodo perimetral 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. Utilice el software de red Wireshark para determinar qué aplicación estaba generando la mayor cantidad de tráfico.
Un. En el shell del host ESXi, obtenga los detalles de switchport de la VM de ESG mediante el comando "net-stats -l ". Tenga en cuenta el switchport del vnic de la máquina virtual de borde en cuestión. Esto le permite saber qué tipo de tráfico está fluyendo a través de este vnic.
B. Realice la captura de paquetes para todos los puertos de switch relacionados uno por uno durante un minuto y guárdelo en un archivo.pcap. Cambie los según la configuración.
pktcap-uw --switchport --capture VnicTx,VnicRx -o /vmfs/volumes//.pcap
5. Coloque toda la información del paquete .pcap en wireshark para generar el informe general en orden cronológico. Solucione el puerto del que provenía la mayor parte del tráfico mediante la identificación de su dirección IP de origen y destino.
6. Parte del tráfico de carga está presente en el ambiente ECMP. Se ancla a un nodo perimetral mediante hash de ECMP. Se transfiere a otro ESG en caso de que se vuelva a cargar o volver a implementar ESG. Después de eso, el ESG al que se transfiere este tráfico comienza a informar un alto uso de CPU.
De manera predeterminada, el tráfico se distribuye entre todos los pares de ECMP en función de su algoritmo de hash interno que utiliza dos tuplas (srcIP+dstIP). Esto es para que todo el tráfico TCP/1556 del puerto no esté anclado a un borde específico.
En nuestra instancia, un tráfico de respaldos de gran impacto entre src e IP de dst se ancla a este borde, lo que hace que ESXi proporcione más ciclos de CPU a esta VM de ESG para ese tráfico. Es por eso que vemos una alta utilización de CPU desde el nivel de ESXi/vCenter, pero dentro del sistema operativo huésped de ESG, la utilización de CPU es normal. En general, este también es el comportamiento esperado.
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.