1. Введение
Последнее обновление: 22 сентября 2022 г.
Что такое политика маршрутизации DNS
Политики маршрутизации Cloud DNS позволяют пользователям настраивать управление трафиком на основе DNS в зависимости от определенных критериев, таких как вес, географическое местоположение или проверки работоспособности.
Cloud 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 в регионе REGION_1
- ВМ с веб-сервером Apache в REGION_1.
Резервные ресурсы -
- Внутренний балансировщик нагрузки L4 в регионе REGION_2
- ВМ с веб-сервером Apache в REGION_2.
Настройка такая, как показано ниже —
Что вы узнаете
- Как создать политику маршрутизации при отказе
- Запуск аварийного переключения DNS
- Как направить трафик на резервный набор
Что вам понадобится
- Базовые знания DNS
- Базовые знания Google Compute Engine.
- Базовые знания внутреннего балансировщика нагрузки L4.
2. Настройка и требования
- Войдите в Google Cloud Console и создайте новый проект или повторно используйте существующий. Если у вас еще нет учетной записи Gmail или Google Workspace, вам необходимо ее создать .
- Имя проекта — это отображаемое имя для участников этого проекта. Это строка символов, не используемая API Google. Вы можете обновить его в любое время.
- Идентификатор проекта должен быть уникальным для всех проектов Google Cloud и неизменяемым (нельзя изменить после его установки). Cloud Console автоматически генерирует уникальную строку; обычно тебя не волнует, что это такое. В большинстве лабораторий кода вам потребуется указать идентификатор проекта (обычно он обозначается как
PROJECT_ID). Если вам не нравится сгенерированный идентификатор, вы можете создать другой случайный идентификатор. Кроме того, вы можете попробовать свой собственный и посмотреть, доступен ли он. Его нельзя изменить после этого шага, и он останется в силе на протяжении всего проекта. - К вашему сведению, есть третье значение — номер проекта , который используют некоторые API. Подробнее обо всех трех этих значениях читайте в документации .
- Затем вам необходимо включить выставление счетов в 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
Следующие шаги
- Если версия 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 выглядит так, как показано ниже, и вы не планируете менять идентификатор проекта, вы можете перейти к следующему шагу (Установка переменных среды).
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-al10n
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
Включить 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.
В этом разделе вы создадите веб-серверы, неуправляемые группы экземпляров для веб-серверов и клиентской виртуальной машины.
Создание виртуальных машин веб-сервера
Используйте команду 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