Concepts de vérification de l'état

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

Aperçu

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

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

GCP utilise l'état de fonctionnement global de chaque backend pour déterminer s'il peut recevoir de nouvelles requêtes. En plus de pouvoir configurer la fréquence de vérification et les seuils d'état opérationnel ou non, vous pouvez configurer les critères définissant la réussite d'une vérification. Ce document décrit en détail le fonctionnement des vérifications d'état.

Pour les vérifications d'état, GCP utilise des routages spéciaux non définis dans votre réseau VPC. Pour obtenir des informations complètes à ce sujet, consultez la documentation relative aux chemins de retour des équilibreurs de charge.

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

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

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

La plupart des équilibreurs de charge GCP requièrent des vérifications d'état non héritées, mais l'équilibrage de la charge réseau nécessite des vérifications d'état héritées qui utilisent le protocole HTTP. Pour obtenir des informations spécifiques au choix de la catégorie et du protocole ainsi qu'à la spécification des ports, reportez-vous à la section Sélectionner une vérification d'état.

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

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.

Sélectionner une vérification d'état

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

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

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

Dans cette section, le terme de groupe d'instances désigne aussi bien des groupes d'instances non gérés que des groupes d'instances zonaux gérés ou des groupes d'instances régionaux gérés.

Catégorie et protocole

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

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

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

