Documentación de Oracle Cloud Infrastructure

Políticas de comprobación del sistema para equilibradores de carga de red

Configure y utilice comprobaciones del sistema para decidir la disponibilidad de los servidores de backend de un equilibrador de carga de red.

Una comprobación del sistema es una prueba para confirmar la disponibilidad de los servidores de backend. Una comprobación del sistema puede ser una solicitud o un intento de conexión. En función del intervalo de tiempo especificado, el equilibrador de carga de red aplica la política de comprobación del sistema para supervisar de forma continua los servidores de backend. Si un servidor no supera la comprobación del sistema, el equilibrador de carga de red saca temporalmente al servidor de la rotación. Si el servidor supera posteriormente la comprobación del sistema, el equilibrador de carga de red lo devuelve a la rotación.

La política de comprobación del sistema se configura al crear un equilibrador de carga de red. También puede configurar la política de comprobación del sistema al crear o editar un juego de backends para un equilibrador de carga existente. A continuación, se muestra un resumen de los protocolos que puede utilizar con la política de comprobación del sistema:

  • Las comprobaciones del sistema a nivel de TCP intentan realizar una conexión TCP con los servidores backend y validar la respuesta en función del estado de conexión.

    Si no resulta práctico crear una solicitud para el protocolo con el que está trabajando, puede omitir los datos de la solicitud. En este caso, el backend se considera correcto si la conexión TCP se realiza correctamente.

  • Las comprobaciones del sistema a nivel de HTTP envían las solicitudes a los servidores de backend de una determinada URI y validan la respuesta en función del código de estado o de los datos de entidad (cuerpo) devueltos.
  • Las comprobaciones del sistema a nivel de HTTPS envían las solicitudes a los servidores de backend de una determinada URI y validan la respuesta en función del código de estado o los datos de entidad (cuerpo) devueltos mediante un protocolo HTTPS seguro y cifrado.
  • Las comprobaciones del sistema a nivel de UDP envían una única solicitud al servidor de backend y hacen coincidir la respuesta (si se recibe) con los datos de respuesta que especifique.
  • Las comprobaciones del sistema a nivel de DNS envían solicitudes a los servidores backend mediante UDP o TCP. La comprobación del sistema también utiliza el nombre de la consulta y la información relacionada que desea proporcionar a la respuesta DNS del servidor de backend.

El servicio proporciona capacidades de comprobación del sistema específicas de la aplicación para ayudar a aumentar la disponibilidad y reducir la ventana de mantenimiento de la aplicación.

Puede realizar las siguientes tareas de gestión de políticas de comprobación del sistema:

Configuración del protocolo de comprobación del sistema para que coincida con la aplicación o el servicio

Si ejecuta un servicio HTTP, asegúrese de configurar una comprobación del sistema a nivel de HTTP. Si ejecuta una comprobación del sistema a nivel de TCP en un servicio HTTP, es posible que no reciba una respuesta correcta. El establecimiento de comunicación TCP puede ser correcto e indicar que el servicio está activo, incluso si el servicio HTTP no está configurado correctamente o tiene otros problemas. Aunque la comprobación del sistema parece estar bien, es posible que los clientes experimenten fallos en las transacciones. Por ejemplo:

  • El servicio HTTP del backend tiene problemas al comunicarse con la URL de comprobación del sistema y la URL de comprobación del sistema devuelve mensajes 5XX. Una comprobación del sistema HTTP captura el mensaje de la URL de comprobación del sistema y marca el servicio como caído. En este caso, el establecimiento de comunicación de la comprobación del sistema TCP se realiza correctamente y marca el servicio como en buen estado, aunque el servicio HTTP podría no poder usarse.
  • El servicio HTTP del backend responde con mensajes 4XX debido a problemas de autorización o a que no hay contenido configurado. Una comprobación del sistema TCP no detecta estos errores.

Indicadores de estado

El servicio Network Load Balancer proporciona indicadores de estado del sistema que utilizan las políticas de comprobación del sistema para informar sobre el estado general de los equilibradores de carga de red y sus componentes. Puede ver los indicadores de estado en las páginas Consola , Lista y Detalles de los equilibradores de carga, los juegos de backends y los servidores de backend. También puede utilizar la API para recuperar esta información.

