Эта страница переведена с помощью Cloud Translation API.

Отработка отказа в нескольких регионах с использованием политик маршрутизации Cloud DNS и проверок работоспособности внутреннего балансировщика нагрузки TCP/UDP

1. Введение

Последнее обновление: 22.09.2022

Что такое политика маршрутизации DNS?

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

Облачный DNS поддерживает следующие политики маршрутизации:

Взвешенная политика маршрутизации циклического распределения
Политика маршрутизации на основе геолокации
Политика маршрутизации на основе геозон
Политика маршрутизации при отказе

В этой лабораторной работе вы настроите и протестируете политику маршрутизации с резервированием.

Политика маршрутизации при отказе

Cloud DNS поддерживает проверку работоспособности внутренних балансировщиков нагрузки TCP/UDP с включенным глобальным доступом. С помощью политики маршрутизации с резервированием можно настроить основные и резервные IP-адреса для записи ресурса. В обычном режиме работы Cloud DNS будет отвечать на запросы IP-адресами, выделенными в основном наборе. Когда все IP-адреса в основном наборе выходят из строя (состояние работоспособности меняется на «неработоспособный»), Cloud DNS начинает обслуживать IP-адреса из резервного набора.

Медицинские осмотры

Политика маршрутизации DNS будет зависеть от встроенных проверок работоспособности внутреннего балансировщика нагрузки (UHC). Внутренний балансировщик нагрузки считается работоспособным, если 20% (или более) бэкэндов находятся в рабочем состоянии. Проверки работоспособности для внутренних балансировщиков нагрузки TCP/UDP и HTTP(S) предоставляют различную информацию. Для внутреннего балансировщика нагрузки HTTP(S) UHC предоставляет информацию о состоянии работоспособности всех прокси-серверов Envoy, а для внутреннего балансировщика нагрузки TCP/UDP Cloud DNS получает прямые сигналы о работоспособности от отдельных экземпляров бэкэндов. Подробную информацию о проверках работоспособности можно найти здесь .

Что вы построите

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

Активные ресурсы -

Внутренний балансировщик нагрузки L4 в РЕГИОНЕ_1
Виртуальная машина, на которой запущен веб-сервер Apache в регионе REGION_1.

Резервные ресурсы -

Внутренний балансировщик нагрузки L4 в регионе_2
Виртуальная машина, на которой запущен веб-сервер Apache в регионе REGION_2.

Схема подключения показана ниже.

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

Как создать политику маршрутизации с резервированием при сбое
Запустить переключение DNS на резервный сервер
Как перенаправить трафик на резервный набор

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

Базовые знания DNS
Базовые знания Google Compute Engine.
Базовые знания о внутреннем балансировщике нагрузки L4.

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

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

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

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

Запустить Cloud Shell

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

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

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

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

3. Версия Google Cloud SDK

На момент написания этой статьи последней версией Google Cloud SDK является 401.0.0 . Все команды в этом лабораторном задании были протестированы с использованием последней версии Google Cloud SDK. Прежде чем продолжить, убедитесь, что Cloud Shell использует последнюю версию SDK.

Проверка версии SDK

Используйте команду gcloud version для проверки версии SDK. Выполните следующие команды в Cloud Shell.

Командование

gcloud version | grep "Google Cloud SDK"

Пример выходных данных

Google Cloud SDK 401.0.0

Следующие шаги

Если версия SDK — 401.0.0 или выше, перейдите к следующему разделу.
Если версия SDK ниже 401.0.0 , выполните указанную ниже команду для обновления SDK.

Дополнительная команда

sudo apt-get update && sudo apt-get install google-cloud-sdk

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

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

Настройте идентификатор проекта.

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

USER@cloudshell:~ (PROJECT_ID)$

Если вы все же хотите изменить идентификатор проекта, используйте указанную ниже команду; приглашение командной строки Cloud Shell изменится с (PROJECT_ID) на (YOUR-PROJECT-ID)

Дополнительная команда

