Stan złożony w przypadku usługi Private Service Connect

1. Wprowadzenie

W tym ćwiczeniu dowiesz się, jak skonfigurować Composite Health w usłudze Private Service Connect (PSC) na potrzeby automatycznego przełączania awaryjnego w regionie. Composite Health for PSC to funkcja sieciowa, która zwiększa odporność i dostępność usługi.

Złożony stan umożliwia producentom usług definiowanie dostosowanych zasad stanu (określanie, jaki stan definiuje zdrową lub niezdrową usługę) i automatyczne propagowanie tych sygnałów do odbiorców usług łączących się z usługą za pomocą backendów PSC. Ta funkcja została zaprojektowana specjalnie z myślą o automatycznym przełączaniu awaryjnym między regionami. Jeśli regionalna usługa producenta stanie się niezdrowa, moduł równoważenia obciążenia odbiorcy automatycznie przestanie kierować ruch do tego regionu i przekieruje go do zdrowej usługi w innym regionie.

W porównaniu z poprzednimi metodami przełączania awaryjnego między regionami, takimi jak wykrywanie wartości odstających, stan złożony zapewnia dokładniejszy sygnał przełączania awaryjnego, ponieważ opiera się bezpośrednio na zagregowanym stanie backendów usługi producenta (grup instancji maszyn wirtualnych lub punktów końcowych sieci). Producenci mogą zdefiniować własną logikę stanu, dzięki czemu będą otrzymywać ruch tylko wtedy, gdy usługa spełnia niezbędne kryteria stanu.

Czego się dowiesz

  • Komponenty złożonego stanu i sposób ich współpracy w celu określenia stanu usługi producenta
  • Implementowanie stanu złożonego w usłudze PSC dla usługi producenta za pomocą poleceń gcloud
  • Konfigurowanie systemu równoważenia obciążenia dostępu konsumenta usługi PSC w wielu regionach w celu korzystania z sygnałów stanu z zasad złożonej kontroli stanu producenta
  • Testowanie scenariuszy awarii usługi i weryfikowanie automatycznego przełączania awaryjnego między regionami

Wymagania

  • projekt Google Cloud,
  • Uprawnienia IAM przyznane roli zdefiniowanej roles/compute.admin lub szerokiemu poziomowi podstawowemu, takiemu jak roles/admin lub starsza roles/owner
  • znajomość pojęć związanych z sieciami w Google Cloud i korzystania z Google Cloud CLI;

2. Pojęcia

Sieć PSC

Topologia sieci w tym ćwiczeniu obejmuje sieć VPC konsumenta i dostawcy w 2 aktywnych regionach Google Cloud.

Po stronie konsumenta znajdują się podsieci regionalne z instancjami maszyn wirtualnych klienta, które służą do uzyskiwania dostępu do usługi producenta za pomocą międzyregionalnego wewnętrznego systemu równoważenia obciążenia aplikacji z backendami grupy punktów końcowych sieci PSC. Istnieją 2 regionalne reguły przekierowania systemu równoważenia obciążenia z regionalnymi adresami IP dla globalnego (międzyregionalnego) ruchu przychodzącego klienta. Usługa backendu to zasób globalny, który obsługuje sieci NEG w różnych regionach. W przypadku przełączenia awaryjnego klient łączący się z dowolną regionalną regułą przekierowania frontendu może zostać przekierowany do działającego globalnego backendu.

figure1

Rys. 1. Topologia sieci w Codelabs

Po stronie producenta znajdują się podsieci regionalne z regionalnymi wewnętrznymi przekazującymi sieciowymi systemami równoważenia obciążenia, które udostępniają usługę za pomocą regionalnego zasobu przyłączenia usługi PSC. Usługi backendu zawierają regionalne zarządzane grupy instancji (MIG) i są sprawdzane pod kątem stanu przez wysyłanie żądań http i weryfikowanie odpowiedzi 200 (OK).

Zapoznaj się z najnowszą dokumentacją dotyczącą zgodności usługi Private Service Connect z konfiguracją producenta, aby sprawdzić, które systemy równoważenia obciążenia obsługują złożoną kontrolę stanu w przypadku PSC.

Stan usługi

