Présentation des vérifications d'état

Trusted Cloud by S3NS propose des vérifications d'état configurables pour les backends de l'Trusted Cloud équilibreur de charge et l'autoréparation basée sur les applications pour les groupes d'instances gérés. Ce document traite des concepts clés liés aux vérifications d'état.

Sauf indication contraire,les vérifications de l'état Trusted Cloud sont implémentées 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 de l'état'état. Chaque tentative de connexion est appelée vérification. Trusted 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 d'accès pour les vérifications d'état.

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

  • Régionales (gRPC, TCP, SSL, HTTP, HTTPS ou HTTP/2)
  • gRPC régional (avec TLS) (version preview)
  • Globales (gRPC, TCP, SSL, HTTP, HTTPS ou HTTP/2)
  • gRPC global (avec TLS) (preview)

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

  • Héritées globales (HTTP)

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 de l'état

Les vérifications d'état doivent être compatibles avec le type d'équilibreur de charge 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 Trusted Cloud pour vérifier les backends. Il est préférable d'utiliser une vérification d'état (ou une vérification de l'é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 de l'état et d'équilibreur de charge n'ont pas besoin d'être identiques.
• Spécification de port : ports utilisés par Trusted 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. Pour en savoir plus sur les exigences concernant le port de vérification de l'état'état par équilibreur de charge, consultez Indicateurs de spécification de 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 et le champ d'application des vérification de l'état d'état compatibles avec chaque type d'équilibreur de charge.

Équilibreur de charge	Catégorie et champ d'application de la vérification d'état
Équilibreur de charge d'application externe régional É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	Vérification d'état (régionale)
Équilibreur de charge réseau passthrough externe	Équilibreur de charge basé sur un service de backend : vérification de l'état (régionale) Équilibreur de charge basé sur un pool cible : vérification d'état héritée (globale avec le protocole HTTP)
Équilibreur de charge réseau passthrough interne	Vérification d'état (globale ou régionale)

Notes supplémentaires sur l'utilisation

• Pour les backends de groupes d'instances de VM, les vérifications d'état ne sont effectuées que sur les instances de VM démarrées. Les instances de VM arrêtées ne reçoivent pas de paquets de vérification d'état.

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

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.

Indicateur de configuration	Objectif	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 Trusted 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 Trusted Cloud puisse se connecter à vos backends. Pour obtenir des instructions, consultez la section Créer les règles de pare-feu requises.

Le tableau suivant indique les plages d'adresses IP sources à autoriser pour chaque équilibreur de charge :

Produit	Plages d'adresses IP sources de vérification d'état
Équilibreur de charge d'application externe régional Équilibreur de charge d'application interne régional Équilibreur de charge réseau proxy externe régional Équilibreur de charge réseau proxy interne régional Équilibreur de charge réseau passthrough interne	Pour le trafic IPv4 vers les backends : 177.222.80.0/23 Pour le trafic IPv6 vers les backends : 2a13:7500:8301:b029:0:2b::/96
Équilibreur de charge réseau passthrough externe	Pour le trafic IPv4 vers les backends : 177.222.87.64/26 Pour le trafic IPv6 vers les backends : 2a13:7500:241:30::/64 Pour les équilibreurs de charge basés sur un pool cible : 177.222.87.0/26

Importance des règles de pare-feu

Trusted 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. Trusted 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érificateursTrusted 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. Trusted Cloud peut automatiquement mettre en œuvre de nouveaux vérificateurs sans notification.

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

Trusted Cloud envoie des vérification de l'état depuis plusieurs systèmes redondants appelés vérificateurs. Les vérificateurs utilisent des plages d'adresses IP sources. Trusted 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,Trusted 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 Trusted 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 Trusted 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,Trusted 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, Trusted 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, Trusted 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,Trusted 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 régional Équilibreur de charge d'application interne régional Équilibreur de charge réseau proxy externe régional Équilibreur de charge réseau proxy interne régional	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), Trusted 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 en savoir plus, consultez 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, Trusted 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.

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

Les vérifications d'état HTTP, HTTPS et HTTP/2 nécessitent toujours la réception d'un code de réponse HTTP 200 (OK) avant l'expiration du délai avant expiration de la vérification de l'état d'état. Tous les autres codes de réponse HTTP, y compris les codes de réponse de redirection tels que 301 et 302, sont considérés comme non opérationnels.

En plus d'exiger un code de réponse HTTP 200 (OK), vous pouvez :

• Configurer chaque vérificateur d'état pour qu'il envoie des requêtes HTTP vers un chemin de requête spécifique au lieu du chemin de requête par défaut, /.

• Configurez chaque vérificateur d'état pour qu'il vérifie la présence d'une chaîne de réponse attendue dans le corps de la réponse HTTP. La chaîne de réponse attendue doit se composer uniquement de caractères ASCII imprimables mono-octets, situés dans les 1 024 premiers octets du corps de la réponse HTTP.

Le tableau suivant liste les combinaisons valides d'options de chemin de requête et de réponse disponibles pour les vérifications d'état HTTP, HTTPS et HTTP/2.

Options de configuration	Comportement du vérificateur	Critères de réussite
Ni --request-path ni --response spécifié	Le vérificateur utilise / comme chemin d'accès à la requête.	Code de réponse HTTP 200 (OK) uniquement.
--request-path et --response spécifiés	Le vérificateur utilise le chemin d'accès à la requête configuré.	Le code de réponse 200 (OK) HTTP et les 1 024 premiers caractères ASCII du corps de la réponse HTTP doivent correspondre à la chaîne de réponse attendue.
Seul --response est spécifié	Le vérificateur utilise / comme chemin d'accès à la requête.	Le code de réponse 200 (OK) HTTP et les 1 024 premiers caractères ASCII du corps de la réponse HTTP doivent correspondre à la chaîne de réponse attendue.
Seul --request-path est spécifié	Le vérificateur utilise le chemin d'accès à la requête configuré.	Code de réponse HTTP 200 (OK) uniquement.

Critères de réussite pour SSL et TCP

Les vérifications d'état TCP et SSL ont les critères de réussite de base suivants :

• Pour les vérifications d'état TCP, un vérificateur d'état doit ouvrir une connexion TCP vers le backend avant le délai d'expiration de la vérification de l'état d'état.

• Pour les vérifications d'état SSL, un vérificateur d'état doit ouvrir une connexion TCP vers le backend et effectuer le handshake TLS/SSL avant le délai d'expiration de la vérification d'état.

• Pour les vérifications d'état TCP, la connexion TCP doit être fermée de l'une des manières suivantes :

  • Par le vérificateur d'état qui envoie un paquet FIN ou RST (reset), ou
  • Par le backend qui envoie un paquet FIN. Si un backend envoie un paquet TCP RST, la vérification peut être considérée comme un échec si le vérificateur d'état a déjà envoyé un paquet FIN.

Le tableau suivant répertorie les combinaisons valides d'options de requête et de réponse disponibles pour les vérifications d'état TCP et SSL. Les indicateurs de requête et de réponse doivent être composés uniquement de caractères ASCII imprimables mono-octets, chaque chaîne ne devant pas dépasser 1 024 caractères.

Options de configuration	Comportement du vérificateur	Critères de réussite
Ni --request ni --response n'ont été spécifiés	Le vérificateur n'envoie aucune chaîne de requête.	Critères de réussite de base uniquement.
--request et --response spécifiés	Le vérificateur envoie la chaîne de requête configurée.	Les critères de réussite de base et la chaîne de réponse reçue par le vérificateur doivent correspondre exactement à la chaîne de réponse attendue.
Seul --response est spécifié	Le vérificateur n'envoie aucune chaîne de requête.	Les critères de réussite de base et la chaîne de réponse reçue par le vérificateur doivent correspondre exactement à la chaîne de réponse attendue.
Seul --request est spécifié	Le vérificateur envoie la chaîne de requête configurée.	Critères de réussite de base uniquement (aucune chaîne de réponse n'est vérifiée).

Critères de réussite pour gRPC

Les vérifications d'état gRPC ne sont utilisées qu'avec les applications gRPC, Trusted Cloud les équilibreurs de charge et Cloud Service Mesh. Trusted Cloud prend en charge deux types de vérifications d'état gRPC :

• Les vérifications d'état GRPC_WITH_TLS (aperçu) sont utilisées pour vérifier l'état des backends gRPC avec TLS activé. Ils sont compatibles avec le chiffrement TLS non authentifié, ce qui signifie que les vérifications de l'état ne valident pas l'identité du serveur.
• Les vérifications d'état GRPC sont utilisées pour vérifier l'état des backends gRPC non sécurisés. Elles ne sont pas compatibles avec l'authentification ni le chiffrement. Elles ne peuvent donc pas être utilisées pour les backends gRPC avec TLS activé.

Si vous utilisez des vérifications d'état gRPC (avec ou sans TLS), 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.

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

Trusted Cloud utilise les indicateurs de configuration suivants pour déterminer l'état de fonctionnement global de chaque backend vers lequel le trafic est soumis à l'équilibrage de charge.

Indicateur de configuration	Objectif	Valeur par défaut
Seuil opérationnel healthy-threshold	Le seuil opérationnel indique le nombre de vérifications séquentielles ayant réussi pour qu'un backend précédemment non opérationnel soit considéré comme opérationnel.	Seuil de 2 vérifications.
Seuil de faible capacité unhealthy-threshold	Le seuil non opérationnel indique le nombre de vérifications séquentielles ayant échoué pour qu'un backend précédemment opérationnel soit considéré comme non opérationnel.	Seuil de 2 vérifications.

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

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

Remarques supplémentaires

Les sections suivantes incluent d'autres remarques sur l'utilisation des vérifications de l'état sur Trusted Cloud.

Certificats et vérifications d'état

Les vérificateurs d'étatTrusted 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.

Si vous utilisez des en-têtes de requêtes personnalisés, notez que l'équilibreur de charge n'ajoute ces en-têtes qu'aux requêtes client et non aux vérifications d'état. Si votre backend nécessite un en-tête spécifique pour l'autorisation qui ne figure dans le paquet de vérification d'état, la vérification d'état peut échouer.

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.