Private Service Connect-Status

1. Einführung

In diesem Codelab geht es um die Systemdiagnose von Private Service Connect (PSC) für das automatische regionale Failover. PSC Health ist eine Netzwerkfunktion, die die Ausfallsicherheit und Verfügbarkeit von Diensten verbessert.

Mit PSC-Systemdiagnosen können Dienstersteller benutzerdefinierte Systemdiagnoserichtlinien definieren (welcher Status einen fehlerfreien oder fehlerhaften Dienst definiert) und diese Signale automatisch an Dienstnutzer weiterleiten, die über PSC-Back-Ends eine Verbindung zum Dienst herstellen. Dieses Feature wurde speziell für das automatische regionsübergreifende Failover entwickelt. Wenn ein regionaler Producer-Dienst fehlerhaft wird, leitet der Consumer-Load-Balancer den Traffic automatisch nicht mehr an diese Region weiter, sondern an einen fehlerfreien Dienst in einer anderen Region.

Im Vergleich zu früheren Methoden für regionsübergreifende Failover wie der Ausreißererkennung bietet der PSC-Status ein genaueres Failoversignal, da er direkt auf dem aggregierten Status der Back-Ends des Erstellerdienstes (VM-Instanzgruppen oder Netzwerkendpunkte) basiert. Ersteller können ihre eigene Statuslogik definieren, damit sie nur dann Traffic erhalten, wenn der Dienst die erforderlichen Statuskriterien erfüllt.

Lerninhalte

• Komponenten des PSC-Zustands und wie sie zusammenwirken, um den Zustand eines Producer-Dienstes zu bestimmen
• PSC-Systemdiagnose für einen Producer-Dienst mit gcloud-Befehlen implementieren
• Konfiguration eines regionenübergreifenden PSC-Consumer-Zugriffs-Load-Balancers zur Verwendung der Systemsignale aus der PSC-Systemdiagnoserichtlinie des Producers
• Dienstausfallszenarien testen und automatischen regionsübergreifenden Failover validieren

Voraussetzungen

• Ein Google Cloud-Projekt
• IAM-Berechtigungen, die der vordefinierten Rolle roles/compute.admin oder einer umfassenden einfachen Rolle wie roles/admin oder der alten Rolle roles/owner gewährt werden
• Vertrautheit mit Google Cloud-Netzwerkkonzepten und der Verwendung der Google Cloud CLI

2. Konzepte

PSC-Netzwerk

Die Netzwerk-Topologie dieses Codelabs umfasst ein Nutzer- und ein Ersteller-VPC-Netzwerk in zwei aktiven Google Cloud-Regionen.

Auf der Consumer-Seite gibt es regionale Subnetze mit Client-VM-Instanzen, die für den Zugriff auf den Producer-Dienst über einen regionenübergreifenden internen Application Load Balancer mit PSC-NEG-Backends verwendet werden. Es gibt zwei regionale Load-Balancer-Weiterleitungsregeln mit regionalen IP-Adressen für den globalen (regionenübergreifenden) Client-Ingress. Der Backend-Dienst ist eine globale Ressource, die NEGs in verschiedenen Regionen unterstützt. In einem Failover-Szenario kann ein Client, der eine Verbindung zu einer der beiden regionalen Frontend-Weiterleitungsregeln herstellt, an ein fehlerfreies globales Backend weitergeleitet werden.

Abbildung 1. Netzwerktopologie des Codelabs

Auf der Erstellerseite gibt es regionale Subnetze mit regionalen internen Passthrough-Network Load Balancern, die einen Dienst über eine regionale PSC-Dienstanhangressource bereitstellen. Die Backend-Dienste enthalten regionale Managed Instance Groups (MIGs) und werden durch das Senden von http-Anfragen und das Validieren von 200 (OK)-Antworten auf Fehler geprüft.

In der aktuellen Dokumentation zur Private Service Connect-Kompatibilität für die Erstellerkonfiguration finden Sie Informationen dazu, welche Load Balancer PSC-Healthchecks unterstützen.

Dienststatus

Die Systemdiagnose des Producer-Back-End-Dienstes, die beim Erstellen des Load-Balancers konfiguriert wird, dient als Ausgangssignal für die Funktion PSC-Systemdiagnose. Die Ressource health source verwendet dieses Signal zusammen mit zusätzlichen Einschränkungen, die in der Ressource health aggregation policy definiert sind, um einen health state für einen einzelnen Backend-Dienst zu ermitteln.

