Google Cloud ofrece comprobaciones de estado configurables para los backends de Google Cloud balanceadores de carga, los backends de Cloud Service Mesh y la autorreparación basada en aplicaciones para grupos de instancias gestionados. En este documento se explican los conceptos clave de las comprobaciones de estado.
A menos que se indique lo contrario,las Google Cloud comprobaciones del estado se implementan mediante tareas de software específicas que se conectan a los backends según los parámetros especificados en un recurso de comprobación del estado. Cada intento de conexión se denomina sondeo. Google Cloud registra si cada sondeo se ha realizado correctamente o no.
En función de un número configurable de comprobaciones secuenciales correctas o fallidas, se calcula un estado de salud general para cada backend. Los backends que responden correctamente el número de veces configurado se consideran en buen estado. Los back-ends que no responden correctamente un número de veces configurable por separado se consideran no aptos.
El estado general de cada backend determina si puede recibir nuevas solicitudes o conexiones. Puede configurar los criterios que definen una sonda correcta. Este tema se trata en detalle en la sección Cómo funcionan las comprobaciones de estado.
Las comprobaciones de estado implementadas por tareas de software específicas usan rutas especiales que no están definidas en tu red de nube privada virtual (VPC). Para obtener más información, consulta Rutas de comprobaciones del estado.
Categorías, protocolos y puertos de comprobación del estado
Las comprobaciones de estado tienen una categoría y un protocolo. Las dos categorías son comprobaciones del estado y comprobaciones del estado antiguas, y sus protocolos admitidos son los siguientes:
Comprobaciones del estado
- Regional (gRPC, TCP, SSL, HTTP, HTTPS o HTTP/2)
- gRPC regional (con TLS) (vista previa)
- Global (gRPC, TCP, SSL, HTTP, HTTPS o HTTP/2)
- gRPC global (con TLS) (vista previa)
Comprobaciones del estado antiguas:
El protocolo y el puerto determinan cómo se realizan las sondas de comprobación del estado. Por ejemplo, una comprobación de estado puede usar el protocolo HTTP en el puerto TCP 80 o el protocolo TCP para un puerto con nombre en un grupo de instancias.
No puedes convertir una comprobación del estado antigua en una comprobación del estado ni viceversa.
Seleccionar una comprobación del estado
Las comprobaciones del estado deben ser compatibles con el tipo de balanceador de carga (o Cloud Service Mesh) y con los tipos de backend. A la hora de seleccionar una comprobación de estado, debes tener en cuenta los siguientes factores:
- Categoría: comprobación del estado o comprobación del estado antigua. Solo los balanceadores de carga de red de paso a través externos basados en grupos de destino requieren comprobaciones de estado antiguas. En el resto de los productos, utilizarás comprobaciones de estado normales.
- Protocolo: protocolo que usa Google Cloud para sondear los backends. Es mejor usar una comprobación del estado (o una comprobación del estado antigua) cuyo protocolo coincida con el protocolo que usa el servicio de backend o el grupo de destino del balanceador de carga. Sin embargo, los protocolos de comprobación del estado y los protocolos del balanceador de carga no tienen que ser los mismos.
- Especificación de puerto: puertos que usa Google Cloud con el protocolo.
Debes especificar un puerto para la comprobación del estado. Las comprobaciones de estado tienen dos métodos de especificación de puertos:
--porty--use-serving-port. En el caso de las comprobaciones de estado antiguas, solo hay un método:--port. Para obtener más información sobre los requisitos de los puertos de comprobación del estado por balanceador de carga, consulta las marcas de especificación de puertos.
En la siguiente sección se describen las selecciones válidas de comprobación de estado para cada tipo de balanceador de carga y backend.
Guía del balanceador de carga
En esta tabla se muestran la categoría y el ámbito de comprobación de estado admitidos para cada tipo de balanceador de carga.
| Modo del balanceador de carga | Comprobaciones del estado antiguas admitidas |
|---|---|
Balanceador de carga de aplicación externo global Balanceador de carga de aplicación clásico |
Sí, si se cumplen las dos condiciones siguientes:
|
| Balanceador de carga de aplicación externo regional | No |
Notas de uso adicionales
En el caso de los backends de grupos de instancias de VM, las comprobaciones de estado solo se realizan en las instancias de VM que se han iniciado. Las instancias de VM detenidas no reciben paquetes de comprobación del estado.
En el caso de los balanceadores de carga de red de paso a través internos, solo puedes usar
TCPoUDPpara el protocolo del servicio de backend. Si sirves tráfico HTTP desde VMs que están detrás de un balanceador de carga de red de transferencia interno, es recomendable usar una comprobación de estado con el protocolo HTTP.Un balanceador de carga de red de paso a través externo basado en un grupo de destino debe usar una comprobación de estado HTTP antigua. No puede usar una comprobación del estado de HTTPS antigua ni ninguna comprobación del estado no antigua. Si usas un balanceador de carga de red de transferencia externo basado en un grupo de destino para balancear el tráfico TCP, debes ejecutar un servicio HTTP en las VMs que se están balanceando para que puedan responder a las sondas de comprobación del estado.
En el caso de casi todos los demás tipos de balanceadores de carga, debes usar comprobaciones de estado normales (no antiguas) en las que el protocolo coincida con el protocolo del servicio de backend del balanceador de carga.En el caso de los servicios de backend que usan el protocolo gRPC, utilice solo comprobaciones de estado de gRPC o TCP. No uses comprobaciones de estado HTTP(S) ni HTTP/2.
Algunos balanceadores de carga basados en Envoy que usan backends de NEG híbridos no admiten comprobaciones de estado de gRPC. Para obtener más información, consulta la descripción general de los NEGs híbridos.
Comprobación del estado con Cloud Service Mesh
Ten en cuenta las siguientes diferencias en el comportamiento cuando uses comprobaciones de estado con Cloud Service Mesh.
Con Cloud Service Mesh, el comportamiento de la comprobación del estado de los puntos finales de red de los tipos
INTERNET_FQDN_PORTyNON_GCP_PRIVATE_IP_PORTes diferente del de otros tipos de puntos finales de red. En lugar de usar tareas de software específicas, Cloud Service Mesh programa proxies de Envoy para realizar comprobaciones de estado de NEGs de Internet (endpointsINTERNET_FQDN_PORT) y NEGs híbridos (endpointsNON_GCP_PRIVATE_IP_PORT).Envoy admite los siguientes protocolos para comprobar el estado:
- HTTP
- HTTPS
- HTTP/2
- TCP
Cuando Cloud Service Mesh se integra con Service Directory y vinculas un servicio de Service Directory a un servicio de backend de Cloud Service Mesh, no puedes definir una comprobación de estado en el servicio de backend.
Cómo funcionan las comprobaciones del estado
En las siguientes secciones se describe cómo funcionan las comprobaciones de estado.
Comprobaciones
Cuando creas una comprobación de estado o una comprobación de estado antigua, especificas las siguientes marcas o aceptas sus valores predeterminados. Cada comprobación del estado o comprobación del estado antigua que crees se implementa mediante varias sondas. Estas marcas controlan la frecuencia con la que cada prueba evalúa las instancias de los grupos de instancias o los endpoints de los NEGs zonales.
Los ajustes de una comprobación del estado no se pueden configurar por backend. Las comprobaciones de estado se asocian a un servicio de backend completo. En el caso de un balanceador de carga de red de paso a través externo basado en grupos de destino, se asocia una comprobación del estado HTTP antigua a todo el grupo de destino. Por lo tanto, los parámetros de la sonda son los mismos para todos los backends a los que hace referencia un servicio de backend o un grupo de destino determinado.
| Marca de configuración | Finalidad | Valor predeterminado |
|---|---|---|
Intervalo de comprobacióncheck-interval |
El intervalo de comprobación es el tiempo que transcurre desde el inicio de una sonda emitida por un comprobador hasta el inicio de la siguiente sonda emitida por el mismo comprobador. Las unidades son segundos. | 5s (5 segundos) |
Tiempo de espera agotadotimeout |
El tiempo de espera es el tiempo que Google Cloud espera una respuesta a una sonda. Su valor debe ser inferior o igual al intervalo de comprobación. Las unidades son segundos. | 5s (5 segundos) |
Intervalos de IP y reglas de cortafuegos de las sondas
Para que las comprobaciones de estado funcionen, debes crear reglas de cortafuegos de entrada allow para que el tráfico de los Google Cloud probers pueda conectarse a tus backends. Para obtener instrucciones, consulta el artículo sobre cómo crear las reglas de cortafuegos necesarias.
En la siguiente tabla se muestran los intervalos de IPs de origen que se deben permitir para cada balanceador de carga:
| Producto | Intervalos de IP de origen de la sonda de comprobación del estado |
|---|---|
|
Para el tráfico IPv6 a los back-ends:
|
|
Para el tráfico IPv6 a los back-ends:
|
|
|
| Balanceador de carga de red de paso a través externo 3 |
Para el tráfico IPv4 a los backends:
Para el tráfico IPv6 a los back-ends:
|
| Balanceador de carga de red de paso a través interno |
Para el tráfico IPv4 a los backends:
Para el tráfico IPv6 a los back-ends:
|
| Cloud Service Mesh con backends de NEG de Internet y backends de NEG híbridos | Direcciones IP de las VMs que ejecutan el software Envoy Para ver una configuración de ejemplo, consulta la documentación de Cloud Service Mesh. |
1 No es necesario permitir el tráfico de los intervalos de comprobación del estado de Google para los NEG híbridos. Sin embargo, si utilizas una combinación de NEGs híbridos y zonales en un mismo servicio de backend, debes permitir el tráfico de los intervalos de sondeo de comprobación de estado de Google para los NEGs zonales.
2 En el caso de los NEGs de Internet regionales, las comprobaciones del estado son opcionales. El tráfico de los balanceadores de carga que usan NEGs de Internet regionales procede de la subred solo de proxy y, a continuación, se traduce mediante NAT (con Cloud NAT) a direcciones IP de NAT asignadas de forma manual o automática. Este tráfico incluye tanto las comprobaciones del estado como las solicitudes de los usuarios del balanceador de carga a los backends. Para obtener más información, consulta NEGs regionales: usar una pasarela de Cloud NAT.
3 Los balanceadores de carga de red de paso a través externos basados en grupos de destino solo admiten tráfico IPv4 y pueden proxyizar las comprobaciones de estado a través del servidor de metadatos. En este caso, las fuentes de paquetes de comprobación del estado coinciden con la dirección IP del servidor de metadatos: 169.254.169.254. No es necesario que cree reglas de cortafuegos para permitir el tráfico del servidor de metadatos. Los paquetes del servidor de metadatos siempre están permitidos.
Importancia de las reglas de cortafuegos
Google Cloud requiere que crees las reglas de cortafuegos de entrada allow
necesarias para permitir el tráfico de los verificadores a tus backends. Como práctica recomendada, limita estas reglas a los protocolos y puertos que coincidan con los que usan tus comprobaciones del estado. En el caso de los intervalos de IPs de origen, asegúrate de usar los intervalos de IPs de sondeo documentados que se indican en la sección anterior.
Si no tienes reglas de cortafuegos de entrada allow que permitan la comprobación del estado, la regla deny implícita bloquea el tráfico entrante. Cuando los verificadores no pueden ponerse en contacto con tus backends, el balanceador de carga considera que estos no están en buen estado.
Consideraciones de seguridad para los intervalos de IPs de sondeo
Ten en cuenta la siguiente información al planificar las comprobaciones del estado y las reglas de cortafuegos necesarias:
Los intervalos de IP de las sondas pertenecen a Google. Google Cloud usa rutas especiales fuera de tu red de VPC, pero dentro de la red de producción de Google, para facilitar la comunicación de las sondas.
Google usa los intervalos de IPs de sondeo para enviar sondeos de comprobación de estado de los balanceadores de carga de aplicaciones externos y los balanceadores de carga de red con proxy externos. Si se recibe un paquete de Internet y la dirección IP de origen del paquete se encuentra dentro de un intervalo de IPs de sondeo, Google lo descarta. como la dirección IP externa de una instancia de Compute Engine o un nodo de Google Kubernetes Engine (GKE).
Los intervalos de IP de las sondas son un conjunto completo de direcciones IP posibles que usan las sondas deGoogle Cloud . Si usas
tcpdumpo una herramienta similar, es posible que no veas el tráfico de todas las direcciones IP de todos los intervalos de IP de sondeo. Como práctica recomendada, cree reglas de cortafuegos de entrada que permitan todos los intervalos de IPs de la sonda como fuentes. Google Cloud puede implementar nuevas sondas automáticamente sin notificación.
Varias sondas y frecuencia
Google Cloud Envía sondeos de comprobación de estado desde varios sistemas redundantes llamados "sondas". Los verificadores usan intervalos de IPs de origen específicos. Google Cloud no se basa en un solo verificador para implementar una comprobación de estado: varios verificadores evalúan simultáneamente las instancias de los backends de grupos de instancias o los endpoints de los backends de NEGs zonales. Si falla una sonda, Google Cloud sigue monitorizando el estado de los back-ends.
Los ajustes de intervalo y de tiempo de espera que configures para una comprobación de estado se aplican a cada comprobador. En un backend determinado, los registros de acceso al software y tcpdump muestran sondeos más frecuentes que los ajustes configurados.
Es un comportamiento esperado y no puedes configurar el número de sondas que Google Cloud usa para las comprobaciones del estado. Sin embargo, puedes estimar el efecto de varias sondas simultáneas teniendo en cuenta los siguientes factores.
Para estimar la frecuencia de las sondas por servicio de backend, ten en cuenta lo siguiente:
Frecuencia base por servicio de backend. Cada comprobación de estado tiene una frecuencia asociada, que es inversamente proporcional al intervalo de comprobación configurado:
1⁄(intervalo de comprobación)
Cuando asocias una comprobación del estado a un servicio de backend, estableces una frecuencia base que usa cada comprobador para los backends de ese servicio.
Factor de escala de la sonda. La frecuencia base del servicio de backend se multiplica por el número de verificadores simultáneos que usa Google Cloud . Este número puede variar, pero suele estar entre 5 y 10.
Varias reglas de reenvío para balanceadores de carga de red de paso a través internos. Si has configurado varias reglas de reenvío internas (cada una con una dirección IP diferente) que apuntan al mismo servicio de backend interno regional,Google Cloud utiliza varios verificadores para comprobar cada dirección IP. La frecuencia de la sonda por servicio de backend se multiplica por el número de reglas de reenvío configuradas.
Varias reglas de reenvío para balanceadores de carga de red de paso a través externos. Si has configurado varias reglas de reenvío que apuntan al mismo servicio de backend o al mismo grupo de destino, Google Cloud se usan varios verificadores para comprobar cada dirección IP. La frecuencia de la sonda por VM de backend se multiplica por el número de reglas de reenvío configuradas.
Varios proxies de destino para balanceadores de carga de aplicación externos. Si tienes varios proxies de destino que dirigen el tráfico al mismo mapa de URLs, Google Cloud usa varios verificadores para comprobar la dirección IP asociada a cada proxy de destino. La frecuencia de la sonda por servicio de backend se multiplica por el número de proxies de destino configurados.
Varios proxies de destino para balanceadores de carga de red de proxy externo y balanceadores de carga de red de proxy interno regional. Si has configurado varios proxies de destino que dirigen el tráfico al mismo servicio de backend,Google Cloud utiliza varios verificadores para comprobar la dirección IP asociada a cada proxy de destino. La frecuencia de la sonda por servicio de backend se multiplica por el número de proxies de destino configurados.
Suma de los servicios de backend. Si varios servicios de backend usan un backend, se contacta con las instancias del backend con la misma frecuencia que la suma de las frecuencias de la comprobación de estado de cada servicio de backend.
Con los back-ends de NEG zonales, es más difícil determinar el número exacto de sondeos de comprobación de estado. Por ejemplo, el mismo endpoint puede estar en varios NEG zonales. Esas NEGs zonales no tienen necesariamente el mismo conjunto de endpoints y diferentes endpoints pueden apuntar al mismo backend.
Destino de los paquetes de sondeo.
En la siguiente tabla se muestran la interfaz de red y las direcciones IP de destino a las que envían paquetes los verificadores de comprobación del estado, en función del tipo de balanceador de carga.
En el caso de los balanceadores de carga de red de paso a través externos e internos, la aplicación debe enlazarse a la dirección IP del balanceador de carga (o a cualquier dirección IP 0.0.0.0).
| Balanceador de carga | Interfaz de red de destino | Dirección IP de destino |
|---|---|---|
|
|
|
|
|
|
| Balanceador de carga de red de paso a través externo | Interfaz de red principal (nic0) |
Dirección IP de la regla de reenvío externa. Si varias reglas de reenvío apuntan al mismo servicio de backend (en el caso de los balanceadores de carga de red de pases externos basados en grupos de destino, al mismo grupo de destino), Google Cloud envía sondeos a la dirección IP de cada regla de reenvío. Esto puede provocar un aumento en el número de comprobaciones. |
| Balanceador de carga de red de paso a través interno | En el caso de los backends de grupos de instancias y los backends de NEGs zonales con
endpoints GCE_VM_IP, la interfaz de red utilizada depende de
cómo se configure el servicio de backend. Para obtener más información, consulta la sección sobre los servicios backend y las interfaces de red.
|
Dirección IP de la regla de reenvío interna. Si varias reglas de reenvío apuntan al mismo servicio de backend, Google Cloud envía sondeos a la dirección IP de cada regla de reenvío. Esto puede provocar un aumento del número de sondeos. |
Criterios de éxito de HTTP, HTTPS y HTTP/2
Las comprobaciones del estado de HTTP, HTTPS y HTTP/2 siempre requieren que se reciba un código de respuesta HTTP 200 (OK) antes de que se agote el tiempo de espera de la comprobación del estado. Todos los demás códigos de respuesta HTTP, incluidos los códigos de respuesta de redirección, como 301 y 302, se consideran incorrectos.
Además de requerir un código de respuesta HTTP 200 (OK), puedes hacer lo siguiente:
Configura cada comprobador de estado para que envíe solicitudes HTTP a una ruta de solicitud específica en lugar de a la ruta de solicitud predeterminada,
/.Configura cada comprobador de estado para que compruebe si hay una cadena de respuesta esperada en el cuerpo de la respuesta HTTP. La cadena de respuesta esperada solo debe incluir caracteres ASCII imprimibles de un byte, que se encuentren en los primeros 1024 bytes del cuerpo de la respuesta HTTP.
En la siguiente tabla se muestran las combinaciones válidas de ruta de solicitud y marcas de respuesta que están disponibles para las comprobaciones de estado HTTP, HTTPS y HTTP/2.
| Marcas de configuración | Comportamiento de la sonda | Criterios de éxito |
|---|---|---|
No se ha especificado ni --request-path ni --response
|
El verificador usa / como ruta de solicitud. |
Solo el código de respuesta HTTP 200 (OK). |
Se han especificado tanto --request-path como --response
|
El comprobador usa la ruta de solicitud configurada. | El código de respuesta HTTP 200 (OK) y los primeros 1024 caracteres ASCII del cuerpo de la respuesta HTTP deben coincidir con la cadena de respuesta esperada. |
Solo se ha especificado --response
|
El verificador usa / como ruta de solicitud. |
El código de respuesta HTTP 200 (OK) y los primeros 1024 caracteres ASCII del cuerpo de la respuesta HTTP deben coincidir con la cadena de respuesta esperada. |
Solo se ha especificado --request-path
|
El comprobador usa la ruta de solicitud configurada. | Solo el código de respuesta HTTP 200 (OK). |
Criterios de éxito de SSL y TCP
Las comprobaciones del estado de TCP y SSL tienen los siguientes criterios de éxito básicos:
En el caso de las comprobaciones de estado de TCP, un comprobador de estado debe abrir correctamente una conexión TCP con el backend antes de que se agote el tiempo de espera de la comprobación de estado.
En el caso de las comprobaciones de estado de SSL, un comprobador de estado debe abrir correctamente una conexión TCP con el backend y completar el handshake de TLS/SSL antes de que se agote el tiempo de espera de la comprobación de estado.
En el caso de las comprobaciones de estado TCP, la conexión TCP debe cerrarse de una de las siguientes formas:
- El verificador de comprobación de estado envía un paquete FIN o RST (restablecimiento).
- El backend envía un paquete FIN. Si un backend envía un paquete TCP RST, es posible que la sonda se considere fallida si el comprobador de estado ya ha enviado un paquete FIN.
En la siguiente tabla se muestran las combinaciones válidas de marcas de solicitud y respuesta que están disponibles para las comprobaciones de estado de TCP y SSL. Tanto las marcas de solicitud como las de respuesta solo pueden incluir caracteres ASCII imprimibles de un byte. La longitud de cada cadena no puede superar los 1024 caracteres.
| Marcas de configuración | Comportamiento de la sonda | Criterios de éxito |
|---|---|---|
No se ha especificado ni --request ni --response
|
El comprobador no envía ninguna cadena de solicitud. | Solo los criterios de éxito básicos. |
Se han especificado tanto --request como --response
|
El comprobador envía la cadena de solicitud configurada. | Los criterios de éxito básicos y la cadena de respuesta recibida por la sonda deben coincidir exactamente con la cadena de respuesta esperada. |
Solo se ha especificado --response
|
El comprobador no envía ninguna cadena de solicitud. | Los criterios de éxito básicos y la cadena de respuesta recibida por la sonda deben coincidir exactamente con la cadena de respuesta esperada. |
Solo se ha especificado --request
|
El comprobador envía la cadena de solicitud configurada. | Solo los criterios de éxito básicos (no se comprueba ninguna cadena de respuesta). |
Criterios de éxito de gRPC
Las comprobaciones de estado de gRPC solo se usan con aplicaciones gRPC, Google Cloud balanceadores de carga y Cloud Service Mesh. Google Cloud admite dos tipos de comprobaciones de estado de gRPC:
GRPC_WITH_TLS(Vista previa) Las comprobaciones de estado se usan para comprobar el estado de los back-ends de gRPC con TLS habilitado. Admiten el cifrado TLS no autenticado, lo que significa que las comprobaciones de estado no verifican la identidad del servidor.- Las comprobaciones del estado
GRPCse usan para comprobar el estado de los backends de gRPC no seguros. No admiten la autenticación ni el cifrado, por lo que no se pueden usar en back-ends de gRPC con TLS habilitado.
Si usas comprobaciones de estado de gRPC (con o sin TLS), asegúrate de que el servicio gRPC envíe la respuesta RPC con el estado OK y el campo de estado definido como SERVING o NOT_SERVING, según corresponda.
Para obtener más información, consulta las siguientes secciones:
- Marca adicional para comprobaciones de estado de gRPC
- Documentación de gRPC sobre comprobaciones de estado
Criterios de éxito de las comprobaciones del estado antiguas
Si la respuesta recibida por la comprobación del estado antigua es HTTP 200 OK, se considera que la comprobación se ha realizado correctamente. Todos los demás códigos de respuesta HTTP, incluida una redirección (301, 302), se consideran incorrectos.
Estado de salud
Google Cloud usa las siguientes marcas de configuración para determinar el estado general de cada backend al que se equilibra la carga del tráfico.
| Marca de configuración | Finalidad | Valor predeterminado |
|---|---|---|
Umbral en buen estadohealthy-threshold |
El umbral de buen estado especifica el número de resultados de sondeo correctos consecutivos para que un backend que no estaba en buen estado se considere que sí lo está. | Umbral de 2
pruebas. |
Umbral en mal estadounhealthy-threshold |
El umbral de mal estado especifica el número de resultados de sondeo fallidos secuenciales para que un backend que estaba en buen estado se considere en mal estado. | Umbral de 2
pruebas. |
Google Cloud considera que los backends están en buen estado cuando se alcanza este umbral. Los backends activos pueden recibir nuevas conexiones.
Google Cloud considera que los backends están en mal estado cuando se alcanza el umbral de mal estado. Los backends que no están en buen estado no pueden recibir conexiones nuevas. Sin embargo, las conexiones que ya existen no se terminan inmediatamente. En su lugar, la conexión permanece abierta hasta que se agota el tiempo de espera o hasta que se interrumpe el tráfico.
Es posible que las conexiones existentes no devuelvan respuestas, en función del motivo por el que no se haya podido realizar la comprobación. Un backend en mal estado puede volver a estar en buen estado si cumple de nuevo el umbral de buen estado.
El comportamiento específico cuando todas las instancias de backend no están en buen estado varía en función del tipo de balanceador de carga que utilices:
| Balanceador de carga | Comportamiento cuando todos los backends están en mal estado |
|---|---|
| Balanceador de carga de aplicación clásico | Devuelve el código de estado HTTP `502` a los clientes cuando todos los back-ends no están en buen estado. |
|
Balanceador de carga de aplicación externo global Balanceador de carga de aplicación interno entre regiones Balanceador de carga de aplicación externo regional Balanceador de carga de aplicación interno regional |
Devuelve el código de estado HTTP `503` a los clientes cuando todos los back-ends no están en buen estado. |
| Balanceadores de carga de red de proxy | Finaliza las nuevas conexiones TCP de clientes cuando todos los backends no están en buen estado. |
| Balanceador de carga de red de paso a través interno Balanceadores de carga de red de paso a través externos basados en el servicio de backend |
Distribuye las nuevas conexiones según la configuración de conmutación por error, el peso del backend y el estado del backend. Para obtener información detallada, consulta estos enlaces: |
| Balanceadores de carga de red de paso a través externos basados en grupos de destino | Distribuye el tráfico a todas las VMs de backend como último recurso cuando todos los backends están en mal estado. |
Notas adicionales
En las siguientes secciones se incluyen más notas sobre el uso de comprobaciones de estado en Google Cloud.
Certificados y comprobaciones del estado
Los verificadores de estado deGoogle Cloud no realizan validaciones de certificados, ni siquiera en protocolos que requieren que tus backends usen certificados (SSL, HTTPS y HTTP/2). Por ejemplo:
- Puedes usar certificados autofirmados o certificados firmados por cualquier autoridad de certificación (CA).
- Se aceptan certificados que hayan caducado o que aún no sean válidos.
- No es necesario que los atributos
CNysubjectAlternativeNamecoincidan con un registro PTR de DNS o encabezadoHost.
Encabezados
Las comprobaciones del estado que usan cualquier protocolo, excepto las antiguas, te permiten definir un encabezado de proxy mediante la marca --proxy-header.
Las comprobaciones de estado que usan los protocolos HTTP, HTTPS o HTTP/2 y las comprobaciones de estado antiguas te permiten especificar un encabezado HTTP Host mediante la marca --host.
Si usas encabezados de solicitud personalizados, ten en cuenta que el balanceador de carga añade estos encabezados solo a las solicitudes de los clientes, no a las sondas de comprobación del estado. Si tu backend requiere un encabezado específico para la autorización que falta en el paquete de comprobación del estado, es posible que la comprobación del estado falle.
Comprobación del estado de ejemplo
Supongamos que configura una comprobación de estado con los siguientes ajustes:
- Intervalo: 30 segundos
- Tiempo de espera: 5 segundos
- Protocolo: HTTP
- Umbral en mal estado: 2 (valor predeterminado)
- Umbral en buen estado: 2 (predeterminado)
Con estos ajustes, la comprobación de estado se comporta de la siguiente manera:
- Se configuran varios sistemas redundantes simultáneamente con los parámetros de comprobación del estado. Los ajustes de intervalo y de tiempo de espera se aplican a cada sistema. Para obtener más información, consulta Varias sondas y frecuencia.
Cada comprobador de estado hace lo siguiente:
- Inicia una conexión HTTP desde una de las direcciones IP de origen a la instancia de backend cada 30 segundos.
- Espera hasta cinco segundos para recibir un código de estado HTTP
200 (OK)(el criterio de éxito para los protocolos HTTP, HTTPS y HTTP/2).
Un backend se considera en mal estado cuando al menos una de las sondas de comprobación del estado del sistema hace lo siguiente:
- No recibe un código de respuesta
HTTP 200 (OK)en dos sondeos consecutivos. Por ejemplo, puede que se rechace la conexión o que se agote el tiempo de espera de la conexión o del socket. - Recibe dos respuestas consecutivas que no cumplen los criterios de éxito específicos del protocolo.
- No recibe un código de respuesta
Se considera que un backend está en buen estado cuando al menos uno de los sistemas de comprobación del estado recibe dos respuestas consecutivas que cumplen los criterios de éxito específicos del protocolo.
En este ejemplo, cada prober inicia una conexión cada 30 segundos. Transcurren 30 segundos entre los intentos de conexión de un comprobador, independientemente de la duración del tiempo de espera (tanto si la conexión se ha agotado como si no). En otras palabras, el tiempo de espera siempre debe ser inferior o igual al intervalo, y nunca lo aumenta.
En este ejemplo, los tiempos de cada sonda son los siguientes (en segundos):
- t=0: inicia la sonda A.
- t=5: detiene la sonda A.
- t=30: inicia la prueba B.
- t=35: detiene la sonda B.
- t=60: inicia la sonda C.
- t=65: Detener la sonda C.
Siguientes pasos
- Para crear, modificar y usar comprobaciones del estado, consulta Usar comprobaciones del estado.
- Para solucionar problemas de las comprobaciones del estado, habilita el registro de comprobaciones del estado.