La CLI de NSX permite obtener copias detalladas del final del registro, tomar capturas de paquetes y consultar las métricas para la resolución de problemas del equilibrador de carga.

Problema

El equilibrio de carga no funciona según lo esperado.

Solución

  1. Habilite el protocolo SSH o verifique que pueda asignarlo al dispositivo virtual. La puerta de enlace de servicios de Edge es un dispositivo virtual que tiene la opción de habilitar el protocolo SSH al implementarlo. Si necesita habilitarlo, seleccione el dispositivo necesario y, en el menú Acciones (Actions), haga clic en Cambiar credenciales de CLI (Change CLI Credentials).
    La imagen se describe en el texto adyacente.
  2. La puerta de enlace de servicios de Edge tiene varios comandos de visualización para consultar el estado del tiempo de ejecución o de la configuración. Utilícelos para mostrar información sobre estadísticas y configuración. 
    nsxedge> show configuration loadbalancer 
nsxedge> show configuration loadbalancer virtual [virtual-server-name] 
nsxedge> show configuration loadbalancer pool [pool-name] 
nsxedge> show configuration loadbalancer monitor [monitor-name] 
nsxedge> show configuration loadbalancer profile [profile-name] 
nsxedge> show configuration loadbalancer rule [rule-name]
  3. Para que las reglas NAT y el equilibrio de carga funcionen correctamente, el firewall debe estar habilitado. Utilice el comando #show firewall. Si no encuentra ningún resultado significativo, consulte la sección Verificación de configuración del equilibrador de carga y solución de problemas a través de la interfaz de usuario.
    Ejemplo de resultado del comando show firewall de la CLI de Edge.
  4. El equilibrador de carga necesite que las reglas NAT funcionen correctamente. Utilice el comando show nat. Si no encuentra ningún resultado significativo, consulte la sección Verificación de configuración del equilibrador de carga y solución de problemas a través de la interfaz de usuario.
    Ejemplo de resultado del comando show nat de la CLI de Edge.
  5. Además de tener habilitado el firewall y de que el equilibrador de carga tenga reglas NAT, también debe asegurarse de que el proceso de equilibrio de carga esté habilitado. Utilice el comando show service loadbalancer para consultar el estado del motor del equilibrador de cara (Capa 4 o Capa 7). 
    nsxedge> show service loadbalancer
haIndex:              0
-----------------------------------------------------------------------
Loadbalancer Services Status:

L7 Loadbalancer     : running
-----------------------------------------------------------------------
L7 Loadbalancer Statistics:
STATUS     PID        MAX_MEM_MB MAX_SOCK   MAX_CONN   MAX_PIPE   CUR_CONN   CONN_RATE  CONN_RATE_LIMIT MAX_CONN_RATE
running    1580       0          2081       1024       0          0          0          0               0
-----------------------------------------------------------------------
L4 Loadbalancer Statistics:
MAX_CONN   ACT_CONN   INACT_CONN TOTAL_CONN
0          0          0          0

Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
    1. El comando show service loadbalancer session permite ver la tabla de sesiones del equilibrador de carga. Se mostrarán sesiones si hay tráfico en el sistema. 
      nsxedge> show service loadbalancer session
-----------------------------------------------------------------------
L7 Loadbalancer Statistics:
STATUS     PID        MAX_MEM_MB MAX_SOCK   MAX_CONN   MAX_PIPE   CUR_CONN   CONN_RATE  CONN_RATE_LIMIT MAX_CONN_RATE
running    1580       0          2081       1024       0          0          0          0               0

-----------------L7 Loadbalancer Current Sessions:

0x2192df1f300: proto=unix_stream src=unix:1 fe=GLOBAL be=<NONE> srv=<none> ts=09 age=0s calls=2 rq[f=c08200h,
i=0,an=00h,rx=20s,wx=,ax=] rp[f=008000h,i=0,an=00h,rx=,wx=,ax=] s0=[7,8h,fd=1,ex=] s1=[7,0h,fd=-1,ex=] exp=19s