gcloud config set project [YOUR-PROJECT-ID]

Пример выходных данных

Updated property [core/project].
USER@cloudshell:~ (YOUR-PROJECT-ID)$

Настройте переменные среды.

Установите переменные среды.

Для установки переменных среды мы будем использовать команду export . Выполните следующие команды в Cloud Shell.

Команды

export REGION_1=us-west1

export REGION_1_ZONE=us-west1-a

export REGION_2=us-east4

export REGION_2_ZONE=us-east4-a

Проверять

Теперь, когда переменные среды установлены, давайте проверим это с помощью команды echo . Результатом выполнения каждой команды должно быть значение, которое мы настроили выше с помощью команды export . Выполните следующие команды в Cloud Shell.

Команды

echo $REGION_1

echo $REGION_1_ZONE

echo $REGION_2

echo $REGION_2_ZONE

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

Используйте команду gcloud services enable для включения API вычислительных ресурсов и DNS. Выполните следующие команды в Cloud Shell.

Включите API вычислений

Командование

gcloud services enable compute.googleapis.com

Включите API DNS

Командование

gcloud services enable dns.googleapis.com

Проверять

Теперь, когда службы включены, давайте проверим это с помощью команды gcloud services list , чтобы получить список всех включенных API.

Командование

gcloud services list | grep -E 'compute|dns'

Пример выходных данных

NAME: compute.googleapis.com
NAME: dns.googleapis.com

5. Создайте правила для сети VPC, подсетей и брандмауэра.

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

Создание сети VPC

Используйте команду gcloud compute networks create для создания сети VPC. Мы устанавливаем режим подсети как пользовательский, поскольку на следующем шаге мы создадим собственные подсети. Выполните следующие команды в Cloud Shell.

Командование

gcloud compute networks create my-vpc --subnet-mode custom

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

Используйте команду gcloud compute networks subnets create для создания двух подсетей: одной в регионе REGION_1 и одной в регионе REGION_2. Выполните следующие команды в Cloud Shell.

Подсеть REGION_1

Командование

gcloud compute networks subnets create ${REGION_1}-subnet \
--network my-vpc \
--range 10.1.0.0/24 \
--region $REGION_1

Подсеть REGION_2

Командование

gcloud compute networks subnets create ${REGION_2}-subnet \
--network my-vpc \
--range 10.2.0.0/24 \
--region $REGION_2

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

Необходимо разрешить трафик на порту 80 из подсетей VPC и из диапазонов IP-адресов, используемых для проверки работоспособности балансировщика нагрузки.

Кроме того, вам также необходимо создать правило брандмауэра, разрешающее SSH-трафик на клиентских виртуальных машинах.

Для создания правил брандмауэра используйте команду gcloud compute firewall-rules create . Выполните следующие команды в Cloud Shell.

Разрешить трафик на порту 80

Командование

gcloud compute firewall-rules create allow-http-lb-hc \
--allow tcp:80 --network my-vpc \
--source-ranges 10.1.0.0/24,10.2.0.0/24,35.191.0.0/16,130.211.0.0/22 \
--target-tags=allow-http

Разрешите SSH-трафик на виртуальной машине клиента.

Командование

gcloud compute firewall-rules create allow-ssh \
--allow tcp:22 --network my-vpc \
--source-ranges 0.0.0.0/0 \
--target-tags=allow-ssh

6. Создайте облачный NAT.

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

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

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

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

Используйте команду gcloud compute routers create для создания облачных маршрутизаторов в регионах us-west1 и us-east4. Выполните следующие команды в Cloud Shell.

Маршрутизатор облака Region_1

Команды

gcloud compute routers create "${REGION_1}-cloudrouter" \
--region $REGION_1 --network=my-vpc --asn=65501

Маршрутизатор облака Region_2

Команды

gcloud compute routers create "${REGION_2}-cloudrouter" \
--region $REGION_2 --network=my-vpc --asn=65501

Создайте NAT-шлюзы

