Przełączanie awaryjne w wielu regionach w przypadku regionalnych zewnętrznych punktów końcowych za pomocą kontroli stanu Cloud DNS

1. Wprowadzenie

Usługa Cloud DNS to wydajne, odporne i globalne rozwiązanie DNS (Domain Name System), które umożliwia publikowanie stref i rekordów bez konieczności zarządzania własną infrastrukturą DNS.

Najważniejsze jest to, że Cloud DNS obsługuje kontrolę stanu i automatyczne przełączanie awaryjne w ramach zasad routingu dla zewnętrznych punktów końcowych. Pamiętaj jednak, że testy stanu tych zewnętrznych punktów końcowych są dostępne wyłącznie w strefach publicznych, a same punkty końcowe muszą być publicznie dostępne przez internet.

Czego się nauczysz

• Jak utworzyć regionalny zewnętrzny system równoważenia obciążenia aplikacji z niezarządzaną grupą instancji.
• Jak skonfigurować kontrole stanu Cloud DNS na potrzeby routingu zewnętrznego DNS.
• Jak utworzyć zasadę routingu przełączania awaryjnego.

Czego potrzebujesz

• Podstawowa wiedza o DNS.
• Podstawowa znajomość Google Compute Engine.
• Podstawowa wiedza o systemie równoważenia obciążenia aplikacji.
• Projekt Google Cloud z uprawnieniami właściciela
• Publiczna domena, której jesteś właścicielem i dla której możesz utworzyć publiczną strefę Cloud DNS.
• W projekcie Google Cloud nie są obecnie egzekwowane te zasady organizacji: chronione maszyny wirtualne i grupy punktów końcowych sieci internetowej.

UWAGA: musisz zaktualizować serwery nazw strefy publicznej, którą utworzysz w tym ćwiczeniu, u dostawcy DNS zarządzającego Twoją domeną.

2. Topologia ćwiczeń z programowania

W tym samouczku użyjesz kontroli stanu Cloud DNS dla zewnętrznych punktów końcowych, aby przekierować ruch do zapasowego regionalnego zewnętrznego systemu równoważenia obciążenia aplikacji, jeśli backend głównego systemu równoważenia obciążenia stanie się niesprawny.

Utworzysz witrynę w 2 regionach, z których każdy będzie obsługiwany przez zewnętrzny system równoważenia obciążenia aplikacji. Następnie skonfigurujesz kontrole stanu Cloud DNS za pomocą zasady routingu przełączania awaryjnego.

3. Konfiguracja i wymagania

Samodzielne konfigurowanie środowiska

1. Zaloguj się w konsoli Google Cloud i utwórz nowy projekt lub użyj istniejącego. Jeśli nie masz jeszcze konta Gmail ani Google Workspace, musisz je utworzyć.

• Nazwa projektu to wyświetlana nazwa uczestników tego projektu. Jest to ciąg znaków, który nie jest używany przez interfejsy API Google. Zawsze możesz ją zaktualizować.
• Identyfikator projektu jest unikalny we wszystkich projektach Google Cloud i nie można go zmienić po ustawieniu. Konsola Cloud automatycznie generuje unikalny ciąg znaków. Zwykle nie musisz się tym przejmować. W większości ćwiczeń z programowania musisz odwoływać się do identyfikatora projektu (zwykle oznaczanego jako PROJECT_ID). Jeśli wygenerowany identyfikator Ci się nie podoba, możesz wygenerować inny losowy identyfikator. Możesz też spróbować własnej nazwy i sprawdzić, czy jest dostępna. Po tym kroku nie można go zmienić i pozostaje on taki przez cały czas trwania projektu.
• Warto wiedzieć, że istnieje też trzecia wartość, numer projektu, której używają niektóre interfejsy API. Więcej informacji o tych 3 wartościach znajdziesz w dokumentacji.

Ostrzeżenie: identyfikator projektu jest unikalny globalnie i po jego wybraniu nie może być używany przez nikogo innego. Jesteś jedynym użytkownikiem tego identyfikatora. Nawet po usunięciu projektu nie można ponownie użyć jego identyfikatora.