-----------------------------------------------------------------------
L4 Loadbalancer Statistics:
MAX_CONN   ACT_CONN   INACT_CONN TOTAL_CONN
0          0          0          0

L4 Loadbalancer Current Sessions:

pro expire state       source       virtual    destination
    2. Consulte el comando show service loadbalancer para ver el estado de la tabla estática de Capa 7 del equilibrador de carga. Tenga en cuenta que esta tabla no muestra información sobre servidores virtuales acelerados. 
      nsxedge> show service loadbalancer table
-----------------------------------------------------------------------
L7 Loadbalancer Sticky Table Status:

TABLE    TYPE    SIZE(BYTE)   USED(BYTE)
  6. Si todos los servicios requeridos funcionan correctamente, consulte la tabla de enrutamiento. Debe tener una ruta al cliente y a los servidores. Utilice los comandos show ip route y show ip forwarding para asignar rutas a las interfaces.
    Ejemplo de salida de los comandos show ip route y show ip forwarding de la CLI de Edge.
  7. Asegúrese de que los sistemas y los servidores backend tienen una entrada de ARP, como la puerta de enlace o el salto siguiente. Para ello, utilice el comando show arp.
    Ejemplo de resultado del comando show arp.
  8. Los registros proporcionan información para localizar el tráfico, lo cual puede resultar útil a la hora de diagnosticar problemas. Utilice los comandos show log o show log follow para seguir los registros que pueden ayudarle a ubicar el tráfico. Tenga en cuenta que, para ejecutar el equilibrador de carga, debe habilitar la opción Registros (Logging) y seleccionar Información (Info) o Depuración (Debug). 
    nsxedge> show log
2016-04-20T20:15:36+00:00 vShieldEdge kernel: Initializing cgroup subsys cpuset
2016-04-20T20:15:36+00:00 vShieldEdge kernel: Initializing cgroup subsys cpu
2016-04-20T20:15:36+00:00 vShieldEdge kernel: Initializing cgroup subsys cpuacct
...
  9. Después de verificar que los servicios básicos se están ejecutando con las rutas adecuadas a los clientes, debe saber lo que sucede en la capa de la aplicación. Utilice el comando show service loadbalancer pool para consultar el estado del grupo del equilibrador de cara (Capa 4 o Capa 7). Al menos un miembro del grupo debe estar activo para publicar contenido. Normalmente, se necesitan más porque el volumen de solicitudes supera la capacidad de carga de trabajo de uno. Si el estado del monitor lo proporciona la comprobación de estado integrada, el resultado muestra la hora del último cambio de estado (last state change time) y el motivo del error (failure reason) cuando falla la comprobación de estado. Si procede del servicio de supervisión, además de los dos resultados anteriores, se muestra la hora de la última comprobación (last check time). 
    nsxedge> show service loadbalancer pool
-----------------------------------------------------------------------
Loadbalancer Pool Statistics:

POOL Web-Tier-Pool-01
|  LB METHOD round-robin
|  LB PROTOCOL L7
|  Transparent disabled
|  SESSION (cur, max, total) = (0, 0, 0)
|  BYTES in = (0), out = (0)
   +->POOL MEMBER: Web-Tier-Pool-01/web-01a, STATUS: UP
   |  |  HEALTH MONITOR = BUILT-IN, default_https_monitor:L7OK
   |  |  |  LAST STATE CHANGE: 2016-05-16 07:02:00
   |  |  SESSION (cur, max, total) = (0, 0, 0)
   |  |  BYTES in = (0), out = (0)
   +->POOL MEMBER: Web-Tier-Pool-01/web-02a, STATUS: UP
   |  |  HEALTH MONITOR = BUILT-IN, default_https_monitor:L7OK
   |  |  |  LAST STATE CHANGE: 2016-05-16 07:02:01
   |  |  SESSION (cur, max, total) = (0, 0, 0)
   |  |  BYTES in = (0), out = (0)
  10. Consulte el estado de supervisión del servicio, que puede ser CORRECTO (OK) , ADVERTENCIA (WARNING) o CRÍTICO (CRITICAL), para conocer el estado de todos los servidores backend configurados. 
    nsxedge> show service loadbalancer monitor
