Créer des vérifications d'état

Google Cloud propose des mécanismes de vérification d'état qui déterminent si les instances de backend répondent au trafic de façon appropriée. Ce document explique comment créer et utiliser des vérifications d'état pour les équilibreurs de charge et Traffic Director.

Sur cette page, nous partons du principe que vous connaissez bien les éléments suivants :

• Règles de pare-feu Google Cloud
• Présentation des vérifications d'état
• Présentation des services de backend

Remarque : Cette page décrit comment créer un composant d'équilibreur de charge spécifique avant ou après la création d'un équilibreur de charge. Les composants spécifiques sont utiles pour les configurations avancées et nécessaires pour certaines options de configuration. Avant d'utiliser les informations de cette page, déterminez le type d'équilibreur de charge Google Cloud dont vous avez besoin.

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

Google Cloud 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.

Traffic Director et la plupart des équilibreurs de charge effectuent des vérifications d'état non héritées, mais l'équilibrage de charge réseau basé sur un pool cible nécessite des vérifications d'état héritées. Pour déterminer la catégorie, le protocole et la méthode de spécification du port appropriés, consultez la page Sélectionner une vérification d'état de la page Présentation des vérifications d'état.

Le protocole que vous sélectionnez pour une vérification d'état n'a pas besoin de correspondre au protocole utilisé par l'équilibreur de charge. Dans certains cas, il arrive que cela ne soit pas possible du tout. Pour en savoir plus, consultez la section Protocoles et équilibreurs de charge.

Le terme "vérification d'état" ne fait pas référence aux vérifications d'état héritées. Dans ce document, celles-ci sont explicitement désignées par le terme "vérifications d'état héritées".

Répertorier les vérifications d'état

Console

Remarque : Cloud Console répertorie à la fois les vérifications d'état et les vérifications d'état héritées sur la page des vérifications d'état.

1. Accédez à la page "Vérifications d'état" dans Google Cloud Console.
   Accéder à la page "Vérifications d'état"
2. Cliquez sur une vérification d'état pour en afficher les détails.

gcloud

Pour répertorier les vérifications d'état, utilisez la commande compute health-checks list :

• Pour répertorier les vérifications d'état globales :

  gcloud compute health-checks list \
     --global
  

• Pour répertorier les vérifications d'état régionales, remplacez REGION_LIST par une liste de régions Google Cloud à interroger, séparées par des virgules.

  gcloud compute health-checks list \
     --regions=REGION_LIST
  

Si vous connaissez le nom et le champ d'application d'une vérification d'état, exécutez la commande compute health-checks describe pour afficher sa configuration actuelle.

• Pour décrire une vérification d'état globale, remplacez NAME par son nom.

  gcloud compute health-checks describe NAME \
     --global
  

• Pour décrire une vérification d'état régionale, remplacez NAME par son nom et REGION par sa région.

  gcloud compute health-checks describe NAME \
     --region=REGION
  

API

Pour répertorier les vérifications d'état, utilisez les appels d'API suivants :

• Pour répertorier les vérifications d'état globales : healthChecks.list

• Pour répertorier les vérifications d'état régionales : regionHealthChecks.list

Pour décrire la configuration actuelle d'une vérification d'état, utilisez les appels d'API suivants :

• Pour décrire une vérification d'état globale : healthChecks.get

• Pour décrire une vérification d'état régionale : regionHealthChecks.get

Créer des vérifications d'état

Google Cloud vous permet de créer ou de sélectionner une vérification d'état une fois la configuration du backend de l'équilibreur de charge terminée dans Cloud Console.

Vous pouvez également créer une vérification d'état indépendamment de la configuration de l'équilibreur de charge dans Cloud Console. Cela est utile si vous devez d'abord créer votre vérification d'état, ou si vous devez utiliser une vérification d'état pour plusieurs équilibreurs de charge. Vous pouvez créer une vérification d'état à l'aide de Cloud Console, de Google Cloud CLI ou des API REST.

Remarque : Vous devez utiliser les anciennes vérifications d'état HTTP avec les équilibreurs de charge réseau basés sur un pool cible. Vous pouvez créer ou sélectionner une vérification d'état héritée une fois la configuration de l'équilibreur de charge réseau terminée dans Cloud Console. Au lieu de la présente section, consultez la section Vérifications d'état héritées. Les équilibreurs de charge réseau basés sur un service de backend utilisent des vérifications d'état non héritées décrites dans cette section.

Console

1. Accédez à la page "Vérifications d'état" dans Google Cloud Console.
   Accéder à la page "Vérifications d'état"
2. Cliquez sur Créer une vérification d'état.
3. Sur la page Créer une vérification d'état, fournissez les informations suivantes :
   • Nom : indiquez le nom de la vérification d'état.
   • Description : vous pouvez éventuellement indiquer une description.
   • Champ d'application : sélectionnez un champ d'application, Global ou Régional, selon le type d'équilibreur de charge.
     • Si vous avez sélectionné Régional, choisissez une Région dans la liste déroulante.
   • Protocole : sélectionnez un protocole de vérification d'état.
   • Port : indiquez un numéro de port. Lorsque vous créez une vérification d'état dans Cloud Console, vous devez spécifier le port à l'aide d'un numéro de port.
   • Protocole de proxy : vous pouvez éventuellement ajouter un en-tête de proxy aux requêtes effectuées par les systèmes de test de vérification d'état.
   • Chemin de requête et réponse : pour les protocoles HTTP, HTTPS et HTTP2, vous pouvez éventuellement fournir un chemin d'URL pour les systèmes de test de vérification d'état à contacter. Pour en savoir plus, consultez la section Options supplémentaires pour les vérifications d'état HTTP, HTTPS et HTTP/2.
   • Requête et Réponse : pour les protocoles TCP et SSL, vous pouvez spécifier une chaîne de texte ASCII à envoyer et une chaîne de réponse textuelle attendue. Pour en savoir plus, consultez la section Options supplémentaires pour les vérifications d'état SSL et TCP.
   • Intervalle entre deux tests : définit la durée écoulée entre le début d'une vérification et le début de la suivante.
   • Délai avant expiration : définit 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.
   • Seuil sanitaire : définit le nombre de vérifications séquentielles qui doivent réussir pour que l'instance de VM soit considérée comme opérationnelle.
   • Seuil non sanitaire : définit le nombre de vérifications séquentielles qui doivent échouer pour que l'instance de VM soit considérée comme non opérationnelle.
4. Cliquez sur Créer.

gcloud