Uwaga: jeśli używasz konta Gmail, możesz pozostawić domyślną lokalizację ustawioną na Brak organizacji. Jeśli używasz konta Google Workspace, wybierz lokalizację odpowiednią dla Twojej organizacji.

2. Następnie musisz włączyć płatności w konsoli Cloud, aby korzystać z zasobów i interfejsów API Google Cloud. Wykonanie tego laboratorium nie będzie kosztować dużo, a może nawet nic. Aby wyłączyć zasoby i uniknąć naliczania opłat po zakończeniu tego samouczka, możesz usunąć utworzone zasoby lub projekt. Nowi użytkownicy Google Cloud mogą skorzystać z bezpłatnego okresu próbnego, w którym mają do dyspozycji środki w wysokości 300 USD.

Uruchamianie Cloud Shell

Z Google Cloud można korzystać zdalnie na laptopie, ale w tym module praktycznym będziesz używać Google Cloud Shell, czyli środowiska wiersza poleceń działającego w chmurze.

W konsoli Google Cloud kliknij ikonę Cloud Shell na pasku narzędzi w prawym górnym rogu:

Uzyskanie dostępu do środowiska i połączenie się z nim powinno zająć tylko kilka chwil. Po zakończeniu powinno wyświetlić się coś takiego:

Ta maszyna wirtualna zawiera wszystkie potrzebne narzędzia dla programistów. Zawiera również stały katalog domowy o pojemności 5 GB i działa w Google Cloud, co znacznie zwiększa wydajność sieci i usprawnia proces uwierzytelniania. Wszystkie zadania w tym laboratorium możesz wykonać w przeglądarce. Nie musisz niczego instalować.

4. Zanim zaczniesz

Włącz interfejsy API

W Cloud Shell sprawdź, czy projekt jest skonfigurowany, i skonfiguruj zmienne.

gcloud auth login
gcloud config list project
gcloud config set project [YOUR-PROJECT-ID]
export projectid=[YOUR-PROJECT-ID]

# Define variables for regions and the domain
export REGION_A=us-central1
export REGION_B=us-west1
export DNS_ZONE=dnscodelab-zone
Export DNS_DOMAIN=gcp.<yourpublicdomain>.com
echo $projectid
echo $REGION_A
echo $REGION_B
echo $DNS_ZONE
echo $DNS_DOMAIN

Włącz wszystkie niezbędne usługi

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

5. Tworzenie infrastruktury Cloud Load Balancing

W tej sekcji utworzysz niezbędne sieci VPC, podsieci, reguły zapory sieciowej, maszyny wirtualne i niezarządzane grupy instancji w 2 różnych regionach, aby obsługiwać podstawowe i zapasowe systemy równoważenia obciążenia.

Sieć VPC

Z Cloud Shell

gcloud compute networks create external-lb-vpc --subnet-mode=custom

Utwórz 2 podsieci w regionach REGION_A (podstawowym) i REGION_B (zapasowym), aby hostować serwery WWW backendu.

Tworzenie podsieci

Z Cloud Shell

gcloud compute networks subnets create subnet-a --network=external-lb-vpc --region=$REGION_A --range=10.10.1.0/24

gcloud compute networks subnets create subnet-b --network=external-lb-vpc --region=$REGION_B --range=10.20.1.0/24

Utwórz podsieci tylko-proxy w każdym regionie dla odpowiedniego regionalnego zewnętrznego systemu równoważenia obciążenia aplikacji, który zostanie utworzony później.

Ta dedykowana podsieć tylko-proxy jest obowiązkowa w przypadku wszystkich regionalnych systemów równoważenia obciążenia opartych na Envoy wdrożonych w tym samym regionie sieci external-lb-vpc. Te serwery proxy zamykają połączenie klienta, a następnie nawiązują nowe połączenia z usługami backendu.

Z Cloud Shell

