Présentation des vérifications d'état

Google Cloud propose des vérifications d'état configurables pour les backends de l'équilibreur de charge Google Cloud, les backends Traffic Director et l'autoréparation basée sur les applications pour les groupes d'instances gérés. Ce document traite des concepts clés des vérifications d'état.

Sauf indication contraire, les vérifications d'état de Google Cloud sont mises en œuvre par des tâches logicielles dédiées qui se connectent aux backends en fonction des paramètres spécifiés dans une ressource de vérification d'état. Chaque tentative de connexion est appelée vérification. Google Cloud enregistre la réussite ou l'échec de chaque vérification.

Pour chaque backend, Google Cloud calcule un état de fonctionnement général en fonction d'un nombre configurable de vérifications séquentielles ayant réussi ou échoué. Les backends qui répondent favorablement à 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.

L'état de fonctionnement général de chaque backend détermine s'il peut recevoir de nouvelles requêtes ou connexions. 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.

Les vérifications d'état mises en œuvre par des tâches logicielles dédiées utilisent des routes spéciales non définies dans votre réseau cloud privé virtuel (VPC). Pour en savoir plus, consultez la section Chemins de retour pour les équilibreurs de charge.

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

Les vérifications d'état sont associées à une catégorie et à un protocole. Il existe deux catégories : les vérifications d'état et les vérifications d'état héritées. Voici les protocoles qu'elles acceptent :

• Vérifications d'état

  • Globales (gRPC, TCP, SSL, HTTP, HTTPS ou HTTP/2)
  • Régionales (gRPC, TCP, SSL, HTTP, HTTPS ou HTTP/2)

• Vérifications d'état héritées :

  • Héritées globales (HTTP)
  • Héritées globales (HTTPS)

Le protocole et le port déterminent la manière dont les vérifications d'état sont effectuées. Par exemple, une vérification d'état peut utiliser le protocole HTTP sur le port TCP 80 ou le protocole TCP pour un port nommé dans un groupe d'instances.

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

Remarque : Le terme vérification d'état ne désigne pas les vérifications d'état héritées. Dans ce document, les vérifications d'état héritées sont explicitement désignées par le terme vérifications d'état héritées. Notez également que ce document utilise le terme groupe d'instances pour désigner les groupes d'instances non gérés, les groupes d'instances gérés zonaux et les groupes d'instances gérés régionaux.

Sélectionner une vérification d'état

Les vérifications d'état doivent être compatibles avec le type d'équilibreur de charge (ou Traffic Director) et les types de backend. Les facteurs à prendre en compte lors de la sélection d'une vérification d'état sont les suivants :

• Catégorie : vérification d'état ou vérification d'état héritée. Seuls les équilibreurs de charge réseau passthrough externes basés sur un pool cible nécessitent des vérifications d'état héritées. Pour tous les autres produits, vous utiliserez les vérifications d'état standards.
• Protocole : protocole utilisé par Google Cloud pour vérifier les backends. Il est préférable d'utiliser une vérification d'état (ou une vérification d'état héritée) dont le protocole correspond à celui utilisé par le service de backend ou le pool cible de l'équilibreur de charge. Toutefois, les protocoles de vérification d'état et d'équilibreur de charge n'ont pas besoin d'être identiques.
• Spécification de port : ports utilisés par Google Cloud avec le protocole. Vous devez spécifier un port pour votre vérification d'état. Les vérifications d'état disposent de deux méthodes de spécification de port : --port et --use-serving-port. Pour les vérifications d'état héritées, il existe une méthode : --port.

La section suivante décrit les sélections de vérifications d'état valides pour chaque type d'équilibreur de charge et de backend.

Guide relatif aux équilibreurs de charge

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

Équilibreur de charge	Type de backend	Catégorie et champ d'application de la vérification d'état	Spécification du port
Équilibreur de charge d'application externe global Équilibreur de charge d'application classique ^1 Équilibreur de charge réseau proxy externe global Équilibreur de charge réseau proxy classique	NEG compatibles	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)
Équilibreur de charge d'application externe régional	NEG compatibles	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)
Équilibreur de charge d'application interne interrégional Équilibreur de charge réseau de proxy interne interrégional	NEG compatibles	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)
Équilibreur de charge d'application interne régional Équilibreur de charge réseau proxy interne régional Équilibreur de charge réseau proxy externe régional	NEG compatibles	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)
Équilibreur de charge réseau pass-through externe^2	Groupes d'instances	Vérification d'état (régionale)	Numéro de port personnalisé (--port)
	Instances dans les pools cibles	Vérification d'état héritée (globale avec 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).