• Pour créer une vérification d'état globale, utilisez la commande compute health-checks create appropriée :

  gcloud compute health-checks create PROTOCOL NAME \
      --global \
      --description=DESCRIPTION \
      --check-interval=CHECK_INTERVAL \
      --timeout=TIMEOUT \
      --healthy-threshold=HEALTHY_THRESHOLD \
      --unhealthy-threshold=UNHEALTHY_THRESHOLD \
      PORT_SPECIFICATION \
      ADDITIONAL_FLAGS
  

• Pour créer une vérification d'état régionale, utilisez la commande compute health-checks create appropriée :

  gcloud compute health-checks create PROTOCOL NAME \
      --region=REGION \
      --description=DESCRIPTION \
      --check-interval=CHECK_INTERVAL \
      --timeout=TIMEOUT \
      --healthy-threshold=HEALTHY_THRESHOLD \
      --unhealthy-threshold=UNHEALTHY_THRESHOLD \
      PORT_SPECIFICATION \
      ADDITIONAL_FLAGS
  

Remplacez les éléments suivants :

• PROTOCOL définit le protocole utilisé pour la vérification d'état. Les options valides sont grpc, http, https, http2, ssl et tcp.
• NAME est le nom de la vérification d'état. Dans un projet donné, chaque vérification d'état globale doit posséder un nom unique, et les vérifications d'état régionales doivent posséder des noms uniques au sein d'une région donnée.
• REGION : tous les équilibreurs de charge, à l'exception des équilibreurs de charge HTTP(S) externes régionaux et des équilibreurs de charge HTTP(S) internes, utilisent des vérifications d'état globales (--global). Les équilibreurs de charge HTTP(S) internes utilisent des vérifications d'état régionales, pour lesquelles la région doit correspondre à celle du service de backend.
• DESCRIPTION est une description facultative.
• CHECK_INTERVAL est la durée écoulée entre le début d'une connexion du système de test de vérification d'état et le début de la connexion suivante. Cette valeur est exprimée en secondes. En cas d'omission, Google Cloud utilise la valeur 5s (cinq secondes).
• TIMEOUT est la durée pendant laquelle Google Cloud attend une réponse à une vérification. La valeur de TIMEOUT doit être inférieure ou égale à celle de CHECK_INTERVAL. Cette valeur est exprimée en secondes. En cas d'omission, Google Cloud utilise la valeur 5s (cinq secondes).
• HEALTHY_THRESHOLD et UNHEALTHY_THRESHOLD indiquent le nombre de tests séquentiels qui doivent réussir ou échouer pour que l'instance de VM soit considérée comme opérationnelle ou non opérationnelle. Si l'une de ces valeurs est omise, Google Cloud utilise le seuil par défaut défini sur 2.
• PORT_SPECIFICATION : définit la spécification du port à l'aide de l'une des options de spécification du port.
• ADDITIONAL_FLAGS correspond à d'autres options permettant de spécifier des ports et des options propres au protocole PROTOCOL. Consultez les sections Options supplémentaires pour les vérifications d'état HTTP, HTTPS et HTTP/2, Options supplémentaires pour les vérifications d'état SSL et TCP ou Options supplémentaires pour les vérifications d'état gRPC.

API

• Pour créer une vérification d'état globale, utilisez healthChecks.insert.

• Pour créer une vérification d'état régionale, utilisez regionHealthChecks.insert.

Modifier des vérifications d'état

Vous ne pouvez pas modifier une vérification d'état de façon à la convertir en vérification d'état héritée (ou inversement). Vous ne pouvez pas non plus modifier le nom ou le champ d'application d'une vérification d'état (par exemple, de global à régional).

Console

1. Accédez à la page "Vérifications d'état" dans Google Cloud Console.
   Accéder à la page "Vérifications d'état"
2. Cliquez sur une vérification d'état pour en afficher les détails.
3. Si vous devez modifier la vérification d'état, cliquez sur Modifier. Procédez ensuite comme suit :
   • Modifiez les paramètres si nécessaire.
   • Cliquez sur Enregistrer.

gcloud

1. Identifiez le nom et le champ d'application de la vérification d'état. Pour obtenir des instructions, consultez la section Répertorier les vérifications d'état.

2. Vous pouvez modifier toutes les options communes, options de spécification du port et options facultatives d'une vérification d'état, sauf le nom, le protocole et le champ d'application. Pour modifier une vérification d'état existante, utilisez la commande compute health-checks update appropriée. Pour les options que vous omettez, les paramètres préconfigurés sont conservés.

   • Exemple de modification d'une vérification d'état globale : la commande suivante modifie une vérification d'état HTTP globale nommée hc-http-port-80 en modifiant l'intervalle entre deux tests, le délai avant expiration et le chemin de requête :

     gcloud compute health-checks update http hc-http-port-80 \
         --global \
         --check-interval=20s \
         --timeout=15s \
         --request-path="/health"
     

   • Exemple de modification d'une vérification d'état régionale : la commande suivante modifie une vérification d'état TCP régionale dans us-west1 nommée hc-west1-tcp-ldap en modifiant sa spécification de port :

     gcloud compute health-checks update tcp hc-west1-tcp-ldap \
         --region=us-west1 \
         --port=631
     

API

1. Identifiez le nom et le champ d'application de la vérification d'état. Pour obtenir des instructions, consultez la section Répertorier les vérifications d'état.

2. Les appels d'API suivants vous permettent de modifier toutes les options communes, options de spécification du port et options facultatives d'une vérification d'état, sauf le nom, le protocole et le champ d'application. Utilisez les appels d'API patch pour conserver les paramètres préconfigurés qui ne sont pas explicitement définis dans la requête.

   • Pour modifier une vérification d'état globale, utilisez healthChecks.update ou healthChecks.patch.

   • Pour modifier une vérification d'état régionale, utilisez regionHealthChecks.update ou regionHealthChecks.patch.

Options supplémentaires

Cette section décrit des options supplémentaires que vous pouvez utiliser lors de la création ou de la modification d'une vérification d'état. Certaines options, telles que la spécification du port, doivent être définies à l'aide de gcloud ou de l'API.

Options de spécification du port

Si vous créez une vérification d'état à l'aide de Google Cloud CLI ou de l'API, vous disposez de deux méthodes pour spécifier le port de la vérification d'état. Le tableau suivant présente les options de spécification du port pour les combinaisons d'équilibreur de charge et de backend valides. Le terme groupe d'instances désigne des groupes d'instances non gérés, des groupes d'instances gérés zonaux ou des groupes d'instances gérés régionaux.