gcloud compute networks subnets create proxy-only-subnet-a \
--purpose=REGIONAL_MANAGED_PROXY \
--role=ACTIVE \
--region=$REGION_A \
--network=external-lb-vpc \
--range=10.129.0.0/23

gcloud compute networks subnets create proxy-only-subnet-b \
--purpose=REGIONAL_MANAGED_PROXY \
--role=ACTIVE \
--region=$REGION_B \
--network=external-lb-vpc \
--range=10.130.0.0/23

Tworzenie reguł zapory sieciowej

fw-allow-health-check. Reguła ruchu przychodzącego, która ma zastosowanie do instancji podlegających równoważeniu obciążenia i zezwalająca na cały ruch TCP z systemów kontroli stanu Google Cloud (w zakresach 130.211.0.0/22 i 35.191.0.0/16). W tym przykładzie do identyfikowania maszyn wirtualnych, do których ma zastosowanie reguła zapory sieciowej, używany jest tag docelowy load-balanced-backend.

fw-allow-proxies Reguła ruchu przychodzącego, która ma zastosowanie do instancji podlegających równoważeniu obciążenia i która zezwala na ruch TCP na portach 80 z zarządzanych serwerów proxy regionalnego zewnętrznego systemu równoważenia obciążenia aplikacji. W tym przykładzie do identyfikowania maszyn wirtualnych, do których ma zastosowanie reguła zapory sieciowej, używany jest tag docelowy load-balanced-backend.

Z Cloud Shell

gcloud compute firewall-rules create fw-allow-health-check \
    --network=external-lb-vpc \
    --action=allow \
    --direction=ingress \
    --source-ranges=130.211.0.0/22,35.191.0.0/16 \
    --target-tags=load-balanced-backend \
    --rules=tcp
gcloud compute firewall-rules create fw-allow-proxies \
  --network=external-lb-vpc \
  --action=allow \
  --direction=ingress \
  --source-ranges=10.129.0.0/23,10.130.0.0/23 \
  --target-tags=load-balanced-backend \
  --rules=tcp:80

Aby umożliwić IAP połączenie z instancjami maszyn wirtualnych, utwórz regułę zapory sieciowej, która:

• Dotyczy wszystkich instancji maszyn wirtualnych, które mają być dostępne przez IAP.
• Zezwala na ruch przychodzący z zakresu adresów IP 35.235.240.0/20. Ten zakres zawiera wszystkie adresy IP, których IAP używa do przekierowywania TCP.

Z Cloud Shell

gcloud compute firewall-rules create allow-ssh \
    --allow tcp:22 --network external-lb-vpc \
    --source-ranges 35.235.240.0/20  \
    --description "SSH with IAP" \
    --target-tags=allow-ssh

6. Tworzenie Cloud NAT i routerów Cloud Router

Aby prywatne maszyny wirtualne mogły pobierać i instalować pakiety z internetu, musisz mieć bramy Cloud NAT w obu regionach.

• Maszyny wirtualne serwera WWW będą musiały pobrać i zainstalować serwer WWW Apache.
• Na maszynie wirtualnej klienta trzeba pobrać i zainstalować pakiet dnsutils, który będzie używany do testowania.

Każda brama Cloud NAT jest powiązana z jedną siecią VPC, regionem i routerem Cloud Router. Zanim utworzymy bramy NAT, musimy utworzyć routery Cloud Router w każdym regionie.

Tworzenie routerów Cloud Router

Z Cloud Shell

gcloud compute routers create "$REGION_A-cloudrouter" \
--region $REGION_A --network=external-lb-vpc --asn=65501

gcloud compute routers create "$REGION_B-cloudrouter" \
--region $REGION_B --network=external-lb-vpc --asn=65501

Tworzenie bram NAT

Z Cloud Shell

gcloud compute routers nats create "$REGION_A-nat-gw" \
--router="$REGION_A-cloudrouter" \
--router-region=$REGION_A \
--nat-all-subnet-ip-ranges --auto-allocate-nat-external-ips

gcloud compute routers nats create "$REGION_B-nat-gw" \
--router="$REGION_B-cloudrouter" \
--router-region=$REGION_B \
--nat-all-subnet-ip-ranges --auto-allocate-nat-external-ips

