Présentation des vérifications d'état

Google Cloud propose des mécanismes de vérification d'état qui déterminent si les backends, tels que les groupes d'instances et les groupes de points de terminaison du réseau (NEG) zonaux, répondent correctement au trafic. Ce document traite des concepts liés aux vérifications d'état dans le contexte spécifique de Google Cloud et ses équilibreurs de charge.

Google Cloud propose des systèmes de vérification de l'état à l'échelle mondiale et régionale, qui se connectent aux backends de manière périodique et configurable. Chaque tentative de connexion est appelée vérification, et chaque système de vérification d'état est appelé vérificateur. Google Cloud enregistre la réussite ou l'échec de chaque vérification.

Les vérifications d'état et les équilibreurs de charge fonctionnent conjointement. Pour chaque backend de l'équilibreur de charge, Google Cloud calcule un état de fonctionnement global en fonction d'un nombre configurable de vérifications ayant successivement réussi ou échoué. Les backends qui répondent correctement à la vérification pour le nombre de succès configuré sont considérés comme opérationnels. Les backends qui échouent à la vérification pour le nombre d'échecs configuré sont considérés comme non opérationnels.

Google Cloud utilise l'état de fonctionnement global de chaque backend pour déterminer s'il peut recevoir de nouvelles requêtes ou connexions. En plus de pouvoir configurer la fréquence de vérification et les seuils d'état opérationnel ou non, vous pouvez configurer les critères définissant la réussite d'une vérification. Vous en trouverez une description détaillée dans la section Fonctionnement des vérifications d'état.

Pour les vérifications d'état, Google Cloud utilise des routages spéciaux non définis dans votre réseau cloud privé virtuel (VPC). Pour en savoir plus, consultez la section Chemins de retour des équilibreurs de charge.

Catégories, protocoles et ports des vérifications d'état

Google Cloud organise les vérifications d'état par catégorie et par protocole.

Il existe deux catégories : les vérifications d'état et les vérifications d'état héritées. Les catégories diffèrent suivant l'ensemble de protocoles qu'elles acceptent et la méthode de spécification du port à utiliser pour la vérification d'état. Le protocole et le port déterminent la manière dont les systèmes de vérification d'état Google Cloud contactent vos backends. Par exemple, vous pouvez créer une vérification d'état qui utilise le protocole HTTP sur le port TCP 80 ou créer une vérification d'état qui utilise le protocole TCP pour un port nommé et configuré sur un groupe d'instances.

La plupart des équilibreurs de charge Google Cloud requièrent des vérifications d'état non héritées, mais l'équilibrage de la charge réseau nécessite des vérifications d'état héritées qui utilisent le protocole HTTP. Vous trouverez des conseils spécifiques sur la sélection de la catégorie, du protocole et des ports dans la section suivante, intitulée "Sélectionner une vérification d'état".

Vous ne pouvez pas convertir une vérification d'état héritée en vérification d'état non héritée, et inversement.

Sélectionner une vérification d'état

