État de Private Service Connect

1. Introduction

Cet atelier de programmation explore l'état de Private Service Connect (PSC) pour le basculement régional automatique. L'état du PSC est une fonctionnalité réseau qui améliore la résilience et la disponibilité des services.

L'état de santé PSC permet aux producteurs de services de définir des règles d'état de santé personnalisées (l'état qui définit un service opérationnel ou non) et de propager automatiquement ces signaux aux consommateurs 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 anomalies, l'état PSC 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 santé du PSC et leur fonctionnement pour déterminer l'état de santé d'un service de producteur
• Implémenter l'état de santé PSC pour un service de producteur à l'aide des commandes gcloud
• Configuration d'un équilibreur de charge d'accès consommateur PSC multirégional pour utiliser les signaux d'état de la règle d'état PSC 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 de 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.

Du côté consommateur, des sous-réseaux régionaux comportent 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 régionales de l'interface peut être redirigé vers un backend global opérationnel.

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 envoyant des 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 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 du 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 de l'état pour déterminer un état pour un seul service de backend.

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

• Un minimum de x % des backends sont opérationnels (valeur par défaut : 60).
• Au moins y backends sont opérationnels (valeur par défaut : 1).

La vérification d'état composite fait référence à toutes les sources de données 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 de données d'état de service de backend qui est agrégée dans une seule vérification de l'état composite.

Fig. 2. Modèle de ressource sur l'état de 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 d'é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 :

• Cloud Shell http://shell.cloud.google.com/
• Un terminal local avec gcloud CLI installé

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

REMARQUE : Les fonctionnalités avant disponibilité générale peuvent utiliser des commandes gcloud beta. Si ce n'est pas le cas, exécutez gcloud components install beta pour l'activer.

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)"

VÉRIFIER : vérifiez que deux connexions PSC acceptées sont disponibles…
.../regions/REGION_1/networkEndpointGroups/neg-foo ACCEPTED
.../regions/REGION_2/networkEndpointGroups/neg-bar ACCEPTED

# 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

Se connecter en SSH à la VM cliente dans la région 1

gcloud compute ssh client-1 --zone=${ZONE_1}

# send request to service using hostname
curl -v www.foobar.com

# send request to load balancer forwarding rule region 1
curl 10.10.1.99

VÉRIFIER : Vérifiez que la réponse provient du service dans la région 1…
Page served from: service-foo-{UID} in zone projects/{PROJECT_NO}/zones/{REGION_1_ZONE}

# send request to load balancer forwarding rule region 2
curl 10.10.2.99

VÉRIFIER : Vérifiez que la réponse provient du service dans la région 1…
Page served from: service-bar-{UID} in zone projects/{PROJECT_NO}/zones/{REGION_2_ZONE}

# exit vm ssh
exit

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

IMPORTANT : 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 est sélectionnée. 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 ne pouvait pas 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é

Les ressources d'état PSC sont configurées par le producteur pour représenter l'état général du service régional. La règle d'état de santé est basée sur ce que le producteur de service définit comme approprié pour maintenir un niveau de service fonctionnel. Les seuils sont définis pour notifier aux 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 beta compute health-aggregation-policies create foo-health-policy \
  --region=${REGION_1} \
  --healthy-percent-threshold=60 \
  --min-healthy-threshold=1

REMARQUE : Les conditions utilisent les valeurs par défaut : --healthy-percent-threshold=60 et --min-healthy-threshold=1

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

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

REMARQUE : La source d'état est définie par la ressource du service de backend et les conditions de la règle d'agrégation de l'état.

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

gcloud beta 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

REMARQUE : La vérification d'état composite fait référence à la ou aux sources d'état et définit la destination d'état. La liaison d'état de bout en bout entre le service producteur et l'accès consommateur est désormais terminée.

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 beta compute health-aggregation-policies list --regions=${REGION_1}

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

# show composite health checks
gcloud beta 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 beta 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 beta 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 beta 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 beta compute health-aggregation-policies list --regions=${REGION_2}

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

# show composite health checks
gcloud beta 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}

Se connecter en SSH à la VM serveur et arrêter le serveur http

gcloud compute ssh ${FOO_FAIL_NAME} --zone=${FOO_FAIL_ZONE}

# stop apache http server to fail service
sudo systemctl stop apache2

# verify service dead
sudo systemctl status apache2 | grep Active:

# exit vm ssh
exit

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}

healthState: UNHEALTHY

Le résultat devrait ressembler à ceci :

