Многорегиональное переключение для региональных внешних конечных точек с использованием проверок работоспособности Cloud DNS

1. Введение

Сервис Cloud DNS предлагает высокопроизводительное, отказоустойчивое и глобальное решение для системы доменных имен (DNS), позволяющее публиковать зоны и записи без необходимости в самостоятельном управлении инфраструктурой DNS.

В первую очередь важно отметить, что Cloud DNS включает в свои политики маршрутизации для внешних конечных точек поддержку проверки работоспособности и автоматического переключения при сбоях . Однако следует отметить, что проверки работоспособности для этих внешних конечных точек доступны исключительно в публичных зонах, а сами конечные точки должны быть общедоступны через Интернет.

Что вы узнаете

• Как создать региональный внешний балансировщик нагрузки приложений с группой неуправляемых экземпляров.
• Как настроить проверки работоспособности Cloud DNS для внешней маршрутизации DNS.
• Как создать политику маршрутизации с резервированием .

Что вам понадобится

• Базовые знания DNS.
• Базовые знания Google Compute Engine.
• Базовые знания Application Load Balancer.
• Проект Google Cloud с правами владельца.
• Общедоступный домен , находящийся в вашей собственности, для которого вы можете создать общедоступную зону Cloud DNS.
• В настоящее время в рамках проекта Google Cloud не применяются следующие организационные политики: защищенные виртуальные машины и группы конечных точек интернет-сети .

ПРИМЕЧАНИЕ: Вам потребуется обновить серверы имен общедоступной зоны, которую вы создадите в этой лабораторной работе, указав серверы DNS вашего поставщика, управляющего вашим доменом.

2. Топология Codelab

В этом практическом занятии вы будете использовать проверки работоспособности Cloud DNS для внешних конечных точек, чтобы перенаправлять трафик на резервный региональный внешний балансировщик нагрузки приложений, если бэкэнд основного балансировщика нагрузки выйдет из строя.

Вам предстоит создать веб-сайт в двух регионах, каждый из которых будет обслуживаться внешним балансировщиком нагрузки приложений (External Application Load Balancer ). Затем вы настроите проверки работоспособности Cloud DNS с политикой маршрутизации с резервированием .

3. Настройка и требования

Настройка среды для самостоятельного обучения

1. Войдите в консоль Google Cloud и создайте новый проект или используйте существующий. Если у вас еще нет учетной записи Gmail или Google Workspace, вам необходимо ее создать .

• Название проекта — это отображаемое имя участников данного проекта. Это строка символов, не используемая API Google. Вы всегда можете его изменить.
• Идентификатор проекта уникален для всех проектов Google Cloud и является неизменяемым (его нельзя изменить после установки). Консоль Cloud автоматически генерирует уникальную строку; обычно вам неважно, какая она. В большинстве практических заданий вам потребуется указать идентификатор вашего проекта (обычно обозначается как PROJECT_ID ). Если сгенерированный идентификатор вас не устраивает, вы можете сгенерировать другой случайный идентификатор. В качестве альтернативы вы можете попробовать свой собственный и посмотреть, доступен ли он. После этого шага его нельзя изменить, и он сохраняется на протяжении всего проекта.
• К вашему сведению, существует третье значение — номер проекта , которое используется некоторыми API. Подробнее обо всех трех значениях можно узнать в документации .

Внимание: Идентификатор проекта является уникальным во всем мире и не может быть использован кем-либо еще после того, как вы его выбрали. Вы являетесь единственным пользователем этого идентификатора. Даже если проект будет удален, идентификатор нельзя будет использовать снова.

Примечание: Если вы используете учетную запись Gmail, вы можете оставить значение по умолчанию « Без организации» . Если вы используете учетную запись Google Workspace, выберите местоположение, которое подходит для вашей организации.

2. Далее вам потребуется включить оплату в консоли Cloud для использования ресурсов/API Cloud. Выполнение этого практического задания не потребует больших затрат, если вообще потребует. Чтобы отключить ресурсы и избежать дополнительных расходов после завершения этого урока, вы можете удалить созданные ресурсы или удалить проект. Новые пользователи Google Cloud имеют право на бесплатную пробную версию стоимостью 300 долларов США .