Équilibreur de charge réseau passthrough interne^2	NEG compatibles	Vérification d'état (globale ou régionale)	Numéro de port personnalisé (--port)
	Groupes d'instances	Vérification d'état (globale ou régionale)	Numéro de port personnalisé (--port)

¹ Pour les équilibreurs de charge d'application externes, les vérifications d'état héritées ne sont pas recommandées, mais sont parfois compatibles, selon le mode de l'équilibreur de charge.

Mode d'équilibreur de charge	Vérifications d'état héritées compatibles
Équilibreur de charge d'application externe global Équilibreur de charge d'application classique	Oui, si les deux conditions suivantes sont remplies : Les backends sont des groupes d'instances. Les VM de backend diffusent du trafic qui utilise le protocole HTTP ou HTTPS.
Équilibreur de charge d'application externe régional	Non

² Vous ne pouvez pas utiliser l'option --use-serving-port, car les services de backend utilisés avec les équilibreurs de charge réseau passthrough internes et les équilibreurs de charge réseau passthrough externes ne sont associés à aucun port nommé. De plus, les équilibreurs de charge réseau passthrough internes n'acceptent que les NEG zonaux avec des points de terminaison GCE_VM_IP, qui sont dépourvus d'informations sur le port.

Notes supplémentaires sur l'utilisation

• Pour les équilibreurs de charge réseau passthrough internes, vous ne pouvez utiliser que TCP ou UDP comme protocole du service de backend. Si vous diffusez le trafic HTTP des VM derrière un équilibreur de charge réseau passthrough interne, il est judicieux d'utiliser une vérification d'état exploitant le protocole HTTP.

• Un équilibreur de charge réseau passthrough externe basé sur un pool cible doit utiliser une vérification d'état HTTP héritée. Il ne peut pas utiliser une ancienne vérification d'état HTTPS ou une autre vérification d'état non héritée. Si vous utilisez un équilibreur de charge réseau passthrough externe basé sur un pool cible pour équilibrer le trafic TCP, vous devez exécuter un service HTTP sur les VM faisant l'objet d'un équilibrage de charge, de sorte qu'elles puissent répondre aux tests de vérification d'état.
  
  Pour presque tous les autres types d'équilibreurs de charge, vous devez utiliser des vérifications d'état standards non héritées dont le protocole correspond à celui du service de backend de l'équilibreur de charge.

• Pour les services de backend utilisant le protocole gRPC, n'utilisez que des vérifications d'état gRPC ou TCP. N'utilisez pas les vérifications d'état HTTP(S) ou HTTP/2.

• Certains équilibreurs de charge basés sur Envoy qui utilisent des backends de NEG hybrides ne sont pas compatibles avec les vérifications d'état gRPC. Pour en savoir plus, consultez la Présentation des NEG hybrides.

Vérification d'état avec Traffic Director

Notez les différences de comportement suivantes lorsque vous utilisez des vérifications d'état avec Traffic Director.

• Avec Traffic Director, le comportement de vérification d'état pour les points de terminaison du réseau de type INTERNET_FQDN_PORT et NON_GCP_PRIVATE_IP_PORT diffère du comportement de vérification d'état des autres types de points de terminaison du réseau. Au lieu d'utiliser les tâches logicielles dédiées, Traffic Director programme les proxys Envoy pour effectuer des vérifications d'état pour les NEG Internet (points de terminaison INTERNET_FQDN_PORT) et les NEG hybrides (points de terminaison NON_GCP_PRIVATE_IP_PORT).

  Envoy est compatible avec les protocoles suivants pour la vérification de l'état :

  • HTTP
  • HTTPS
  • HTTP/2
  • TCP