Catégorie de vérification d'état Protocoles compatibles
Contrôle d'état • HTTP
• HTTPS
• HTTP/2
• SSL
• TCP
Vérification d'état héritée • HTTP
• HTTPS (les vérifications d'état HTTPS héritées ne sont pas compatibles avec les équilibreurs de charge réseau et ne peuvent pas être utilisées avec la plupart des autres équilibreurs de charge).

Spécifier des catégories et des ports

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

Catégorie de vérification d'état Méthodes et signification des spécifications de ports
Contrôle d'état --port : spécifie un numéro de port TCP.
--port-name : spécifie un ensemble de ports nommés dans un groupe d'instances.
--use-serving-port : pour les groupes d'instances, utilise le même port nommé que celui utilisé par le service backend ; pour les groupes de points de terminaison du réseau, utilise le port défini sur chaque point de terminaison.
Vérification d'état héritée --port : spécifie un numéro de port TCP.

Remarque valable ici et ci-dessous : l'indicateur --use-serving-port est mis en œuvre pour la commande gcloud beta compute health-checks create, mais pas pour la commande gcloud beta compute health-checks update.

Guide relatif aux équilibreurs de charge

Utilisez le tableau suivant afin de choisir la catégorie et le protocole de vérification d'état appropriés pour un équilibreur de charge donné.

Équilibreur de charge Type de backend Catégorie et champ d'application de la vérification d'état Spécification du port
TCP/UDP interne Groupes d'instances sur un service backend interne régional Vérification d'état (globale) Numéro de port (--port) ou port nommé (--port-name).
Vous ne pouvez pas utiliser l'indicateur --use-serving-port car les services backend présentant des schémas d'équilibrage de charge internes (INTERNAL) ne possèdent pas de port nommé associé.
HTTP(S) interne Groupes de points de terminaison du réseau
sur un service backend
Vérification d'état (régionale) Numéro de port (--port ) ou
--use-serving-port
Groupes d'instances sur un service backend Vérification d'état (régionale) Numéro de port (--port), port nommé (--port-name) ou
--use-serving-port
Réseau Groupes d'instances utilisant des pools cibles Vérifications d'état héritées (globales)
utilisant le protocole HTTP
Les vérifications d'état héritées ne sont compatibles qu'avec les spécifications de port par numéro de port (--port).
Proxy TCP
Proxy SSL
HTTP(S) 1
Groupes de points de terminaison du réseau
sur un service backend
Vérification d'état (globale) Numéro de port (--port ) ou
--use-serving-port
Groupes d'instances sur un service backend Vérification d'état (globale) Numéro de port (--port), port nommé (--port-name) ou
--use-serving-port

1Il est possible, mais déconseillé, d'utiliser une vérification d'état héritée pour les services backend associés à des équilibreurs de charge HTTP(S) dans les cas suivants :

  • Les backends utilisés par le service backend sont des groupes d'instances, et non des groupes de points de terminaison du réseau.
  • Les VM backend peuvent être vérifiées à l'aide de HTTP ou HTTPS.

Fonctionnement des vérifications d'état

Vérifications

Lorsque vous créez une vérification d'état ou que vous créez une vérification d'état héritée, vous spécifiez les indicateurs ci-dessous ou vous acceptez leurs valeurs par défaut. Ces indicateurs contrôlent la fréquence à laquelle chaque système de vérification d'état de GCP vérifie votre groupe d'instances ou vos backends NEG. GCP met en œuvre les vérifications au travers de plusieurs systèmes.

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 backend dans son ensemble, et les vérifications d'état héritées sont associées à un pool cible dans son ensemble ou à l'ensemble d'un service backend pour certains équilibreurs de charge HTTP(S). 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 système de vérification donné et le début de la vérification suivante émise par le même système. Cette valeur est exprimée en secondes. Si cette valeur est omise, GCP utilise 5s (5 secondes).
Inactive
timeout
Le délai d'expiration correspond à la durée pendant laquelle GCP 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. Si cette valeur est omise, GCP utilise 5s (5 secondes).

Plages d'adresses IP de vérification

Les adresses IP source des systèmes de vérification GCP dépendent du type de l'équilibreur de charge. Utilisez le tableau suivant pour créer des règles de pare-feu autorisant le trafic entrant en provenance des systèmes de vérification GCP vers vos backends.

Équilibreur de charge Plages d'adresses IP de vérification Exemple de règle de pare-feu
• Interne
• Proxy TCP
• Proxy SSL
• HTTP(S)
• HTTP(S) interne
• 35.191.0.0/16
• 130.211.0.0/22
Règles de pare-feu pour tous les équilibreurs de charge, à l'exception des équilibreurs de charge réseau
• Réseau • 35.191.0.0/16
• 209.85.152.0/22
• 209.85.204.0/22
Règles de pare-feu pour les équilibreurs de charge réseau

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

GCP envoie des vérifications d'état depuis plusieurs systèmes redondants situés dans les plages d'adresses IP source appropriées. Aucun système n'est, à lui seul, responsable de l'intégralité de ces vérifications. Plusieurs systèmes émettent des vérifications simultanément, de sorte que l'échec d'un système isolé n'empêche pas GCP de suivre l'état de fonctionnement du backend.

Les réglages d'intervalle et de délai d'expiration que vous configurez pour une vérification d'état sont appliqués à chaque système de vérification. Pour un backend donné, les journaux d'accès logiciel et tcpdump montrent des vérifications d'état plus fréquentes que les paramètres que vous avez configurés. Plusieurs systèmes de vérification contactent simultanément vos backends, ce qui résulte en davantage de vérifications d'état que n'en sont configurées pour un seul système de vérification.

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

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

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

      1(intervalle entre deux tests)

      Lorsque vous associez une vérification d'état à un service backend, vous définissez une fréquence de base utilisée par chaque système de vérification 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 systèmes de vérification simultanés utilisés par GCP. 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 backend interne régional, GCP utilise plusieurs systèmes de vérification pour vérifier chaque adresse IP. La fréquence de vérification par service backend est alors multipliée par le nombre de règles de transfert configurées.

  • Règles de transfert multiples pour les équilibreurs de charge réseau : si vous avez configuré plusieurs règles de transfert pointant vers le même pool cible, GCP utilise plusieurs systèmes de vérification pour vérifier chaque adresse IP. La fréquence de vérification telle qu'elle est perçue par chaque backend dans le pool cible est multipliée par le nombre de règles de transfert configurées.

  • Proxys cibles multiples pour les équilibreurs de charge HTTP(S) : si vous avez configuré plusieurs proxys cibles pour le même mappage d'URL pour l'équilibrage de charge HTTP(S), GCP utilise plusieurs systèmes de vérification 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 proxy TCP : si vous avez configuré plusieurs proxys cibles pour le même service backend d'équilibrage de charge proxy SSL ou TCP, GCP utilise plusieurs systèmes de vérification pour vérifier l'adresse IP associée à chaque proxy cible. La fréquence de vérification par service backend est alors multipliée par le nombre de proxys cibles configurés.

  • Somme sur un ensemble de services backend : si un backend (par exemple, un groupe d'instances) est utilisé par plusieurs services 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 backend.

    Avec les backends de groupes de points de terminaison du réseau, il est plus difficile de déterminer le nombre exact de vérifications d'état. Par exemple, le même point de terminaison peut faire partie de plusieurs NEG ne partageant 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 associés à la vérification d'état

Les vérifications d'état de GCP envoient des paquets uniquement à l'interface réseau principale de chaque instance de backend. L'adresse IP de destination de ces paquets dépend du type de l'équilibreur de charge :

  • Pour les équilibreurs de charge TCP/UDP internes et les équilibreurs de charge réseau, la destination des paquets de vérification d'état est l'adresse IP définie par la règle de transfert de l'équilibreur de charge. Si plusieurs règles de transfert pointent vers le même service backend ou le même pool cible, GCP 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, comme décrit dans la section précédente.
  • Pour les équilibreurs de charge HTTP(S), proxy TCP, proxy SSL et HTTP(S) internes utilisant des groupes d'instances comme backends, la destination des paquets de vérification d'état est l'adresse IP interne principale associée à l'interface réseau principale de chaque instance backend.
  • Pour les équilibreurs de charge HTTP(S), proxy TCP, proxy SSL et HTTP(S) internes utilisant les groupes de points de terminaison du réseau comme backends, la destination des paquets de vérification d'état est l'adresse IP du point de terminaison, qui peut être une adresse IP principale ou secondaire (adresse IP d'alias).

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

Les vérifications d'état HTTP(S), HTTP/2, TCP et SSL peuvent éventuellement être basées sur le contenu (requête/réponse). Avec une vérification d'état basée sur le contenu, le système de vérification d'état envoie une chaîne de requête au backend. La vérification d'état est configurée pour attendre une réponse particulière à cette requête.

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

Les réponses des vérifications d'état pour les protocoles HTTP, HTTPS ou HTTP/2 ne sont considérées comme des réussites que si GCP reçoit une réponse HTTP 200 (OK) à la requête et que cette réponse arrive avant expiration du délai de la vérification.

Les requêtes sont envoyées à un chemin de requête configurable ou, en l'absence de valeur particulière spécifiée, à /. Toute réponse est acceptée, sauf si vous utilisez la vérification basée sur le contenu pour fournir une chaîne de réponse attendue. Voici les indicateurs disponibles pour contrôler les critères de réussite des vérifications d'état HTTP, HTTPS et HTTP/2 :

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

L'utilisation d'une vérification d'état basée sur le contenu est facultative. Que vous spécifiiez ou non une chaîne de réponse attendue, GCP s'attend à ce que le backend soumis à la vérification envoie une réponse HTTP 200 (OK). Lorsque vous renseignez une réponse attendue, chaque système de vérification d'état de GCP analyse les réponses fournies par vos backends et y recherche la chaîne de réponse attendue dans les 1 024 premiers octets renvoyés. Une vérification d'état HTTP basée sur le contenu est considérée comme une réussite si le système de vérification reçoit la réponse HTTP 200 (OK) et que la chaîne de réponse attendue est trouvée parmi les 1 024 premiers octets de la réponse renvoyée.

Critères de réussite pour SSL et TCP

Par défaut, les réponses des vérifications d'état utilisant les protocoles SSL et TCP sont considérées comme des réussites uniquement si GCP parvient à réaliser un handshake SSL ou TCP pour établir une session avant la fin du délai d'expiration de la vérification.

En plus de la réussite du handshake, vous pouvez éventuellement fournir 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, GCP considère qu'une vérification réussit uniquement si le handshake SSL ou TCP a bien lieu 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'indicateurs de requête et de réponse pour les vérifications d'état utilisant les protocoles SSL et TCP :

Indicateurs de configuration Comportement
Ni une requête, ni une réponse ne sont spécifiées
Aucun indicateur n'est spécifié : --request, --response
GCP considère que la vérification a réussi si la session TCP ou SSL est établie avant la fin du délai d'expiration de la vérification.
Requête et réponse sont spécifiées
Les deux indicateurs sont spécifiés : --request, --response
GCP envoie la chaîne de requête que vous avez configurée et attend la chaîne de réponse escomptée. La vérification réussit si la session TCP ou SSL est établie et que la chaîne de réponse renvoyée correspond exactement à la chaîne de réponse attendue, avant la fin du délai d'expiration de la vérification.
Uniquement la réponse est spécifiée
Indicateur spécifié : uniquement --response
GCP attend la chaîne de réponse escomptée. La vérification réussit si la session TCP ou SSL est établie et que la chaîne de réponse renvoyée correspond exactement à la chaîne de réponse attendue, avant la fin du délai d'expiration de la vérification.
Vous ne devez utiliser l'indicateur --response isolément que si vos backends soumis à l'équilibrage de charge envoient automatiquement une chaîne de réponse dans le cadre du handshake.
Uniquement la requête est spécifiée
Indicateur spécifié : uniquement --request
GCP envoie la chaîne de requête que vous avez configurée. La vérification réussit si une session TCP ou SSL est établie avant la fin du délai d'expiration de la vérification. La réponse éventuellement renvoyée n'est pas vérifiée.

État de fonctionnement

GCP utilise les indicateurs de configuration suivants et la réussite ou l'échec des vérifications pour déterminer l'état de fonctionnement global de chaque backend soumis à équilibrage de charge :

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

GCP considère que le système est opérationnel une fois le seuil sanitaire atteint. Les backends opérationnels sont autorisés à recevoir de nouvelles connexions.

GCP considère un backend comme non opérationnel lorsque le seuil non sanitaire 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 sanitaire.

Étape suivante

Pour en savoir plus sur la configuration des vérifications d'état, consultez la documentation Créer des vérifications d'état.