État composite pour Private Service Connect

1. Introduction

Cet atelier de programmation explore la vérification d'état composite pour Private Service Connect (PSC) pour le basculement régional automatique. La fonctionnalité d'état de santé composite pour PSC est une fonctionnalité de mise en réseau qui améliore la résilience et la disponibilité des services.

L'état de santé composite permet aux producteurs de services de définir des règles d'état de santé personnalisées (l'état qui définit un service sain ou non sain) et de propager automatiquement ces signaux aux clients de services qui se connectent au service avec des backends PSC. Cette fonctionnalité est spécifiquement conçue pour prendre en charge le basculement interrégional automatique. Si un service de producteur régional n'est plus opérationnel, l'équilibreur de charge du consommateur arrête automatiquement de router le trafic vers cette région et le dirige vers un service opérationnel dans une autre région.

Par rapport aux méthodes précédentes de basculement interrégional, comme la détection des valeurs aberrantes, l'état composite offre un signal de basculement plus précis, car il est basé directement sur l'état agrégé des backends de service du producteur (groupes d'instances de VM ou points de terminaison réseau). Les producteurs peuvent définir leur propre logique d'état, ce qui garantit qu'ils ne reçoivent du trafic que lorsque le service répond réellement aux critères d'état nécessaires.

Objectifs

  • Composants de l'état de fonctionnement composite et leur fonctionnement pour déterminer l'état de fonctionnement d'un service de producteur
  • Implémenter l'état de santé composite pour PSC pour un service de production à l'aide des commandes gcloud
  • Configuration d'un équilibreur de charge d'accès consommateur PSC interrégional pour utiliser les signaux d'état de la stratégie d'état composite du producteur
  • Tester les scénarios de défaillance de service et valider le basculement interrégional automatique

Ce dont vous avez besoin

  • Un projet Google Cloud
  • Autorisations IAM accordées au rôle prédéfini roles/compute.admin ou à un rôle de base étendu tel que roles/admin ou l'ancien rôle roles/owner
  • Bonne connaissance des concepts de mise en réseau Google Cloud et de l'utilisation de Google Cloud CLI

2. Concepts

Mise en réseau PSC

La topologie du réseau de cet atelier de programmation inclut un réseau VPC consommateur et un réseau VPC producteur dans deux régions Google Cloud actives.

Le côté consommateur comporte des sous-réseaux régionaux avec des instances de VM clientes utilisées pour accéder au service du producteur via un équilibreur de charge d'application interne interrégional avec des backends de groupe de points de terminaison réseau (NEG) PSC. Il existe deux règles de transfert d'équilibreur de charge régional, avec des adresses IP régionales, pour l'entrée des clients globaux (multirégionaux). Le service de backend est une ressource globale qui accepte les NEG dans différentes régions. En cas de basculement, un client se connectant à l'une ou l'autre des règles de transfert d'interface régionale peut être redirigé vers un backend global opérationnel.

figure1

Fig. 1. Topologie du réseau de l'atelier de programmation

Du côté du producteur, des sous-réseaux régionaux avec des équilibreurs de charge réseau passthrough internes régionaux exposent un service via une ressource de rattachement de service PSC régional. Les services de backend contiennent des groupes d'instances gérés (MIG) régionaux et sont vérifiés en sondant les requêtes http et en validant les réponses 200 (OK).

Consultez la dernière documentation sur la compatibilité de Private Service Connect pour la configuration du producteur afin de savoir quels équilibreurs de charge sont compatibles avec l'état de santé composite pour PSC.

État du service

La vérification de l'état du service de backend du producteur, configurée lors de la création de l'équilibreur de charge, sert de signal d'origine pour la fonctionnalité État de fonctionnement composite pour PSC. La ressource source d'état utilise ce signal ainsi que des contraintes supplémentaires définies dans la ressource règle d'agrégation des états pour déterminer un état de fonctionnement pour un seul service de backend.

Par défaut, un service est considéré comme opérationnel lorsque les deux contraintes suivantes sont remplies :

  • Un minimum de x % des backends sont opérationnels (valeur par défaut : 60).
  • Un nombre minimal de backends (y) doit être opérationnel (valeur par défaut : 1).

La vérification de l'état composite fait référence à toutes les sources d'état de tous les services de backend pour déterminer l'état général de l'ensemble du service de producteur régional. Dans le cas de cet atelier, chaque service de producteur régional ne comporte qu'une seule source d'état de service de backend qui est agrégée dans une seule vérification de l'état composite.

figure2

Fig. 2. État composite pour le modèle de ressources PSC

La définition de ressource de vérification d'état composite fait également référence à la règle de transfert de l'équilibreur de charge du service producteur. Le NEG PSC de backend de l'équilibreur de charge d'accès client est logiquement connecté au rattachement de service PSC du producteur et à la règle de transfert de l'équilibreur de charge du producteur. Cela associe l'équilibreur de charge d'accès au consommateur à l'état de la vérification de l'état composite du service du producteur. L'état de santé global du service de producteur régional est ensuite propagé à l'équilibreur de charge du consommateur pour sélectionner le backend approprié.

3. Configuration du projet

Accéder à votre projet

Cet atelier de programmation est conçu pour utiliser un seul projet Google Cloud. Les étapes de configuration utilisent gcloud et des commandes shell Linux.

REMARQUE : Dans un déploiement en production, les ressources clientes et les services producteurs de PSC se trouvent généralement dans des projets différents.

Commencez par accéder à la ligne de commande de votre projet Google Cloud en utilisant :

Définir votre ID de projet

gcloud config set project YOUR_PROJECT_ID_HERE

Définir des variables d'environnement de shell

export PROJECT_ID=$(gcloud config list --format="value(core.project)")
export REGION_1="us-west1"
export ZONE_1="us-west1-c"
export REGION_2="us-east1"
export ZONE_2="us-east1-c"
echo ${PROJECT_ID}
echo ${REGION_1}
echo ${ZONE_1}
echo ${REGION_2}
echo ${ZONE_2}

Activer les services d'API

gcloud services enable compute.googleapis.com
gcloud services enable dns.googleapis.com

4. Service producteur

Créer des ressources partagées

Créer un réseau

gcloud compute networks create vnet-producer --subnet-mode=custom

Créer des sous-réseaux

# create subnet for service workload in region 1
gcloud compute networks subnets create subnet-foo \
  --network=vnet-producer \
  --region=${REGION_1} \
  --range=172.16.1.0/24 \
  --enable-private-ip-google-access

# create subnet for psc nat in region 1
gcloud compute networks subnets create subnet-foo-pscnat \
  --network=vnet-producer \
  --region=${REGION_1} \
  --range=192.168.1.0/29 \
  --purpose=PRIVATE_SERVICE_CONNECT

# create subnet for service workload in region 2
gcloud compute networks subnets create subnet-bar \
  --network=vnet-producer \
  --region=${REGION_2} \
  --range=172.16.2.0/24 \
  --enable-private-ip-google-access

# create subnet for psc nat in region 2
gcloud compute networks subnets create subnet-bar-pscnat \
  --network=vnet-producer \
  --region=${REGION_2} \
  --range=192.168.2.0/29 \
  --purpose=PRIVATE_SERVICE_CONNECT

Créer des composants de pare-feu

Des règles de pare-feu sont nécessaires pour autoriser le trafic vers les ressources de VM (les règles de pare-feu par défaut implicites sont de refuser l'entrée et d'autoriser la sortie). Les stratégies sont la méthode privilégiée pour déployer des règles de pare-feu. Pour ce faire, vous devez créer une ressource de stratégie de pare-feu réseau, créer et ajouter des règles à la stratégie, puis associer la stratégie à un réseau VPC.

# create fw policy
gcloud compute network-firewall-policies create fw-policy-producer --global

# create fw policy rules
gcloud compute network-firewall-policies rules create 1001 \
  --description="allow iap for ssh" \
  --firewall-policy=fw-policy-producer \
  --global-firewall-policy \
  --action=allow \
  --direction=INGRESS \
  --layer4-configs=tcp:22  \
  --src-ip-ranges=35.235.240.0/20

gcloud compute network-firewall-policies rules create 1002 \
  --description="allow health checks" \
  --firewall-policy=fw-policy-producer \
  --global-firewall-policy \
  --action=allow \
  --direction=INGRESS \
  --layer4-configs=tcp,udp,icmp  \
  --src-ip-ranges=130.211.0.0/22,35.191.0.0/16

gcloud compute network-firewall-policies rules create 1003 \
  --description="allow psc nat clients" \
  --firewall-policy=fw-policy-producer \
  --global-firewall-policy \
  --action=allow \
  --direction=INGRESS \
  --layer4-configs=tcp:80  \
  --src-ip-ranges=192.168.1.0/29,192.168.2.0/29

# associate fw policy to vnet
gcloud compute network-firewall-policies associations create \
  --firewall-policy=fw-policy-producer \
  --network=vnet-producer \
  --name=fw-policy-association-producer \
  --global-firewall-policy

Créer des routeurs Cloud et des passerelles NAT

# create routers for nat in each region
gcloud compute routers create cr-nat-foo \
  --network=vnet-producer \
  --asn=16550 \
  --region=${REGION_1}

gcloud compute routers create cr-nat-bar \
  --network=vnet-producer \
  --asn=16550 \
  --region=${REGION_2}

# create nat gateways in each region
gcloud compute routers nats create natgw-foo \
  --router=cr-nat-foo \
  --region=${REGION_1} \
  --auto-allocate-nat-external-ips \
  --nat-all-subnet-ip-ranges

gcloud compute routers nats create natgw-bar \
  --router=cr-nat-bar \
  --region=${REGION_2} \
  --auto-allocate-nat-external-ips \
  --nat-all-subnet-ip-ranges

Créer une configuration de démarrage de VM avec un serveur HTTP

cat > vm-server-startup.sh << 'EOF'
#! /bin/bash
apt-get update
apt-get install apache2 -y
vm_hostname="$(curl -H "Metadata-Flavor:Google" \
http://169.254.169.254/computeMetadata/v1/instance/name)"
vm_zone="$(curl -H "Metadata-Flavor:Google" \
http://169.254.169.254/computeMetadata/v1/instance/zone)"
echo "Page served from: $vm_hostname in zone $vm_zone" | \
tee /var/www/html/index.html
systemctl restart apache2
EOF

Configurer le service foo dans la région 1

Créer un service de calcul

# create managed instance group template
gcloud compute instance-templates create mig-template-foo \
  --machine-type=e2-micro \
  --network=vnet-producer \
  --region=${REGION_1} \
  --subnet=subnet-foo \
  --no-address \
  --shielded-secure-boot \
  --metadata-from-file=startup-script=vm-server-startup.sh

# create regional managed instance group
gcloud compute instance-groups managed create mig-foo \
  --region=${REGION_1} \
  --size=2 \
  --template=mig-template-foo \
  --base-instance-name=service-foo

Créer des composants d'équilibreur de charge de service

# create lb health check
gcloud compute health-checks create http hc-foo-http \
  --region=${REGION_1} \
  --port=80 \
  --enable-logging

# create backend service
gcloud compute backend-services create ilb-foo \
  --load-balancing-scheme=INTERNAL \
  --protocol=tcp \
  --region=${REGION_1} \
  --health-checks=hc-foo-http \
  --health-checks-region=${REGION_1}

# add managed instance group to backend service
gcloud compute backend-services add-backend ilb-foo \
  --instance-group=mig-foo \
  --instance-group-region=${REGION_1} \
  --region=${REGION_1}

# create forwarding rule
gcloud compute forwarding-rules create fr-foo \
  --region=${REGION_1} \
  --load-balancing-scheme=INTERNAL \
  --network=vnet-producer \
  --subnet=subnet-foo \
  --address=172.16.1.99 \
  --ip-protocol=TCP \
  --ports=80 \
  --backend-service=ilb-foo \
  --backend-service-region=${REGION_1} \
  --allow-global-access

Publier un service PSC

# create psc service attachment
gcloud compute service-attachments create psc-sa-foo \
  --region=${REGION_1} \
  --target-service=projects/${PROJECT_ID}/regions/${REGION_1}/forwardingRules/fr-foo \
  --connection-preference=ACCEPT_AUTOMATIC \
  --nat-subnets=subnet-foo-pscnat

Configurer le service bar dans la région 2

Créer un service de calcul

# create managed instance group template
gcloud compute instance-templates create mig-template-bar \
  --machine-type=e2-micro \
  --network=vnet-producer \
  --region=${REGION_2} \
  --subnet=subnet-bar \
  --no-address \
  --shielded-secure-boot \
  --metadata-from-file=startup-script=vm-server-startup.sh

# create regional managed instance group
gcloud compute instance-groups managed create mig-bar \
  --region=${REGION_2} \
  --size=2 \
  --template=mig-template-bar \
  --base-instance-name=service-bar

Créer des composants d'équilibreur de charge de service

# create lb health check
gcloud compute health-checks create http hc-bar-http \
  --region=${REGION_2} \
  --port=80 \
  --enable-logging

# create backend service
gcloud compute backend-services create ilb-bar \
  --load-balancing-scheme=INTERNAL \
  --protocol=tcp \
  --region=${REGION_2} \
  --health-checks=hc-bar-http \
  --health-checks-region=${REGION_2}

# add managed instance group to backend service
gcloud compute backend-services add-backend ilb-bar \
  --instance-group=mig-bar \
  --instance-group-region=${REGION_2} \
  --region=${REGION_2}

# create forwarding rule
gcloud compute forwarding-rules create fr-bar \
  --region=${REGION_2} \
  --load-balancing-scheme=INTERNAL \
  --network=vnet-producer \
  --subnet=subnet-bar \
  --address=172.16.2.99 \
  --ip-protocol=TCP \
  --ports=80 \
  --backend-service=ilb-bar \
  --backend-service-region=${REGION_2} \
  --allow-global-access

Publier un service PSC

# create psc service attachment
gcloud compute service-attachments create psc-sa-bar \
  --region=${REGION_2} \
  --target-service=projects/${PROJECT_ID}/regions/${REGION_2}/forwardingRules/fr-bar \
  --connection-preference=ACCEPT_AUTOMATIC \
  --nat-subnets=subnet-bar-pscnat

5. Accès des consommateurs

Configurer les ressources client

Créer des composants réseau

# create vpc network
gcloud compute networks create vnet-consumer --subnet-mode=custom

# create client subnet in each region
gcloud compute networks subnets create subnet-client-1 \
  --network=vnet-consumer \
  --region=${REGION_1} \
  --range=10.10.1.0/24 \
  --enable-private-ip-google-access

gcloud compute networks subnets create subnet-client-2 \
  --network=vnet-consumer \
  --region=${REGION_2} \
  --range=10.10.2.0/24 \
  --enable-private-ip-google-access

L'équilibreur de charge d'application (basé sur un proxy) du consommateur nécessite des sous-réseaux proxy réservés. Ces sous-réseaux fournissent un pool d'adresses IP utilisées par les équilibreurs de charge basés sur un proxy comme adresses sources internes lors de l'envoi de trafic aux backends.

# create proxy subnet in each region
gcloud compute networks subnets create subnet-proxy-1 \
  --purpose=GLOBAL_MANAGED_PROXY \
  --role=ACTIVE \
  --network=vnet-consumer \
  --region=${REGION_1} \
  --range=10.10.128.0/23

gcloud compute networks subnets create subnet-proxy-2 \
  --purpose=GLOBAL_MANAGED_PROXY \
  --role=ACTIVE \
  --network=vnet-consumer \
  --region=${REGION_2} \
  --range=10.10.130.0/23

Créer des composants de pare-feu

# create fw policy
gcloud compute network-firewall-policies create fw-policy-consumer --global

# create fw policy rules
gcloud compute network-firewall-policies rules create 1001 \
  --description="allow iap for ssh" \
  --firewall-policy=fw-policy-consumer \
  --global-firewall-policy \
  --action=allow \
  --direction=INGRESS \
  --layer4-configs=tcp:22  \
  --src-ip-ranges=35.235.240.0/20

# associate fw policy to vnet
gcloud compute network-firewall-policies associations create \
  --firewall-policy=fw-policy-consumer \
  --network=vnet-consumer \
  --name=fw-policy-association-consumer \
  --global-firewall-policy

Créer des composants pour l'équilibreur de charge

# create psc network endpoint group per region
gcloud compute network-endpoint-groups create neg-foo \
  --network-endpoint-type=private-service-connect \
  --psc-target-service=projects/${PROJECT_ID}/regions/${REGION_1}/serviceAttachments/psc-sa-foo \
  --region=${REGION_1} \
  --network=vnet-consumer \
  --subnet=subnet-client-1

gcloud compute network-endpoint-groups create neg-bar \
  --network-endpoint-type=private-service-connect \
  --psc-target-service=projects/${PROJECT_ID}/regions/${REGION_2}/serviceAttachments/psc-sa-bar \
  --region=${REGION_2} \
  --network=vnet-consumer \
  --subnet=subnet-client-2

# verify psc connections
gcloud compute network-endpoint-groups list --format="value(selfLink, pscData.pscConnectionStatus)"

# create global backend service
gcloud compute backend-services create bes-foobar \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --protocol=HTTP \
  --global

# add negs to backend service
gcloud compute backend-services add-backend bes-foobar \
  --network-endpoint-group=neg-foo \
  --network-endpoint-group-region=${REGION_1} \
  --global

gcloud compute backend-services add-backend bes-foobar \
  --network-endpoint-group=neg-bar \
  --network-endpoint-group-region=${REGION_2} \
  --global

# create global url map
gcloud compute url-maps create ilb-foobar \
  --default-service=bes-foobar \
  --global

# create global target proxy
gcloud compute target-http-proxies create proxy-foobar \
  --url-map=ilb-foobar \
  --global

# create global forwarding rule for region 1
gcloud compute forwarding-rules create fr-foobar-1 \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=vnet-consumer \
  --subnet=subnet-client-1 \
  --subnet-region=${REGION_1} \
  --address=10.10.1.99 \
  --ports=80 \
  --target-http-proxy=proxy-foobar \
  --global

# create global forwarding rule for region 2
gcloud compute forwarding-rules create fr-foobar-2 \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=vnet-consumer \
  --subnet=subnet-client-2 \
  --subnet-region=${REGION_2} \
  --address=10.10.2.99 \
  --ports=80 \
  --target-http-proxy=proxy-foobar \
  --global

Créer des enregistrements DNS

# create dns zone
gcloud dns managed-zones create zone-foobar \
  --description="private zone for foobar" \
  --dns-name=foobar.com \
  --networks=vnet-consumer \
  --visibility=private

# create geo dns record
gcloud dns record-sets create www.foobar.com \
  --zone=zone-foobar \
  --type=A \
  --ttl=300 \
  --routing-policy-type=GEO \
  --routing-policy-item="location=${REGION_1},rrdatas=10.10.1.99" \
  --routing-policy-item="location=${REGION_2},rrdatas=10.10.2.99"

Créer des ressources de calcul

# create client vm in region 1
gcloud compute instances create client-1 \
  --machine-type=e2-micro \
  --zone=${ZONE_1} \
  --subnet=subnet-client-1 \
  --no-address \
  --shielded-secure-boot

# create client vm in region 2
gcloud compute instances create client-2 \
  --machine-type=e2-micro \
  --zone=${ZONE_2} \
  --subnet=subnet-client-2 \
  --no-address \
  --shielded-secure-boot

Tester le niveau de référence du service

Depuis la VM cliente de la région 1

# send request from vm to service using hostname
gcloud compute ssh client-1 --zone=${ZONE_1} --command='
  curl -s -v www.foobar.com'

# send request from vm to load balancer forwarding rule region 1
gcloud compute ssh client-1 --zone=${ZONE_1} --command='
  curl -s 10.10.1.99'

# send request from vm to load balancer forwarding rule region 2
gcloud compute ssh client-1 --zone=${ZONE_1} --command='
  curl -s 10.10.2.99'

Facultatif : Effectuez les mêmes tests à partir de la VM cliente dans la région 2 : gcloud compute ssh client-2 --zone=${ZONE_2}

POINT CLÉ : Le comportement normal de l'équilibreur de charge pour les requêtes client entrant dans une règle de transfert dans region-x est de privilégier les backends du même region-x. Si toutes les ressources de backend sont opérationnelles, la région avec la latence la plus faible l'emporte. Les backends mondiaux basculeront vers l'autre région avec le signal d'état approprié.

Toutefois, comme les ressources de service producteur réelles se trouvent derrière l'équilibreur de charge producteur dans le réseau VPC producteur, ces signaux d'état étaient auparavant opaques pour l'équilibreur de charge consommateur. Par conséquent, le côté consommateur n'était pas en mesure de déterminer si un basculement du backend était nécessaire. L'état de santé du PSC résout ce problème en propageant les informations sur l'état de santé du service du côté du producteur vers le côté du consommateur.

6. Ressources sur la santé

L'état de santé composite des ressources PSC est configuré par le producteur pour représenter l'état de santé global du service régional. La règle d'état de santé est basée sur ce que le producteur du service définit comme approprié pour maintenir un niveau de service fonctionnel. Des seuils sont définis pour avertir les consommateurs de basculer lorsque les conditions définies par le producteur ne sont plus remplies.

Configurer l'état du service foo dans la région 1

Créer une règle d'agrégation des données d'état

gcloud compute health-aggregation-policies create foo-health-policy \
  --region=${REGION_1} \
  --healthy-percent-threshold=60 \
  --min-healthy-threshold=1

Créer une source de données de santé

gcloud compute health-sources create foo-health-source \
  --region=${REGION_1} \
  --source-type=BACKEND_SERVICE \
  --sources=ilb-foo \
  --health-aggregation-policy=foo-health-policy

Créer une vérification d'état composite

gcloud compute composite-health-checks create foo-health-composite \
  --region=${REGION_1} \
  --health-sources=foo-health-source \
  --health-destination=projects/${PROJECT_ID}/regions/${REGION_1}/forwardingRules/fr-foo

Vérifier la configuration de l'état du service foo

Les configurations des ressources d'état peuvent être consultées avec les commandes list (et describe) par région.

# show health aggregation policies
gcloud compute health-aggregation-policies list --regions=${REGION_1}

# show health sources
gcloud compute health-sources list --regions=${REGION_1}

# show composite health checks
gcloud compute composite-health-checks list --regions=${REGION_1}

Configurer l'état du service bar dans la région 2

Créer une règle d'agrégation des données d'état

gcloud compute health-aggregation-policies create bar-health-policy \
  --region=${REGION_2} \
  --healthy-percent-threshold=60 \
  --min-healthy-threshold=1

Créer une source de données de santé

gcloud compute health-sources create bar-health-source \
  --region=${REGION_2} \
  --source-type=BACKEND_SERVICE \
  --sources=ilb-bar \
  --health-aggregation-policy=bar-health-policy

Créer une vérification d'état composite

gcloud compute composite-health-checks create bar-health-composite \
  --region=${REGION_2} \
  --health-sources=bar-health-source \
  --health-destination=projects/${PROJECT_ID}/regions/${REGION_2}/forwardingRules/fr-bar

Vérifier la configuration de l'état du service bar

# show health aggregation policies
gcloud compute health-aggregation-policies list --regions=${REGION_2}

# show health sources
gcloud compute health-sources list --regions=${REGION_2}

# show composite health checks
gcloud compute composite-health-checks list --regions=${REGION_2}

La partie configuration est terminée. Passons aux tests.

7. Test de basculement

Scénario de service foo région 1 non opérationnel

Ce scénario simule une défaillance du service de producteur PSC foo dans la région 1 en arrêtant le serveur Web sur l'une des deux instances de VM.

Obtenir les détails d'une VM serveur

# set env var for a foo service vm name
export FOO_FAIL_NAME=$(gcloud compute instance-groups managed list-instances mig-foo \
  --limit=1 \
  --region=${REGION_1} \
  --format="value(name)")
echo ${FOO_FAIL_NAME}

# set env var for a foo service zone
export FOO_FAIL_ZONE=$(gcloud compute instance-groups managed list-instances mig-foo \
  --limit=1 \
  --region=${REGION_1} \
  --format="value(ZONE)")
echo ${FOO_FAIL_ZONE}

Arrêter le serveur http de la région 1

# stop apache http server to fail service
gcloud compute ssh ${FOO_FAIL_NAME} --zone=${FOO_FAIL_ZONE} --command='
  sudo systemctl stop apache2'

# verify service dead
gcloud compute ssh ${FOO_FAIL_NAME} --zone=${FOO_FAIL_ZONE} --command='
  sudo systemctl status apache2 | grep Active:'

Vérifier que le service régional n'est pas opérationnel

# check health state of backend service
gcloud compute backend-services get-health ilb-foo --region=${REGION_1}

Le résultat devrait ressembler à ceci :

backend: .../regions/us-west1/instanceGroups/mig-foo
status:
  healthStatus:
  -   forwardingRule: .../regions/us-west1/forwardingRules/fr-foo
    forwardingRuleIp: 172.16.1.99
    healthState: UNHEALTHY
    instance: .../zones/us-west1-a/instances/service-foo-<UID_1>
    ipAddress: 172.16.1.2
    port: 80
  -   forwardingRule: .../regions/us-west1/forwardingRules/fr-foo
    forwardingRuleIp: 172.16.1.99
    healthState: HEALTHY
    instance: .../zones/us-west1-b/instances/service-foo-<UID_2>
    ipAddress: 172.16.1.3
    port: 80
  kind: compute#backendServiceGroupHealth

# check health state of health source
gcloud compute health-sources get-health foo-health-source --region=${REGION_1}

Le résultat devrait ressembler à ceci :

healthState: UNHEALTHY
kind: compute#healthSourceHealth
sources:
- backends:
  - endpointCount: 1
    group: .../zones/us-west1-a/instanceGroups/mig-foo
    healthyEndpointCount: 0
  - endpointCount: 0
    group: .../zones/us-west1-c/instanceGroups/mig-foo
    healthyEndpointCount: 0
  - endpointCount: 1
    group: .../zones/us-west1-b/instanceGroups/mig-foo
    healthyEndpointCount: 1
  forwardingRule: .../regions/us-west1/forwardingRules/fr-foo
  source: .../regions/us-west1/backendServices/ilb-foo

Tester le basculement du client de la région 1

# send request to service using hostname
gcloud compute ssh client-1 --zone=${ZONE_1} --command='
  curl -s -v www.foobar.com'

# curl to ilb vip in region 1
gcloud compute ssh client-1 --zone=${ZONE_1} --command='
  curl -s 10.10.1.99'

# curl to ilb vip in region 2
gcloud compute ssh client-1 --zone=${ZONE_1} --command='
  curl -s 10.10.2.99'

L'état de santé composite pour PSC a mis à jour l'équilibreur de charge du consommateur et lui a demandé d'éviter le service de backend non opérationnel dans la région 1. Il a plutôt redirigé le trafic vers le service opérationnel bar dans la région 2.

Redémarrer le serveur http de la région 1

# start apache http server to return service to healthy
gcloud compute ssh ${FOO_FAIL_NAME} --zone=${FOO_FAIL_ZONE} --command='
  sudo systemctl start apache2'

# verify service running
gcloud compute ssh ${FOO_FAIL_NAME} --zone=${FOO_FAIL_ZONE} --command='
  sudo systemctl status apache2 | grep Active:'

# check health state of health source
gcloud compute health-sources get-health foo-health-source --region=${REGION_1}

Le résultat doit maintenant indiquer un état HEALTHY semblable à celui-ci :

healthState: HEALTHY
kind: compute#healthSourceHealth
sources:
- backends:
  - endpointCount: 1
    group: .../zones/us-west1-a/instanceGroups/mig-foo
    healthyEndpointCount: 1
  - endpointCount: 0
    group: .../zones/us-west1-c/instanceGroups/mig-foo
    healthyEndpointCount: 0
  - endpointCount: 1
    group: .../zones/us-west1-b/instanceGroups/mig-foo
    healthyEndpointCount: 1
  forwardingRule: .../regions/us-west1/forwardingRules/fr-foo
  source: .../regions/us-west1/backendServices/ilb-foo

Modifier la règle d'état

Les producteurs peuvent ajuster les règles relatives à l'état des services en fonction de différents critères. La ressource Règle d'agrégation des états spécifie les seuils minimaux nécessaires pour maintenir un état opérationnel dans toutes les sources de données d'état (services de backend).

Mettre à jour la règle d'agrégation des données d'état du service bar

gcloud compute health-aggregation-policies update bar-health-policy \
  --region=${REGION_2} \
  --description="min 40% threshold" \
  --healthy-percent-threshold=40 \
  --min-healthy-threshold=2

# verify new policy is applied
gcloud compute health-aggregation-policies list --regions=${REGION_2}

Cette modification du règlement sur l'état de santé des producteurs permet d'accomplir les actions suivantes :

  1. Le seuil minimal de VM opérationnelles passe de 60% à 40 %. Désormais, une seule instance de VM en échec ne déclenchera pas un état non opérationnel basé sur --healthy-percent-threshold (l'état d'échec sera de 50% et il ne faudra que 40% pour être opérationnel).
  2. Le nombre minimal de backends opérationnels passe de 1 à 2 instances de VM. Désormais, une seule instance de VM défaillante déclenchera un état non opérationnel basé sur --min-healthy-threshold (l'état d'échec sera de 1, mais il faut 2 pour que l'état soit opérationnel).

Scénario de service bar non opérationnel dans la région 2

Ce scénario simule une défaillance du service producteur PSC bar dans la région 2 en arrêtant le serveur Web sur l'une des deux instances de VM.

Obtenir les détails d'une VM serveur

# set env var for a bar service vm name
export BAR_FAIL_NAME=$(gcloud compute instance-groups managed list-instances mig-bar \
  --limit=1 \
  --region=${REGION_2} \
  --format="value(name)")
echo ${BAR_FAIL_NAME}

# set env var for a bar service zone
export BAR_FAIL_ZONE=$(gcloud compute instance-groups managed list-instances mig-bar \
  --limit=1 \
  --region=${REGION_2} \
  --format="value(ZONE)")
echo ${BAR_FAIL_ZONE}

Arrêter le serveur http de la région 2

# stop apache http server to fail service
gcloud compute ssh ${BAR_FAIL_NAME} --zone=${BAR_FAIL_ZONE} --command='
  sudo systemctl stop apache2'

# verify service dead
gcloud compute ssh ${BAR_FAIL_NAME} --zone=${BAR_FAIL_ZONE} --command='
  sudo systemctl status apache2 | grep Active:'

Vérifier que le service régional n'est pas opérationnel

# check health state of backend service
gcloud compute backend-services get-health ilb-bar --region=${REGION_2}

Le résultat devrait ressembler à ceci :

backend: .../regions/us-east1/instanceGroups/mig-bar
status:
  healthStatus:
  -   forwardingRule: .../regions/us-east1/forwardingRules/fr-bar
    forwardingRuleIp: 172.16.2.99
    healthState: UNHEALTHY
    instance: .../zones/us-east1-b/instances/service-bar-<UID_1>
    ipAddress: 172.16.2.3
    port: 80
  -   forwardingRule: .../regions/us-east1/forwardingRules/fr-bar
    forwardingRuleIp: 172.16.2.99
    healthState: HEALTHY
    instance: .../zones/us-east1-d/instances/service-foo-<UID_2>
    ipAddress: 172.16.2.2
    port: 80
  kind: compute#backendServiceGroupHealth

# check health state of health source
gcloud compute health-sources get-health bar-health-source --region=${REGION_2}

Le résultat devrait ressembler à ceci :

healthState: UNHEALTHY
kind: compute#healthSourceHealth
sources:
- backends:
  - endpointCount: 1
    group: .../zones/us-east1-b/instanceGroups/mig-bar
    healthyEndpointCount: 0
  - endpointCount: 1
    group: .../zones/us-east1-d/instanceGroups/mig-bar
    healthyEndpointCount: 1
  - endpointCount: 0
    group: .../zones/us-east1-c/instanceGroups/mig-bar
    healthyEndpointCount: 0
  forwardingRule: .../regions/us-west1/forwardingRules/fr-bar
  source: .../regions/us-west1/backendServices/ilb-bar

Tester le basculement du client de la région 2

# send request to service using hostname
gcloud compute ssh client-2 --zone=${ZONE_2} --command='
  curl -s -v www.foobar.com'

# curl to ilb vip in region 1
gcloud compute ssh client-2 --zone=${ZONE_2} --command='
  curl -s 10.10.1.99'

# curl to ilb vip in region 2
gcloud compute ssh client-2 --zone=${ZONE_2} --command='
  curl -s 10.10.2.99'

L'état de santé composite pour PSC a mis à jour l'équilibreur de charge du consommateur et lui a demandé d'éviter le service de backend non opérationnel dans la région 2. Il a plutôt redirigé le trafic vers le service opérationnel foo dans la région 1.

Si l'équilibreur de charge du consommateur considère que tous les services du producteur sont défaillants, il ne peut pas basculer vers une instance opérationnelle. Le comportement attendu est que l'équilibreur de charge répartisse le trafic sur tous les backends non opérationnels (fail open).

La partie test est terminée. Passons à la surveillance.

8. Surveiller votre santé

Les changements d'état sont enregistrés par défaut. Les projets Producteur peuvent consulter les journaux des sources d'état et des vérifications d'état composites. Les projets consommateurs peuvent afficher les journaux des NEG PSC connectés aux services publiés à l'aide de l'état de santé composite.

Bien que cet atelier déploie les ressources consommateur et producteur dans le même projet par souci de simplicité, les journaux afficheront les deux rôles dissociés lorsqu'ils seront déployés dans des projets distincts.

Ressource surveillée

Afficher

Nom du journal

Sources d'état et vérifications composites

Vue du producteur

.../logs/compute.googleapis.com%2Fcompositehealth

NEG Private Service Connect

Vue consommateur

.../logs/compute.googleapis.com%2Fservicehealthchecks

Journaux du producteur

Les journaux du producteur affichent le cumul de l'état interne des services du producteur :

  • HealthSource : état de santé des services de backend individuels (par exemple, états de VM mig-bar et mig-foo)
  • CompositeHealthCheck : état de santé agrégé de la région du service publié, mappé à la destination de la règle de transfert du producteur (par exemple, fr-bar ou fr-foo)
# query logs for producer
gcloud logging read \
  'logName="projects/'${PROJECT_ID}'/logs/compute.googleapis.com%2Fcompositehealth"' \
  --project=${PROJECT_ID} \
  --limit=10 \
  --format='table(
    timestamp.date(format="%I:%M:%S %p", tz=LOCAL):label=TIME,
    resource.type.basename():label=TYPE,
    resource.labels.location:label=REGION,
    jsonPayload.healthState:label=STATE,
    jsonPayload.sources[0].backends[].group.basename().join(","):label=BACKENDS,
    jsonPayload.sources[0].backends[].healthyEndpointCount.join(","):label=HEALTHY,
    jsonPayload.sources[0].backends[].endpointCount.join(","):label=TOTAL,
    jsonPayload.healthDestination.basename():label=DESTINATION
  )'

Journaux des consommateurs

Les journaux du consommateur affichent l'état de santé propagé des ressources du consommateur :

  • NetworkEndpointGroup : état de santé propagé du NEG PSC connecté au service publié (par exemple, neg-bar et neg-foo)

Dans une configuration distincte de consommateur et de producteur, utilisez cette requête de journal dans le projet consommateur pour cibler les événements d'état composites pour les NEG PSC…

# query logs for consumer
gcloud logging read \
  "logName=projects/${PROJECT_ID}/logs/compute.googleapis.com%2Fservicehealthchecks
  AND resource.type=\"compute.googleapis.com/NetworkEndpointGroupV2\"" \
  --project="${PROJECT_ID}" \
  --freshness=30m \
  --limit=10 \
  --format="table(
    timestamp.date(format='%I:%M:%S %p', tz=LOCAL):label=TIME,
    resource.labels.location:label=REGION,
    jsonPayload.serviceHealthCheckResult.healthState:label=STATE,
    jsonPayload.serviceHealthCheckResult.previousHealthState:label=PREV_STATE,
    resource.labels.network_endpoint_group_id:label=NEG_ID
  )"

La partie sur la surveillance est terminée. Passons au nettoyage.

9. Nettoyage 

# delete health resources
gcloud -q compute composite-health-checks delete foo-health-composite --region=${REGION_1}

gcloud -q compute health-sources delete foo-health-source --region=${REGION_1}

gcloud -q compute health-aggregation-policies delete foo-health-policy --region=${REGION_1}

gcloud -q compute composite-health-checks delete bar-health-composite --region=${REGION_2}

gcloud -q compute health-sources delete bar-health-source --region=${REGION_2}

gcloud -q compute health-aggregation-policies delete bar-health-policy --region=${REGION_2}

# delete consumer compute and load balancer resources
gcloud -q compute instances delete client-2 --zone=${ZONE_2}

gcloud -q compute instances delete client-1 --zone=${ZONE_1}

gcloud -q dns record-sets delete www.foobar.com --type=A --zone=zone-foobar

gcloud -q dns managed-zones delete zone-foobar

gcloud -q compute forwarding-rules delete fr-foobar-2 --global

gcloud -q compute forwarding-rules delete fr-foobar-1 --global

gcloud -q compute target-http-proxies delete proxy-foobar --global

gcloud -q compute url-maps delete ilb-foobar --global

gcloud -q compute backend-services delete bes-foobar --global



# delete consumer network resources
gcloud -q compute network-endpoint-groups delete neg-bar --region=${REGION_2}

gcloud -q compute network-endpoint-groups delete neg-foo --region=${REGION_1}

gcloud -q compute networks subnets delete subnet-proxy-2 --region=${REGION_2}

gcloud -q compute networks subnets delete subnet-proxy-1 --region=${REGION_1}

gcloud -q compute networks subnets delete subnet-client-2 --region=${REGION_2}

gcloud -q compute networks subnets delete subnet-client-1 --region=${REGION_1}

gcloud -q compute network-firewall-policies associations delete \
  --firewall-policy=fw-policy-consumer \
  --name=fw-policy-association-consumer \
  --global-firewall-policy

gcloud -q compute network-firewall-policies delete fw-policy-consumer --global

gcloud -q compute networks delete vnet-consumer

# delete producer load balancer resources
gcloud -q compute service-attachments delete psc-sa-bar --region=${REGION_2}

gcloud -q compute service-attachments delete psc-sa-foo --region=${REGION_1}

gcloud -q compute forwarding-rules delete fr-bar --region=${REGION_2}

gcloud -q compute forwarding-rules delete fr-foo --region=${REGION_1}

gcloud -q compute backend-services delete ilb-bar --region=${REGION_2}

gcloud -q compute backend-services delete ilb-foo --region=${REGION_1}

gcloud -q compute health-checks delete hc-bar-http --region=${REGION_2}

gcloud -q compute health-checks delete hc-foo-http --region=${REGION_1}

# delete producer compute resources
gcloud -q compute instance-groups managed delete mig-bar --region=${REGION_2}

gcloud -q compute instance-groups managed delete mig-foo --region=${REGION_1}

gcloud -q compute instance-templates delete mig-template-bar --global

gcloud -q compute instance-templates delete mig-template-foo --global

# delete producer network resources
gcloud -q compute networks subnets delete subnet-bar-pscnat --region=${REGION_2}

gcloud -q compute networks subnets delete subnet-foo-pscnat --region=${REGION_1}

gcloud -q compute networks subnets delete subnet-bar --region=${REGION_2}

gcloud -q compute networks subnets delete subnet-foo --region=${REGION_1}

gcloud -q compute routers delete cr-nat-bar --region=${REGION_2}

gcloud -q compute routers delete cr-nat-foo --region=${REGION_1}

gcloud -q compute network-firewall-policies associations delete \
  --firewall-policy=fw-policy-producer \
  --name=fw-policy-association-producer \
  --global-firewall-policy

gcloud -q compute network-firewall-policies delete fw-policy-producer --global

gcloud -q compute networks delete vnet-producer

# delete shell variables and script file
unset FOO_FAIL_NAME FOO_FAIL_ZONE BAR_FAIL_NAME BAR_FAIL_ZONE

unset PROJECT_ID REGION_1 ZONE_1 REGION_2 ZONE_2

rm vm-server-startup.sh
#

10. Conclusion

Félicitations ! Vous avez correctement configuré l'état composite pour PSC et testé le basculement régional automatique.

N'hésitez pas à nous faire part de vos commentaires, questions ou corrections en utilisant ce formulaire.

Merci !