Standardmäßig gilt ein Dienst als fehlerfrei, wenn beide folgenden Bedingungen erfüllt sind:

• Mindestens x % der Backends sind fehlerfrei (Standardwert: 60)
• Mindestens y Backends sind fehlerfrei (Standardwert: 1)

Die zusammengesetzte Systemdiagnose verweist auf alle Systemdiagnosequellen für alle Back-End-Dienste, um den allgemeinen Zustand des gesamten regionalen Diensterstellerdienstes zu ermitteln. In diesem Lab hat jeder regionale Producer-Dienst nur eine Backend-Dienst-Systemdiagnosequelle, die in der einen zusammengesetzten Systemdiagnose zusammengefasst wird.

Abbildung 2. PSC-Systemdiagnosen-Ressourcenmodell

Die Ressourcendefinition für die zusammengesetzte Systemdiagnose verweist auch auf die Weiterleitungsregel des Load-Balancers des Producer-Dienstes. Das PSC-NEG des Nutzer-Load-Balancer-Back-Ends ist logisch mit dem PSC-Dienstanhang des Erstellers und der Weiterleitungsregel des Load Balancers des Erstellers verbunden. Dadurch wird der Load-Balancer für den Nutzerzugriff an den Status der zusammengesetzten Systemdiagnose des Erstellerdienstes gebunden. Der allgemeine Dienststatus für den regionalen Erstellerdienst wird dann an den Nutzer-Load-Balancer weitergegeben, um die entsprechende Back-End-Auswahl zu treffen.

3. Projekt einrichten

Auf Ihr Projekt zugreifen

In diesem Codelab wird ein einzelnes Google Cloud-Projekt verwendet. Bei den Konfigurationsschritten werden gcloud- und Linux-Shell-Befehle verwendet.

HINWEIS:In einer Produktionsbereitstellung befinden sich PSC-Nutzerressourcen und Producer-Dienste in der Regel in verschiedenen Projekten.

Rufen Sie zuerst die Befehlszeile Ihres Google Cloud-Projekts auf:

• Cloud Shell http://shell.cloud.google.com/ oder
• Ein lokales Terminal mit installiertem gcloud CLI

Projekt-ID festlegen

gcloud config set project YOUR_PROJECT_ID_HERE

Shell-Umgebungsvariablen festlegen

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}

API-Dienste aktivieren

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

HINWEIS:Bei Pre-GA-Funktionen werden möglicherweise gcloud beta-Befehle verwendet. Wenn sie nicht installiert ist, führen Sie gcloud components install beta aus, um sie zu aktivieren.

4. Producer-Dienst

Freigegebene Ressourcen erstellen

Netzwerk erstellen

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

Subnetze erstellen

# 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

Firewallkomponenten erstellen

Firewallregeln sind erforderlich, um Traffic zu VM-Ressourcen zuzulassen. Die impliziten Standard-Firewallregeln sind, eingehenden Traffic abzulehnen und ausgehenden Traffic zuzulassen. Richtlinien sind die bevorzugte Methode zum Bereitstellen von Firewallregeln. Dazu erstellen Sie eine Netzwerk-Firewallrichtlinienressource, erstellen und fügen der Richtlinie Regeln hinzu und verknüpfen die Richtlinie dann mit einem VPC-Netzwerk.

# 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

Cloud Router und NAT-Gateways erstellen

# 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

VM-Startkonfiguration mit HTTP-Server erstellen

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

Dienst foo in Region 1 einrichten

Compute-Dienst erstellen

# 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

Komponenten für Dienst-Load Balancer erstellen

# 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

PSC-Dienst veröffentlichen

# 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

Dienst bar in Region 2 einrichten

Compute-Dienst erstellen

# 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

Komponenten für Dienst-Load Balancer erstellen

# 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

PSC-Dienst veröffentlichen

# 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. Zugriff für Nutzer

Clientressourcen einrichten

Netzwerkkomponenten erstellen

# 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

Der Load Balancer der Consumer-Anwendung (proxybasiert) erfordert Nur-Proxy-Subnetze. Diese Subnetze stellen einen Pool von IP-Adressen bereit, die von Proxy-basierten Load-Balancern als interne Quelladressen verwendet werden, wenn Traffic an Back-Ends gesendet wird.