Chaque vérification d'état ne peut utiliser qu'un seul type de spécification de port.

Produit	Type de backend	Options de spécification du port
Équilibrage de charge au niveau du réseau	Groupes d'instances	• --port : spécifie un port TCP par numéro, de 1 à 65535 L'option --use-serving-port sera ignorée pour une vérification d'état associée avec un équilibreur de charge réseau, car les services de backend des équilibreurs de charge réseau n'ont pas de spécification de port.
Équilibrage de charge TCP/UDP interne	Groupes d'instances	• --port : spécifie un port TCP par numéro, de 1 à 65535 L'option --use-serving-port sera ignorée pour une vérification d'état associée avec un équilibreur de charge TCP/UDP interne, car les services de backend des équilibreurs de charge TCP/UDP internes n'ont pas de spécification de port.
Équilibrage de charge HTTP(S) interne Équilibrage de charge proxy TCP Équilibrage de charge proxy SSL Équilibrage de charge HTTP(S) externe (global et régional) Traffic Director	NEG zonaux	• --port : spécifie un port TCP par son numéro, compris entre 1 et 65535 • --use-serving-port : utilise le port spécifié par chaque point de terminaison dans le groupe de points de terminaison du réseau
	Groupes d'instances	• --port : spécifie un port TCP par numéro, compris entre 1 et 65535 • --use-serving-port : utilise le même port nommé de groupe d'instances que celui configuré pour le service de backend

Si vous omettez la spécification du port, Google Cloud utilise les valeurs par défaut suivantes :

• Si le protocole de la vérification d'état est TCP ou HTTP, il utilise --port=80.
• Si le protocole de la vérification d'état est SSL, HTTPS ou HTTP2, il utilise --port=443.
• Si le protocole de la vérification d'état est GRPC, il n'y a pas de valeur par défaut implicite. Vous devez inclure la spécification de port.

Options supplémentaires pour les vérifications d'état HTTP, HTTPS et HTTP/2

En plus des indicateurs communs et de la spécification du port, vous pouvez utiliser les indicateurs facultatifs suivants pour les vérifications d'état HTTP, HTTPS et HTTP/2. Cet exemple crée une vérification d'état HTTP nommée hc-http-port-80 utilisant le port 80 avec les critères d'intervalle, de délai avant expiration et de seuil sanitaire par défaut.

gcloud compute health-checks create HTTP_PROTOCOL hc-http-port-80 \
    COMMON_FLAGS \
    PORT_SPECIFICATION \
    --host=HOST \
    --proxy-header=PROXY_HEADER \
    --request-path=REQUEST_PATH \
    --response=RESPONSE

• HTTP_PROTOCOL : peut prendre la valeur http (HTTP/1.1 sans TLS), https (HTTP/1.1 avec TLS) ou http2 (HTTP/2 avec TLS).
• COMMON_FLAGS : définit les options communes. Consultez la section Procédure de création.
• PORT_SPECIFICATION : définit la spécification du port à l'aide de l'une des options de spécification du port.
• HOST vous permet de fournir un en-tête HTTP Host. En cas d'omission, l'adresse IP de la règle de transfert de l'équilibreur de charge est utilisée.
• PROXY_HEADER doit être défini sur NONE ou PROXY_V1. En cas d'omission, Google Cloud utilise NONE. La valeur PROXY_V1 ajoute l'en-tête PROXY UNKNOWN\r\n.
• REQUEST_PATH spécifie le chemin d'URL que Google Cloud utilise lors de l'envoi de requêtes de vérification d'état. En cas d'omission, la requête de vérification d'état est envoyée à /.
• RESPONSE définit une réponse attendue facultative. Les chaînes de réponse doivent respecter les règles suivantes :
  • La chaîne de réponse doit être composée de lettres ASCII, de chiffres et d'espaces.
  • La chaîne de réponse peut comporter jusqu'à 1 024 caractères.
  • La mise en correspondance des caractères génériques n'est pas prise en charge.
  • La vérification basée sur le contenu n'est pas compatible avec l'inversion. Par exemple, des opérateurs tels que ! dans HAProxy ne sont pas acceptés.

Si Google Cloud trouve la chaîne de réponse attendue n'importe où dans les 1 024 premiers octets du corps de la réponse reçue, et si l'état HTTP est 200 (OK), la vérification est considérée comme réussie.

Les options --request-path et --response modifient les critères de réussite des vérifications d'état.

Options supplémentaires pour les vérifications d'état SSL et TCP

En plus des indicateurs communs et de la spécification du port, vous pouvez utiliser les indicateurs facultatifs suivants pour les vérifications d'état SSL et TCP. Cet exemple crée une vérification d'état TCP nommée hc-tcp-3268 utilisant le port 3268 avec les critères d'intervalle, de délai avant expiration et de seuil sanitaire par défaut.

gcloud compute health-checks create tcp hc-tcp-3268 \
    COMMON_FLAGS \
    PORT_SPECIFICATION \
    --proxy-header=PROXY_HEADER \
    --request=REQUEST_STRING \
    --response=RESPONSE_STRING

• Le protocole peut être tcp (comme dans cet exemple) ou ssl.
• COMMON_FLAGS : définit les options communes. Consultez la section Procédure de création.
• PORT_SPECIFICATION : définit la spécification du port à l'aide de l'une des options de spécification du port.
• PROXY_HEADER doit être défini sur NONE ou PROXY_V1. En cas d'omission, Google Cloud utilise NONE. La valeur PROXY_V1 ajoute l'en-tête PROXY UNKNOWN\r\n.
• REQUEST_STRING : vous pouvez fournir une chaîne contenant jusqu'à 1 024 caractères ASCII, qui sera envoyée une fois la session TCP ou SSL établie.
• RESPONSE_STRING : vous pouvez fournir une chaîne contenant jusqu'à 1 024 caractères ASCII en tant que réponse attendue.

Les options --request et --response modifient les critères de réussite des vérifications d'état. Si vous utilisez l'option --response, soit seule, soit conjointement avec l'option --request, la réponse renvoyée doit correspondre exactement à la chaîne de réponse attendue.

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

Votre serveur gRPC backend doit mettre en œuvre le service d'état gRPC tel que décrit dans le protocole de vérification de l'état gRPC. Google Cloud envoie un message HealthCheckRequest à vos backends en appelant la méthode Check du service de santé sur votre backend. Le paramètre de service dans la requête est défini sur une chaîne vide, sauf si un nom de service gRPC est spécifié.