Используйте команду gcloud compute routers nat create для создания NAT-шлюзов в регионах us-west1 и us-east4. Выполните следующие команды в Cloud Shell.

NAT-шлюз региона_1

Команды

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

NAT-шлюз региона_2

Команды

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

7. Создание виртуальных машин Compute Engine.

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

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

Для создания веб-серверов используйте команду ` gcloud compute instances create . Нам нужно создать два веб-сервера: один в регионе REGION_1, а другой в регионе REGION_2. Для установки и настройки Apache на веб-серверах мы используем скрипты запуска.

Веб-сервер REGION_1

Выполните следующую команду в Cloud Shell.

Командование

gcloud compute instances create "${REGION_1}-instance" \
--image-family=debian-11 --image-project=debian-cloud \
--zone=$REGION_1_ZONE \
--network-interface=network=my-vpc,subnet=${REGION_1}-subnet,no-address \
--tags=allow-http \
--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://169.254.169.254/computeMetadata/v1/instance/name)"
    echo "Page served from: $vm_hostname" | \
    tee /var/www/html/index.html
    systemctl restart apache2'

Веб-сервер REGION_2

Выполните следующую команду в Cloud Shell.

Командование

gcloud compute instances create "${REGION_2}-instance" \
--image-family=debian-11 --image-project=debian-cloud \
--zone=$REGION_2_ZONE \
--network-interface=network=my-vpc,subnet=${REGION_2}-subnet,no-address \
--tags=allow-http \
--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://169.254.169.254/computeMetadata/v1/instance/name)"
    echo "Page served from: $vm_hostname" | \
    tee /var/www/html/index.html
    systemctl restart apache2'

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

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

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

Используйте команду gcloud compute instance-groups unmanaged create для создания двух групп неуправляемых экземпляров: одной для веб-сервера us-west1 и одной для веб-сервера us-east4.

Группа экземпляров Region_1

Команды

gcloud compute instance-groups unmanaged create \
"${REGION_1}-instance-group" --zone=$REGION_1_ZONE

Группа экземпляров Region_2

Команды

gcloud compute instance-groups unmanaged create \
"${REGION_2}-instance-group" --zone=$REGION_2_ZONE

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

Используйте команду gcloud compute instance-groups unmanaged add-instances , чтобы добавить экземпляры в только что созданные группы экземпляров. Добавьте веб-сервер REGION_1 в группу экземпляров REGION_1, а веб-сервер REGION_2 — в группу экземпляров REGION_2.

Группа экземпляров Region_1

Команды

gcloud compute instance-groups unmanaged add-instances \
"${REGION_1}-instance-group" --instances $REGION_1-instance \
--zone=$REGION_1_ZONE

Группа экземпляров Region_2

Команды

gcloud compute instance-groups unmanaged add-instances \
"${REGION_2}-instance-group" --instances $REGION_2-instance \
--zone=$REGION_2_ZONE

Создайте клиентскую виртуальную машину.

Мы будем использовать эту виртуальную машину для проведения тестов и проверки нашей конфигурации DNS. Для установки пакета dnsutils мы используем скрипт запуска. Выполните следующие команды в Cloud Shell.

Командование

gcloud compute instances create client-instance --image-family=debian-11 \
--image-project=debian-cloud \
--zone=$REGION_1_ZONE \
--network-interface=network=my-vpc,subnet=${REGION_1}-subnet,no-address \
--tags=allow-ssh \
--metadata=startup-script='#! /bin/bash
    apt-get update
    apt-get install dnsutils -y'

8. Создайте внутренние балансировщики нагрузки уровня L4.

Для создания балансировщика нагрузки уровня L4 нам необходимо создать проверку работоспособности, серверную службу и правило переадресации.

Создать проверку здоровья

Для создания проверки работоспособности используйте команду gcloud compute health-checks create . Мы создаём базовую HTTP-проверку работоспособности, целевой порт — 80. Выполните следующие команды в Cloud Shell.

Командование

gcloud compute health-checks create http http-hc --port 80

Настройка серверных служб

Для создания бэкэнд-сервиса используйте команду ` gcloud compute backend-services create . После создания бэкэнд-сервисов мы добавим к ним группы неуправляемых экземпляров с помощью команды ` gcloud compute backend-services add-backend . Выполните следующие команды в Cloud Shell.

Создать бэкэнд-сервис

Команды

gcloud compute backend-services create $REGION_1-backend-service \
--load-balancing-scheme=INTERNAL --protocol=TCP \
--health-checks=http-hc --region=$REGION_1

gcloud compute backend-services create $REGION_2-backend-service \
--load-balancing-scheme=INTERNAL --protocol=TCP \
--health-checks=http-hc --region=$REGION_2

Добавить бэкэнд

Командование

gcloud compute backend-services add-backend $REGION_1-backend-service \
--instance-group=$REGION_1-instance-group \
--region=$REGION_1 \
--instance-group-zone=$REGION_1_ZONE

gcloud compute backend-services add-backend $REGION_2-backend-service \
--instance-group=$REGION_2-instance-group \
--region=$REGION_2 \
--instance-group-zone=$REGION_2_ZONE

Создайте правила пересылки.

Используйте команду gcloud compute forwarding-rules create для создания правил пересылки в обоих регионах. Выполните следующие команды в Cloud Shell.

Правило пересылки REGION_1

Команды

gcloud compute forwarding-rules create $REGION_1-ilb \
    --region=$REGION_1 \
    --load-balancing-scheme=internal \
    --network=my-vpc \
    --subnet=$REGION_1-subnet \
    --ip-protocol=TCP \
    --ports=80 \
    --backend-service=$REGION_1-backend-service \
    --backend-service-region=$REGION_1 \
    --allow-global-access

Правило пересылки REGION_2

gcloud compute forwarding-rules create $REGION_2-ilb \
    --region=$REGION_2 \
    --load-balancing-scheme=internal \
    --network=my-vpc \
    --subnet=$REGION_2-subnet \
    --ip-protocol=TCP \
    --ports=80 \
    --backend-service=$REGION_2-backend-service \
    --backend-service-region=$REGION_2 \
    --allow-global-access

9. Настройка DNS

В этом разделе мы создадим частную зону и набор DNS-записей с политикой маршрутизации для обеспечения отказоустойчивости.

Создайте частную DNS-зону.

Используйте команду ` gcloud dns managed-zones create для создания частной зоны для example.com. Мы будем использовать эту зону для создания набора записей ресурсов с политикой маршрутизации с резервированием. Выполните следующую команду в Cloud Shell.