# 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

Firewallkomponenten erstellen

# 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

Load-Balancer-Komponenten erstellen

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

PRÜFEN:Prüfen Sie, ob zwei akzeptierte PSC-Verbindungen vorhanden sind.
.../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

DNS-Einträge erstellen

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

Compute-Ressourcen erstellen

# 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

Baseline für Testdienst

SSH-Verbindung zur Client-VM in Region 1 herstellen

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

PRÜFEN:Prüfen Sie, ob die Antwort vom Dienst in Region 1 stammt…
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

PRÜFEN:Prüfen, ob die Antwort vom Dienst in Region 1 stammt…
Page served from: service-bar-{UID} in zone projects/{PROJECT_NO}/zones/{REGION_2_ZONE}

# exit vm ssh
exit

Optional:Führen Sie dieselben Tests auf der Client-VM in Region 2 aus: gcloud compute ssh client-2 --zone=${ZONE_2}

WICHTIG:Beim normalen Load-Balancer-Verhalten für Clientanfragen, die über eine Weiterleitungsregel in region-x eingehen, werden Backends in derselben region-x bevorzugt. Wenn alle Backend-Ressourcen fehlerfrei sind, gewinnt die Region mit der niedrigsten Latenz. Globale Backends werden auf die andere Region mit dem richtigen Health-Signal umgeleitet.

Da sich die tatsächlichen Ersteller-Dienstressourcen jedoch hinter dem Ersteller-Loadbalancer im Ersteller-VPC-Netzwerk befinden, waren diese Health-Signale für den Nutzer-Loadbalancer bisher nicht sichtbar. Daher konnte die Nutzer-Seite keine solchen Backend-Failover-Entscheidungen treffen. PSC Health behebt dieses Problem, indem Dienststatusinformationen von der Erstellerseite an die Nutzerseite weitergegeben werden.

6. Gesundheitsressourcen

PSC Health-Ressourcen werden vom Produzenten konfiguriert, um den allgemeinen Zustand des regionalen Dienstes darzustellen. Die Richtlinie zur Dienstintegrität basiert auf den Anforderungen, die der Dienstanbieter als angemessen definiert, um ein funktionierendes Serviceniveau aufrechtzuerhalten. Schwellenwerte werden festgelegt, um Verbraucher zu benachrichtigen, wenn die vom Ersteller definierten Bedingungen nicht mehr erfüllt werden.

Dienststatus foo in Region 1 einrichten

Richtlinie zur Aggregation von Systemdiagnosen erstellen

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

HINWEIS: Für Bedingungen werden die Standardwerte --healthy-percent-threshold=60 und --min-healthy-threshold=1 verwendet.

Quelle für Systemdiagnose erstellen

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

HINWEIS:Die Gesundheitsdatenquelle wird durch die Backend-Dienstressource und die Bedingungen der Richtlinie zur Aggregation von Gesundheitsdaten definiert.

Zusammengesetzte Systemdiagnose erstellen

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

HINWEIS:Die zusammengesetzte Systemdiagnose verweist auf die Systemdiagnosequelle(n) und definiert das Systemdiagnoseziel. Die End-to-End-Verknüpfung zwischen dem Erstellerdienst und dem Zugriff des Nutzers ist jetzt abgeschlossen.

Konfiguration der Systemdiagnose für den Dienst foo prüfen

Konfigurationen von Gesundheitsressourcen können mit den Befehlen „list“ (und describe) pro Region aufgerufen werden.

# 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}

Dienstzustand bar in Region 2 einrichten

Richtlinie zur Aggregation von Systemdiagnosen erstellen

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

Quelle für Systemdiagnose erstellen

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

Zusammengesetzte Systemdiagnose erstellen

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

Konfiguration der Systemdiagnose für den Dienst bar prüfen

# 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}

Damit ist die Konfiguration abgeschlossen. Jetzt geht es ans Testen.

7. Failover-Test

Dienst foo, Region 1, fehlerhaft

In diesem Szenario wird ein Fehler des PSC-Erstellerdienstes foo in Region 1 simuliert, indem der Webserver auf einer der beiden VM-Instanzen beendet wird.

Details zur Server-VM abrufen

# 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}

SSH-Verbindung zur Server-VM herstellen und http-Server beenden

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

Prüfen, ob der regionale Dienst nicht fehlerfrei arbeitet

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

