Présentation des vérifications d'état

Google Cloud fournit des vérifications d'état afin de déterminer si les backends répondent au trafic. Ce document traite des concepts liés aux vérifications d'état pour les équilibreurs de charge Google Cloud et Traffic Director.

Les vérifications d'état se connectent aux backends de manière périodique et configurable. 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 utilisent des routes spéciales non définies dans votre réseau de 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 :

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.

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.
  • Protocole : protocole utilisé par Google Cloud pour vérifier les backends.
  • Spécification de port : ports utilisés par Google Cloud avec le protocole.

Le guide concernant les équilibreurs de charge décrit les vérifications d'état valides pour chaque type d'équilibreur de charge et de backend. Pour obtenir un récapitulatif plus général, consultez le tableau des fonctionnalités de vérifications d'état.

Catégorie et protocole

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, en dépit du fait qu'ils soient compatibles avec les protocoles TCP ou UDP, les équilibreurs de charge réseau basés sur un pool cible nécessitent des vérifications d'état héritées et que celles-ci utilisent le protocole HTTP. Pour les équilibreurs de charge réseau basés sur un pool cible, vous devez exécuter un serveur HTTP sur vos instances de machines virtuelles (VM) afin de pouvoir répondre aux vérifications 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.

Spécifier des catégories et des ports

Vous devez spécifier un port pour votre vérification d'état. Les vérifications d'état fournissent deux méthodes de spécification de port (--port et --use-serving-port), tandis que les vérifications d'état héritées fournissent une seule méthode (--port).

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
Équilibrage de charge TCP/UDP interne1 NEG zonaux 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)
É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 réseau1 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).
É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 utilisés avec l'équilibrage de charge TCP/UDP interne et l'équilibrage de charge réseau ne sont associés à aucun port nommé.
2 Il est possible, mais déconseillé, d'utiliser une vérification d'état héritée pour les équilibreurs de charge HTTP(S) externes si les deux conditions suivantes sont remplies :

  • 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 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 équilibrage de charge réseau 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.

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. 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
É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 Pour tous les types de backends :
35.191.0.0/16
209.85.152.0/22
209.85.204.0/22

En outre, pour ceux basés sur un pool cible uniquement :
169.254.169.254
(serveurs de métadonnées)

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 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. 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 non opérationnels.

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

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

  • Un équilibreur de charge réseau tente, en dernier recours, de répartir le trafic vers toutes les VM de backend lorsqu'elles sont toutes 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 non opérationnelles. 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 pour envoyer des vérifications d'état aux équilibreurs de charge HTTP(S) externes, aux équilibreurs de charge proxy SSL et aux équilibreurs de charge proxy TCP. 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 :

      1/(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 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 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 HTTP(S) 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 proxy SSL et les équilibreurs de charge proxy TCP : 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 et les équilibreurs de charge TCP/UDP 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
É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 de chacune de ces règles. 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 service de backend (pour les équilibrages de charge réseau 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.
É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, il s'agit de l'adresse IP interne principale associée à l'interface réseau principale (nic0) de chaque instance.
  • Pour les backends de NEG zonaux, il s'agit de 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 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 l'état HTTP 200 (OK).

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 lors 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 :

É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. 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.
  • 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 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