Запустить Cloud Shell

Хотя Google Cloud можно управлять удаленно с ноутбука, в этом практическом занятии вы будете использовать Google Cloud Shell — среду командной строки, работающую в облаке.

В консоли Google Cloud нажмите на значок Cloud Shell на панели инструментов в правом верхнем углу:

Подготовка и подключение к среде займут всего несколько минут. После завершения вы должны увидеть что-то подобное:

Эта виртуальная машина содержит все необходимые инструменты разработки. Она предоставляет постоянный домашний каталог объемом 5 ГБ и работает в облаке Google, что значительно повышает производительность сети и аутентификацию. Вся работа в этом практическом задании может выполняться в браузере. Вам не нужно ничего устанавливать.

4. Прежде чем начать

Включить API

Внутри Cloud Shell убедитесь, что ваш проект настроен, и настройте переменные.

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

Включите все необходимые службы

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

5. Создайте инфраструктуру балансировки нагрузки в облаке.

В этом разделе вы создадите необходимые VPC, подсети, правила брандмауэра, виртуальные машины и группы неуправляемых экземпляров в двух разных регионах для поддержки основного и резервного балансировщиков нагрузки.

Сеть VPC

Из Cloud Shell

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

Создайте две подсети в REGION_A (основная) и REGION_B (резервная) для размещения серверных веб-серверов.

Создание подсетей

Из 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

Создайте в каждом регионе подсети, работающие только в режиме прокси, для соответствующего регионального внешнего балансировщика нагрузки приложений, который будет создан позже.

Эта выделенная подсеть, предназначенная только для прокси-серверов, является обязательным требованием для всех региональных балансировщиков нагрузки на базе Envoy, развернутых в одном регионе сети external-lb-vpc. Эти прокси-серверы фактически разрывают соединение клиента и впоследствии устанавливают новые соединения с бэкэнд-сервисами.

Из 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

Создание правил сетевого брандмауэра

fw-allow-health-check. Правило входящего трафика, применяемое к экземплярам, ​​подлежащим балансировке нагрузки, которое разрешает весь TCP-трафик от систем проверки работоспособности Google Cloud (в сетях 130.211.0.0/22 ​​и 35.191.0.0/16). В этом примере используется целевой тег load-balanced-backend для идентификации виртуальных машин, к которым применяется правило брандмауэра.

fw-allow-proxies. Правило входящего трафика, применяемое к экземплярам, ​​подлежащим балансировке нагрузки, которое разрешает TCP-трафик через порт 80 от управляемых прокси-серверов регионального внешнего балансировщика нагрузки приложений. В этом примере используется целевой тег load-balanced-backend для идентификации виртуальных машин, к которым применяется правило брандмауэра.

Из 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

Чтобы разрешить IAP подключаться к вашим виртуальным машинам, создайте правило брандмауэра, которое:

• Применяется ко всем экземплярам виртуальных машин, к которым вы хотите обеспечить доступ с помощью IAP.
• Разрешает входящий трафик из диапазона IP-адресов 35.235.240.0/20. Этот диапазон содержит все IP-адреса, которые IAP использует для пересылки TCP-трафика.

Из 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. Создайте облачный NAT и облачные маршрутизаторы.

Для того чтобы частные виртуальные машины могли загружать и устанавливать пакеты из интернета, вам потребуются шлюзы Cloud NAT в обоих регионах.

• Нашим виртуальным машинам веб-сервера потребуется загрузить и установить веб-сервер Apache.
• Клиентской виртуальной машине потребуется загрузить и установить пакет dnsutils, который мы будем использовать для тестирования.

Каждый шлюз Cloud NAT связан с одной сетью VPC, регионом и облачным маршрутизатором. Поэтому, прежде чем создавать шлюзы NAT, необходимо создать облачные маршрутизаторы в каждом регионе.

Создание облачных маршрутизаторов

Из 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

Создание NAT-шлюзов

Из 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

Создание виртуальных машин бэкэнда и неуправляемых групп экземпляров.

Создайте виртуальную машину в каждом регионе и установите веб-сервер (например, Apache):

Из 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'

Создайте группу неуправляемых экземпляров и добавьте в нее экземпляр виртуальной машины для каждого региона:

Из 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. Настройка региональных внешних балансировщиков нагрузки приложений.

Вам потребуется настроить полноценный региональный внешний балансировщик нагрузки приложений как в регионе A (основной), так и в REGION_B (резервный).

Создание проверок состояния и серверных служб

Региональные внешние балансировщики нагрузки приложений работают на основе Envoy и требуют настройки региональных проверок работоспособности.

Создайте HTTP-проверку работоспособности (используемую балансировщиками нагрузки для проверки работоспособности экземпляра):

В облачной оболочке

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

Создайте региональную службу бэкэнда и подключите к ней группу экземпляров в каждом регионе.

В облачной оболочке

# 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

ПРИМЕЧАНИЕ: Для создания готовой к использованию в производственной среде конфигурации рекомендуется использовать целевые HTTPS-прокси, порт 443 и сертификат на балансировщике нагрузки.

Создание фронтенд-компонентов

Создайте карты URL-адресов и настройте целевые HTTP-прокси в обоих регионах:

В облачной оболочке

#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

Зарезервировать статические IP-адреса (внешние) для правил переадресации:

В облачной оболочке

# 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

Создайте правила пересылки для двух балансировщиков нагрузки:

В облачной оболочке

# 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

Настройка облачного DNS для обеспечения отказоустойчивости

Создать проверку работоспособности Cloud DNS для внешних конечных точек

Необходимо создать отдельную глобальную проверку работоспособности для публичных IP-адресов балансировщика нагрузки . Это отличается от внутренней проверки работоспособности балансировщика нагрузки.

Сначала определим внешние IP-адреса балансировщиков нагрузки для настройки политики отказоустойчивости и экспортируем их в качестве переменной.

В облачной оболочке

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

Примечание : Если бета-версия gcloud не установлена, вы можете установить её, выполнив следующие команды.

gcloud components update

gcloud components install beta

Создайте глобальную проверку работоспособности DNS (требуется три исходных региона):

В облачной оболочке

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

Создайте общедоступную управляемую зону и политику маршрутизации для обеспечения отказоустойчивости.

Создайте общедоступную управляемую зону (используйте принадлежащий вам DNS-домен):

В облачной оболочке

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

Создайте запись типа A с политикой маршрутизации при отказе . Эта политика указывает на основной IP-адрес и использует проверку работоспособности для определения момента переключения на резервный IP-адрес.

Приведённая ниже команда использует имена правил пересылки балансировщика нагрузки для указания IP-адресов в политике маршрутизации.

Примечание : замените имя записи " 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. Тестирование регионального переключения при сбое

1. Первоначальная проверка: Используйте инструмент (например, dig или веб-браузер) для запроса к вашему домену. Он должен разрешить основной IP-адрес ( $PRIMARY_IP ) и вернуть страницу "Регион A - Основной бэкэнд".

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>

Вывод из браузера

2. Имитация переключения на резервный сервер: Войдите в основную виртуальную машину ( vm-a ) и выключите Apache, чтобы имитировать сбой в работе:

В облачной оболочке

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

3. Проверка работоспособности: Подождите 2-3 минуты, пока проверка работоспособности DNS не покажет, что основная конечная точка неисправна.

# 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. Проверка отказоустойчивости: повторно запросите свой домен. Теперь он должен разрешаться в резервный IP-адрес ( $BACKUP_IP ) и возвращать страницу "Регион B - Резервная система".

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>

Вывод из браузера

5. Имитация восстановления после сбоя (необязательно): подключитесь по SSH и запустите Apache на основной виртуальной машине, затем дождитесь завершения проверки работоспособности DNS, которая покажет, что основная конечная точка исправна. Трафик должен автоматически перенаправляться обратно на основной IP-адрес.
6. Дополнительно: Вы можете проанализировать журналы проверки работоспособности Cloud DNS, выполнив следующую команду в облачной оболочке.

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. Этапы очистки

Удалите все компоненты, чтобы избежать дополнительных расходов.

Из 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. Поздравляем!

Поздравляем с завершением Codelab!

• Вы успешно настроили и проверили многорегиональную систему переключения в активном и пассивном режимах с использованием проверок работоспособности Cloud DNS и регионального внешнего балансировщика нагрузки приложений.