• Lorsque Traffic Director est intégré à l'Annuaire des services et que vous liez un service de l'Annuaire des services à un service de backend Traffic Director, vous ne pouvez pas définir de vérification d'état sur le service de backend.

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 une vérification d'état héritée, vous spécifiez les options ci-dessous ou 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 évalue les instances des groupes d'instances ou les points de terminaison des 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 entier. Pour un équilibreur de charge réseau passthrough externe basé sur un pool cible, une vérification d'état HTTP héritée est associée à l'ensemble du pool cible. Par conséquent, les paramètres de la vérification sont identiques pour tous les backends référencés par un service backend ou un pool cible donnés.

Option 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.	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.	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 provenant 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
Équilibreur de charge d'application externe global Équilibreur de charge d'application classique Équilibreur de charge d'application externe régional^1, 2 Équilibreur de charge d'application interne interrégional^1 Équilibreur de charge d'application interne régional ^1, 2 Équilibreur de charge réseau passthrough interne Équilibreur de charge réseau proxy externe Équilibreur de charge réseau proxy interne régional^1, 2 Équilibreur de charge réseau proxy interne interrégional ^1 Équilibreur de charge réseau proxy externe régional^1, 2 Traffic Director, à l'exception des backends NEG Internet et backends NEG hybrides	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 passthrough externes
Équilibreur de charge réseau passthrough externe	Pour le trafic IPv4 vers les backends : 35.191.0.0/16 209.85.152.0/22 209.85.204.0/22 Pour le trafic IPv6 vers les backends : 2600:1901:8001::/48 ^3	Règles de pare-feu pour les équilibreurs de charge réseau passthrough externes
Équilibreur de charge réseau passthrough interne	Pour le trafic IPv4 vers les backends : 35.191.0.0/16 130.211.0.0/22 Pour le trafic IPv6 vers les backends : 2600:2d00:1:b029::/64	Règles de pare-feu pour les équilibreurs de charge réseau passthrough internes
Traffic Director avec backends NEG et backends NEG hybrides	Adresses IP des VM exécutant le logiciel Envoy	Exemple de règle de pare-feu

¹ L'ajout de plages de vérification de l'état à la liste d'autorisation de Google n'est pas nécessaire pour les NEG hybrides. Toutefois, si vous utilisez à la fois des NEG hybrides et zonaux dans un service de backend, vous devez ajouter les plages de vérification d'état Google à la liste d'autorisation pour les NEG zonaux.

² Pour les NEG Internet régionaux, les vérifications d'état sont facultatives. Le trafic provenant des équilibreurs de charge qui utilisent des NEG Internet régionaux provient du sous-réseau proxy réservé, puis est traduit par la NAT (à l'aide de Cloud NAT) en adresses IP NAT allouées manuellement ou automatiquement. Ce trafic inclut à la fois les vérifications d'état et les requêtes des utilisateurs depuis l'équilibreur de charge vers les backends. Pour en savoir plus, consultez la page NEG régionaux : utiliser Cloud NAT pour la sortie.

³ Les équilibreurs de charge réseau passthrough externes basés sur un pool cible n'acceptent que le trafic IPv4 et peuvent effectuer des vérifications d'état par l'intermédiaire du serveur de métadonnées. Dans ce cas, les sources des paquets de vérification d'état correspondent à l'adresse IP du serveur de métadonnées : 169.254.169.254. Vous n'avez pas besoin de créer de règles de pare-feu pour autoriser le trafic provenant du serveur de métadonnées. Les paquets du serveur de métadonnées sont toujours autorisés.

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 trafic entre les vérificateurs et vos backends. Nous vous recommandons de limiter ces règles 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 la vérification d'état, la règle deny implicite bloque le trafic entrant. Lorsque les vérificateurs ne parviennent pas à contacter vos backends, l'équilibreur de charge considère que vos backends ne sont pas opérationnels.

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 pour envoyer des vérifications d'état aux équilibreurs de charge d'application externes et aux équilibreurs de charge réseau proxy externes. Si un paquet provient d'Internet et que son adresse IP source se trouve dans une plage d'adresses IP de vérification, Google supprime le paquet. Cela inclut l'adresse IP externe d'une instance Compute Engine ou d'un nœud Google Kubernetes Engine (GKE).

