Conceptos de verificación de estado

Google Cloud Platform (GCP) proporciona mecanismos de comprobación de estado que determinan si los backends, como los grupos de instancias y los grupos de extremos de red (NEG), responden al tráfico de manera adecuada. En este documento, se analizan los conceptos de verificación de estado específicos de GCP y sus balanceadores de cargas.

Descripción general

GCP proporciona sistemas de verificación de estado globales y regionales que se conectan a backends de forma periódica y configurable. Cada intento de conexión se denomina sondeo. GCP registra el éxito o el fracaso de cada sondeo.

Las verificaciones de estado y los balanceadores de cargas funcionan en conjunto. En función de una cantidad configurable de sondeos secuenciales exitosos o fallidos, GCP calcula un estado general para cada backend en el balanceador de cargas. Los backends que responden de manera adecuada durante la cantidad de veces configurada se consideran en buen estado. Los backends que no responden de manera satisfactoria una cantidad distinta de veces están en mal estado.

GCP usa el estado general de cada backend a fin de determinar su elegibilidad para recibir solicitudes nuevas. Además de poder configurar la frecuencia de sondeo y los umbrales de estado, puedes configurar los criterios que definen un sondeo exitoso. En este documento, se describe cómo funcionan las verificaciones de estado en detalle.

GCP usa rutas especiales no definidas en la red de VPC para las verificaciones de estado. Para obtener información completa sobre esto, lee acerca de las rutas de acceso de retorno del balanceador de cargas.

Protocolos, puertos y categorías de verificación de estado

GCP organiza las verificaciones de estado por categoría y protocolo.

Existen dos categorías de verificación de estado: verificaciones de estado y verificaciones de estado heredadas. Cada categoría admite un conjunto diferente de protocolos y un medio a fin de especificar el puerto que se usa para la verificación de estado. El protocolo y el puerto determinan cómo los sistemas de verificación de estado de GCP se comunican con tus backends. Por ejemplo, puedes crear una verificación de estado que use el protocolo HTTP en el puerto TCP 80 o puedes crear una que use el protocolo TCP para un puerto con nombre configurado en un grupo de instancias.

La mayoría de los balanceadores de cargas de GCP requieren verificaciones de estado no heredadas, pero el balanceo de cargas de red requiere verificaciones de estado heredadas que usan el protocolo HTTP. Consulta la página sobre cómo seleccionar una verificación de estado para obtener orientación específica acerca de cómo seleccionar la categoría y el protocolo, además de especificar los puertos.

No puedes convertir una verificación de estado heredada en una verificación de estado o viceversa.

El término verificación de estado no se refiere a verificaciones de estado heredadas. En este documento, las verificaciones de estado heredadas se denominan de forma explícita verificaciones de estado heredadas.

Selecciona una verificación de estado

Las verificaciones de estado deben ser compatibles con el tipo de balanceador de cargas y los tipos de backends que usa (grupos de instancias o grupos de extremos de red). Estos son los tres factores que debes especificar cuando creas una verificación de estado:

  • Categoría: verificación de estado o verificación de estado heredada, que debe ser compatible con el balanceador de cargas
  • Protocolo: define qué protocolo usan los sistemas de GCP para sondear tus backends de forma periódica
  • Especificación de puerto: define qué puertos se usan para el protocolo de verificación de estado

En la guía al final de esta sección, se resumen combinaciones válidas de la categoría de verificación de estado, protocolo y especificación de puerto en función de un tipo determinado de balanceador de cargas y de backend.

Tal como se usa en esta sección, el término grupo de instancias se refiere a grupos de instancias no administrados, administrados zonales o administrados regionales.

Categoría y protocolo

El tipo de balanceador de cargas y los tipos de backends que usa el balanceador de cargas determinan la categoría de la verificación de estado. El balanceo de cargas de red requiere verificaciones de estado heredadas que usan el protocolo HTTP. Para todos los demás tipos de balanceadores de cargas, usa verificaciones de estado normales.