backend: .../regions/<REGION_1>/instanceGroups/mig-foo
status:
  healthStatus:
  -   forwardingRule: .../regions/<REGION_1>/forwardingRules/fr-foo
    forwardingRuleIp: 172.16.1.99
    healthState: UNHEALTHY
    instance: .../zones/<ZONE_1x>/instances/<FOO_FAIL_NAME>
    ipAddress: <FOO_FAIL_IP>
    port: 80
  -   forwardingRule: .../regions/<REGION_1>/forwardingRules/fr-foo
    forwardingRuleIp: 172.16.1.99
    healthState: HEALTHY
    instance: .../zones/<ZONE_1y>/instances/<FOO_OTHER_NAME>
    ipAddress: <FOO_OTHER_IP>
    port: 80
  kind: compute#backendServiceGroupHealth

Se connecter en SSH à la VM cliente de la région 1 et tester le basculement

gcloud compute ssh client-1 --zone=${ZONE_1}

# send request to service using hostname
curl -v www.foobar.com

# curl to ilb vip in region 1
curl 10.10.1.99

# curl to ilb vip in region 2
curl 10.10.2.99

VÉRIFIER : vérifiez que la réponse provient du service dans la région 2…
Page served from: service-bar-{UID} in zone projects/{PROJECT_NO}/zones/{REGION_2_ZONE}

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

# exit client vm ssh
exit

Se connecter en SSH à la VM serveur et redémarrer le serveur http

# ssh to foo service vm
gcloud compute ssh ${FOO_FAIL_NAME} --zone=${FOO_FAIL_ZONE}

# start apache http server to return service to healthy
sudo systemctl start apache2

# verify service running
sudo systemctl status apache2 | grep Active:

# exit vm ssh
exit

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 health aggregation policy (stratégie d'agrégation de l'état) spécifie les seuils minimaux nécessaires pour maintenir un état sain dans toutes les sources d'état (services de backend).

REMARQUE : Cette modification montre comment appeler une condition différente dans la règle d'agrégation de l'état de santé à l'aide de --min-healthy-threshold.

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

gcloud beta 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 beta compute health-aggregation-policies list --regions=${REGION_2}

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

1. Le seuil minimal de pourcentage d'instances opérationnelles passe de 60 % à 40 %. Désormais, la défaillance d'une seule instance de VM ne déclenchera pas un état non opérationnel basé sur --healthy-percent-threshold (l'état de défaillance 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 de défaillance sera de 1, mais il faut 2 pour que l'état soit opérationnel).

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

Ce scénario simule une défaillance du service de 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}

Se connecter en SSH à la VM serveur et arrêter le serveur http

gcloud compute ssh ${BAR_FAIL_NAME} --zone=${BAR_FAIL_ZONE}

# stop apache http server to fail service
sudo systemctl stop apache2

# verify service dead
sudo systemctl status apache2 | grep Active:

# exit vm ssh
exit

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}

healthState: UNHEALTHY

Le résultat devrait ressembler à ceci :

backend: .../regions/<REGION_2>/instanceGroups/mig-bar
status:
  healthStatus:
  -   forwardingRule: .../regions/<REGION_2>/forwardingRules/fr-bar
    forwardingRuleIp: 172.16.2.99
    healthState: UNHEALTHY
    instance: .../zones/<ZONE_2x>/instances/<BAR_FAIL_NAME>
    ipAddress: <BAR_FAIL_IP>
    port: 80
  -   forwardingRule: .../regions/<REGION_2>/forwardingRules/fr-bar
    forwardingRuleIp: 172.16.2.99
    healthState: HEALTHY
    instance: .../zones/<ZONE_2y>/instances/<BAR_OTHER_NAME>
    ipAddress: <BAR_OTHER_IP>
    port: 80
  kind: compute#backendServiceGroupHealth

Se connecter en SSH à la VM cliente de la région 2 et tester le basculement

gcloud compute ssh client-2 --zone=${ZONE_2}

# send request to service using hostname
curl -v www.foobar.com

# curl to ilb vip in region 1
curl 10.10.1.99

# curl to ilb vip in region 2
curl 10.10.2.99

VÉRIFIER : Vérifiez que la réponse provient du service dans la région 1…
Page served from: service-foo-{UID} in zone projects/{PROJECT_NO}/zones/{REGION_1_ZONE}

L'état du PSC a mis à jour l'équilibreur de charge du consommateur et lui a demandé d'éviter le service de backend défectueux 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).

# exit client vm ssh
exit

La partie consacrée aux tests est terminée. Passons au nettoyage.

8. Nettoyage

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

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

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

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

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

gcloud -q beta 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
#

9. Conclusion

Félicitations ! Vous avez correctement configuré l'état du 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 de commentaires.

Merci !