• 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 similaire, 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 qui autorisent toutes les plages d'adresses IP de vérification comme sources. 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 ci-après.

• 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 est associée à une fréquence de vérification, inversement proportionnelle à la valeur configurée pour l'intervalle entre deux tests :

    ¹/_{(Intervalle entre deux tests)}

    Lorsque vous associez une vérification d'état à un service de backend, vous établissez 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 réseau passthrough 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 passthrough externes Si vous avez configuré plusieurs règles de transfert pointant vers le même service de backend ou le même pool cible, Google Cloud utilise plusieurs vérificateurs pour vérifier chaque adresse IP. La fréquence de vérification par VM de backend est alors multipliée par le nombre de règles de transfert configurées.

• Proxys cibles multiples pour les équilibreurs de charge d'application externes si plusieurs proxys cibles dirigent le trafic vers le même mappage d'URL, 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 réseau proxy externes et les équilibreurs de charge réseau proxy internes régionaux. si vous avez configuré plusieurs proxys cibles dirigeant le trafic vers le même service de backend, 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 de backend est alors multipliée par le nombre de proxys cibles configurés.

• Somme sur un ensemble de services de backend. Si un backend 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. Ces NEG zonaux 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 auxquelles les vérificateurs d'état envoient des paquets, en fonction du type d'équilibreur de charge.

Pour les équilibreurs de charge réseau passthrough externes et les équilibreurs de charge réseau passthrough internes, l'application doit être liée à l'adresse IP de l'équilibreur de charge (ou à toute adresse IP 0.0.0.0).

Équilibreur de charge	Interface réseau de destination	Adresse IP de destination
Équilibreur de charge d'application externe global Équilibreur de charge d'application classique Équilibreur de charge d'application externe régional Équilibreur de charge d'application interne interrégional Équilibreur de charge d'application interne Équilibreur de charge réseau proxy externe global Équilibreur de charge réseau proxy classique Équilibreur de charge réseau proxy interne régional Équilibreur de charge réseau proxy interne interrégional Traffic Director	Pour les backends de groupe d'instances, il s'agit de l'interface réseau principale (nic0). Pour les backends de NEG zonaux utilisant les points de terminaison GCE_VM_IP_PORT, Il s'agit de l'interface réseau du réseau VPC associé au NEG. Pour les backends de NEG zonaux utilisant des points de terminaison NON_GCP_PRIVATE_IP_PORT, le point de terminaison doit représenter une interface d'une ressource sur site accessible via une route du réseau VPC associé au NEG et dans la région qui contient le NEG.	Pour les backends de groupe d'instances, l'adresse IPv4 interne principale associée à l'interface réseau principale (nic0) de chaque instance. Pour les backends de NEG zonaux avec des points de terminaison GCE_VM_IP_PORT, l'adresse IP du point de terminaison : une adresse IPv4 interne principale de l'interface réseau ou une adresse IPv4 interne issue d'une plage d'adresses IP d'alias du réseau. Pour les backends de NEG zonaux avec des points de terminaison NON_GCP_PRIVATE_IP_PORT, l'adresse IP du point de terminaison.
Équilibreur de charge réseau passthrough externe	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 service de backend (pour les équilibrages de charge réseau passthrough externes basés sur un pool cible, le même pool cible), Google Cloud envoie des vérifications à chaque adresse IP associée. Cela peut entraîner une augmentation du nombre de vérifications.
Équilibreur de charge réseau passthrough interne	Pour les backends de groupes d'instances et les backends de NEG zonaux utilisant des points de terminaison GCE_VM_IP, l'interface réseau utilisée dépend de la configuration du service de backend. Pour plus d'informations, 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.

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 d'état 200 (OK) HTTP 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 cette chaîne dans les 1 024 premiers octets du corps de la réponse HTTP.

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.

Option 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, /.
Réponse response	L'option de réponse facultative 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 un code d'état 200 (OK) HTTP.

Critères de réussite pour SSL et TCP

Hormis si vous spécifiez une chaîne de réponse attendue, les vérifications d'état qui utilisent les protocoles SSL et TCP sont réussies lorsque les deux conditions de base suivantes sont remplies :