Debes seleccionar un protocolo de la lista de protocolos compatibles con la categoría de verificación de estado. Se recomienda usar el mismo protocolo que el balanceador de cargas; sin embargo, no es un requisito, ni siempre es posible. Por ejemplo, los balanceadores de cargas de red requieren verificaciones de estado heredadas que usen el protocolo HTTP, a pesar de que el balanceo de cargas de red admite TCP y UDP en general. Para los balanceadores de cargas de red, debes ejecutar un servidor HTTP en las VM a fin de que puedan responder a los sondeos de verificación de estado.

En la siguiente tabla, se enumeran las categorías de verificación de estado y los protocolos que admite cada categoría.

Categoría de verificación de estado Protocolos admitidos
Verificación de estado • HTTP
• HTTPS
• HTTP/2
• SSL
• TCP
Verificación de estado heredada • HTTP
• HTTPS (las verificaciones de estado HTTPS heredadas no son compatibles con los balanceadores de cargas de red y no se pueden usar con la mayoría de los otros tipos de balanceadores de cargas).

Categoría y especificación de puerto

Además de un protocolo, debes seleccionar una especificación de puerto para la verificación de estado. Las verificaciones de estado proporcionan tres métodos de especificación de puertos y las de estado heredadas proporcionan uno. No todos los métodos de especificación de puertos son aplicables a cada tipo de balanceador de cargas. El tipo de balanceador de cargas y los tipos de backends que usa determinan el método de especificación de puerto que puedes usar.

Categoría de verificación de estado Métodos de especificación de puertos y significados
Verificación de estado --port: especifica un número de puerto TCP
--port-name: especifica cualquier conjunto de puertos con nombre en un grupo de instancias
--use-serving-port: para los grupos de instancias, usa el mismo puerto con nombre que usa el servicio de backend; para los grupos de extremos de red, usa el puerto definido en cada extremo
Verificación de estado heredada --port: especifica un número de puerto TCP

Ten en cuenta aquí y a continuación: la marca --use-serving-port se implementa con gcloud beta compute health-checks create, pero no con gcloud beta compute health-checks update.

Guía del balanceador de cargas

Usa esta tabla para elegir la categoría y el protocolo correctos de verificación de estado para un balanceador de cargas determinado.

Balanceador de cargas Tipo de backend Categoría y alcance de la verificación de estado Especificación de puerto
TCP/UDP interno Grupos de instancias en un servicio de backend interno regional Verificación de estado (global) Número de puerto (--port) o puerto con nombre (--port-name).
No puedes usar la marca --use-serving-port porque los servicios de backend con esquemas de balanceo de cargas INTERNAL no tienen un puerto con nombre asociado.
HTTP(S) interno Grupos de extremos de red
en un servicio de backend
Verificación de estado (regional) Número de puerto (--port) o
--use-serving-port
Grupos de instancias en un servicio de backend Verificación de estado (regional) Número de puerto (--port), puerto con nombre (--port-name) o
--use-serving-port
De red Grupos de instancias que usan grupos de destino Verificación de estado heredada (global)
con el protocolo HTTP
Las verificaciones de estado heredadas solo admiten la especificación del puerto por número de puerto (--port).
Proxy TCP
Proxy SSL
HTTP(S) 1
Grupos de extremos de red
en un servicio de backend
Verificación de estado (global) Número de puerto (--port) o
--use-serving-port
Grupos de instancias en un servicio de backend Verificación de estado (global) Número de puerto (--port), puerto con nombre (--port-name) o
--use-serving-port

1Es posible, pero no se recomienda, usar una verificación de estado heredada para servicios de backend asociados con balanceadores de cargas HTTP(S) en las siguientes circunstancias:

  • Los backends que usa el servicio de backend son grupos de instancias, no grupos de extremos de red.
  • Las VM de backend se pueden sondear con HTTP o HTTPS.

Cómo funcionan las verificaciones de estado

Sondeos

Cuando creas una verificación de estado o una verificación de estado heredada, especifica las siguientes marcas o acepta sus valores predeterminados. Estas marcas controlan la frecuencia con la que cada sistema de verificación de estado de GCP sondea tu grupo de instancias o backends de NEG. GCP implementa sondeos con varios sistemas.

La configuración de una verificación de estado no se puede establecer por backend. Las verificaciones de estado se asocian con un servicio de backend completo y las de estado heredadas se asocian con un grupo de destino o servicio de backend completo para ciertos balanceadores de cargas de HTTP(S). Por lo tanto, los parámetros del sondeo son los mismos para todos los backends a los que hace referencia un servicio de backend o grupo de destino determinado.