-----------------------------------------------------------------------
Loadbalancer Health Check Statistics:

MONITOR PROVIDER   POOL               MEMBER     HEALTH STATUS
built-in           Web-Tier-Pool-01   web-01a    default_https_monitor:L7OK
built-in           Web-Tier-Pool-01   web-02a    default_https_monitor:L7OK
    Para el comando show service load balancer monitor, aparecen tres tipos de valores de supervisión de estado en la salida de la CLI:
    • Integrado (Built-in): la comprobación de estado está habilitada y la realiza un motor de Capa 7 (proxy de HA).
    • Servicio de supervisión (Monitor Service): la comprobación de estado está habilitada y la realiza un motor de servicio de supervisión (NAGIOS). Los comandos de la CLI show service monitor y show service monitor service pueden comprobar el estado de ejecución del servicio de supervisión. El campo Estado (Status) debe aparecer como CORRECTO (OK), ADVERTENCIA (WARNING) o CRÍTICO (CRITICAL).
    • Sin definir (Not Defined): la comprobación de estado está deshabilitada.
    La última columna de resultados se corresponde con el estado del miembro del grupo. Se muestran los siguientes estados:
    Tabla 1. Estado y descripción
    Estado Descripción (Description)
    Integrado (Built-in)
    • UNK: desconocido
    • INI: inicializando
    • SOCKERR: error de socket
    • L4OK: comprobación de la capa 4 correcta, pero no están habilitadas las pruebas de capas superiores
    • L4TOUT: tiempo de espera de las capas 1 a la 4
    • L4CON: problema de conexión de las capas 1 a la 4. Por ejemplo, "Conexión rechazada" (Connection refused), tpc rst, o "Sin ruta al host" (No route to host), icmp
    • L6OK: comprobación de la capa 6 correcta
    • L6TOUT: tiempo de espera de la capa 6 (SSL)
    • L6RSP: respuesta no válida de la capa 6: error de protocolo. Se pudo provocar ya que:
      • El servidor backend solo admite "SSLv3" o "TLSv1.0",
      • El certificado del servidor backend no es válido, o bien
      • Se produjo un error en la negociación del cifrado, etc.
    • L7OK: comprobación de la capa 7 correcta
    • L7OKC: comprobación de la capa 7 correcta de forma condicional. Por ejemplo, 404 con la opción deshabilitar-en-404 (disable-on-404)
    • L7TOUT: tiempo de espera de la capa 7 (HTTP/SMTP)
    • L7RSP: respuesta no válida de la capa 7: error de protocolo
    • L7STS: error de respuesta de la capa 7. Por ejemplo, HTTP 5xx
    CRÍTICO (CRITICAL)
    • La biblioteca SSL no admite la versión 2 del protocolo SSL
    • Versión del protocolo SSL no admitida
    • No se puede crear el contexto SSL
    • No se puede establecer la conexión SSL
    • No se puede iniciar el protocolo de enlace SSL
    • No se puede recuperar el certificado del servidor
    • No se puede recuperar el sujeto del certificado
    • Formato de hora incorrecto en el certificado
    • El certificado "<cn>" caducó el <fecha en la que caducó el certificado>
    • El certificado "<cn>" caducó hoy <fecha en la que caducó el certificado>
    ADVERTENCIA/CRÍTICO (WARNING/CRITICAL)

    El certificado "<cn>" caducará en <días_restantes/fecha en la que caducará el certificado> días

    ICMP
    • Red no accesible
    • Host no accesible
    • Protocolo no accesible
    • Puerto no accesible
    • Error en la ruta de origen
    • Host de origen aislado
    • Red desconocida
    • Host desconocido
    • Red denegada
    • Host denegado
    • Tipo de servicio (ToS) incorrecto para la red
    • Tipo de servicio (ToS) incorrecto para el host
    • Prohibido por el filtro
    • Infracción de la prioridad de host
    • Límite de prioridad. La operación requiere el nivel mínimo de prioridad
    • Código no válido
    UDP/TCP
    • Error al crear el socket
    • Conectar a la dirección xxxx y al puerto xxx: [consulte el código de error de Linux]
    • No se recibió ningún dato del host
    • Respuesta inesperada del host/socket
    HTTP/HTTPS
    • HTTP DESCONOCIDO: error de asignación de memoria
    • HTTP CRÍTICO: no se puede abrir el socket TCP (error al crear el socket o al conectarse al servidor)
    • HTTP CRÍTICO: error al recibir datos
    • HTTP CRÍTICO: no se recibió ningún dato del host
    • HTTP CRÍTICO: se recibió una respuesta HTTP no válida desde el host: <línea de estado> (formato incorrecto de la línea de estado)
    • HTTP CRÍTICO: línea de estado no válida <línea de estado> (el código de estado no está compuesto por 3 dígitos: XXX)
    • HTTP CRÍTICO: estado no válido <línea de estado> (el código de estado es 600 o un valor superior, o bien menor a 100)
    • HTTP CRÍTICO: no se encuentra la cadena
    • HTTP CRÍTICO: no se encuentra el patrón
    • ADVERTENCIA DE HTTP: el tamaño <longitud_página> de la página es demasiado grande
    • ADVERTENCIA DE HTTP: el tamaño <longitud_página> de la página es demasiado pequeño
  11. Si el código de error es L4TOUT/L4CON, normalmente se corresponde con problemas de conectividad en las redes subyacentes. Duplicate IP suele suceder como causa principal por dicha razón. Cuando se produce este error, solucione el problema de la siguiente manera:
    1. Consulte el estado Alta disponibilidad (High Availability, HA) de los Edge cuando se habilite la alta disponibilidad. Para ello, utilice el comando show service highavailability en ambos Edge. Compruebe si el vínculo de HA está INACTIVO (DOWN) y todos los Edge están Active para que no haya IP de Edge duplicadas en la red.
    2. Consulte la tabla ARP de Edge con el comando show arp y verifique si la entrada ARP del servidor backend cambia entre las dos direcciones MAC.
    3. Consulte la tabla ARP del servidor backend o utilice el comando arp-ping y compruebe si la IP de otro equipo es la misma que la IP de Edge.
  12. Compruebe las estadísticas del los objetos del equilibrador de carga (VIPs, grupos o miembros). Consulte el grupo específico y verifique que los miembros estén activos y ejecutándose. Compruebe si el modo transparente está habilitado. Si es así, la puerta de enlace de servicios de Edge debe estar en línea entre el cliente y el servidor. Verifique si los servidores muestran incrementos en el contador de sesiones. 
    nsxedge> show service loadbalancer pool Web-Tier-VIP-01
