Google Cloud propose des vérifications d'état configurables pour les backends de l'équilibreur de charge Google Cloud, les backends Cloud Service Mesh 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 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 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
Vérifications d'état héritées :
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 (ou Cloud Service Mesh) 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 :
--portet--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 par équilibreur de charge, consultez la section 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
Ce tableau indique la catégorie et le champ d'application des vérifications 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 global Équilibreur de charge d'application classique * Équilibreur de charge réseau proxy externe global Équilibreur de charge réseau proxy classique Équilibreur de charge d'application interne interrégional Équilibreur de charge réseau proxy interne interrégional |
Vérification d'état (globale) |
|
É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égional) Équilibreur de charge basé sur un pool cible : vérification d'état héritée |
| Équilibreur de charge réseau passthrough interne | Vérification d'état (globale ou régionale) |
| Mode d'équilibreur de charge | Vérifications d'état héritées compatibles |
|---|---|
Équilibreur de charge d'application externe mondial Équilibreur de charge d'application classique |
Oui, si les deux conditions suivantes sont remplies :
|
| Équilibreur de charge d'application externe régional | Non |
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
TCPouUDPcomme 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 Cloud Service Mesh
Notez les différences de comportement suivantes lorsque vous utilisez des vérifications d'état avec Cloud Service Mesh.
Avec Cloud Service Mesh, le comportement de vérification d'état pour les points de terminaison du réseau de type
INTERNET_FQDN_PORTetNON_GCP_PRIVATE_IP_PORTdiffère du comportement de vérification d'état pour les autres types de points de terminaison du réseau. Au lieu d'utiliser les tâches logicielles dédiées, Cloud Service Mesh programme les proxys Envoy pour effectuer des vérifications d'état pour les NEG Internet (points de terminaisonINTERNET_FQDN_PORT) et les NEG hybrides (points de terminaisonNON_GCP_PRIVATE_IP_PORT).Envoy est compatible avec les protocoles suivants pour la vérification de l'état :
- HTTP
- HTTPS
- HTTP/2
- TCP
Lorsque Cloud Service Mesh est intégré à l'Annuaire des services et que vous liez un service de l'Annuaire des services à un service de backend Cloud Service Mesh, 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 | Objectif | Valeur par défaut |
|---|---|---|
Intervalle entre deux testscheck-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 expirationtimeout |
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. 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 |
|---|---|
|
Pour le trafic IPv6 vers les backends :
|
|
Pour le trafic IPv6 vers les backends :
|
|
|
| Équilibreur de charge réseau passthrough externe3 |
Pour le trafic IPv4 vers les backends :
Pour le trafic IPv6 vers les backends :
|
| Équilibreur de charge réseau passthrough interne |
Pour le trafic IPv4 vers les backends :
Pour le trafic IPv6 vers les backends :
|
| Cloud Service Mesh avec backends NEG et backends NEG hybrides | Adresses IP des VM exécutant le logiciel Envoy Pour obtenir un exemple de configuration, consultez la documentation de Cloud Service Mesh. |
1 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.
2 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.
3 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
tcpdumpou 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 de 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 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 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
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 de vérification 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 ne doit contenir que des caractères ASCII imprimables à un seul octet, situés dans les 1 024 premiers octets du corps de la réponse HTTP.
Le tableau suivant présente les combinaisons valides de chemins de requête et d'indicateurs de réponse disponibles pour les vérifications d'état HTTP, HTTPS et HTTP/2.
| Options de configuration | Comportement du programme d'essai | Critères de réussite |
|---|---|---|
Ni --request-path, ni --response n'est spécifié
|
L'outil de sondage 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 HTTP 200 (OK) et les 1 024 premiers caractères ASCII du corps de la réponse HTTP doivent correspondre à la chaîne de réponse attendue. |
--response uniquement spécifié
|
L'outil de sondage utilise / comme chemin d'accès à la requête. |
Le code de réponse HTTP 200 (OK) et les 1 024 premiers caractères ASCII du corps de la réponse HTTP doivent correspondre à la chaîne de réponse attendue. |
--request-path uniquement 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 critères de réussite de base des vérifications d'état TCP et SSL sont les suivants :
Pour les vérifications d'état TCP, un vérificateur d'état doit ouvrir une connexion TCP avec le backend avant l'expiration du délai de vérification 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'intégrité 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 présente les combinaisons valides d'indicateurs 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 ne doivent contenir que des caractères ASCII imprimables sur un seul octet, chaque chaîne ne devant pas dépasser 1 024 caractères.
| Options de configuration | Comportement du programme d'essai | Critères de réussite |
|---|---|---|
--request et --response non 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. |
--response uniquement 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. |
--request uniquement 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
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 Cloud Service Mesh.
- 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 | Objectif | Valeur par défaut |
|---|---|---|
Seuil opérationnelhealthy-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 interne interrégional Équilibreur de charge d'application externe régional Équilibreur de charge d'application interne régional |
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. |
| Équilibreur de charge réseau passthrough interne É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 incluent d'autres remarques sur l'utilisation des vérifications d'état sur Google Cloud.
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
CNousubjectAlternativeNamene doit correspondre à un en-têteHostou à 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 :
- 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.
Chaque vérificateur d'état effectue les actions suivantes :
- Établissement d'une connexion HTTP entre l'une des adresses IP sources et l'instance backend toutes les 30 secondes
- 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)
Un backend est considéré comme non opérationnel lorsqu'au moins un système de vérification d'état remplit les conditions suivantes :
- 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é. - Les deux réponses consécutives reçues ne correspondent pas aux critères de réussite spécifiques au protocole.
- Deux vérifications consécutives ne renvoient pas de code de réponse
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 :
- t = 0 : lancement de la vérification A
- t = 5 : arrêt de la vérification A
- t = 30 : lancement de la vérification B
- t = 35 : arrêt de la vérification B
- t = 60 : lancement de la vérification C
- 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.