Solución de incidencias del servidor de backend del equilibrador de carga

Obtenga información sobre los problemas del servidor backend asociados a los equilibradores de carga.

Depuración de un timeout de servidor de backend

Cuando el servidor de backend excede el tiempo de respuesta al responder a una solicitud, se produce un error 504 que indica que el servidor de backend está caído o no responde a la solicitud reenviada por el equilibrador de carga. La aplicación cliente recibe el siguiente código de respuesta: HTTP/1.1 504 Gateway Timeout.

Se pueden producir errores por los siguientes motivos:

  • El equilibrador de carga no ha podido establecer una conexión con el servidor de backend antes de que caduque el timeout de conexión.
  • El equilibrador de carga ha establecido una conexión con el servidor de backend, pero el backend no respondió antes de que transcurra el período de tiempo inactivo.
  • Las listas de seguridad o el grupo de seguridad para la subred o la VNIC no permiten el tráfico desde los backends al equilibrador de carga.
  • Fallo del servidor de backend o del servidor de aplicaciones.

Siga estos pasos para solucionar los errores de timeout del servidor de backend:

  1. Use la utilidad curl para probar directamente el servidor de backend desde un host de la misma red.
    curl -i http://backend_ip_address
    Si esta prueba tarda más de un segundo en responder, quiere decir que una incidencia de nivel de aplicación está causando latencia. Se recomienda comprobar las dependencias ascendentes que puedan causar latencia, entre otras:
    • El almacenamiento conectado a la red, como iSCSI o NFS
    • La latencia de base de datos
    • Una API local
    • Un nivel de aplicación
  2. Compruebe la aplicación accediendo a ella directamente desde el servidor de backend. Compruebe sus logs de acceso para determinar si se puede acceder a la aplicación y si funciona correctamente.
  3. Si el equilibrador de carga y el servidor de backend están en subredes diferentes, compruebe si las listas de seguridad contienen reglas para permitir el tráfico. Si no existe ninguna regla, el tráfico no se permite.
  4. Introduzca los siguientes comandos para determinar si existen reglas de firewall en los servidores de backend que bloquean el tráfico:

    iptables -L muestra todas las reglas de firewall aplicadas por iptables

    sudo firewall-cmd --list-all muestra todas las reglas de firewall aplicadas por firewalld

  5. Active el registro en el equilibrador de carga para determinar si el equilibrador de carga o el servidor de backend están causando la latencia.

Prueba de servidores de backend TCP y HTTP

En este tema se describe cómo solucionar problemas de una conexión de equilibrador de carga. La topología utilizada en este procedimiento tiene un equilibrador de carga público en una subred pública, y los servidores backend están en la misma subred.

Le recomendamos que utilice el servicio Oracle Cloud Infrastructure Logging para solucionar incidencias. (Consulte Detalles de los logs del equilibrador de carga).