Une vérification d'état gRPC peut vérifier l'état d'un service gRPC. Vous pouvez inclure une chaîne contenant jusqu'à 1 024 caractères ASCII, soit le nom d'un service gRPC particulier s'exécutant sur une VM de backend ou un NEG. Pour ce faire, utilisez l'option facultative suivante pour les vérifications d'état gRPC :

--grpc-service-name=GRPC_SERVICE_NAME

Par exemple, vous pouvez avoir les services et l'état suivants, que le serveur backend enregistre avec le service d'état gRPC de votre backend.

• MyPackage.ServiceA avec l'état de diffusion SERVING
• MyPackage.ServiceB avec l'état de diffusion NOT_SERVING
• Nom du service vide avec l'état de diffusion NOT_SERVING

Si vous créez une vérification d'état avec MyPackage.ServiceA, comme suit, celle-ci renvoie HEALTHY, car l'état du service est SERVING.

gcloud beta compute health-checks create grpc MyGrpcHealthCheckServiceA \
    --grpc-service-name=MyPackage.ServiceA

Si vous créez une vérification d'état sur MyPackage.ServiceB, celle-ci renvoie UNHEALTHY, car l'état du service est NOT_SERVING.

Si vous créez une vérification d'état sur MyPackage.ServiceC, qui n'est pas enregistrée auprès du service d'état gRPC, la vérification de l'état renvoie l'état gRPC NOT_FOUND, ce qui équivaut à UNHEALTHY.

Si vous créez une vérification d'état avec le nom de service vide, celle-ci renvoie l'état UNHEALTHY, car le nom de service vide est enregistré avec l'état NOT_SERVING.

Important : Les vérifications d'état gRPC de Google Cloud ne sont pas compatibles avec l'authentification et le chiffrement (TLS). Cela signifie que les VM peuvent passer les vérifications d'état gRPC, mais déclencher des erreurs HTTP 502 lorsqu'un équilibreur de charge envoie des requêtes à ces VM. Pour contourner ce problème, envisagez d'utiliser des vérifications d'état TCP pour les VM gRPC qui se trouvent derrière un équilibreur de charge.

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

Cette section décrit comment répertorier, créer et modifier des vérifications d'état héritées HTTP et HTTPS.

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.

Remarque : L'équilibrage de charge réseau basé sur un pool cible s'appuie sur les anciennes vérifications d'état HTTP pour déterminer l'état des instances du pool cible. Un équilibreur de charge réseau basé sur un pool cible peut uniquement utiliser une vérification d'état HTTP héritée, et non une vérification d'état héritée HTTPS. Notez que les équilibreurs de charge réseau basés sur un service de backend utilisent des vérifications d'état non héritées.

Répertorier les vérifications d'état héritées

Console

1. Accédez à la page "Vérifications d'état" dans Google Cloud Console.
   Accéder à la page "Vérifications d'état"
2. Cliquez sur une vérification d'état héritée pour en afficher les détails.

gcloud

1. Pour répertorier les vérifications d'état héritées HTTP, utilisez la commande compute http-health-checks list :

   gcloud compute http-health-checks list
   

   Pour répertorier les vérifications d'état héritées HTTPS, utilisez la commande compute https-health-checks list :

   gcloud compute https-health-checks list
   

2. Pour décrire une vérification d'état héritée HTTP, utilisez la commande compute http-health-checks describe en remplaçant NAME par son nom.

   gcloud compute http-health-checks describe NAME
   

   Pour décrire une vérification d'état héritée HTTPS, utilisez la commande compute https-health-checks describe en remplaçant NAME par son nom.

   gcloud compute https-health-checks describe NAME
   

API

1. Pour répertorier les vérifications d'état héritées :

   • Utilisez la méthode httpHealthChecks.list pour répertorier les vérifications d'état héritées HTTP.

   • Utilisez la méthode httpsHealthChecks.list pour répertorier les vérifications d'état héritées HTTPS.

2. Pour décrire une vérification d'état héritée :

   • Utilisez la méthode httpHealthChecks.get pour décrire une vérification d'état héritée HTTP.

   • Utilisez la méthode httpsHealthChecks.get pour décrire une vérification d'état héritée HTTPS.

Créer des vérifications d'état héritées

Console

Bien que la page des vérifications d'état de Cloud Console répertorie et permette de modifier à la fois les vérifications d'état et les vérifications d'état héritées, vous ne pouvez pas créer une vérification d'état héritée depuis cette page.

Vous pouvez créer une vérification d'état héritée dans Cloud Console uniquement pendant la création d'un équilibreur de charge réseau basé sur un pool cible. Pour créer la vérification d'état héritée séparément, suivez les instructions gcloud ou d'API de cette section.

gcloud

Pour créer une vérification d'état héritée, exécutez la commande compute http-health-checks create :

gcloud compute LEGACY_CHECK_TYPE create NAME \
    --description=DESCRIPTION \
    --check-interval=CHECK_INTERVAL \
    --timeout=TIMEOUT \
    --healthy-threshold=HEALTHY_THRESHOLD \
    --unhealthy-threshold=UNHEALTHY_THRESHOLD \
    --host=HOST \
    --port=PORT \
    --request-path=REQUEST_PATH

Remplacez les éléments suivants :

• LEGACY_CHECK_TYPE correspond à http-health-checks pour une vérification d'état héritée HTTP ou à https-health-checks pour une vérification d'état héritée HTTPS. Si vous créez la vérification d'état héritée pour un équilibreur de charge réseau basé sur un pool cible, vous devez utiliser http-health-checks.
• NAME est le nom de la vérification d'état héritée. Dans un projet donné, chaque vérification d'état héritée doit avoir un nom unique.
• DESCRIPTION est une description facultative.
• CHECK_INTERVAL définit la durée écoulée entre le début d'un test et le début du suivant Cette valeur est exprimée en secondes. En cas d'omission, Google Cloud utilise la valeur 5s (cinq secondes).
• TIMEOUT est la durée pendant laquelle Google Cloud attend une réponse à une vérification. La valeur de TIMEOUT doit être inférieure ou égale à celle de CHECK_INTERVAL. Cette valeur est exprimée en secondes. En cas d'omission, Google Cloud utilise la valeur 5s (cinq secondes).
• HEALTHY_THRESHOLD et UNHEALTHY_THRESHOLD indiquent le nombre de tests séquentiels qui doivent réussir ou échouer pour qu'une instance de VM soit considérée comme opérationnelle ou non opérationnelle. Si l'une de ces valeurs est omise, Google Cloud utilise le seuil par défaut défini sur 2.
• HOST vous permet de fournir un en-tête HTTP d'hôte. En cas d'omission, l'adresse IP de la règle de transfert de l'équilibreur de charge est utilisée.
• PORT vous permet d'indiquer un numéro de port. En cas d'omission, Google Cloud utilise 80.
• REQUEST_PATH spécifie le chemin d'URL que Google Cloud utilise lors de l'envoi de requêtes de vérification d'état. En cas d'omission, la requête de vérification d'état est envoyée à /.