Les vérifications d'état doivent être compatibles avec le type d'équilibreur de charge et avec les types de backends (groupes d'instances ou NEG zonaux) que celui-ci utilise. Les trois facteurs à spécifier lors de la création d'une vérification d'état sont les suivants :

  • La catégorie : vérification d'état ou vérification d'état héritée, qui doit être compatible avec l'équilibreur de charge.
  • Le protocole : définit le protocole utilisé par les systèmes Google Cloud pour tester régulièrement vos backends.
  • La spécification du port : définit les ports utilisés par le protocole choisi pour les vérifications d'état.

Le guide figurant à la fin de cette section récapitule les combinaisons valides de catégorie, de protocole et de spécification de port suivant le type d'équilibreur de charge et le type de backend utilisés.

Pour en savoir plus sur les types de vérifications d'état compatibles avec différents équilibreurs de charge, consultez la section Vérifications d'état.

Catégorie et protocole

Le type d'équilibreur de charge et les types de backends exploités par l'équilibreur de charge déterminent la catégorie de vérification d'état à utiliser. L'équilibrage de la charge réseau nécessite des vérifications d'état héritées qui utilisent le protocole HTTP. Tous les autres types d'équilibreurs de charge utilisent des vérifications d'état standards.

Vous devez sélectionner un protocole dans la liste des protocoles compatibles avec la catégorie de vérification d'état. Il est recommandé d'utiliser le même protocole que l'équilibreur de charge, mais ce n'est pas une obligation, et cela n'est pas toujours possible. Par exemple, les équilibreurs de charge réseau requièrent des vérifications d'état héritées et exigent que celles-ci utilisent le protocole HTTP, et ce bien que l'équilibrage de charge réseau accepte généralement les protocoles TCP et UDP. Pour les équilibreurs de charge réseau, vous devez donc exécuter un serveur HTTP sur vos instances de machines virtuelles (VM) afin de pouvoir répondre aux vérifications d'état.

Le tableau suivant répertorie les catégories de vérifications d'état et les protocoles compatibles avec chaque catégorie.

Catégorie de vérification d'état Protocoles compatibles
Contrôle d'état • HTTP
• HTTPS
• HTTP/2 (avec TLS)
• SSL
• TCP
Vérification d'état héritée • HTTP
• HTTPS

Les vérifications d'état HTTPS héritées ne sont pas compatibles avec les équilibreurs de charge réseau et ne peuvent pas être utilisées avec la plupart des autres équilibreurs de charge.

Spécifier des catégories et des ports

Outre le protocole, vous devez sélectionner une spécification de port pour votre vérification d'état. Les vérifications d'état fournissent trois méthodes de spécification de port, tandis que les vérifications d'état héritées fournissent une seule méthode. Toutes les méthodes de spécification de port ne sont pas forcément utilisables avec chaque type d'équilibreur de charge. Le type d'équilibreur de charge et les types de backends exploités par celui-ci déterminent la méthode de spécification de port que vous pouvez utiliser.

Catégorie de vérification d'état Méthodes et signification des spécifications de ports
Contrôle d'état --port : spécifiez un numéro de port TCP
--use-serving-port :
• pour les groupes d'instances, utilisez le port nommé auquel le service de backend s'abonne
• pour les NEG zonaux, utilisez le port défini sur chaque point de terminaison
Vérification d'état héritée --port : spécifie un numéro de port TCP.

Guide relatif aux équilibreurs de charge

Le tableau suivant indique la catégorie, le champ d'application et les spécifications de port compatibles avec chaque équilibreur de charge et type de backend Google Cloud.

Équilibreur de charge Type de backend Catégorie et champ d'application de la vérification d'état Spécification du port
Équilibrage de charge TCP/UDP interne 1 Groupes d'instances Vérification d'état (globale)
  • Numéro de port personnalisé (--port)
Équilibrage de charge HTTP(S) interne NEG zonaux Vérification d'état (régionale)
  • Numéro de port personnalisé (--port)
  • Numéro de port du point de terminaison (--use-serving-port)
Groupes d'instances Vérification d'état (régionale)
  • Numéro de port personnalisé (--port)
  • Port nommé du service de backend (--use-serving-port)
Équilibrage de charge au niveau du réseau Instances
dans les pools cibles
Vérification d'état héritée (globale) utilisant le protocole HTTP Les vérifications d'état héritées ne sont compatibles qu'avec la spécification par numéro de port (--port).
Équilibrage de charge HTTP(S) externe2

Équilibrage de charge proxy TCP

Équilibrage de charge proxy SSL
NEG zonaux Vérification d'état (globale)
  • Numéro de port personnalisé (--port)
  • Numéro de port du point de terminaison (--use-serving-port)
Groupes d'instances Vérification d'état (globale)
  • Numéro de port personnalisé (--port)
  • Port nommé du service de backend (--use-serving-port)

1 Vous ne pouvez pas utiliser l'option --use-serving-port, car les services de backend internes ne sont pas associés à un port nommé.
2 Il est possible, mais déconseillé, d'utiliser une vérification d'état héritée pour les services de backend associés à des équilibreurs de charge HTTP(S) externes dans les cas suivants :

  • Les backends sont des groupes d'instances, et non des NEG zonaux.
  • Les VM de backend diffusent du trafic qui utilise les protocoles HTTP ou HTTPS.

Fonctionnement des vérifications d'état

Les sections suivantes décrivent le fonctionnement des vérifications d'état.

Vérifications

Lorsque vous créez une vérification d'état ou que vous créez une vérification d'état héritée, vous spécifiez les options ci-dessous ou vous acceptez leurs valeurs par défaut. Chaque vérification d'état ou vérification d'état héritée que vous créez est mise en œuvre par plusieurs vérifications. Ces options déterminent la fréquence à laquelle chaque vérification d'état Google Cloud évalue les instances dans les backends de groupe d'instances ou les points de terminaison dans les backends de NEG zonaux.

Les paramètres d'une vérification d'état ne peuvent pas être configurés backend par backend. Les vérifications d'état sont associées à un service de backend dans son ensemble, et les vérifications d'état héritées sont associées à un pool cible dans son ensemble (pour l'équilibrage de charge réseau) ou à un service de backend (pour certaines configurations de l'équilibrage de charge HTTP(S) externe). Par conséquent, les paramètres de la vérification sont identiques pour tous les backends référencés par un service de backend ou un pool cible donnés.

Indicateur de configuration Raison Valeur par défaut
Intervalle entre deux tests
check-interval
L'intervalle entre deux tests correspond à la durée écoulée entre le début d'une vérification émise par un vérificateur donné et le début de la vérification suivante émise par le même vérificateur. Cette valeur est exprimée en secondes. En cas d'omission, Google Cloud utilise 5s (5 secondes).
Délai avant expiration
timeout
Le délai avant expiration correspond à la durée pendant laquelle Google Cloud attend une réponse à une vérification. Sa valeur doit être inférieure ou égale à l'intervalle entre deux tests. Cette valeur est exprimée en secondes. En cas d'omission, Google Cloud utilise 5s (5 secondes).

Plages d'adresses IP de vérification et règles de pare-feu

Pour que les vérifications d'état fonctionnent, vous devez créer des règles de pare-feu d'entrée allow afin que le trafic issu des vérificateurs Google Cloud puisse se connecter à vos backends.

Le tableau suivant indique les plages d'adresses IP sources à autoriser :

Produit Plages d'adresses IP sources de vérification Exemple de règle de pare-feu
Équilibrage de charge TCP/UDP interne
Équilibrage de charge HTTP(S) interne
Équilibrage de charge HTTP(S) externe
Équilibrage de charge proxy SSL
Équilibrage de charge proxy TCP
Traffic Director
35.191.0.0/16
130.211.0.0/22
Règles de pare-feu pour tous les produits à l'exception des équilibreurs de charge réseau
Équilibrage de charge au niveau du réseau 35.191.0.0/16
209.85.152.0/22
209.85.204.0/22
Règles de pare-feu pour les équilibreurs de charge réseau

Importance des règles de pare-feu

Google Cloud exige que vous créiez les règles de pare-feu d'entrée allow nécessaires pour autoriser le passage du trafic des vérificateurs à vos backends. Nous vous recommandons de limiter cette règle aux seuls protocoles et ports qui correspondent à ceux utilisés par vos vérifications d'état. Pour les plages d'adresses IP sources, veillez à utiliser les plages d'adresses IP de vérification documentées qui sont répertoriées dans la section précédente.

Si vous ne disposez pas de règles de pare-feu d'entrée allow autorisant le protocole, le port et la plage d'adresses IP source utilisés par votre vérification d'état, la règle de pare-feu d'entrée deny implicite bloque le trafic entrant provenant de toutes les sources. Lorsque les vérificateurs ne parviennent pas à contacter vos backends, l'équilibreur de charge Google Cloud classe tous vos backends comme étant non opérationnels. Lorsque tous les backends sont considérés comme non opérationnels, le comportement dépend du type d'équilibreur de charge :

  • Un équilibreur de charge HTTP(S) externe renvoie des réponses HTTP 502 aux clients lorsque tous les backends sont considérés comme non opérationnels.

  • Un équilibreur de charge HTTP(S) interne renvoie des réponses HTTP 503 aux clients lorsque tous les backends sont considérés comme non opérationnels.

  • Les équilibreurs de charge proxy SSL et les équilibreurs de charge proxy TCP expirent lorsque tous les backends sont considérés comme non opérationnels.

  • Un équilibreur de charge réseau tente de répartir le trafic vers toutes les VM de backend lorsqu'elles sont toutes considérées comme non opérationnelles en dernier recours.

  • Un équilibreur de charge TCP/UDP interne sans basculement configuré répartit le trafic vers toutes les VM de backend lorsqu'elles sont toutes considérées comme non opérationnelles en dernier recours. Vous pouvez désactiver ce comportement si vous activez le basculement.

Considérations liées à la sécurité pour les plages d'adresses IP de vérification

Tenez compte des informations suivantes lors de la planification des vérifications d'état et des règles de pare-feu nécessaires :

  • Les plages d'adresses IP de vérification appartiennent à Google. Google Cloud utilise des routes spéciales en dehors de votre réseau VPC, mais au sein du réseau de production de Google, pour faciliter la communication avec les vérificateurs.

  • Google utilise les plages d'adresses IP de vérification exclusivement pour exécuter des vérifications d'état et envoyer le trafic provenant des GFE (Google Front End) pour les équilibreurs de charge HTTP(S) externes, les équilibreurs de charge proxy SSL et les équilibreurs de charge proxy TCP. Si un paquet provient d'Internet, y compris de l'adresse IP externe d'une instance Compute Engine ou d'un nœud Google Kubernetes Engine (GKE), et que l'adresse IP source du paquet se trouve dans une plage d'adresses IP de vérification, Google supprime le paquet.

  • Les plages d'adresses IP de vérification constituent un ensemble complet d'adresses IP possibles utilisées par les vérificateurs Google Cloud. Si vous utilisez tcpdump ou un outil semblable, il est possible que vous n'observiez pas de trafic provenant de toutes les adresses IP dans toutes les plages d'adresses IP de vérification. Nous vous recommandons de créer des règles de pare-feu d'entrée allow pour l'équilibreur de charge choisi en utilisant toutes les plages d'adresses IP de vérification comme sources, car Google Cloud peut automatiquement mettre en œuvre de nouveaux vérificateurs sans notification.

Vérifications multiples et fréquence de vérification

Google Cloud envoie des vérifications d'état depuis plusieurs systèmes redondants appelés vérificateurs. Les vérificateurs utilisent des plages d'adresses IP sources spécifiques. Google Cloud ne repose pas sur un seul vérificateur pour mettre en œuvre une vérification d'état : plusieurs vérificateurs évaluent simultanément les instances dans les backends de groupe d'instances ou les points de terminaison dans les backends de NEG zonaux. Si un vérificateur échoue, Google Cloud continue de suivre l'état de fonctionnement des backends.

Les paramètres d'intervalle et de délai avant expiration que vous configurez pour une vérification d'état sont appliqués à chaque vérificateur. Pour un backend donné, les journaux d'accès logiciel et tcpdump montrent des vérifications plus fréquentes que les paramètres que vous avez configurés.

Ce comportement est normal, et vous ne pouvez pas configurer le nombre de vérificateurs utilisés par Google Cloud pour les vérifications d'état. Toutefois, vous pouvez estimer l'effet de plusieurs vérifications simultanées en tenant compte des facteurs suivants :

  • Pour estimer la fréquence de vérification par service backend, prenez en compte les éléments suivants :

    • Fréquence de base par service de backend : chaque vérification d'état possède sa propre fréquence de vérification, inversement proportionnelle à la valeur configurée pour l'intervalle entre deux tests :

      1/(Intervalle entre deux tests)

      Lorsque vous associez une vérification d'état à un service de backend, vous définissez une fréquence de base utilisée par chaque vérificateur pour les backends de ce service.

    • Facteur d'évolutivité de la vérification : la fréquence de base du service de backend est multipliée par le nombre de vérificateurs simultanés utilisés par Google Cloud. Ce nombre peut varier, mais il est généralement compris entre 5 et 10.

  • Règles de transfert multiples pour les équilibreurs de charge TCP/UDP internes : si vous avez configuré plusieurs règles de transfert internes (chacune ayant une adresse IP différente) pointant vers le même service de backend interne régional, Google Cloud utilise plusieurs vérificateurs pour vérifier chaque adresse IP. La fréquence de vérification par service de backend est alors multipliée par le nombre de règles de transfert configurées.

  • Règles de transfert multiples pour les équilibreurs de charge réseau : si vous avez configuré plusieurs règles de transfert pointant vers le même pool cible, Google Cloud utilise plusieurs vérificateurs pour vérifier chaque adresse IP. La fréquence de vérification telle qu'elle est vue par chaque instance du pool cible est alors multipliée par le nombre de règles de transfert configurées.

  • Proxys cibles multiples pour les équilibreurs de charge HTTP(S) externes : si vous avez configuré plusieurs proxys dirigeant le trafic vers le même mappage d'URL pour l'équilibrage de charge HTTP(S) externe, Google Cloud utilise plusieurs vérificateurs pour vérifier l'adresse IP associée à chaque proxy cible. La fréquence de vérification par service backend est alors multipliée par le nombre de proxys cibles configurés.

  • Proxys cibles multiples pour les équilibreurs de charge proxy SSL et les équilibreurs de charge proxy TCP : si vous avez configuré plusieurs proxys dirigeant le trafic vers le même service de backend pour l'équilibrage de charge proxy SSL ou l'équilibrage de charge proxy TCP, Google Cloud utilise plusieurs vérificateurs pour vérifier l'adresse IP associée à chaque proxy cible. La fréquence de vérification par service backend est alors multipliée par le nombre de proxys cibles configurés.

  • Somme sur un ensemble de services de backend : si un backend (par exemple, un groupe d'instances) est utilisé par plusieurs services de backend, la fréquence de vérification des instances backend est la somme des fréquences associées aux vérifications d'état de chaque service de backend.

    Avec les backends de NEG zonaux, il est plus difficile de déterminer le nombre exact de vérifications d'état. Par exemple, le même point de terminaison peut se trouver dans plusieurs NEG zonaux, alors que ceux-ci ne présentent pas nécessairement le même ensemble de points de terminaison, et différents points de terminaison peuvent pointer vers le même backend.

Destination des paquets de vérification

Le tableau suivant indique l'interface réseau et les adresses IP de destination utilisées par les vérificateurs d'état, en fonction du type d'équilibreur de charge.

Équilibreur de charge Interface réseau de destination Adresse IP de destination
Équilibrage de charge TCP/UDP interne Interface réseau de l'instance située dans le réseau spécifié pour le service de backend interne. Si elle n'est pas spécifiée, l'interface réseau principale (nic0) est utilisée.

Pour en savoir plus, consultez la section Services de backend et interfaces réseau.
Adresse IP de la règle de transfert interne.

Si plusieurs règles de transfert pointent vers le même service de backend, Google Cloud envoie des vérifications à l'adresse IP associée à chaque règle de transfert. Cela peut entraîner une augmentation du nombre de vérifications.
Équilibrage de charge au niveau du réseau Interface réseau principale (nic0) Adresse IP de la règle de transfert externe.

Si plusieurs règles de transfert pointent vers le même pool cible, Google Cloud envoie des vérifications à l'adresse IP associée à chaque règle de transfert. Cela peut entraîner une augmentation du nombre de vérifications.
Équilibrage de charge HTTP(S) externe

Équilibrage de charge HTTP(S) interne

Équilibrage de charge proxy SSL

Équilibrage de charge proxy TCP

Interface réseau principale (nic0)
  • Pour les backends de groupe d'instances, l'adresse IP interne principale associée à l'interface réseau principale (nic0) de chaque instance.
  • Pour les backends de NEG zonaux, l'adresse IP du point de terminaison, qui est soit une adresse IP interne principale, soit une plage d'adresses IP d'alias (de l'interface réseau principale, nic0, dans l'instance hébergeant le point de terminaison).

Critères de réussite pour HTTP, HTTPS et HTTP/2

Lorsqu'une vérification d'état utilise le protocole HTTP, HTTPS ou HTTP/2, chaque vérification requiert un code de réponse HTTP 200 (OK) avant la fin du délai avant expiration de la vérification. En outre, vous pouvez effectuer les opérations suivantes :

  • Vous pouvez configurer les vérificateurs Google Cloud de sorte qu'ils envoient des requêtes HTTP vers un chemin de requête spécifique. Si vous ne spécifiez pas de chemin de requête, le chemin / est utilisé.

  • Si vous configurez une vérification d'état basée sur le contenu en spécifiant une chaîne de réponse attendue, Google Cloud doit trouver la chaîne attendue dans les 1 024 premiers octets de la réponse HTTP.

  • Si vous configurez une chaîne de réponse attendue, chaque vérification d'état de Google Cloud doit trouver la chaîne de réponse attendue dans les 1 024 premiers octets de la réponse réelle de vos backends.

Vous pouvez utiliser les combinaisons suivantes d'options de chemin de requête et de chaîne de réponse pour les vérifications d'état qui utilisent les protocoles HTTP, HTTPS et HTTP/2.

Indicateur de configuration Critères de réussite
Chemin de requête
request-path
Indique le chemin de l'URL à laquelle Google Cloud envoie des requêtes de vérification d'état.
En cas d'omission, Google Cloud envoie les requêtes de vérification au chemin racine, /. L'option request-path n'est pas compatible avec l'utilisation de paramètres de requête.
Réponse
response
L'indicateur de réponse (facultatif) vous permet de configurer une vérification d'état basée sur le contenu. La chaîne de réponse attendue doit être de longueur inférieure ou égale à 1 024 caractères ASCII (mono-octets). Lorsque cette valeur est configurée, Google Cloud attend cette chaîne dans les 1 024 premiers octets de la réponse, en plus de recevoir l'état HTTP 200 (OK).

Critères de réussite pour SSL et TCP

Sauf dans le cas où vous spécifiez une chaîne de réponse attendue, les vérifications d'état qui utilisent les protocoles SSL et TCP sont efficaces lorsque les deux conditions de base suivantes sont remplies :

  • Chaque vérificateur Google Cloud parvient à effectuer un handshake SSL ou TCP réussi avant la fin du délai avant expiration de la vérification qui a été configuré.
  • Pour les vérifications d'état TCP, la session TCP est arrêtée normalement par votre backend ou par le vérificateur Google Cloud, ou votre backend envoie un paquet TCP RST (reset) alors que la session TCP est toujours établie avec le vérificateur.

Sachez que si votre backend envoie un paquet TCP RST (reset) pour fermer une session TCP pour une vérification TCP, une fois que le vérificateur Google Cloud a initié un arrêt TCP normal, la vérification peut être considérée comme un échec.

Vous pouvez créer une vérification d'état basée sur le contenu si vous fournissez une chaîne de requête et une chaîne de réponse attendue, chacune ayant une longueur maximale de 1 024 caractères ASCII (mono-octets). Lorsqu'une chaîne de réponse attendue est configurée, Google Cloud considère qu'une vérification réussit uniquement si les conditions de base sont remplies et que la chaîne renvoyée correspond exactement à la chaîne de réponse attendue.

Vous pouvez utiliser les combinaisons suivantes d'options de requête et de réponse pour les vérifications d'état utilisant les protocoles SSL et TCP :

Indicateurs de configuration Critères de réussite
Aucune requête ni réponse spécifiée

Aucune option spécifiée : --request, --response
Google Cloud considère que la vérification est réussie lorsque les conditions de base sont remplies.
Requête et réponse spécifiées

Les deux options spécifiées : --request, --response
Google Cloud envoie la chaîne de requête que vous avez configurée et attend la chaîne de réponse attendue. Google Cloud considère que la vérification réussit lorsque les conditions de base sont satisfaites et que la chaîne renvoyée correspond exactement à la chaîne de réponse attendue.
Réponse spécifiée uniquement

Options spécifiées : --response uniquement
Google Cloud attend la chaîne de réponse attendue et considère que la vérification réussit lorsque les conditions de base sont satisfaites et que la chaîne renvoyée correspond exactement à la chaîne de réponse attendue.

Vous ne devez utiliser l'option --response seule que si vos backends envoient automatiquement une chaîne de réponse dans le cadre du handshake TCP ou SSL.
Requête spécifiée uniquement

Options spécifiées : --request uniquement
Google Cloud envoie la chaîne de requête que vous avez configurée et considère que la vérification réussit lorsque les conditions de base sont satisfaites. La réponse éventuellement renvoyée n'est pas vérifiée.

État de fonctionnement

Google Cloud utilise les options de configuration suivantes pour déterminer l'état de fonctionnement global de chaque backend soumis à un équilibrage de charge.

Indicateur de configuration Raison Valeur par défaut
Seuil opérationnel
healthy-threshold
Le seuil sanitaire indique le nombre de vérifications séquentielles ayant réussi pour qu'un backend soit considéré comme opérationnel. En cas d'omission, Google Cloud utilise un seuil de 2 vérifications.
Seuil de faible capacité
unhealthy-threshold
Le seuil non sanitaire indique le nombre de vérifications séquentielles ayant échoué pour qu'un backend soit considéré comme non opérationnel. En cas d'omission, Google Cloud utilise un seuil de 2 vérifications.

Google Cloud considère que les backends sont opérationnels une fois le seuil opérationnel atteint. Les backends opérationnels sont autorisés à recevoir de nouvelles connexions.

Google Cloud considère que les backends sont non opérationnels lorsque le seuil de faible capacité est atteint. Les backends non opérationnels ne sont pas autorisés à recevoir de nouvelles connexions. Toutefois, les connexions existantes ne sont pas immédiatement interrompues. Au lieu de cela, la connexion reste ouverte jusqu'à expiration d'un délai ou jusqu'à ce que le trafic soit interrompu. Le comportement spécifique diffère selon le type d'équilibreur de charge que vous utilisez.

Suivant la cause de l'échec de la vérification, les connexions existantes peuvent échouer à renvoyer des réponses. Un backend non opérationnel peut redevenir opérationnel s'il parvient de nouveau à atteindre le seuil opérationnel.

Remarques supplémentaires

Vérifications d'état basées sur le contenu

Une vérification d'état basée sur le contenu est une vérification dont les critères de réussite dépendent de l'évaluation d'une chaîne de réponse attendue. Elle vous permet de demander aux vérifications d'état Google Cloud de valider plus complètement la réponse de votre backend.

  • Pour configurer une vérification d'état basée sur le contenu HTTP, HTTPS ou HTTP/2, vous devez spécifier une chaîne de réponse attendue et éventuellement définir un chemin de requête. Pour en savoir plus, consultez la section Critères de réussite pour HTTP, HTTPS et HTTP/2.

  • Pour configurer une vérification d'état basée sur le contenu SSL ou TCP, vous devez spécifier une chaîne de réponse attendue et éventuellement définir une chaîne de requête. Pour en savoir plus, consultez la section Critères de réussite pour SSL et TCP.

Certificats et vérifications d'état

Les vérificateurs d'état Google Cloud n'effectuent pas de validation de certificat, même pour les protocoles qui requièrent l'utilisation de certificats (SSL, HTTPS et HTTP/2) par les backends. Par exemple :

  • Vous pouvez utiliser des certificats autosignés ou des certificats signés par une autorité de certification (CA).
  • Les certificats arrivés à expiration ou qui ne sont pas encore valides sont acceptés.
  • Ni les attributs CN, ni les attributs subjectAlternativeName ne doivent correspondre à un en-tête Host ou à un enregistrement PTR de DNS.

En-têtes

À l'exception des vérifications d'état héritées, les vérifications d'état qui utilisent un protocole vous permettent de définir un en-tête de proxy à l'aide de l'option --proxy-header.

Les vérifications d'état qui utilisent les protocoles HTTP, HTTPS ou HTTP/2 et les vérifications d'état héritées vous permettent de spécifier un en-tête HTTP Host à l'aide de l'option --host.

Exemple de vérification d'état

Supposons que vous configuriez une vérification d'état avec les paramètres suivants :

  • Intervalle : 30 secondes
  • Délai avant expiration : 5 secondes
  • Protocole : HTTP
  • Seuil de faible capacité : 2 (valeur par défaut)
  • Seuil opérationnel : 2 (valeur par défaut)

Avec ces paramètres, la vérification d'état se comporte comme suit :

  1. Plusieurs systèmes redondants sont configurés simultanément avec les paramètres de contrôle d'état. Les paramètres d'intervalle et de délai avant expiration sont appliqués à chaque système. Pour en savoir plus, consultez la section Vérifications multiples et fréquence de vérification.
  2. Chaque vérificateur d'état effectue les actions suivantes :

    1. Établissement d'une connexion HTTP entre l'une des adresses IP sources et l'instance backend toutes les 30 secondes.
    2. Attente d'un code de réponse HTTP 200 (OK) pendant cinq secondes au maximum (critère de réussite pour les protocoles HTTP, HTTPS et HTTP/2).
  3. Un backend est considéré comme non opérationnel lorsqu'au moins un système de vérification d'état remplit les conditions suivantes :

    1. Deux vérifications consécutives ne renvoient pas de code de réponse HTTP 200 (OK). Par exemple, la connexion peut être refusée, ou le délai avant expiration d'une connexion ou d'un socket peut être dépassé.
    2. Les deux réponses consécutives reçues ne correspondent pas aux critères de réussite spécifiques au protocole.
  4. Un backend est considéré comme opérationnel lorsqu'au moins un système de vérification d'état reçoit deux réponses consécutives qui correspondent aux critères de réussite spécifiques au protocole.

Dans cet exemple, chaque vérificateur établit une connexion toutes les 30 secondes. Trente secondes s'écoulent entre les tentatives de connexion d'un vérificateur, quelle que soit la durée du délai avant expiration (que la connexion ait expiré ou non). En d'autres termes, le délai avant expiration doit toujours être inférieur ou égal à l'intervalle, et il n'augmente jamais celui-ci.

Dans cet exemple, la durée de chaque vérificateur se présente comme suit, en secondes :

  1. t = 0 : lancement de la vérification A
  2. t = 5 : arrêt de la vérification A
  3. t = 30 : lancement de la vérification B
  4. t = 35 : arrêt de la vérification B
  5. t = 60 : lancement de la vérification C
  6. t = 65 : arrêt de la vérification C

Étape suivante