Tworzenie maszyn wirtualnych backendu i niezarządzanych grup instancji

Utwórz maszynę wirtualną w każdym regionie i zainstaluj serwer WWW (np.Apache):

Z Cloud Shell

# Primary (Region A)
gcloud compute instances create vm-a \
--zone=$REGION_A-a \
--image-family=debian-12 --image-project=debian-cloud \
--subnet=subnet-a \
--no-address \
--tags=load-balanced-backend,allow-ssh \
--metadata=startup-script='#! /bin/bash
apt-get update
apt-get install apache2 -y
a2ensite default-ssl
a2enmod ssl
vm_hostname="$(curl -H "Metadata-Flavor:Google" \
http://metadata.google.internal/computeMetadata/v1/instance/name)"
echo "Page served from: $vm_hostname" - $REGION_A Primary Backend |\
tee /var/www/html/index.html
systemctl restart apache2'


# Backup (Region B)
gcloud compute instances create vm-b \
--zone=$REGION_B-a \
--image-family=debian-12 --image-project=debian-cloud \
--subnet=subnet-b \
--no-address \
--tags=load-balanced-backend,allow-ssh \
--metadata=startup-script='#! /bin/bash
apt-get update
apt-get install apache2 -y
a2ensite default-ssl
a2enmod ssl
vm_hostname="$(curl -H "Metadata-Flavor:Google" \
http://metadata.google.internal/computeMetadata/v1/instance/name)"
echo "Page served from: $vm_hostname" - $REGION_B Backup Backend |\
tee /var/www/html/index.html
systemctl restart apache2'

Utwórz niezarządzaną grupę instancji i dodaj do niej instancję maszyny wirtualnej w każdym regionie:

Z Cloud Shell

# Primary (Region A)
gcloud compute instance-groups unmanaged create ig-a --zone=$REGION_A-a

gcloud compute instance-groups unmanaged add-instances ig-a --zone=$REGION_A-a --instances=vm-a

# Backup (Region B)
gcloud compute instance-groups unmanaged create ig-b --zone=$REGION_B-a

gcloud compute instance-groups unmanaged add-instances ig-b --zone=$REGION_B-a --instances=vm-b

7. Konfigurowanie regionalnych zewnętrznych systemów równoważenia obciążenia aplikacji

Skonfigurujesz kompletny regionalny zewnętrzny system równoważenia obciążenia aplikacji w regionach REGION_A (podstawowym) i REGION_B (zapasowym).

Tworzenie kontroli stanu i usług backendu

Regionalne zewnętrzne systemy równoważenia obciążenia aplikacji są oparte na usłudze Envoy i wymagają skonfigurowania regionalnych kontroli stanu.

Utwórz kontrolę stanu HTTP (używaną przez systemy równoważenia obciążenia do sprawdzania stanu instancji):

W Cloud Shell

gcloud compute health-checks create http http-lb-hc-primary-region \
--port 80 \
--region=$REGION_A

​​gcloud compute health-checks create http http-lb-hc-backup-region \
--port 80 \
--region=$REGION_B

Utwórz regionalną usługę backendu i dołącz do niej grupę instancji w każdym regionie**.**

W Cloud Shell

# Primary (Region A)
gcloud compute backend-services create be-svc-a \
--load-balancing-scheme=EXTERNAL_MANAGED \
--protocol=HTTP \
--port-name=http \
--health-checks=http-lb-hc-primary-region \
--health-checks-region=$REGION_A \
--region=$REGION_A

gcloud compute backend-services add-backend be-svc-a \
--instance-group=ig-a \
--instance-group-zone=$REGION_A-a \
--region=$REGION_A

# Backup (Region B)
gcloud compute backend-services create be-svc-b \
--load-balancing-scheme=EXTERNAL_MANAGED \
--protocol=HTTP \
--port-name=http \
--health-checks=http-lb-hc-backup-region \
--health-checks-region=$REGION_B \
--region=$REGION_B