API

• Pour créer une vérification d'état héritée HTTP, utilisez l'appel d'API httpHealthChecks.insert.

• Pour créer une vérification d'état héritée HTTPS, utilisez l'appel d'API httpsHealthChecks.insert.

Modifier des vérifications d'état héritées

Console

1. Accédez à la page "Vérifications d'état" dans Google Cloud Console.
   Accéder à la page "Vérifications d'état"
2. Cliquez sur une vérification d'état pour en afficher les détails.
3. Cliquez sur Modifier , apportez les modifications nécessaires, puis cliquez sur Enregistrer.

gcloud

• Pour modifier une vérification d'état héritée HTTP, utilisez la commande compute http-health-checks update en remplaçant NAME par son nom. Lorsque vous modifiez une vérification d'état héritée avec gcloud, les paramètres préconfigurés des options omises sont conservés. Les options "OTHER_OPTIONS" sont celles décrites à la section Créer une vérification d'état héritée.

  gcloud compute http-health-checks update NAME \
    OTHER_OPTIONS
  

• Pour modifier une vérification d'état héritée HTTPS, utilisez la commande compute https-health-checks update en remplaçant NAME par son nom. Lorsque vous modifiez une vérification d'état héritée avec gcloud, les paramètres préconfigurés des options omises sont conservés. Les options "OTHER_OPTIONS" sont celles décrites à la section Créer une vérification d'état héritée.

  gcloud compute https-health-checks update NAME \
    OTHER_OPTIONS
  

API

Hormis le nom et le type d'une vérification d'état héritée, vous pouvez modifier n'importe quelle option utilisée pour sa création. Les appels d'API patch conservent les paramètres préconfigurés qui ne sont pas explicitement définis dans la requête "patch".

• Pour modifier une vérification d'état héritée HTTP, utilisez httpHealthChecks.update ou httpHealthChecks.patch.

• Pour modifier une vérification d'état héritée HTTPS, utilisez httpsHealthChecks.update ou httpsHealthChecks.patch.

Règles de pare-feu requises

Vous devez créer des règles de pare-feu d'entrée applicables à toutes les VM faisant l'objet d'un équilibrage de charge pour autoriser le trafic provenant des plages d'adresses IP du système de test de vérification d'état. Les exemples suivants créent des règles de pare-feu applicables aux instances de VM en fonction de leur tag cible. Pour en savoir plus sur la spécification des cibles pour les règles de pare-feu, consultez la description des cibles sur la page Présentation des règles de pare-feu ainsi que la page Configurer des tags réseau.

Chacun de ces exemples permet d'acheminer tout le trafic TCP en provenance des systèmes de vérification d'état de Google Cloud vers vos instances de VM. (Le trafic TCP inclut le trafic SSL, HTTP, HTTPS et HTTP/2.) Si vous préférez, vous pouvez spécifier des ports avec le protocole TCP. Toutefois, si vous spécifiez des ports, vos règles de pare-feu peuvent devenir propres à une certaine vérification d'état. Si vous utilisez tcp:80 pour le protocole et le port, cela autorise le trafic TCP sur le port 80. Google Cloud peut alors contacter vos VM via HTTP sur le port 80, mais pas via HTTPS sur le port 443.

Règles de pare-feu pour les vérifications d'état

L'exemple suivant crée une règle de pare-feu d'entrée pour les équilibreurs de charge suivants :

• Équilibrage de charge TCP/UDP interne
• Équilibrage de charge HTTP(S) interne
• Équilibrage de charge proxy TCP
• Équilibrage de charge proxy SSL
• Équilibrage de charge HTTP(S) (global et régional)

Pour ces équilibreurs de charge, les plages d'adresses IP sources des vérifications d'état (y compris des vérifications d'état héritées si elles sont utilisées pour l'équilibrage de charge HTTP(S)) sont les suivantes :

• 35.191.0.0/16
• 130.211.0.0/22

Si vous devez créer des règles pour l'équilibrage de charge au niveau du réseau, consultez la section suivante, Règles pour l'équilibrage de charge au niveau du réseau.

Console

1. Accédez à la page "Pare-feu" de Google Cloud Console.
   Accéder à la page Pare-feu
2. Cliquez sur Créer une règle de pare-feu.
3. Sur la page Créer une règle de pare-feu, fournissez les informations suivantes :
   • Nom : attribuez un nom à la règle. Pour cet exemple, utilisez fw-allow-health-checks.
   • Réseau : choisissez un réseau VPC.
   • Priorité : saisissez un numéro pour la priorité. Plus la valeur est faible, plus la priorité est élevée. Assurez-vous que la règle de pare-feu a une priorité plus élevée que les autres règles susceptibles de refuser le trafic entrant.
   • Sens du trafic : choisissez Entrée.
   • Action en cas de correspondance : sélectionnez Autoriser.
   • Cibles : sélectionnez Tags cibles spécifiés, puis saisissez des tags dans la zone de texte Tags cibles. Pour cet exemple, utilisez allow-health-checks.
   • Filtre source : choisissez Plages d'adresses IP.
   • Plages d'adresses IP sources : 35.191.0.0/16,130.211.0.0/22
   • Protocoles et ports autorisés: utilisez tcp et le port configuré dans votre vérification d'état. TCP est le protocole sous-jacent de tous les protocoles de vérification d'état.
   • Cliquez sur Create (Créer).
4. Sur chacune de vos instances faisant l'objet d'un équilibrage de charge, ajoutez le tag réseau de sorte que cette nouvelle règle de pare-feu d'entrée lui soit appliquée. Cet exemple utilise allow-health-checks pour le tag réseau.

gcloud

