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
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
- Accédez à la page "Vérifications d'état" dans Google Cloud Console.
Accéder à la page "Vérifications d'état" - 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 etREGION
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.
Console
- Accédez à la page "Vérifications d'état" dans Google Cloud Console.
Accéder à la page "Vérifications d'état" - Cliquez sur Créer une vérification d'état.
- 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.
- 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 sontgrpc
,http
,https
,http2
,ssl
ettcp
.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 valeur5s
(cinq secondes).TIMEOUT
est la durée pendant laquelle Google Cloud attend une réponse à une vérification. La valeur deTIMEOUT
doit être inférieure ou égale à celle deCHECK_INTERVAL
. Cette valeur est exprimée en secondes. En cas d'omission, Google Cloud utilise la valeur5s
(cinq secondes).HEALTHY_THRESHOLD
etUNHEALTHY_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 sur2
.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 protocolePROTOCOL
. 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
- Accédez à la page "Vérifications d'état" dans Google Cloud Console.
Accéder à la page "Vérifications d'état" - Cliquez sur une vérification d'état pour en afficher les détails.
- 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
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.
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éehc-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
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.
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
ouHTTP
, il utilise--port=80
. - Si le protocole de la vérification d'état est
SSL
,HTTPS
ouHTTP2
, 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 valeurhttp
(HTTP/1.1 sans TLS),https
(HTTP/1.1 avec TLS) ouhttp2
(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 HTTPHost
. 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 surNONE
ouPROXY_V1
. En cas d'omission, Google Cloud utiliseNONE
. La valeurPROXY_V1
ajoute l'en-têtePROXY 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) oussl
. 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 surNONE
ouPROXY_V1
. En cas d'omission, Google Cloud utiliseNONE
. La valeurPROXY_V1
ajoute l'en-têtePROXY 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 diffusionSERVING
MyPackage.ServiceB
avec l'état de diffusionNOT_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
.
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.
Répertorier les vérifications d'état héritées
Console
- Accédez à la page "Vérifications d'état" dans Google Cloud Console.
Accéder à la page "Vérifications d'état" - Cliquez sur une vérification d'état héritée pour en afficher les détails.
gcloud
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
Pour décrire une vérification d'état héritée HTTP, utilisez la commande
compute http-health-checks describe
en remplaçantNAME
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çantNAME
par son nom.gcloud compute https-health-checks describe NAME
API
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.
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 utiliserhttp-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 valeur5s
(cinq secondes).TIMEOUT
est la durée pendant laquelle Google Cloud attend une réponse à une vérification. La valeur deTIMEOUT
doit être inférieure ou égale à celle deCHECK_INTERVAL
. Cette valeur est exprimée en secondes. En cas d'omission, Google Cloud utilise la valeur5s
(cinq secondes).HEALTHY_THRESHOLD
etUNHEALTHY_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 sur2
.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 utilise80
.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
- Accédez à la page "Vérifications d'état" dans Google Cloud Console.
Accéder à la page "Vérifications d'état" - Cliquez sur une vérification d'état pour en afficher les détails.
- 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çantNAME
par son nom. Lorsque vous modifiez une vérification d'état héritée avecgcloud
, 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çantNAME
par son nom. Lorsque vous modifiez une vérification d'état héritée avecgcloud
, 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
- Accédez à la page "Pare-feu" de Google Cloud Console.
Accéder à la page Pare-feu - Cliquez sur Créer une règle de pare-feu.
- 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).
- Nom : attribuez un nom à la règle. Pour cet exemple, utilisez
- 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
Exécutez la commande
gcloud
suivante pour créer une règle de pare-feu nomméefw-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 tagallow-health-checks
. RemplacezNETWORK_NAME
par le nom de votre réseau VPC etPORT
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
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.
Console
- Accédez à la page "Pare-feu" de Google Cloud Console.
Accéder à la page Pare-feu - Cliquez sur Créer une règle de pare-feu.
- 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.
- Nom : attribuez un nom à la règle. Pour cet exemple, utilisez
- 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
Exécutez la commande
gcloud
suivante pour créer une règle de pare-feu nomméefw-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 tagallow-network-lb-health-checks
. RemplacezNETWORK_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
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
ouUDP
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 :
- Accédez à la page "Équilibrage de charge" dans Google Cloud Console.
Accéder à la page Équilibrage de charge - Cliquez sur un équilibreur de charge pour en afficher les détails.
- Cliquez sur Modifier , puis sur Configuration du backend.
- Sélectionnez une vérification d'état dans le menu Vérification d'état.
- Cliquez sur Mettre à jour.
gcloud
Pour associer une vérification d'état à un service de backend existant, procédez comme suit.
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. RemplacezURL_MAP_NAME
par le nom du mappage d'URL etREGION
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
Identifiez une vérification d'état. Consultez la section Répertorier les vérifications d'état.
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, remplacezBACKEND_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
Vous pouvez répertorier les services de backend à l'aide de l'appel d'API backendServices.list.
Pour associer une vérification d'état à un service de backend, utilisez l'un des appels d'API suivants :
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 :
- Accédez à la page "Équilibrage de charge" dans Google Cloud Console.
Accéder à la page Équilibrage de charge - Cliquez sur un équilibreur de charge réseau pour en afficher les détails.
- Cliquez sur Modifier , puis sur Configuration du backend.
- 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.)
- 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 :
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
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.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 etLEGACY_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
Vous pouvez répertorier les pools cibles à l'aide de l'appel d'API targetPools.list.
Affichez les vérifications d'état héritées, puis identifiez-en une qui utilise le protocole HTTP.
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
- Accédez à la page de résumé de l'équilibrage de charge.
Accéder à la page "Équilibrage de charge" - Cliquez sur le nom d'un équilibreur de charge.
- 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çantNAME
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 etREGION
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.