Команды

gcloud dns managed-zones create example-com \
--dns-name example.com. --description="My private zone" \
--visibility=private --networks my-vpc

Создайте DNS-запись с политикой маршрутизации с резервированием.

Используйте команду gcloud dns record-sets create для создания DNS-записи с политикой маршрутизации с резервированием. Основной целью является балансировщик нагрузки в регионе REGION_1. Cloud DNS поддерживает только резервные цели на основе географического местоположения; резервный набор представляет собой политику геолокации с балансировщиком нагрузки REGION_2 в качестве цели как для REGION_1, так и для REGION_2. Выполните следующие команды в Cloud Shell.

Командование

gcloud dns record-sets create failover.example.com --ttl 5 --type A \
--routing-policy-type=FAILOVER \
--routing-policy-primary-data=$REGION_1-ilb \
--routing-policy-backup-data="${REGION_1}=${REGION_2}-ilb;${REGION_2}=${REGION_2}-ilb" \
--routing-policy-backup-data-type=GEO \
--zone=example-com \
--enable-health-checking

Пример выходных данных

NAME: failover.example.com.
TYPE: A
TTL: 5
DATA: Primary: "10.1.0.4, 80, tcp, https://www.googleapis.com/compute/v1/projects/my-clouddns-codelab/global/networks/my-vpc, my-clouddns-codelab, us-west1, regionalL4ilb" Backup: us-west1: "10.2.0.3, 80, tcp, https://www.googleapis.com/compute/v1/projects/my-clouddns-codelab/global/networks/my-vpc, my-clouddns-codelab, us-east4, regionalL4ilb";us-east4: "10.2.0.3, 80, tcp, https://www.googleapis.com/compute/v1/projects/my-clouddns-codelab/global/networks/my-vpc, my-clouddns-codelab, us-east4, regionalL4ilb"