1. Exécutez la commande gcloud suivante pour créer une règle de pare-feu nommée fw-allow-health-checks qui autorise les connexions TCP entrantes, en provenance des systèmes de vérification d'état de Google Cloud, à destination des instances de votre réseau VPC portant le tag allow-health-checks. Remplacez NETWORK_NAME par le nom de votre réseau VPC et PORT par les ports utilisés par votre équilibreur de charge.

   gcloud compute firewall-rules create fw-allow-health-checks \
       --network=NETWORK_NAME \
       --action=ALLOW \
       --direction=INGRESS \
       --source-ranges=35.191.0.0/16,130.211.0.0/22 \
       --target-tags=allow-health-checks \
       --rules=tcp:PORT

2. Sur chacune de vos instances faisant l'objet d'un équilibrage de charge, ajoutez le tag réseau de sorte que cette nouvelle règle de pare-feu d'entrée lui soit appliquée. Cet exemple utilise allow-health-checks pour le tag réseau.

Pour en savoir plus, consultez la documentation sur les règles de pare-feu gcloud et la documentation de l'API.

Règles pour l'équilibrage de charge réseau

L'exemple suivant crée une règle d'entrée de pare-feu pour l'équilibrage de charge réseau.

Pour les équilibreurs de charge réseau qui gèrent le trafic IPv4, vous devez autoriser les vérifications d'état des plages d'adresses IP sources suivantes:

• 35.191.0.0/16
• 209.85.152.0/22
• 209.85.204.0/22

Pour les équilibreurs de charge réseau qui gèrent le trafic IPv6, vous devez autoriser les vérifications d'état à partir de la plage d'adresses IP source suivante:

• 2600:1901:8001::/48

Ces plages s'appliquent aux deux types d'équilibreurs de charge réseau : un équilibreur de charge réseau basé sur un pool cible qui utilise des vérifications d'état héritées, un équilibreur de charge réseau basé sur le service de backend qui utilise des vérifications d'état non héritées.

Remarque: Les équilibreurs de charge réseau basés sur un pool cible peuvent relayer les vérifications d'état via le 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.

Console

1. Accédez à la page "Pare-feu" de Google Cloud Console.
   Accéder à la page Pare-feu
2. Cliquez sur Créer une règle de pare-feu.
3. Sur la page Créer une règle de pare-feu, fournissez les informations suivantes :
   • Nom : attribuez un nom à la règle. Pour cet exemple, utilisez fw-allow-network-lb-health-checks.
   • Réseau : choisissez un réseau VPC.
   • Priorité : saisissez un numéro pour la priorité. Plus la valeur est faible, plus la priorité est élevée. Assurez-vous que la règle de pare-feu a une priorité plus élevée que les autres règles susceptibles de refuser le trafic entrant.
   • Sens du trafic : choisissez Entrée.
   • Action en cas de correspondance : sélectionnez Autoriser.
   • Cibles : sélectionnez Tags cibles spécifiés, puis saisissez des tags dans la zone de texte Tags cibles. Pour cet exemple, utilisez allow-network-lb-health-checks.
   • Filtre source : choisissez Plages d'adresses IP.
   • Plages d'adresses IP sources : 35.191.0.0/16, 209.85.152.0/22, 209.85.204.0/22.
   • Protocoles et ports autorisés : utilisez tcp. TCP est le protocole sous-jacent pour HTTP et HTTPS.
   • Cliquez sur Créer.
4. Sur chacune de vos instances faisant l'objet d'un équilibrage de charge, ajoutez le tag réseau de sorte que cette nouvelle règle de pare-feu d'entrée lui soit appliquée. Cet exemple utilise allow-network-lb-health-checks pour le tag réseau.

gcloud

1. Exécutez la commande gcloud suivante pour créer une règle de pare-feu nommée fw-allow-network-lb-health-checks qui autorise les connexions TCP entrantes, en provenance des systèmes de vérification d'état de Google Cloud, à destination des instances de votre réseau VPC portant le tag allow-network-lb-health-checks. Remplacez NETWORK_NAME par le nom de votre réseau VPC.

   gcloud compute firewall-rules create fw-allow-network-lb-health-checks \
       --network=NETWORK_NAME \
       --action=ALLOW \
       --direction=INGRESS \
       --source-ranges=35.191.0.0/16,209.85.152.0/22,209.85.204.0/22 \
       --target-tags=allow-network-lb-health-checks \
       --rules=tcp

2. Sur chacune de vos instances faisant l'objet d'un équilibrage de charge, ajoutez le tag réseau de sorte que cette nouvelle règle de pare-feu d'entrée lui soit appliquée. Cet exemple utilise allow-network-lb-health-checks pour le tag réseau.

Pour en savoir plus, consultez la documentation sur les règles de pare-feu gcloud et la documentation de l'API.

Associer des vérifications d'état avec des équilibreurs de charge et Traffic Director

Cette section décrit certaines recommandations de vérification d'état et les exigences qui doivent être remplies avant d'associer une vérification d'état à un équilibreur de charge ou à Traffic Director.

Faire correspondre le protocole

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. Par exemple :

• Pour l'équilibrage de charge TCP/UDP interne, 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 TCP/UDP interne, il est judicieux d'utiliser une vérification d'état exploitant le protocole HTTP.

• Un équilibreur de charge réseau basé sur un pool cible doit utiliser une vérification d'état héritée HTTP. 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 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.
  
  Un équilibreur de charge réseau basé sur un service de backend peut utiliser des vérifications d'état non héritées. Autrement dit, vous pouvez utiliser une vérification d'état dont le protocole correspond à celui utilisé par le service de backend de l'équilibreur de charge réseau.

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

Vérifications d'état pour les services de backend

Cette section explique comment associer une vérification d'état à un service de backend pour les types d'équilibreurs de charge suivants :

• Équilibrage de charge TCP/UDP interne
• Équilibrage de charge HTTP(S) interne
• Équilibrage de charge proxy TCP
• Équilibrage de charge proxy SSL
• Équilibrage de charge HTTP(S)
• Équilibrage de charge réseau basé sur un service de backend

Cette section suppose que vous avez déjà :

• créé un équilibreur de charge TCP/UDP interne, un équilibreur de charge réseau basé sur un service de backend, un équilibreur de charge proxy TCP, un équilibreur de charge proxy SSL ou un équilibreur de charge HTTP(S) externe (global ou régional) ;
• créé une vérification d'état ;
• configuré les règles de pare-feu pour les vérifications d'état. Dans le cas d'un équilibreur de charge réseau basé sur un service de backend, consultez la section Règles de pare-feu pour l'équilibrage de charge réseau.