gcloud compute backend-services add-backend be-svc-b --instance-group=ig-b --instance-group-zone=$REGION_B-a --region=$REGION_B

UWAGA: w przypadku projektu gotowego do wdrożenia w środowisku produkcyjnym zalecamy używanie docelowych serwerów proxy HTTPS, portu 443 i certyfikatu w systemie równoważenia obciążenia.

Tworzenie komponentów frontendu

Utwórz mapy URL i docelowe serwery proxy HTTP w obu regionach:

W Cloud Shell

#Primary (Region A)
gcloud compute url-maps create url-map-a \
--default-service=be-svc-a \
--region=$REGION_A
gcloud compute target-http-proxies create http-proxy-a \
--url-map=url-map-a \
--url-map-region=$REGION_A \
--region=$REGION_A
#Backup (Region B)
gcloud compute url-maps create url-map-b \
--default-service=be-svc-b \
--region=$REGION_B

gcloud compute target-http-proxies create http-proxy-b \
--url-map=url-map-b \
--url-map-region=$REGION_B \
--region=$REGION_B

Zarezerwuj statyczne adresy IP (zewnętrzne) dla reguł przekierowania:

W Cloud Shell

# Primary IP (Region A)
gcloud compute addresses create rxlb-ip-a --region=$REGION_A

# Backup IP (Region B)
gcloud compute addresses create rxlb-ip-b --region=$REGION_B

Utwórz reguły przekierowania dla 2 systemów równoważenia obciążenia:

W Cloud Shell

# Primary (Region A)
gcloud compute forwarding-rules create http-fwd-rule-a \
--load-balancing-scheme=EXTERNAL_MANAGED \
--network=external-lb-vpc \
--region=$REGION_A \
--target-http-proxy-region=$REGION_A \
--address=rxlb-ip-a \
--target-http-proxy=http-proxy-a \
--ports=80

# Backup (Region B)
gcloud compute forwarding-rules create http-fwd-rule-b \
--load-balancing-scheme=EXTERNAL_MANAGED \
--network=external-lb-vpc \
--region=$REGION_B \
--target-http-proxy-region=$REGION_B \
--address=rxlb-ip-b \
--target-http-proxy=http-proxy-b \
--ports=80

Konfigurowanie Cloud DNS na potrzeby przełączania awaryjnego

Tworzenie kontroli stanu Cloud DNS dla zewnętrznych punktów końcowych

Musisz utworzyć dedykowaną globalną kontrolę stanu dla publicznych adresów IP systemu równoważenia obciążenia. Różni się ona od wewnętrznej kontroli stanu systemu równoważenia obciążenia.

Najpierw określmy zewnętrzne adresy IP systemów równoważenia obciążenia, aby skonfigurować zasadę przełączania awaryjnego, i wyeksportujmy je jako zmienną.

W Cloud Shell

PRIMARY_IP=$(gcloud compute addresses describe rxlb-ip-a --region=$REGION_A --format='get(address)')

BACKUP_IP=$(gcloud compute addresses describe rxlb-ip-b --region=$REGION_B --format='get(address)')

Uwaga: jeśli gcloud beta nie jest zainstalowany, możesz go zainstalować, uruchamiając te polecenia.

gcloud components update

gcloud components install beta

Utwórz globalną kontrolę stanu DNS (wymaga 3 regionów źródłowych):

W Cloud Shell

gcloud beta compute health-checks create http dns-failover-health-check \
    --global \
    --source-regions=$REGION_A,$REGION_B,europe-west1 \
    --request-path=/ \
    --check-interval=30s \
    --port=80 \
    --enable-logging

Utwórz publiczną strefę zarządzaną i zasadę routingu przełączania awaryjnego.

Utwórz publiczną strefę zarządzaną (użyj domeny DNS, której jesteś właścicielem):

W Cloud Shell

gcloud dns managed-zones create codelab-publiczone --dns-name=$DNS_DOMAIN --description="Codelab DNS Failover Zone"