Kontrola stanu usługi backendu producenta, skonfigurowana podczas tworzenia systemu równoważenia obciążenia, służy jako sygnał źródłowy dla funkcji złożonego stanu w przypadku PSC. Zasób źródła informacji o stanie wykorzystuje ten sygnał wraz z dodatkowymi ograniczeniami zdefiniowanymi w zasobie zasad agregacji stanu do określania stanu pojedynczej usługi backendu.

Domyślnie usługa jest uznawana za działającą prawidłowo, gdy spełnione są oba te warunki:

  • co najmniej x% backendów jest w dobrym stanie (domyślnie 60),
  • co najmniej y backendów jest w dobrym stanie (domyślnie 1);

Złożona kontrola stanu odwołuje się do wszystkich źródeł informacji o stanie wszystkich usług backendu, aby określić ogólny stan całej regionalnej usługi producenta. W tym module każda regionalna usługa producenta ma tylko jedno źródło informacji o stanie usługi backendu, które jest agregowane w ramach jednej złożonej kontroli stanu.

figure2

Rys. 2. Model zasobu Composite Health dla PSC

Definicja zasobu złożonej kontroli stanu odnosi się też do reguły przekierowania systemu równoważenia obciążenia usługi producenta. Backend PSC NEG systemu równoważenia obciążenia dostępu konsumenta jest logicznie połączony z przyłączem usługi PSC producenta i regułą przekierowania systemu równoważenia obciążenia producenta. Łączy to system równoważenia obciążenia dostępu konsumenta ze stanem złożonej kontroli stanu usługi producenta. Ogólny stan usługi regionalnego producenta jest następnie propagowany do systemu równoważenia obciążenia konsumenta, aby umożliwić odpowiedni wybór backendu.

3. Konfigurowanie projektu

Dostęp do projektu

To ćwiczenie zostało opracowane z myślą o używaniu jednego projektu Google Cloud. Kroki konfiguracji wykorzystują polecenia gcloud i polecenia powłoki Linux.

UWAGA: w przypadku wdrożenia produkcyjnego zasoby klienta PSC i usługi producenta znajdują się zwykle w różnych projektach.

Zacznij od uzyskania dostępu do wiersza poleceń swojego projektu w chmurze Google, używając:

Ustawianie identyfikatora projektu

gcloud config set project YOUR_PROJECT_ID_HERE

Ustawianie zmiennych środowiskowych powłoki

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}

Włączanie usług API

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

4. Usługa producenta

Tworzenie zasobów udostępnionych

Utwórz sieć

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

Tworzenie podsieci

# 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

Tworzenie komponentów zapory sieciowej

Reguły zapory sieciowej są potrzebne, aby zezwolić na ruch do zasobów maszyn wirtualnych (domyślne reguły zapory sieciowej to blokowanie ruchu przychodzącego i zezwalanie na ruch wychodzący). Zasady są preferowanym sposobem wdrażania reguł zapory sieciowej. W tym celu należy utworzyć zasób zasad zapory sieciowej, utworzyć i dodać reguły do zasad, a następnie powiązać zasady z siecią 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

Tworzenie routerów Cloud Router i bram 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

Tworzenie konfiguracji uruchamiania maszyny wirtualnej z serwerem 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

Konfigurowanie usługi foo w regionie 1

Tworzenie usługi obliczeniowej

# 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

Tworzenie komponentów systemu równoważenia obciążenia usługi

# 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

Publikowanie usługi 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

Konfigurowanie usługi bar w regionie 2

Tworzenie usługi obliczeniowej

# 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

Tworzenie komponentów systemu równoważenia obciążenia usługi

# 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

Publikowanie usługi 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. Dostęp konsumenta

Konfigurowanie zasobów klienta

Tworzenie komponentów sieci

# 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

System równoważenia obciążenia aplikacji konsumenta (oparty na proxy) wymaga podsieci tylko-proxy. Te podsieci zapewniają pulę adresów IP używanych przez systemy równoważenia obciążenia oparte na serwerze proxy jako wewnętrzne adresy źródłowe podczas wysyłania ruchu do backendów.

# 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

Tworzenie komponentów zapory sieciowej

# 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

Tworzenie komponentów systemu równoważenia obciążenia

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

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

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

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

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

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

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

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

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

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