Sin embargo, además de utilizar el registro de Oracle Cloud Infrastructure, puede usar otras herramientas que se muestran en esta sección para solucionar el tráfico procesado por el equilibrador de carga y enviado a un servidor backend. Para realizar estas pruebas, le recomendamos que cree una instancia en la misma red que el equilibrador de carga y permita el tráfico en las mismas listas de seguridad y grupos de seguridad. Utilice las siguientes herramientas para solucionar problemas:

  • haciendo ping
    Antes de usar las utilidades más avanzadas que se muestran aquí, le recomendamos que realice una prueba ping básica. Para poder realizar esta prueba correctamente, debe permitir un tráfico ICMP entre la instancia de prueba y el servidor backend.
    $ ping backend_ip_address
    La respuesta debe ser similar a:
    PING 192.0.2.2 (192.0.2.2) 56(84) bytes of data.
    64 bytes from 192.0.2.2: icmp_seq=1 ttl=64 time=0.028 ms
    64 bytes from 192.0.2.2: icmp_seq=2 ttl=64 time=0.044 ms

    Si recibe un mensaje que contiene "64 bytes de...", quiere decir que el ping se ha realizado correctamente.

    La recepción de un mensaje que contiene "Host de destino no accesible" indica que el sistema ya no existe.

    Si no se recibe ningún mensaje, significa que el sistema existe, pero el protocolo ICMP no se permite. Compruebe todos los firewalls, las listas de seguridad y los grupos de seguridad de red para asegurarse de que ICMP está permitido.

  • rizo

    Use la utilidad curl para enviar solicitudes HTTP a un host, un puerto o una URL específicos.

    • En el siguiente ejemplo se muestra el uso de la curl para conectarse a un servidor back-end que envía un error 403 Forbidden:

      $ curl -I http://backend_ip_address/health
      HTTP/1.1 403 Forbidden
      Date: Tue, 17 Mar 2021 17:47:10 GMT
      Content-Type: text/html; charset=UTF-8
      Content-Length: 3539
      Connection: keep-alive
      Last-Modified: Tue, 10 Mar 2021 20:33:28 GMT
      ETag: "dd3-5b3c6975e7600"
      Accept-Ranges: bytes

      En el ejemplo anterior, la comprobación del usuario falla, y devuelve un error 403, que indica que el servidor backend No tiene permisos del archivo local configurados correctamente para la página de comprobación del usuario.

    • En el siguiente ejemplo se muestra el uso de la curl para conectarse a un servidor back-end que envía un error 404 Not Found:
      $ curl -I http://backend_ip_address/health
      HTTP/1.1 404 Not Found
      Date: Tue, 17 Mar 2021 17:47:10 GMT
      Content-Type: text/html; charset=UTF-8
      Content-Length: 3539
      Connection: keep-alive
      Last-Modified: Tue, 10 Mar 2021 20:33:28 GMT
      ETag: "dd3-5b3c6975e7600"
      Accept-Ranges: bytes

      En el ejemplo anterior, la comprobación del sistema falla, y devuelve un error 404, que indica que la página de comprobación del sistema Health check no existe en la ubicación esperada.

    • En el siguiente ejemplo se muestra que existe un servidor de backend y un grupo, las listas de seguridad o un firewall local están bloqueando el tráfico:
      $ curl -I backend_ip_address
      curl: (7) Failed connect to backend_ip_address:port; Connection refused
    • En el siguiente ejemplo se muestra un servidor backend que no existe:
      $ curl -I backend_ip_address
      curl: (7) Failed connect to backend_ip_address:port; No route to host
  • Netcat

    Netcat es una utilidad de red para leer y escribir en conexiones de red mediante TCP o UDP.

    • En el siguiente ejemplo se muestra el uso de la utilidad netcat en el nivel de TCP para garantizar que el servidor de backend de destino pueda recibir una conexión:
      $ nc -vz backend_ip_address port
      Ncat: Connected to backend_ip_address:port.

      En el ejemplo anterior, port está abierto para conexiones.

    • $ nc -vn backend_ip_address port
      Ncat: Connection timed out.

      En el ejemplo anterior, port está cerrado.

  • Tcpdump

    Use la utilidad tcpdump para capturar todo su tráfico en un servidor backend y asegurarse del tráfico que procede de un equilibrador y de qué se devuelve al equilibrador.

    sudo tcpdump -i any -A port port src load_balancer_ip_address
    11:25:54.799014 IP 192.0.2.224.39224 > 192.0.2.224.80: Flags [P.], seq 1458768667:1458770008, ack 2440130792, win 704, options [nop,nop,TS val 461552632 ecr 208900561], length 1341: HTTP: POST /health HTTP/1.1
  • OpenSSL

    Al solucionar problemas de SSL entre la instancia de equilibrador y los servidores de backend, se recomienda usar la utilidad openssl. Esta utilidad abre una conexión SSL a un puerto y un nombre de host específicos e imprime el certificado SSL y otros parámetros.

    Otras opciones para solucionar incidencias son:

    • -showcerts

      Esta opción imprime todos los certificados de la cadena de certificados presentada por el servidor de backend. Use esta opción para identificar incidencias, como un certificado de autoridad de certificación intermedio que falte.

    • -cipher cipher_name

      Esta opción fuerza al cliente y a los servidores a utilizar un conjunto de cifrado específico y ayuda a descartar si el servidor backend permite cifrados específicos.

  • Netstat

    Use el comando netstat -natp para asegurarse de que la aplicación que se ejecuta en el servidor de backend está activa y en ejecución. Para tráfico TCP o HTTP, la aplicación de backend, la dirección IP y los puertos deben estar en el modo de recepción. Si el puerto de aplicación del servidor de backend no se encuentra en modo de recepción, el puerto TCP de la aplicación no se encuentra activo.

    Para resolver esta incidencia, asegúrese de que la aplicación está activa y en ejecución reiniciando la aplicación o el servidor de backend.