healthState: UNHEALTHY

Die Ausgabe sollte ungefähr so aussehen:

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

SSH-Verbindung zur Client-VM in Region 1 herstellen und Failover testen

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

PRÜFEN:Prüfen, ob die Antwort vom Dienst in Region 2 stammt…
Page served from: service-bar-{UID} in zone projects/{PROJECT_NO}/zones/{REGION_2_ZONE}

Der Zustand von PSC wurde im Nutzer-Load-Balancer aktualisiert und er wurde angewiesen, den fehlerhaften Backend-Dienst in Region 1 zu vermeiden. Stattdessen wurde der Traffic an den fehlerfreien Dienst bar in Region 2 weitergeleitet.

# exit client vm ssh
exit

SSH-Verbindung zur Server-VM herstellen und http-Server neu starten

# 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

Richtlinie für den Systemzustand ändern

Produzenten können Richtlinien zur Dienstintegrität anhand verschiedener Kriterien anpassen. Die Ressource Richtlinie zur Aggregation von Systemdiagnosen gibt die Mindestschwellenwerte an, die erforderlich sind, um einen fehlerfreien Status für alle verschiedenen Systemdiagnosequellen (Backend-Dienste) aufrechtzuerhalten.

HINWEIS:Diese Änderung zeigt, wie eine andere Bedingung in der Richtlinie zur Gesundheitsdatenaggregation aufgerufen wird, indem --min-healthy-threshold verwendet wird.

Richtlinie zur Aggregation von Systemdiagnosen für bar aktualisieren

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}

Mit dieser Änderung der Hersteller-Richtlinie wird Folgendes erreicht:

1. Der Mindestschwellenwert für den fehlerfreien Zustand wird von 60% auf 40 % gesenkt. Ein einzelner VM-Instanzfehler löst jetzt keinen fehlerhaften Zustand basierend auf --healthy-percent-threshold aus (der Fehlerstatus liegt bei 50% und es sind nur 40% für einen fehlerfreien Zustand erforderlich).
2. Erhöht die Mindestanzahl fehlerfreier Back-Ends von 1 auf 2 VM-Instanzen. Ein einzelner VM-Instanzfehler löst jetzt einen fehlerhaften Zustand basierend auf --min-healthy-threshold aus (Fehlerstatus ist 1, aber 2 sind erforderlich, um fehlerfrei zu sein).

Szenario 2: Dienst bar in Region 2 ist fehlerhaft

In diesem Szenario wird ein Fehler des PSC-Erstellerdienstes bar in Region 2 simuliert, indem der Webserver auf einer der beiden VM-Instanzen beendet wird.

Details zur Server-VM abrufen

# 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}

SSH-Verbindung zur Server-VM herstellen und http-Server beenden

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

Prüfen, ob der regionale Dienst nicht fehlerfrei arbeitet

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

healthState: UNHEALTHY

Die Ausgabe sollte ungefähr so aussehen:

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

SSH-Verbindung zur Client-VM in Region 2 herstellen und Failover testen

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

PRÜFEN:Prüfen Sie, ob die Antwort vom Dienst in Region 1 stammt…
Page served from: service-foo-{UID} in zone projects/{PROJECT_NO}/zones/{REGION_1_ZONE}

Der Zustand von PSC wurde aktualisiert und der Nutzer-Load-Balancer wurde angewiesen, den fehlerhaften Backend-Dienst in Region 2 zu vermeiden. Stattdessen wurde der Traffic an den fehlerfreien Dienst foo in Region 1 weitergeleitet.

Wenn der Nutzer-Load Balancer alle Erstellerdienste als fehlerhaft ansieht, kann der Load Balancer kein Failover auf eine fehlerfreie Instanz durchführen. Dabei wird folgendes Verhalten erwartet: Der Load-Balancer verteilt den Traffic auf alle fehlerhaften Back-Ends (Fail-Open).

# exit client vm ssh
exit

Damit ist der Test abgeschlossen. Nun geht es an die Bereinigung.

8. Bereinigen

# 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. Fazit

Glückwunsch! Sie haben die Systemdiagnose für Private Service Connect erfolgreich konfiguriert und das automatische regionale Failover getestet.

Wenn Sie Anmerkungen, Fragen oder Korrekturen haben, können Sie uns diese gern über dieses Feedbackformular mitteilen.

Vielen Dank!