Pour associer une vérification d'état à un nouvel équilibreur de charge TCP/UDP interne, un équilibreur de charge proxy TCP, un équilibreur de charge proxy SSL, un équilibreur de charge HTTP(S) externe ou un équilibreur de charge réseau basé sur un service de backend, reportez-vous au guide de configuration de l'équilibreur de charge correspondant.

Console

Pour associer une vérification d'état à un équilibreur de charge TCP/UDP interne, un équilibreur de charge proxy TCP, un équilibreur de charge proxy SSL, un équilibreur de charge HTTP(S) externe ou un équilibreur de charge réseau basé sur un service de backend, procédez comme suit :

1. Accédez à la page "Équilibrage de charge" dans Google Cloud Console.
   Accéder à la page Équilibrage de charge
2. Cliquez sur un équilibreur de charge pour en afficher les détails.
3. Cliquez sur Modifier , puis sur Configuration du backend.
4. Sélectionnez une vérification d'état dans le menu Vérification d'état.
5. Cliquez sur Mettre à jour.

gcloud

Pour associer une vérification d'état à un service de backend existant, procédez comme suit.

1. Identifiez le nom et le champ d'application du service de backend. Un équilibreur de charge réseau, un équilibreur de charge TCP/UDP interne, un équilibreur de charge proxy TCP et un équilibreur de charge proxy SSL ne disposent que d'un seul service de backend par équilibreur de charge. Les équilibreurs de charge HTTP(S) externes et les équilibreurs de charge HTTP(S) internes sont associés à un ou plusieurs services de backend liés à un mappage d'URL unique.

   • Pour répertorier les services de backend des équilibreurs de charge TCP/UDP internes, exécutez la commande suivante en remplaçant REGION_LIST par une liste de régions Google Cloud à interroger, séparées par des virgules.

     gcloud compute backend-services list \
         --filter="region:( REGION1 REGION2 ... ) AND loadBalancingScheme=INTERNAL"
     

   • Pour répertorier les services de backend des équilibreurs de charge réseau, exécutez la commande suivante, en remplaçant chaque élément REGION par la région Google Cloud à interroger.

     gcloud compute backend-services list \
         --filter="region:( REGION1 REGION2 ... ) AND loadBalancingScheme=EXTERNAL"
     

   • Pour répertorier les services de backend des équilibreurs de charge proxy TCP, exécutez la commande suivante. Les services de backend pour les équilibreurs de charge proxy TCP sont toujours globaux, quel que soit le niveau de service réseau.

     gcloud compute backend-services list \
         --global \
         --filter="loadBalancingScheme=EXTERNAL" \
         --filter="protocol=TCP"
     

   • Pour répertorier les services de backend pour les équilibreurs de charge proxy SSL, exécutez la commande suivante. Les services de backend pour les équilibreurs de charge proxy SSL sont toujours globaux, quel que soit le niveau de service réseau.

     gcloud compute backend-services list \
         --global \
         --filter="loadBalancingScheme=EXTERNAL" \
         --filter="protocol=SSL"
     

   • Pour identifier les services de backend d'un équilibreur de charge HTTP(S) externe, commencez par identifier un mappage d'URL, puis décrivez-le. Les mappages d'URL et les services de backend pour l'équilibreur de charge HTTP(S) externe sont toujours globaux, quel que soit le niveau de service réseau. Remplacez URL_MAP_NAME par le nom du mappage d'URL. Les services de backend utilisés par l'équilibreur de charge sont répertoriés dans la réponse.

     gcloud compute url-maps list \
         --global
     

     gcloud compute url-maps describe URL_MAP_NAME \
         --global
     

   • Pour identifier les services de backend d'un équilibreur de charge HTTP(S) externe régional ou d'un équilibreur de charge HTTP(S) interne, identifiez d'abord un mappage d'URL, puis décrivez-le. Les mappages d'URL et les services de backend pour les équilibreurs de charge HTTP(S) internes sont régionaux. Remplacez REGION_LIST par une liste de régions Google Cloud à interroger, séparées par des virgules. Remplacez URL_MAP_NAME par le nom du mappage d'URL et REGION par sa région. Les services de backend utilisés par l'équilibreur de charge sont répertoriés dans la réponse.

     gcloud compute url-maps list \
         --regions=REGION_LIST
     

     gcloud compute url-maps describe URL_MAP_NAME \
         --region=REGION
     

2. Identifiez une vérification d'état. Consultez la section Répertorier les vérifications d'état.

3. Associez une vérification d'état au service de backend à l'aide de la commande compute backend-services update. Chaque service de backend doit faire référence à une seule vérification d'état. Dans les commandes ci-dessous, remplacez BACKEND_SERVICE_NAME par le nom du service de backend, HEALTH_CHECK_NAME par le nom de la vérification d'état et, si nécessaire, REGION par la région Google Cloud du service de backend, la vérification d'état ou les deux.

   • Pour modifier la vérification d'état d'un équilibreur de charge TCP/UDP interne, sachez que le service de backend d'un équilibreur de charge TCP/UDP interne est régional. Il peut faire référence à une vérification d'état globale ou régionale. L'exemple suivant montre une référence de vérification d'état régionale. Si vous utilisez une vérification d'état globale avec votre équilibreur de charge TCP/UDP interne, indiquez --global-health-checks au lieu de --health-checks-region.

     gcloud compute backend-services update BACKEND_SERVICE_NAME \
         --region=REGION \
         --health-checks=HEALTH_CHECK_NAME \
         --health-checks-region=REGION
     

   • Pour modifier la vérification d'état d'un équilibreur de charge réseau basé sur un service de backend, notez que le service de backend d'un équilibreur de charge réseau est régional. Il peut faire référence à une vérification d'état régionale.

     gcloud compute backend-services update BACKEND_SERVICE_NAME \
         --region=REGION \
         --health-checks=HEALTH_CHECK_NAME \
         --health-checks-region=REGION
     

   • Pour modifier la vérification d'état d'un équilibreur de charge proxy TCP, proxy SSL ou HTTP(S) externe, notez que le service de backend et la vérification de l'état sont globaux. Un équilibreur de charge HTTP(S) externe peut faire référence à plusieurs vérifications d'état s'il fait référence à plusieurs services de backend.

     gcloud compute backend-services update BACKEND_SERVICE_NAME \
         --global \
         --health-checks HEALTH_CHECK_NAME \
         --global-health-checks
     

   • Pour modifier la vérification d'état d'un équilibreur de charge HTTP(S) externe régional ou d'un équilibreur de charge HTTP(S) interne, notez que les services de backend et la vérification d'état sont régionaux. Un équilibreur de charge HTTP(S) interne peut faire référence à plusieurs vérifications d'état s'il fait référence à plusieurs services de backend.

     gcloud compute backend-services update BACKEND_SERVICE_NAME \
         --region=REGION \
         --health-checks=HEALTH_CHECK_NAME \
         --health-checks-region=REGION
     

