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

1. Введение

Последнее обновление: 22 сентября 2022 г.

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

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

Cloud DNS поддерживает следующие политики маршрутизации:

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

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

Примечание. На момент написания этой лабораторной работы политика отработки отказа и поддержка проверок работоспособности находились в общедоступной предварительной версии.

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

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

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

Проверка здоровья

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

Что ты построишь

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

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

• Внутренний балансировщик нагрузки L4 в регионе REGION_1
• ВМ с веб-сервером Apache в REGION_1.

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

• Внутренний балансировщик нагрузки L4 в регионе REGION_2
• ВМ с веб-сервером Apache в REGION_2.

Настройка такая, как показано ниже —

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

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

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

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

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

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

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

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

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

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

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

Запустить Cloud Shell

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

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

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

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

3. Версия Google Cloud SDK

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

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

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

Команда

gcloud version | grep "Google Cloud SDK"

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

Google Cloud SDK 401.0.0

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

Внимание: выберите вариант 1 или 2 в зависимости от вывода команды gcloud version .

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

Необязательная команда

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

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

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

Установить идентификатор проекта

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

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

Примечание. В этой лабораторной работе мы используем регионы us-west1 и us-east4. Вычислительная мощность может быть ограничена в зоне. Если при создании виртуальных машин вы видите какие-либо ошибки емкости, используйте другой регион/зону. Список доступных регионов и зон доступен здесь .

Проверять

Теперь, когда переменные среды установлены, давайте проверим их с помощью команды 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

Включить DNS API

Команда

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.

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

Команды

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

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

Команды

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.

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

Примечание. В этой лабораторной работе мы используем регионы us-west1 и us-east4. Вычислительная мощность может быть ограничена в зоне. Если при создании виртуальных машин вы видите какие-либо ошибки емкости, используйте другой регион/зону. Список доступных регионов и зон доступен здесь .

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

Используйте команду 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.

Группа экземпляров Регион_1

Команды

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

Группа экземпляров Регион_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.

Группа экземпляров Регион_1

Команды

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

Группа экземпляров Регион_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.

Чтобы создать ILB 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 имеет IP-адрес 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 | Экземпляры виртуальных машин».

Нажмите кнопку 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-адрес основного балансировщика нагрузки примерно через 10 секунд. 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