10. Проверьте разрешение DNS.

Прежде чем тестировать нашу систему резервирования, запишем IP-адреса обоих внутренних балансировщиков нагрузки. Выполните следующие команды в Cloud Shell.

Командование

gcloud compute forwarding-rules list --filter="name:($REGION_1-ilb $REGION_2-ilb)"

Пример выходных данных

В этом примере у us-west1-ilb IP-адрес 10.1.0.4 , а у us-east4-ilb — 10.2.0.3

NAME: us-west1-ilb
REGION: us-west1
IP_ADDRESS: 10.1.0.4
IP_PROTOCOL: TCP
TARGET: us-west1/backendServices/us-west1-backend-service

NAME: us-east4-ilb
REGION: us-east4
IP_ADDRESS: 10.2.0.3
IP_PROTOCOL: TCP
TARGET: us-east4/backendServices/us-east4-backend-service

Теперь войдем в клиентский экземпляр и проверим разрешение DNS. В веб-консоли перейдите в раздел "Compute Engine | VM Instances".

Нажмите кнопку SSH, чтобы войти в клиентский экземпляр с консоли.

Теперь, когда мы находимся в клиентской виртуальной машине, используйте команду dig для разрешения доменного имени failover.example.com .

Цикл настроен на выполнение команды десять раз с задержкой в 6 секунд.

Командование

for i in {1..10}; do echo $i; dig failover.example.com +short; sleep 6; done

Поскольку значение TTL для DNS-записи установлено на 5 секунд, добавлен таймер задержки на 6 секунд. Таймер задержки гарантирует получение некэшированного DNS-ответа для каждого DNS-запроса. Выполнение этой команды займет приблизительно одну минуту.

В выходных данных вы увидите IP-адрес балансировщика нагрузки в основном наборе записи ресурса. В нашей конфигурации это будет IP-адрес балансировщика нагрузки в регионе us-west1.

11. Тестирование переключения на резервный сервер

Мы имитируем переключение на резервный сервер, удалив сетевой тег с виртуальной машины REGION_1. Это заблокирует доступ к порту 80, и в результате проверки работоспособности начнут завершаться с ошибкой.

Удалите сетевой тег