API

1. Vous pouvez répertorier les services de backend à l'aide de l'appel d'API backendServices.list.

2. Affichez les vérifications d'état.

3. Pour associer une vérification d'état à un service de backend, utilisez l'un des appels d'API suivants :

   • backendServices.update
   • backendServices.patch

Vérifications d'état héritées pour l'équilibrage de charge réseau basé sur un pool cible

Cette section explique comment associer une vérification d'état héritée à un pool cible pour l'équilibrage de charge au niveau du réseau. Cette section suppose que vous avez déjà :

• créé un équilibreur de charge réseau basé sur un pool cible ;
• créé une vérification d'état héritée ;
• configuré les règles de pare-feu pour l'équilibrage de charge réseau.

Pour associer une vérification d'état héritée à un nouvel équilibreur de charge réseau, consultez la page Configurer un équilibreur de charge réseau avec un pool cible. Vous devez associer une vérification d'état héritée à son pool cible lorsque vous créez un équilibreur de charge réseau.

Console

Pour associer une vérification d'état à un équilibreur de charge réseau basé sur un pool cible existant, procédez comme suit :

1. Accédez à la page "Équilibrage de charge" dans Google Cloud Console.
   Accéder à la page Équilibrage de charge
2. Cliquez sur un équilibreur de charge réseau pour en afficher les détails.
3. Cliquez sur Modifier , puis sur Configuration du backend.
4. Sélectionnez une vérification d'état héritée dans le menu Vérification d'état. (Seules les vérifications d'état héritées éligibles sont affichées.)
5. Cliquez sur Mettre à jour.

gcloud

Pour associer une vérification d'état à un équilibreur de charge réseau basé sur un pool cible existant, procédez comme suit :

1. Identifiez le ou les pools cibles. Un équilibreur de charge réseau dispose d'au moins un pool cible et éventuellement d'un pool de sauvegarde secondaire.

   gcloud compute target-pools list
   

2. Identifiez une vérification d'état héritée utilisant le protocole HTTP. Si nécessaire, affichez les vérifications d'état héritées.

3. Associez la vérification d'état héritée aux pools cibles. Dans les commandes suivantes, remplacez TARGET_POOL_NAME par le nom du pool cible, REGION par sa région et LEGACY_CHECK_NAME par le nom de la vérification d'état héritée. La vérification d'état héritée doit utiliser le protocole HTTP.

   • Pour supprimer une vérification d'état héritée HTTP d'un pool cible, exécutez la commande suivante :

     gcloud compute target-pools remove-health-checks TARGET_POOL_NAME \
         --region=REGION \
         --http-health-check LEGACY_CHECK_NAME
     

   • Pour ajouter une vérification d'état héritée à un pool cible, exécutez la commande suivante :

     gcloud compute target-pools add-health-checks TARGET_POOL_NAME \
         --region=REGION \
         --http-health-check LEGACY_CHECK_NAME
     

API

1. Vous pouvez répertorier les pools cibles à l'aide de l'appel d'API targetPools.list.

2. Affichez les vérifications d'état héritées, puis identifiez-en une qui utilise le protocole HTTP.

3. Pour associer une vérification d'état héritée HTTP à un pool cible, utilisez l'appel d'API targetPools.addHealthCheck.

Vérifier l'état de la vérification d'état

Une fois que vous avez associé une vérification d'état à un service de backend ou à un pool cible, vous pouvez obtenir l'état instantané de la vérification de l'état des backends associés à l'équilibreur de charge.

Console

1. Accédez à la page de résumé de l'équilibrage de charge.
   Accéder à la page "Équilibrage de charge"
2. Cliquez sur le nom d'un équilibreur de charge.
3. Sous Backend, examinez la colonne Opérationnel. L'état de fonctionnement y apparaît pour chaque groupe d'instances backend ou groupe de points de terminaison du réseau.

gcloud

• Pour tous les équilibreurs de charge, à l'exception des équilibreurs de charge réseau basés sur un pool cible, identifiez le nom et le champ d'application du service de backend. Les équilibreurs de charge réseau basés sur un service de backend, les équilibreurs de charge TCP/UDP internes, les équilibreurs de charge HTTP(S) externes régionaux et les équilibreurs de charge HTTP(S) internes utilisent des services de backend régionaux. L'équilibreur de charge proxy TCP, l'équilibreur de charge proxy SSL et l'équilibreur de charge HTTP(S) externe utilisent des services de backend globaux.

  Exécutez la commande compute backend-services get-health en remplaçant NAME par le nom du service de backend et, si nécessaire, REGION par sa région.

  • Pour obtenir l'état de fonctionnement instantané d'un service de backend global, procédez comme suit :

    gcloud compute backend-services get-health NAME \
        --global
    

  • Pour obtenir l'état de fonctionnement instantané d'un service de backend régional, procédez comme suit :

    gcloud compute backend-services get-health NAME \
        --region=REGION
    

• Pour les équilibreurs de charge réseau basés sur un pool cible, identifiez le nom et la région du pool cible de l'équilibreur de charge, puis utilisez la commande compute target-pools get-health, en remplaçantNAME par le nom du pool cible et REGION par sa région.

  gcloud compute target-pools get-health NAME \
      --region=REGION
  

API

• Pour tous les équilibreurs de charge, à l'exception des équilibreurs de charge réseau basés sur un pool cible, identifiez le nom et le champ d'application du service de backend. Les équilibreurs de charge réseau basés sur un service de backend, les équilibreurs de charge TCP/UDP internes, les équilibreurs de charge HTTP(S) externes régionaux et les équilibreurs de charge HTTP(S) internes utilisent des services de backend régionaux. L'équilibreur de charge proxy TCP, l'équilibreur de charge proxy SSL et l'équilibreur de charge HTTP(S) externe utilisent des services de backend globaux.

  • Pour obtenir l'état de fonctionnement instantané d'un service de backend global, utilisez la méthode backendServices.getHealth.

  • Pour obtenir l'état de fonctionnement instantané d'un service de backend régional, utilisez la méthode regionBackendServices.getHealth.

• Pour les équilibreurs de charge réseau basés sur un pool cible, utilisez targetPools.getHealth.