Marca de configuración Propósito Valor predeterminado
Intervalo de verificación
check-interval
El intervalo de verificación es la cantidad de tiempo desde el inicio de un sondeo que emite un sistema de sondeo hasta el inicio del próximo sondeo que emita el mismo sistema. Las unidades son segundos. Si se omite, GCP usa 5s (5 segundos).
Tiempo de espera
timeout
El tiempo de espera es la cantidad de tiempo que GCP esperará una respuesta de un sondeo. Su valor debe ser menor o igual que el intervalo de verificación. Las unidades son segundos. Si se omite, GCP usa 5s (5 segundos).

Rangos de IP del sondeo

Las direcciones IP de origen para los sistemas de sondeo de GCP dependen del tipo de balanceador de cargas. Usa la siguiente tabla para crear reglas de firewall de entrada que permiten el tráfico de los sistemas de sondeo de GCP a tus backends.

Balanceador de cargas Rangos de IP del sondeo Ejemplo de regla de firewall
Interno
Proxy TCP
Proxy SSL
HTTP(S)
HTTP(S) interno
35.191.0.0/16
130.211.0.0/22
Reglas de firewall para todos los balanceadores de cargas, excepto los balanceadores de cargas de red
De red 35.191.0.0/16
209.85.152.0/22
209.85.204.0/22
Reglas de firewall para los balanceadores de cargas de red

Sondeos múltiples y frecuencia

GCP envía sondeos de verificación de estado de varios sistemas redundantes desde los rangos de IP de origen apropiados. Ningún sistema de sondeo único es responsable de todos los sondeos. Varios sistemas emiten sondeos al mismo tiempo, de modo que, si falla uno de ellos, GCP no perderá de vista los estados del backend.

La configuración de intervalo y tiempo de espera que configures para una verificación de estado se aplica a cada sistema de sondeo. Para un backend determinado, los registros de acceso al software y tcpdump muestran sondeos de verificación de estado más frecuentes que la configuración establecida. Los múltiples sistemas de sondeo que se comunican de manera simultánea con los backends generan más sondeos de verificación de estado que la configuración de un sistema de sondeo único.

Este es el comportamiento esperado y no puedes configurar la cantidad de sistemas de sondeo que usa GCP para las verificaciones de estado. Sin embargo, puedes estimar el efecto de múltiples sondeos simultáneos si consideras los siguientes factores:

  • Considera esto para estimar la frecuencia de sondeo por servicio de backend:

    • Frecuencia base por servicio de backend: cada verificación de estado tiene una frecuencia de verificación asociada, inversamente proporcional al intervalo de verificación configurado:

      1(verifica el intervalo)

      Cuando asocias una verificación de estado con un servicio de backend, estableces una frecuencia base que usa cada sistema de sondeo para backends en ese servicio de backend.

    • Factor de escala de sondeo: la frecuencia base del servicio de backend se multiplica por la cantidad de sistemas de sondeo simultáneos que usa GCP. Esta cantidad puede variar, pero por lo general está entre 5 y 10.

  • Varias reglas de reenvío para balanceadores de cargas TCP/UDP internos: si configuraste varias reglas de reenvío internas (cada una con una dirección IP diferente) que apuntan al mismo servicio de backend interno regional, GCP usa múltiples sistemas de sondeo a fin de verificar cada dirección IP. La frecuencia de sondeo por servicio de backend se multiplica por la cantidad de reglas de reenvío configuradas.

  • Varias reglas de reenvío para balanceadores de cargas de red: si configuraste varias reglas de reenvío que apuntan al mismo grupo de destino, GCP usa varios sistemas de sondeo a fin de verificar cada dirección IP. La frecuencia de sondeo que ve cada backend en el grupo de destino se multiplica por la cantidad de reglas de reenvío configuradas.

  • Varios proxies de destino para balanceadores de cargas de HTTP(S): si configuraste varios proxies de destino para la misma asignación de URL con el fin de realizar el balanceo de cargas de HTTP(S), GCP usa varios sistemas de sondeo a fin de verificar la dirección IP asociada con cada proxy de destino. La frecuencia de sondeo por servicio de backend se multiplica por la cantidad de proxies de destino configurados.

  • Varios proxies de destino para balanceadores de cargas Proxy SSL y Proxy TCP: si configuraste varios proxies de destino para el mismo servicio de backend para el balanceo de cargas de Proxy TCP o Proxy SSL, GCP usa varios sistemas de sondeo a fin de verificar la dirección IP asociada con cada proxy de destino. La frecuencia de sondeo por servicio de backend se multiplica por la cantidad de proxies de destino configurados.

  • Suma sobre servicios de backend: si varios servicios de backend usan un backend (como un grupo de instancias), las instancias de backend se contactan con tanta frecuencia como la suma de frecuencias para cada verificación de estado del servicio de backend.

    Con los backends de grupo de extremo de red (NEG), es más difícil determinar la cantidad exacta de sondeos de verificación de estado. Por ejemplo, el mismo extremo puede estar en varios NEG, en los que esos NEG no necesariamente tienen el mismo conjunto de extremos, y diferentes extremos pueden apuntar al mismo backend.