Используйте команду ` gcloud compute instances remove-tags , чтобы удалить сетевой тег с виртуальной машины. Выполните следующую команду в Cloud Shell.

Командование

gcloud compute instances remove-tags $REGION_1-instance \
--zone=$REGION_1_ZONE --tags=allow-http

Проверка работоспособности завершится неудачей через 10 секунд. Запустите тест разрешения DNS еще раз.

Разрешение DNS

С клиентского экземпляра выполните следующую команду.

Командование

for i in {1..10}; do echo $i; dig failover.example.com +short; sleep 6; done

В выходных данных вы увидите IP-адрес балансировщика нагрузки в резервном наборе записей ресурсов. В нашей конфигурации это будет IP-адрес балансировщика нагрузки в регионе us-east4.

12. Постепенный поток тестового трафика

По умолчанию политика отказоустойчивости возвращает IP-адрес основной конечной точки для всех DNS-запросов и возвращает резервные IP-адреса только в том случае, если основная точка не проходит проверку работоспособности. Cloud DNS позволяет пользователям настраивать коэффициент переадресации (Trickle Ratio), который позволяет Cloud DNS направлять часть трафика на резервные целевые точки, даже если основные целевые точки работают исправно. Значение коэффициента должно быть от 0 до 1 Значение по умолчанию — 0 .

Чтобы это проверить, давайте добавим сетевой тег обратно на веб-сервер REGION_1.

Добавить сетевой тег

Добавьте тег обратно к виртуальной машине веб-сервера, чтобы разрешить HTTP-трафик к виртуальной машине основного региона. Выполните следующую команду в Cloud Shell.

Командование

gcloud compute instances add-tags $REGION_1-instance \
--zone $REGION_1_ZONE --tags allow-http

Проверка состояния здоровья займет 10 секунд.

Убедитесь, что разрешение DNS указывает на основной балансировщик нагрузки. В нашей конфигурации это будет IP-адрес балансировщика нагрузки в регионе us-west1.

С клиентского экземпляра выполните следующую команду.

Командование

dig +short failover.example.com

Обновите запись DNS.

Теперь мы изменим DNS-запись для failover.example.com , чтобы перенаправлять 30% трафика на резервный сервер, даже когда основной сервер работает исправно. Выполните следующую команду в Cloud Shell.

Командование

gcloud dns record-sets update failover.example.com --ttl 30 --type A \
--routing-policy-type=FAILOVER \
--routing-policy-primary-data=$REGION_1-ilb \
--routing-policy-backup-data="${REGION_1}=${REGION_2}-ilb;${REGION_2}=${REGION_2}-ilb" \
--routing-policy-backup-data-type=GEO \
--zone=example-com --enable-health-checking \
--backup-data-trickle-ratio=0.3

Разрешение DNS

Выполните следующую команду на виртуальной машине клиента. Вы заметите, что DNS-запись failover.example.com будет разрешаться в IP-адрес основного балансировщика нагрузки примерно в 70% случаев и в IP-адрес резервного балансировщика нагрузки примерно в 30% случаев.

for i in {1..10}; do echo $i; dig failover.example.com +short; sleep 6; done

13. Этапы очистки

Для освобождения ресурсов, используемых в этой лабораторной работе, выполните следующие команды в CloudShell.

gcloud dns record-sets delete failover.example.com --type=A \
--zone=example-com --quiet

gcloud dns managed-zones delete example-com --quiet

gcloud compute forwarding-rules delete $REGION_1-ilb \
--region=$REGION_1 --quiet

gcloud compute forwarding-rules delete $REGION_2-ilb \
--region=$REGION_2 --quiet

gcloud compute backend-services delete $REGION_1-backend-service \
--region=$REGION_1 --quiet

gcloud compute backend-services delete $REGION_2-backend-service \
--region=$REGION_2 --quiet

gcloud compute health-checks delete http-hc --quiet

gcloud compute instances delete client-instance --zone=$REGION_1_ZONE --quiet

gcloud compute instance-groups unmanaged delete $REGION_1-instance-group \
--zone=$REGION_1_ZONE --quiet

gcloud compute instance-groups unmanaged delete $REGION_2-instance-group \
--zone=$REGION_2_ZONE --quiet

gcloud compute instances delete $REGION_1-instance \
--zone=$REGION_1_ZONE --quiet

gcloud compute instances delete $REGION_2-instance \
--zone=$REGION_2_ZONE --quiet

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

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

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

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

gcloud compute firewall-rules delete allow-ssh allow-http-lb-hc --quiet

gcloud compute networks subnets delete $REGION_1-subnet \
--region=$REGION_1 --quiet

gcloud compute networks subnets delete $REGION_2-subnet \
--region=$REGION_2 --quiet

gcloud compute networks delete my-vpc --quiet

14. Поздравляем!

Поздравляем, вы успешно развернули и протестировали политику маршрутизации с резервированием Cloud DNS.

Что мы рассмотрели

Как настроить политику маршрутизации с резервированием в Cloud DNS
Проверка отказоустойчивости DNS
Как перенаправить трафик на резервный набор

Что дальше?

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

Узнать больше

https://cloud.google.com/dns/docs/zones/manage-routing-policies