Utwórz rekord A z zasadą routingu przełączania awaryjnego. Ta zasada wskazuje podstawowy adres IP i używa kontroli stanu, aby określić, kiedy przełączyć się na zapasowy adres IP.

Poniższe polecenie używa nazw reguł przekierowania systemu równoważenia obciążenia, aby odwoływać się do adresów IP w zasadach routingu.

Uwaga: zastąp nazwę rekordu „ codelab.gcp.axiszulu.com" with your actual domain name "codelab.gcp.<your public domain>.com"

gcloud beta dns record-sets create codelab.gcp.axiszulu.com. \
--type=A \
--ttl=5 \
--zone=codelab-publiczone \
--routing_policy_type=FAILOVER \
--routing-policy-primary-data=$PRIMARY_IP \
--routing-policy-backup-data-type=GEO \
--routing-policy-backup-item=location=$REGION_B,external_endpoints=$BACKUP_IP \
--health-check=dns-failover-health-check

8. Testowanie przełączania awaryjnego w regionie

1. Wstępna weryfikacja: użyj narzędzia (np. dig lub przeglądarki internetowej), aby wysłać zapytanie do domeny. Powinien on zostać rozpoznany jako podstawowy adres IP ($PRIMARY_IP) i zwrócić stronę „Region A – podstawowy backend”.

dig codelab.gcp.axiszulu.com

OUTPUT
; <<>> DiG 9.18.39-0ubuntu0.24.04.2-Ubuntu <<>> codelab.gcp.axiszulu.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16096
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;codelab.gcp.axiszulu.com.      IN      A

;; ANSWER SECTION:
codelab.gcp.axiszulu.com. 5     IN      A   <PRIMARY_IP>

Dane wyjściowe z przeglądarki

2. Symulacja przełączenia awaryjnego: zaloguj się na podstawową maszynę wirtualną (vm-a) i wyłącz Apache, aby zasymulować awarię:

W Cloud Shell

gcloud compute ssh vm-a --zone=$REGION_A-a --command="sudo systemctl stop apache2"

3. Sprawdź stan niepoprawny: poczekaj 2–3 minuty, aż kontrola stanu DNS oznaczy główny punkt końcowy jako niepoprawny.

# check health status
gcloud compute backend-services get-health be-svc-a --region=${REGION_A}

Output:
backend: https://www.googleapis.com/compute/v1/projects/precise-airship-466617-c3/zones/us-central1-a/instanceGroups/ig-a
status:
  healthStatus:
  - healthState: UNHEALTHY
    instance: https://www.googleapis.com/compute/v1/projects/precise-airship-466617-c3/zones/us-central1-a/instances/vm-a
    ipAddress: 10.10.1.2
    port: 80
  kind: compute#backendServiceGroupHealth

4. Sprawdź przełączanie awaryjne: ponownie wyślij zapytanie dotyczące domeny. Powinien teraz rozpoznać zapasowy adres IP ($BACKUP_IP) i wyświetlić stronę „Region B – zapasowy backend”.

dig codelab.gcp.axiszulu.com

OUTPUT
; <<>> DiG 9.18.39-0ubuntu0.24.04.2-Ubuntu <<>> codelab.gcp.axiszulu.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16096
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;codelab.gcp.axiszulu.com.      IN      A

;; ANSWER SECTION:
codelab.gcp.axiszulu.com. 5     IN      A   <BACKUP_IP>

Dane wyjściowe z przeglądarki

5. Symulacja powrotu po awarii (opcjonalnie): połącz się z podstawową maszyną wirtualną przez SSH i uruchom na niej serwer Apache. Poczekaj, aż kontrola stanu DNS oznaczy podstawowy punkt końcowy jako działający prawidłowo. Ruch powinien automatycznie wrócić do podstawowego adresu IP.
6. Opcjonalnie: możesz przeanalizować logowanie kontroli stanu Cloud DNS, uruchamiając w Cloud Shell to polecenie:

gcloud logging read "logName=projects/${projectid}/logs/compute.googleapis.com%2Fhealthchecks" \
--limit=10 \
--project=${projectid} \
--freshness=1d \
--format="table(timestamp:label=TIME, \
jsonPayload.healthCheckProbeResult.ipAddress:label=BACKEND_IP, \
jsonPayload.healthCheckProbeResult.previousDetailedHealthState:label=PREVIOUS_STATE, \
jsonPayload.healthCheckProbeResult.detailedHealthState:label=CURRENT_STATE, \
jsonPayload.healthCheckProbeResult.probeResultText:label=RESULT_TEXT)"

9. Procedura czyszczenia

Usuń wszystkie komponenty, aby uniknąć dalszych opłat.

Z Cloud Shell

# Delete VMs
gcloud compute instances delete vm-a --zone=$REGION_A-a --quiet
gcloud compute instances delete vm-b --zone=$REGION_B-a --quiet
# Delete Load Balancer Components (Primary)
gcloud compute forwarding-rules delete http-fwd-rule-a --region=$REGION_A --quiet
gcloud compute target-http-proxies delete http-proxy-a --region=$REGION_A --quiet
gcloud compute url-maps delete url-map-a --region=$REGION_A --quiet
gcloud compute backend-services delete be-svc-a --region=$REGION_A --quiet
gcloud compute addresses delete rxlb-ip-a --region=$REGION_A --quiet
# Delete Load Balancer Components (Backup)
gcloud compute forwarding-rules delete http-fwd-rule-b --region=$REGION_B --quiet
gcloud compute target-http-proxies delete http-proxy-b --region=$REGION_B --quiet
gcloud compute url-maps delete url-map-b --region=$REGION_B --quiet
gcloud compute backend-services delete be-svc-b --region=$REGION_B --quiet
gcloud compute addresses delete rxlb-ip-b --region=$REGION_B --quiet
# Delete Instance Groups and LB Health Checks
gcloud compute instance-groups unmanaged delete ig-a --zone=$REGION_A-a --quiet
gcloud compute instance-groups unmanaged delete ig-b --zone=$REGION_B-a --quiet
gcloud compute health-checks delete http-lb-hc-primary-region --region=$REGION_A --quiet
gcloud compute health-checks delete http-lb-hc-backup-region --region=$REGION_B --quiet

# Delete Cloud DNS Records Zone and DNS Heath Checks
gcloud dns record-sets delete $DNS_DOMAIN --type=A --zone=codelab-publiczone --quiet
gcloud dns managed-zones delete codelab-publiczone --quiet

gcloud compute health-checks delete dns-failover-health-check --global --quiet

# Delete Cloud NAT and Cloud Routers
gcloud compute routers nats delete $REGION_A-nat-gw \
--router=$REGION_A-cloudrouter --region=$REGION_A --quiet

gcloud compute routers nats delete $REGION_B-nat-gw \
--router=$REGION_B-cloudrouter --region=$REGION_B --quiet

gcloud compute routers delete $REGION_A-cloudrouter \
--region=$REGION_A --quiet

gcloud compute routers delete $REGION_B-cloudrouter \
--region=$REGION_B --quiet


# Delete Subnets and Firewall Rules
gcloud compute firewall-rules delete fw-allow-health-check --quiet
gcloud compute firewall-rules delete fw-allow-proxies --quiet
gcloud compute firewall-rules delete allow-ssh --quiet
gcloud compute networks subnets delete subnet-a \
--region=$REGION_A --quiet

gcloud compute networks subnets delete subnet-b \
--region=$REGION_B --quiet
gcloud compute networks subnets delete proxy-only-subnet-a \
--region=$REGION_A --quiet

gcloud compute networks subnets delete proxy-only-subnet-b \
--region=$REGION_B --quiet

gcloud compute networks delete external-lb-vpc --quiet

10. Gratulacje!

Gratulujemy ukończenia ćwiczenia.

• Udało Ci się skonfigurować i zweryfikować przełączanie awaryjne w wielu regionach w trybie aktywnym i pasywnym za pomocą kontroli stanu Cloud DNS i regionalnego zewnętrznego systemu równoważenia obciążenia aplikacji.