• Chaque vérificateur Google Cloud parvient à effectuer un handshake SSL ou TCP avant la fin du délai avant expiration configuré pour la vérification.
• Pour les vérifications d'état TCP, la session TCP est arrêtée normalement par :
  • le backend ;
  • le vérificateur Google Cloud envoie un paquet TCP RST (reset) tandis que la session TCP vers le vérificateur est toujours établie.

Si le backend envoie un paquet TCP RST (reset) afin de fermer une session TCP pour une vérification d'état TCP, la vérification peut être considérée comme un échec. Cela se produit lorsque le vérificateur Google Cloud a déjà lancé l'arrêt de TCP.

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 de réponse 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 :

Options 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 remplies et que la chaîne renvoyée correspond exactement à la chaîne de réponse attendue.
Seule la réponse est spécifiée Option spécifiée : --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 remplies 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.
Seule la requête est spécifiée Option spécifiée : --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 remplies. La réponse éventuellement renvoyée n'est pas vérifiée.

Critères de réussite pour gRPC

Si vous utilisez des vérifications d'état gRPC, assurez-vous que le service gRPC envoie la réponse RPC avec l'état OK et le champ d'état défini sur SERVING ou NOT_SERVING en conséquence.

Veuillez noter les points suivants :

• Les vérifications d'état gRPC ne sont utilisées qu'avec les applications gRPC et Traffic Director.
• Les vérifications d'état gRPC ne sont pas compatibles avec TLS.

Pour en savoir plus, consultez les ressources suivantes :

• Option supplémentaire pour les vérifications d'état gRPC
• Documentation gRPC sur les vérifications d'état

Critères de réussite pour les vérifications d'état héritées

Si la réponse reçue par la vérification d'état héritée est HTTP 200 OK, le test est considéré comme ayant réussi. Tous les autres codes de réponse HTTP, y compris une redirection (301, 302), sont considérés comme non opérationnels.

État de fonctionnement

Google Cloud utilise les options de configuration suivantes pour déterminer l'état de fonctionnement général de chaque backend vers lequel le trafic est soumis à l'équilibrage de charge.

Option 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.	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.	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.

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.

Le comportement spécifique correspondant au cas où tous les backends sont non opérationnels varie selon le type d'équilibreur de charge que vous utilisez :

Équilibreur de charge	Comportement lorsque tous les backends ne sont pas opérationnels
Équilibreur de charge d'application classique	Renvoie un code d'état HTTP "502" aux clients lorsqu'aucun backend n'est opérationnel.
Équilibreur de charge d'application externe global Équilibreur de charge d'application externe régional Équilibreur de charge d'application interne	Renvoie un code d'état HTTP "503" aux clients lorsqu'aucun backend n'est opérationnel.
Équilibreurs de charge réseau proxy	Arrêtez les connexions client lorsqu'aucun backend n'est opérationnel.
Équilibreurs de charge réseau passthrough internes et équilibreurs de charge réseau passthrough externes basés sur un service de backend	Distribuez le trafic vers toutes les VM de backend en dernier recours lorsqu'aucun backend n'est opérationnel et que le basculement n'est pas configuré. Pour en savoir plus sur ce comportement, consultez les pages Distribution du trafic pour les équilibreurs de charge réseau passthrough internes et Distribution du trafic pour les équilibreurs de charge réseau passthrough externes basés sur un service de backend.
Équilibreurs de charge réseau passthrough externes basés sur un pool cible	En dernier recours, répartissez le trafic vers toutes les VM de backend, lorsqu'aucun backend n'est opérationnel.

Remarques supplémentaires

Les sections suivantes contiennent des remarques supplémentaires sur l'utilisation des vérifications d'état sur Google Cloud.

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.
• Les certificats arrivés à expiration ou qui ne sont pas encore valides sont acceptés.
• Aucun attribut CN ou subjectAlternativeName ne doit 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 vérification 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 d'état 200 (OK) HTTP 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

Étapes suivantes

• Pour en savoir plus sur la création, la modification et l'utilisation des vérifications d'état, consultez la page Utiliser des vérifications d'état.
• Pour résoudre les problèmes liés aux vérifications d'état, activez la journalisation des vérifications d'état.