Destino de los paquetes de verificación de estado

Los sondeos de verificación de estado de GCP envían paquetes solo a la interfaz de red principal de cada instancia de backend. La dirección IP de destino de estos paquetes depende del tipo de balanceador de cargas:

  • Para los balanceadores de cargas TCP/UDP internos y los de red, el destino de los paquetes de verificación de estado es la dirección IP de la regla de reenvío del balanceador de cargas. Si varias reglas de reenvío apuntan al mismo servicio de backend o grupo de destino, GCP envía sondeos a la dirección IP de cada regla de reenvío. Esto puede dar como resultado un aumento en la cantidad de sondeos, como se describió en la sección anterior.
  • Para los balanceadores de cargas de HTTP(S), TCP Proxy, SSL Proxy y HTTP(S) internos que usan grupos de instancias como backends, el destino de los paquetes de verificación de estado es la dirección IP interna principal asociada con la interfaz de red principal de cada instancia de backend.
  • Para los balanceadores de cargas HTTP(S), Proxy TCP, Proxy SSL y HTTP(S) internos que usan grupos de extremos de red como backends, el destino de los paquetes de verificación de estado es la dirección IP del extremo, que puede ser una dirección principal o secundaria (IP de alias).

Verificaciones de estado en función del contenido

Las verificaciones de estado HTTP(S), HTTP/2, TCP y SSL pueden basarse en el contenido (solicitud/respuesta) de manera opcional. En una verificación de estado en función del contenido, el sondeo de la verificación de estado envía una string de solicitud al backend. La verificación de estado está configurada para esperar una respuesta particular al sondeo.

Criterios de éxito para HTTP, HTTPS y HTTP/2

Las respuestas de sondeos para verificaciones de estado mediante protocolos HTTP, HTTPS o HTTP/2 solo tienen éxito si GCP recibe una respuesta HTTP 200 (OK) a la solicitud que envía y esa respuesta se entrega antes de que se agote el tiempo de espera del sondeo.

Las solicitudes se envían a una ruta de solicitud configurable o /, si no se especifica. Se acepta cualquier respuesta, a menos que uses la verificación basada en contenido para proporcionar una string de respuesta esperada. Estas son las marcas disponibles para controlar los criterios de éxito para las verificaciones de estado HTTP, HTTPS y HTTP/2:

Marca de configuración Propósito
Ruta de la solicitud
request-path
Especifica la ruta de URL a la que GCP envía solicitudes de sondeo de verificación de estado.
Si se omite, GCP envía solicitudes de sondeo a la ruta raíz, /. La opción request-path no admite parámetros de consulta.
Respuesta
response
La marca de respuesta opcional te permite configurar una verificación de estado basada en el contenido. La string de respuesta esperada debe ser menor o igual que 1,024 caracteres ASCII (un solo byte). Cuando se configura, GCP espera esta string dentro de los primeros 1,024 bytes de la respuesta, además de recibir el estado HTTP 200 (OK).