Tworzenie rekordów 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"

Tworzenie zasobów obliczeniowych

# 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

Testowanie obrazu bazowego usługi

Z klienckiej maszyny wirtualnej w regionie 1

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

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

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

Opcjonalnie: przeprowadź te same testy na klienckiej maszynie wirtualnej w regionie 2: gcloud compute ssh client-2 --zone=${ZONE_2}

WAŻNE: normalne działanie systemu równoważenia obciążenia w przypadku żądań klientów wchodzących do reguły przekierowania w region-x polega na preferowaniu backendów w tym samym region-x. Jeśli wszystkie zasoby backendu są w dobrym stanie, wygrywa region o najkrótszym czasie oczekiwania. Globalne usługi backendu przełączą się awaryjnie na inny region z odpowiednim sygnałem stanu.

Ponieważ jednak rzeczywiste zasoby usługi producenta znajdują się za modułem równoważenia obciążenia producenta w sieci VPC producenta, sygnały o stanie były wcześniej niedostępne dla modułu równoważenia obciążenia konsumenta, a tym samym strona konsumenta nie mogła podejmować decyzji o przełączeniu awaryjnym na backend. Stan połączenia PSC rozwiązuje ten problem, przekazując informacje o stanie usługi ze strony producenta na stronę konsumenta.

6. Zasoby dotyczące zdrowia

Złożony stan zasobów PSC jest konfigurowany przez producenta w celu odzwierciedlenia ogólnego stanu usługi regionalnej. Zasady dotyczące stanu opierają się na tym, co producent usługi uznaje za odpowiednie do utrzymania działającego poziomu usługi. Progi są ustawiane tak, aby powiadamiać konsumentów o przełączeniu awaryjnym, gdy warunki określone przez producenta nie są już spełnione.

Skonfiguruj stan usługi foo w regionie 1.

Tworzenie zasady agregacji stanu

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

Tworzenie źródła danych o stanie

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

Tworzenie złożonej kontroli stanu

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

Sprawdzanie foo stanu konfiguracji usługi

Konfiguracje zasobów związanych ze zdrowiem można wyświetlać za pomocą poleceń list (i describe) w poszczególnych regionach.

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

Skonfiguruj stan usługi bar w regionie 2.

Tworzenie zasady agregacji stanu

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

Tworzenie źródła danych o stanie

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

Tworzenie złożonej kontroli stanu

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

Sprawdzanie bar stanu konfiguracji usługi

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

To koniec części dotyczącej konfiguracji. Przejdźmy do testowania.

7. Testowanie przełączania awaryjnego

Usługa foo w regionie 1 w złym stanie

Ten scenariusz symuluje awarię usługi producenta PSC foo w regionie 1 przez zatrzymanie serwera WWW na jednej z 2 instancji maszyn wirtualnych.

Pobieranie szczegółów maszyny wirtualnej serwera

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

Zatrzymaj serwer http w regionie 1

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

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

Weryfikacja, czy usługa regionalna jest w złym stanie

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

Dane wyjściowe powinny wyglądać podobnie do tych:

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}

Dane wyjściowe powinny wyglądać podobnie do tych:

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

Przełączanie awaryjne klienta w regionie testowym 1

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

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

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

Stan złożony w przypadku PSC zaktualizował system równoważenia obciążenia konsumenta i skierował go tak, aby unikał niesprawnej usługi backendu w regionie 1. Zamiast tego skierował ruch do sprawnej usługi bar w regionie 2.

Ponowne uruchamianie serwera 1 http w regionie

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

Dane wyjściowe powinny teraz zawierać stan HEALTHY podobny do tego...

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

Zmienianie zasady dotyczącej stanu

Producenci mogą dostosowywać zasady dotyczące stanu usługi na podstawie różnych kryteriów. Zasób zasady agregacji stanu określa minimalne progi wymagane do utrzymania stanu „działa prawidłowo” we wszystkich źródłach informacji o stanie (usługach backendu).

Aktualizowanie zasady agregacji stanu usługi bar

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

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