TIMESTAMP            	SESSIONS   	BYTESIN    	BYTESOUT   	SESSIONRATE	HTTPREQS
2016-04-27 19:56:40  	00         	00         	00         	00         	00
2016-04-27 19:55:00  	00         	32         	100        	00         	00

    nsxedge> show service loadbalancer pool Web-Tier-VIP-01 | MEMBER
+—> POOL MEMBER: TENANT-1-TCP-POOL-80/SERVER-1, STATUS:  UP
+—> POOL MEMBER: TENANT-1-TCP-POOL-80/SERVER-2, STATUS:  UP
  13. Consulte ahora el servidor virtual, verifique si hay un grupo predeterminado y compruebe si el grupo está enlazado al servidor. Si utiliza los grupos a través de reglas de aplicaciones, debe consultar los grupos específicos que se muestran en el comando #show service loadbalancer pool. Especifique el nombre del servidor virtual. 
    nsxedge> show service loadbalancer virtual Web-Tier-VIP-01

-----------------------------------------------------------------------
Loadbalancer VirtualServer Statistics:

VIRTUAL Web-Tier-VIP-01
|  ADDRESS [172.16.10.10]:443
|  SESSION (cur, max, total) = (0, 0, 0)
|  RATE (cur, max, limit) = (0, 0, 0)
|  BYTES in = (0), out = (0)
   +->POOL Web-Tier-Pool-01
   |  LB METHOD round-robin
   |  LB PROTOCOL L7
   |  Transparent disabled
   |  SESSION (cur, max, total) = (0, 0, 0)
   |  BYTES in = (0), out = (0)
      +->POOL MEMBER: Web-Tier-Pool-01/web-01a, STATUS: UP
      |  |  HEALTH MONITOR = BUILT-IN, default_https_monitor:L7OK
      |  |  |  LAST STATE CHANGE: 2016-05-16 07:02:00
      |  |  SESSION (cur, max, total) = (0, 0, 0)
      |  |  BYTES in = (0), out = (0)
      +->POOL MEMBER: Web-Tier-Pool-01/web-02a, STATUS: UP
      |  |  HEALTH MONITOR = BUILT-IN, default_https_monitor:L7OK
      |  |  |  LAST STATE CHANGE: 2016-05-16 07:02:01
      |  |  SESSION (cur, max, total) = (0, 0, 0)
      |  |  BYTES in = (0), out = (0)
  14. Si parece que todo está configurado correctamente y sigue apareciendo un error, debe capturar el tráfico para comprender lo que ocurre. Hay dos conexiones: la del cliente con el servidor virtual y la de la puerta de enlace de servicios de Edge con el grupo backend (con o sin configuración transparente en el grupo). El comando #show ip forwarding enumera las interfaces de vNic. Utilice esos datos.
    Por ejemplo, suponga que el equipo cliente utiliza la interfaz vNic_0 y el servidor usa la vNic_1. En ese caso, use una IP del cliente 192.168.1.2 y una IP VIP 192.168.2.2 en el puerto 80. La interfaz del equilibrador de carga tendrá la IP 192.168.3.1 y la IP del servidor backend será 192.168.3.3. Hay dos comandos de captura de paquetes distintos. Uno muestra los paquetes, mientras que el otro los captura en archivos que se pueden descargar. Capture los paquetes para detectar errores del equilibrador de carga que no sean normales. Puede hacerlo desde dos direcciones:
    • Capture los paquetes desde el cliente.
    • Capture los paquetes enviados al servidor backend. 
    #debug packet capture interface interface-name [filter using _ for space]- creates a packet capture file that you can download
#debug packet display interface interface-name [filter using _ for space]- outputs packet data to the console
#debug show files - to see a list of packet capture
#debug copy scp user@url:path file-name/all - to download the packet capture
    Por ejemplo:
    • Captura en vNIC_0: debug packet display interface vNic_0
    • Captura en todas las interfaces: debug packet display interface any
    • Captura en vNIC_0 con un filtro: debug packet display interface vNic_0 host_192.168.11.3_and_host_192.168.11.41
    • Una captura de paquetes del cliente para el tráfico del servidor virtual: #debug packet display|capture interface vNic_0 host_192.168.1.2_and_host_192.168.2.2_and_port_80
    • Una captura de paquetes entre la puerta de enlace de servicios de Edge y el servidor en la que el grupo está en modo transparente: #debug packet display|capture interface vNic_1 host 192.168.1.2_and_host_192.168.3.3_and_port_80
    • Una captura de paquetes entre la puerta de enlace de servicios de Edge y el servidor en la que el grupo no está en modo transparente: #debug packet display|capture interface vNic_1 host 192.168.3.1_and_host_192.168.3.3_and_port_80