Los indicadores de estado tienen cuatro niveles. En la siguiente tabla se proporciona el significado general de cada nivel:

Nivel Color Descripción
Correcto Verde No se requiere ninguna atención.

El recurso funciona según lo previsto.
Advertencia Amarillo Algunas entidades de informes necesitan atención.

El recurso no funciona con su máxima eficacia o el recurso está incompleto y necesita más trabajo.
Crítico Rojo Algunas o todas las entidades de informes necesitan una atención inmediata.

El recurso no funciona o se va a producir un fallo inesperado.
Desconocido Gris No se puede determinar el estado.

El recurso no responde o está en transición y se podría resolver en otro estado con el tiempo.

El significado exacto de cada nivel varía en los siguientes componentes:

Uso del estado

Al máximo nivel, el estado del equilibrador de carga de red refleja el estado de sus componentes. Los indicadores de estado proporcionan información que podría necesitar para aumentar detalle e investigar un problema existente. Algunos de los problemas comunes que los indicadores de estado pueden ayudar a detectar y corregir son:

Una comprobación del sistema tiene una configuración incorrecta.

En este caso, todos los servidores de backend de uno o más listeners afectados informan de que están en mal estado. Si su investigación detecta que los servidores backend no tienen problemas, es probable que un juego de backends contenga una comprobación del sistema mal configurada.

Un listener tiene una configuración incorrecta.

Todos los indicadores de estado del servidor backend muestran el estado OK, pero el equilibrador de carga de red no transfiere tráfico en un listener.

El listener podría estar configurado para:

  • Recibir en el puerto incorrecto.
  • Usar el protocolo incorrecto.
  • Usar la política incorrecta.

Si al investigar se detecta que el listener no está fallando, compruebe la configuración de la lista de seguridad.

Una regla de seguridad tiene una configuración incorrecta.

Los indicadores de estado le ayudan a diagnosticar dos casos de reglas de seguridad con la configuración incorrecta:

  • Todos los indicadores de estado de la entidad muestran el estado Aceptar, pero el tráfico no fluye (como con listeners configurados incorrectamente). Si el listener no tiene fallos, compruebe la configuración de la regla de seguridad.
  • Todos los estados de la entidad informan de que tienen un estado incorrecto. Ha comprobado la configuración de comprobación del sistema y los servicios se ejecutan correctamente en los servidores backend.

    En este caso, las reglas de seguridad pueden no incluir el rango de direcciones IP para el origen de las solicitudes de comprobación del sistema. La IP de origen de comprobación del sistema se encuentra en la página Detalles de cada servidor backend. También se puede utilizar la API para buscar la IP en el campo sourceIpAddress del objeto HealthCheckResult.

    Nota

    La IP de origen para las solicitudes de comprobación del sistema proviene de una instancia informática gestionada por el servicio Network Load Balancer.

Uno o más servidores de backend informan de que están en mal estado.

Puede que un servidor de backend esté en mal estado o que la comprobación del sistema tenga una configuración incorrecta. Para ver el código de error correspondiente, compruebe el campo estado de la página Detalles del servidor backend. También puede utilizar la API para buscar el código de error en el campo healthCheckStatus del objeto HealthCheckResult.

Entre otros casos en los que el estado puede resultar útil son:

El estado del sistema se actualiza cada tres minutos. No hay disponible granularidad más precisa.

El estado del sistema no proporciona datos de estado históricos.

Mejores prácticas de comprobación del sistema

Configure el protocolo de comprobación del sistema para que coincida con la aplicación o el servicio. Si ejecuta un servicio HTTP, asegúrese de configurar una comprobación del sistema a nivel de HTTP. Si ejecuta una comprobación del sistema a nivel de TCP en un servicio HTTP, es posible que no reciba una respuesta correcta. El establecimiento de comunicación TCP puede ser correcto e indicar que el servicio está activo, incluso si el servicio HTTP no está configurado correctamente o tiene otros problemas. Aunque la comprobación del sistema parece estar bien, es posible que los clientes experimenten fallos en las transacciones.