Ta zmiana zasad dotyczących zdrowia producenta ma następujące konsekwencje:

  1. Zmniejsza minimalny próg dobrego stanu z 60% do 40% – teraz pojedyncze niepowodzenie instancji maszyny wirtualnej nie spowoduje stanu złego stanu na podstawie --healthy-percent-threshold (stan niepowodzenia będzie wynosić 50%, a do osiągnięcia stanu dobrego wystarczy 40%).
  2. Zwiększa minimalną liczbę backendów w dobrym stanie z 1 do 2 instancji maszyn wirtualnych – teraz awaria pojedynczej instancji maszyny wirtualnej spowoduje stan zły na podstawie --min-healthy-threshold (stan awarii będzie wynosić 1, ale do stanu dobrego potrzeba 2)

Usługa bar w regionie 2 w złym stanie

Ten scenariusz symuluje awarię usługi producenta PSC bar w regionie 2 przez zatrzymanie serwera WWW na jednej z 2 instancji maszyn wirtualnych.

Pobieranie szczegółów maszyny wirtualnej serwera

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

Zatrzymaj serwer http w regionie 2

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

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

Weryfikacja, czy usługa regionalna jest w złym stanie

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

Dane wyjściowe powinny wyglądać podobnie do tych:

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}

Dane wyjściowe powinny wyglądać podobnie do tych:

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

Testowanie przełączania awaryjnego klienta w regionie 2

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

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

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

Stan złożony w przypadku PSC zaktualizował system równoważenia obciążenia konsumenta i skierował go tak, aby unikał niesprawnej usługi backendu w regionie 2. Zamiast tego skierował ruch do sprawnej usługi foo w regionie 1.

Jeśli system równoważenia obciążenia konsumenta widzi wszystkie usługi producenta jako nieprawidłowe, nie może przełączyć się na prawidłową instancję. System równoważenia obciążenia powinien rozdzielać ruch między wszystkie nieprawidłowe backendy (fail open).

To koniec części testowej… przejdźmy do monitorowania.

8. Monitorowanie stanu zdrowia

Zmiany stanu zdrowia są rejestrowane domyślnie. Projekty producenta mogą wyświetlać logi źródeł informacji o stanie zdrowia i złożonych testów stanu zdrowia. Projekty konsumenta mogą wyświetlać logi negatywnych grup końcowych usług PSC połączonych z opublikowanymi usługami za pomocą złożonego testu stanu zdrowia.

Chociaż w tym module zasoby konsumenta i producenta są wdrażane w tym samym projekcie, aby uprościć proces, w przypadku wdrożenia w osobnych projektach dzienniki będą pokazywać te 2 role oddzielnie.

Monitorowany zasób

Wyświetl

Nazwa logu

Źródła informacji o stanie i złożone kontrole

Widok producenta

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

Grupy punktów końcowych sieci Private Service Connect

Widok klienta

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

Logi producenta

Logi producenta pokazują wewnętrzne podsumowanie stanu usług producenta:

  • HealthSource: stan poszczególnych usług backendu (np. stan maszyn wirtualnych mig-bar i mig-foo);
  • CompositeHealthCheck: zagregowany stan usługi w regionie opublikowanej usługi, który jest mapowany na miejsce docelowe reguły przekierowania producenta (np. fr-bar lub 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
  )'

Logi konsumenckie

W logach usługobiorcy widoczny jest propagowany stan zasobów usługobiorcy:

  • NetworkEndpointGroup: propagowany stan kondycji grupy punktów końcowych sieci w usłudze PSC połączonej z opublikowaną usługą (np. neg-bar i neg-foo);

W przypadku oddzielnej konfiguracji konsumenta i producenta użyj tego zapytania do dziennika w projekcie konsumenta, aby kierować reklamy na złożone zdarzenia związane ze zdrowiem w przypadku negatywnych zdarzeń związanych z prywatnością i bezpieczeństwem konsumentów.

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

To koniec monitorowania. Przejdźmy do czyszczenia.

9. Czyszczenie 

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

Gratulacje! Udało Ci się skonfigurować złożoną kontrolę stanu dla PSC i przetestować automatyczne przełączanie awaryjne w regionie.

Jeśli masz jakieś uwagi, pytania lub poprawki, możesz je przesłać za pomocą tego formularza opinii.

Dziękujemy!