Zusammengesetzte Systemdiagnosen für Private Service Connect

1. Einführung

In diesem Codelab wird Composite Health für Private Service Connect (PSC) für das automatische regionale Failover untersucht. Composite Health für PSC ist eine Netzwerkfunktion, die die Dienstresilienz und ‑verfügbarkeit verbessert.

Mit Composite Health können Diensthersteller benutzerdefinierte Richtlinien für den Zustand definieren (welcher Status definiert einen fehlerfreien oder fehlerhaften Dienst) und diese Signale automatisch an Dienstnutzer weiterleiten, die mit PSC-Back-Ends eine Verbindung zum Dienst herstellen. Diese Funktion wurde speziell für das automatische regionsübergreifende Failover entwickelt. Wenn ein regionaler Erstellerdienst fehlerhaft wird, leitet der Load-Balancer des Nutzers 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übergreifendes Failover, wie z. B. Ausreißererkennung, bietet „Composite Health“ ein genaueres Failover-Signal, da es 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 zusammengesetzten Systemzustands und ihre Funktionsweise zur Bestimmung des Systemzustands eines Producer-Dienstes
• Zusammengesetzte Health für PSC für einen Producer-Dienst mit gcloud-Befehlen implementieren
• Konfiguration eines regionenübergreifenden PSC-Consumer-Zugriffs-Load-Balancers zur Verwendung der Systemsignale aus der Composite Health-Richtlinie 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 allgemeinen 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 globalen (regionenübergreifenden) Client-Ingress. Der Backend-Dienst ist eine globale Ressource, die NEGs in verschiedenen Regionen unterstützt. Im Failover-Szenario kann ein Client, der eine Verbindung zu einer der regionalen Front-End-Weiterleitungsregeln herstellt, an ein fehlerfreies globales Back-End weitergeleitet werden.

Abbildung 1. Netzwerktopologie des Codelabs

Auf der Producer-Seite 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 Senden von http-Anfragen und Validieren von 200 (OK)-Antworten auf Systemdiagnosen geprüft.

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

Dienststatus

Die Systemdiagnose des Producer-Backend-Dienstes, die beim Erstellen des Load-Balancers konfiguriert wird, dient als ursprüngliches Signal für die Funktion Zusammengesetzte Systemdiagnose für PSC. Die Ressource Systemdiagnosequelle verwendet dieses Signal zusammen mit zusätzlichen Einschränkungen, die in der Ressource Richtlinie zur Aggregation von Systemdiagnosen definiert sind, um einen Systemdiagnosestatus für einen einzelnen Backend-Dienst zu bestimmen.

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 Backend-Dienste, um den Gesamtzustand des gesamten regionalen Erstellerdienstes zu ermitteln. In diesem Lab hat jeder regionale Erstellerdienst nur eine Systemdiagnosequelle für den Backend-Dienst, die in der einen zusammengesetzten Systemdiagnose zusammengefasst wird.

Abbildung 2: Zusammengesetzte Integrität für das PSC-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 Erstellerdienste 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 gcloud CLI installiert

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

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

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

Für den Load-Balancer der Consumer-Anwendung (proxybasiert) sind Nur-Proxy-Subnetze erforderlich. Diese Subnetze bieten einen Pool von IP-Adressen, die von proxybasierten 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:Suche nach zwei akzeptierten PSC-Verbindungen...
.../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 den Testdienst

Von der Client-VM in Region 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'

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 from vm to load balancer forwarding rule region 2
gcloud compute ssh client-1 --zone=${ZONE_1} --command='
  curl -s 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}

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 entsprechenden Health-Signal umgeleitet.

Da sich die tatsächlichen Producer-Dienstressourcen jedoch hinter dem Producer-Load-Balancer im Producer-VPC-Netzwerk befinden, waren diese Health-Signale für den Consumer-Load-Balancer bisher nicht sichtbar. Daher konnte die Consumer-Seite keine Backend-Failover-Entscheidungen treffen. PSC-Health behebt dieses Problem, indem Dienst-Health-Informationen von der Producer-Seite an die Consumer-Seite weitergegeben werden.

6. Gesundheitsressourcen

Die zusammengesetzte Systemdiagnose für PSC-Ressourcen wird vom Dienstersteller konfiguriert, um den allgemeinen Zustand des regionalen Dienstes darzustellen. Die Systemdiagnoserichtlinie basiert darauf, was der Dienstersteller als angemessen definiert, um ein funktionierendes Dienstniveau aufrechtzuerhalten. Grenzwerte werden festgelegt, um Nutzer zu benachrichtigen, wenn die vom Dienstersteller definierten Bedingungen nicht mehr erfüllt werden.