Por ejemplo:

  • El servicio HTTP del backend tiene problemas al comunicarse con la URL de comprobación del sistema y la URL de comprobación del sistema devuelve mensajes 5XX. Una comprobación del sistema HTTP captura el mensaje de la URL de comprobación del sistema y marca el servicio como caído. En este caso, el establecimiento de comunicación de la comprobación del sistema TCP se realiza correctamente y marca el servicio como en buen estado, aunque el servicio HTTP podría no poder usarse.
  • El servicio HTTP del backend responde con mensajes 4XX debido a problemas de autorización o a que no hay contenido configurado. Una comprobación del sistema TCP no detecta estos errores.

Efectos secundarios comunes de la configuración incorrecta de las comprobaciones del sistema

A continuación se muestran los efectos secundarios comunes de la configuración incorrecta de las comprobaciones del sistema, que se pueden utilizar para solucionar problemas.

  • Puerto incorrecto

    En este caso, todos los servidores de backend informan de que están en mal estado. Si los servidores de backend no tienen problemas, es posible que haya cometido un error al definir el puerto. El puerto debe recibir y ha permitido el tráfico en el backend.

    Error de registro de OCI: errno":"EHOSTUNREACH","syscall":"connect".

  • Ruta de acceso incorrecta

    En este caso, todos los servidores de backend informan de que están en mal estado. Si los servidores back-end no tienen problemas, puede que haya cometido un error al definir la ruta de acceso para la comprobación del sistema HTTP que necesita que coincida con una aplicación real en el servidor backend. En este caso, puede usar una prueba curl desde un sistema de la misma red.

    Por ejemplo: 

    $ curl -i http://10.0.0.5/health

    Aparece el código de estado configurado en la respuesta Error de registro de OCI: 

    "msg":"invalid statusCode","statusCode":404,"expected":"200".
  • Protocolo incorrecto

    En este caso, todos los servidores de backend informan de que están en mal estado. Si los servidores de backend no tienen problemas, es posible que haya cometido un error al definir el protocolo que necesita para que coincida con el protocolo que recibe en el backend. Por ejemplo: solo están soportadas las comprobaciones del sistema TCP y HTTP. Si el servidor backend utiliza HTTPS, utilice TCP como protocolo.

    Error de registro de OCI:

    "code":"EPROTO","errno":"EPROTO".
  • Código de estado incorrecto

    En este caso, todos los servidores de backend informan de que están en mal estado. Si los servidores de backend no tienen problemas, para una comprobación del sistema HTTP podría haber cometido un error al definir el código de estado para que coincida con el código de estado real que se devuelve del backend. Un escenario común es cuando un backend devuelve un 302 y se espera un 200. Como consecuencia es probable que el backend le envíe a una página de conexión o a otra ubicación del servidor. En este caso, puede corregir el backend para que devuelva el código esperado o utilizar 302 en la configuración de comprobación del sistema.

    Error de OCI Logging:

    "msg":"invalid statusCode","statusCode":XX,"expected":"200"

    donde XX debe ser el código de estado devuelto.

  • Patrón de expresión regular incorrecto

    Todos los servidores de backend informan de que están en mal estado. Si los servidores de backend no tienen problemas, es posible que haya cometido un error al definir un patrón de expresión regular incorrecto consistente con el cuerpo o que el backend no devuelva el cuerpo esperado. En este caso, puede cambiar el backend para que coincida con el patrón o corregir el patrón para que coincida con el backend. A continuación se muestran algunos ejemplos de patrón específicos.

    • Cualquier contenido: ".*"
    • Una página que devuelve el valor "Estado:Correcto:" - "Estado:Correcto:.*"
    • Error de registro de OCI: "resultado de coincidencia de respuesta: con fallos"
  • Grupos de seguridad de red, listas de seguridad o firewall local mal configurados

Todos o algunos de los servidores de backend informan de que están en mal estado. Si los servidores backend no tienen problemas, es posible que haya cometido un error al configurar los NSG, las listas de seguridad o los firewalls locales como firewalld, iptables o SELiinux. En este escenario, puede usar una prueba curl o netcat de un sistema que pertenezca a la misma subred y NSG que el HTTP de la instancia del equilibrador:

Por ejemplo: 

$ curl -i http://10.0.0.5/health TCP: ex: nc -zvw3 10.0.05 443.

Puede comprobar el firewall local mediante el siguiente comando: 

firewall-cmd --list-all --zone=public.

Si en el firewall faltan las reglas esperadas, puede utilizar un juego de comandos como este para agregar el servicio: (este ejemplo es para el puerto HTTP 80): 

  • firewall-cmd --zone=public --add-service=http
  • firewall-cmd --zone=public --permanent --add-service=http

Configuración del protocolo de comprobación del sistema para que coincida con su aplicación o servicio

El servicio proporciona capacidades de comprobación del sistema específicas de la aplicación para ayudar a aumentar la disponibilidad y reducir la ventana de mantenimiento de la aplicación.

Si ejecuta un servicio HTTP, asegúrese de configurar una comprobación del sistema a nivel de HTTP. Si ejecuta una comprobación del sistema a nivel de TCP en un servicio HTTP, es posible que no reciba una respuesta correcta. El establecimiento de comunicación TCP puede ser correcto e indicar que el servicio está activo, incluso si el servicio HTTP no está configurado correctamente o tiene otros problemas. Aunque la comprobación del sistema parece estar bien, es posible que los clientes experimenten fallos en las transacciones. Por ejemplo:

  • El servicio HTTP del backend tiene problemas al comunicarse con la URL de comprobación del sistema y la URL de comprobación del sistema devuelve mensajes 5XX. Una comprobación del sistema HTTP captura el mensaje de la URL de comprobación del sistema y marca el servicio como caído. En este caso, el establecimiento de comunicación de la comprobación del sistema TCP se realiza correctamente y marca el servicio como en buen estado, aunque el servicio HTTP podría no poder usarse.
  • El servicio HTTP del backend responde con mensajes 4XX debido a problemas de autorización o a que no hay contenido configurado. Una comprobación del sistema TCP no detecta estos errores.

Comprobación del sistema de DNS

El servicio Network Load Balancer soporta la comprobación del sistema de DNS en el transporte de TCP y UDP, tanto para los servidores backend IPv4 como IPv6. La comprobación del sistema de DNS para los servidores backend de resolución de DNS es una mejora con respecto a las comprobaciones basadas en TCP o UDP, porque verifica que el protocolo DNS funciona para los servidores backend de resolución de DNS. Esos protocolos utilizan el formato base64 para especificar los mensajes de solicitud y respuesta, y eso puede ser difícil al formar solicitudes y respuestas DNS. Además, puede haber varias respuestas válidas y RCODE en el mensaje de respuesta, por ejemplo, NOERROR(0) y NXDOMAIN(3). No es posible manejar todos estos escenarios con la comprobación de estado estándar de TCP o UDP.

Al crear un juego de backends, ya sea durante la creación del equilibrador de carga de red inicial o al agregar un juego de backends a un equilibrador de carga de red existente, debe especificar las siguientes configuraciones específicas del protocolo si utiliza la comprobación del sistema de DNS:

  • Nombre de consulta: proporcione un nombre de dominio DNS para la consulta.
  • Clase de consulta: seleccione una de las siguientes opciones:
    • IN: Internet (predeterminado)
    • CH: Caos
  • Tipo de consulta: seleccione una de las siguientes opciones:
    • A: indica un nombre de host correspondiente a la dirección IPv4. (valor por defecto)
    • AAAA: indica un nombre de host correspondiente a la dirección IPv6.
    • TXT: indica un campo de texto.
  • Códigos de respuesta aceptables: seleccione una o más de las siguientes opciones:
    • La consulta de DNS RCODE:0 NOERROR se ha completado correctamente.
    • El servidor RCODE:2 SERVFAIL no pudo completar la solicitud de DNS.
    • RCODE:3 NXDOMAIN El nombre de dominio no existe.
    • RCODE:5 REFUSED El servidor se negó a responder a la consulta.