El uso de una verificación de estado en función del contenido es opcional. Ya sea que especifiques o no una string de respuesta esperada, GCP espera que el backend verificado responda con HTTP 200 (OK). Cuando proporcionas una respuesta esperada, cada sondeo de verificación de estado de GCP busca la string de respuesta esperada dentro de los primeros 1,024 bytes en la respuesta que proporcionan tus backends. Una verificación de estado HTTP basada en el contenido se considera exitosa si se recibe HTTP 200 (OK) y la respuesta esperada se encuentra en los primeros 1,024 bytes de la respuesta.

Criterios de éxito para SSL y TCP

De forma predeterminada, las respuestas provenientes de sondeos de verificaciones de estado mediante protocolos SSL y TCP son exitosas solo si GCP puede completar un protocolo de enlace SSL o TCP a fin de establecer una sesión antes del que se agote el tiempo de espera del sondeo.

De manera opcional, además de completar un protocolo de enlace, puedes proporcionar una string de solicitud y una string de respuesta esperada, cada una de hasta 1,024 caracteres ASCII (de un solo byte). Cuando se configura una string de respuesta esperada, GCP considera que un sondeo es exitoso solo si se completa el protocolo de enlace SSL o TCP y la string de respuesta mostrada coincide de forma exacta con la string de respuesta esperada. Las siguientes combinaciones de marcas de solicitud y respuesta están disponibles para las verificaciones de estado mediante los protocolos SSL y TCP:

Marcas de configuración Comportamiento
No se especifican ni una solicitud ni una respuesta
No se especifica ninguna de las dos marcas: --request, --response
GCP considera que el sondeo tuvo éxito si la sesión TCP o SSL se establece antes de que se agote el tiempo de espera del sondeo.
Se especifican la solicitud y la respuesta
Se especifican las dos marcas: --request, --response
GCP envía la string de solicitud configurada y espera la string de respuesta esperada. El sondeo se ejecuta de manera correcta si la sesión TCP o SSL se establece y la string de respuesta que se muestra coincide de forma exacta con la string de respuesta esperada antes de que se agote el tiempo de espera del sondeo.
Solo se especifica la respuesta
Marcas especificadas: solo --response
GCP espera la string de respuesta esperada. El sondeo se ejecuta de manera correcta si la sesión TCP o SSL se establece y la string de respuesta que se muestra coincide de forma exacta con la string de respuesta esperada antes de que se agote el tiempo de espera del sondeo.
Solo debes usar --response si los backends cuya carga se balancea enviarían de manera automática una string de respuesta como parte del protocolo de enlace.
Solo se especifica la solicitud
Marcas especificadas: solo --request
GCP envía la string de solicitud configurada. El sondeo tiene éxito si se establece una sesión TCP o SSL antes de que se agote el tiempo de espera del sondeo. La respuesta, si la hay, no está verificada.

Estado

GCP usa las siguientes marcas de configuración y examina si los sondeos se realizaron de manera correcta para determinar el estado general de cada uno de los backends cuyas cargas se balancean:

Marca de configuración Propósito Valor predeterminado
Umbral de buen estado
healthy-threshold
El umbral de buen estado especifica la cantidad de resultados de sondeos secuenciales correctos para que se considere que un backend está en buen estado. Si se omite, GCP usa un umbral de 2 sondeos.
Umbral de mal estado
unhealthy-threshold
El umbral de mal estado especifica la cantidad de resultados de sondeos secuenciales fallidos para que se considere que un backend está en mal estado. Si se omite, GCP usa un umbral de 2 sondeos.

GCP considera que los backends están en buen estado una vez que se alcanza este umbral de buen estado. Los backends en buen estado son aptos para recibir conexiones nuevas.

GCP considera que los backends están en mal estado cuando se alcanza el umbral de mal estado. Los backends en mal estado no son aptos para recibir conexiones nuevas. Sin embargo, las conexiones existentes no se finalizan de inmediato. En cambio, la conexión permanece abierta hasta que se agota el tiempo de espera o se deja de recibir tráfico. El comportamiento específico difiere según el tipo de balanceador de cargas que uses.

Las conexiones existentes pueden no mostrar respuestas, según la causa por la que fallan el sondeo. Un backend en mal estado puede mejorar si es capaz de alcanzar el umbral de buen estado otra vez.

Próximos pasos

Para obtener información sobre cómo configurar verificaciones de estado, consulta la página acerca de cómo crear verificaciones de estado.

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...