Dienstzustand foo in Region 1 einrichten

Richtlinie zur Aggregation von Systemdiagnosen erstellen

gcloud 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 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 Systemdiagnosequelle wird durch die Backend-Dienstressource und die Bedingungen der Richtlinie zur Aggregation von Systemdiagnosen definiert.

Zusammengesetzte Systemdiagnose erstellen

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

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

Dienststatus bar in Region 2 einrichten

Richtlinie zur Aggregation von Systemdiagnosen erstellen

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

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

Server 1 für Region 1 stoppenhttp

# 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:'

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

Die Ausgabe sollte ungefähr so aussehen:

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

Client-Failover für Region 1 testen

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

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

Die zusammengesetzte Systemdiagnose für PSC hat den Nutzer-Load-Balancer aktualisiert und ihn angewiesen, den fehlerhaften Backend-Dienst in Region 1 zu umgehen. Stattdessen wird der Traffic an den fehlerfreien Dienst bar in Region 2 weitergeleitet.

Server für Region 1 http neu starten

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

Die Ausgabe sollte jetzt einen HEALTHY-Status ähnlich dem folgenden anzeigen:

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

Richtlinie für den Systemzustand ändern

Produzenten können Richtlinien zur Dienstintegrität anhand verschiedener Kriterien anpassen. In der Ressource Richtlinie zur Aggregation von Systemdiagnosen werden die Mindestschwellenwerte angegeben, 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 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}

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 beträgt 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).

Dienst bar, Region 2, fehlerhaftes Szenario

In diesem Szenario wird ein Fehler des PSC-Erstellerservices 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}

Server für Region 2 http anhalten

# 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:'

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

Die Ausgabe sollte ungefähr so aussehen:

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

Client-Failover für Region 2 testen

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

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}

„Composite Health“ für PSC hat den Nutzer-Load-Balancer aktualisiert und ihn angewiesen, den fehlerhaften Backend-Dienst in Region 2 zu umgehen. Stattdessen wird 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).

Damit ist der Test abgeschlossen. Weiter geht es mit dem Monitoring.

8. Gesundheit im Blick behalten

Änderungen des Systemzustands werden standardmäßig protokolliert. In Erstellerprojekten können Logs für Gesundheitsquellen und zusammengesetzte Systemdiagnosen aufgerufen werden. In Nutzerprojekten können Logs für PSC-NEGs angezeigt werden, die über Composite Health mit veröffentlichten Diensten verbunden sind.

In diesem Lab werden sowohl die Nutzer- als auch die Erstellerressourcen der Einfachheit halber im selben Projekt bereitgestellt. Wenn sie in separaten Projekten bereitgestellt werden, werden die beiden Rollen in den Logs entkoppelt dargestellt.

Überwachte Ressource	Ansehen	Logname
Systemdiagnosequellen und zusammengesetzte Systemdiagnosen	Erstelleransicht	.../logs/compute.googleapis.com%2Fcompositehealth
Private Service Connect-NEGs	Ansicht für Verbraucher	.../logs/compute.googleapis.com%2Fservicehealthchecks

Producer-Logs

In den Produzentenprotokollen wird der interne Health-Rollup der Produzentendienste angezeigt:

• HealthSource: Der Status einzelner Backend-Dienste, z. B. die VM-Status von mig-bar und mig-foo.
• CompositeHealthCheck: Der aggregierte regionale Zustand des veröffentlichten Dienstes, der dem Ziel der Weiterleitungsregel des Erstellers zugeordnet ist (z. B. fr-bar oder 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
  )'

Nutzerprotokolle

Die Nutzerlogs enthalten den weitergegebenen Systemstatus der Nutzerressourcen:

• NetworkEndpointGroup: Der weitergeleitete Diagnosestatus des PSC-NEG, das mit dem veröffentlichten Dienst verbunden ist (z. B. neg-bar und neg-foo).

HINWEIS:Da sich die Nutzer-NEGs im selben Projekt und VPC-Netzwerk wie die Erstellerressourcen befinden, werden die doppelten Logging-Ereignisse für Nutzer-NEGs nicht angezeigt. Sie sind identische Statusübergänge wie auf der Erstellerseite.

Verwenden Sie in einer separaten Einrichtung für Nutzer und Ersteller diese Log-Abfrage im Nutzerprojekt, um zusammengesetzte Gesundheitsereignisse für PSC-NEGs zu erfassen…

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

Damit ist der Monitoring-Teil abgeschlossen. Nun geht es an die Bereinigung.

9. Bereinigen

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

Glückwunsch! Sie haben die zusammengesetzte Systemdiagnose für PSC 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!