Перевод балансировщика сетевой нагрузки из целевых пулов в региональные серверные службы.

1. Введение

В этом руководстве приведены инструкции по переводу существующего балансировщика сетевой нагрузки с целевого пула бэкэндов на региональную службу бэкэнда.

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

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

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

• Опыт работы с балансировщиками нагрузки.

2. Обзор региональных серверных служб для балансировки сетевой нагрузки.

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

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

3. Преимущества региональных серверных служб

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

На начальном этапе региональные бэкэнд-сервисы предоставляют:

• Высокоточная проверка работоспособности с помощью унифицированной проверки — благодаря региональным бэкэнд-сервисам вы теперь можете в полной мере использовать возможности проверки работоспособности балансировки нагрузки, освобождаясь от ограничений устаревших проверок работоспособности по протоколу HTTP. В целях соответствия нормативным требованиям, проверки работоспособности по протоколу TCP с поддержкой пользовательских строк запроса и ответа или HTTPS были распространенным запросом от клиентов, использующих балансировку сетевой нагрузки.
• Повышенная отказоустойчивость благодаря группам отказоустойчивости — с помощью групп отказоустойчивости можно назначить одну группу экземпляров в качестве основной, а другую — в качестве резервной, и переключать трафик, когда состояние экземпляров в активной группе опускается ниже определенного порога. Для более полного контроля над механизмом отказоустойчивости можно использовать агент, такой как keepalived или pacemaker , и отображать проверку работоспособности (работоспособность или сбой) в зависимости от изменений состояния экземпляра бэкэнда.
• Масштабируемость и высокая доступность с помощью управляемых групп экземпляров — региональные бэкэнд-сервисы поддерживают управляемые группы экземпляров в качестве бэкэндов. Теперь вы можете указать шаблон для экземпляров виртуальных машин бэкэнда и использовать автоматическое масштабирование на основе загрузки ЦП или других показателей мониторинга.

В дополнение к вышесказанному, вы сможете воспользоваться функцией Connection Draining для протоколов TCP (connection-oriented protocol) и ускорить процесс программирования при масштабных развертываниях.

топология сети Codelab

В этом руководстве приведены инструкции по переводу существующего балансировщика сетевой нагрузки с целевого пула бэкэндов на региональную службу бэкэнда.

Переход на региональную серверную службу позволяет воспользоваться такими преимуществами, как проверки работоспособности (для TCP, SSL, HTTP, HTTPS и HTTP/2), управляемые группы экземпляров, автоматическое завершение соединения и политика отказоустойчивости .

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

Ранее: Балансировка сетевой нагрузки с использованием целевого пула.

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

После: Балансировка сетевой нагрузки с использованием региональной серверной службы.

В этом примере предполагается, что у вас есть традиционный сетевой балансировщик нагрузки на основе пула целевых объектов с двумя экземплярами в зоне us-central-1a и двумя экземплярами в зоне us-central-1c.

Для осуществления такого перехода необходимы следующие основные шаги:

1. Сгруппируйте экземпляры целевого пула в группы экземпляров. Сервисы бэкэнда работают только с управляемыми или неуправляемыми группами экземпляров. Обратите внимание, что хотя количество экземпляров, которые можно разместить в одном целевом пуле, не ограничено, группы экземпляров имеют максимальный размер . Если ваш целевой пул содержит больше экземпляров, чем это максимальное количество, вам потребуется распределить его бэкэнды по нескольким группам экземпляров. Если в вашей существующей конфигурации используется резервный целевой пул, создайте отдельную группу экземпляров для этих экземпляров. Эта группа экземпляров будет настроена как группа отказоустойчивости.
2. Создайте региональную службу бэкэнда. Если ваша система развертывания включает резервный пул целевых объектов, вам потребуется указать коэффициент отказоустойчивости при создании службы бэкэнда. Он должен соответствовать коэффициенту отказоустойчивости, ранее настроенному для развертывания целевого пула.
3. Добавьте группы экземпляров (созданные ранее) в службу бэкэнда. Если ваше развертывание включает пул целевых резервных копий, отметьте соответствующую группу экземпляров с флагом –failover при добавлении ее в службу бэкэнда.
4. Настройте правило переадресации, указывающее на новый бэкэнд-сервис. Здесь у вас есть 2 варианта:

• (Рекомендуется) Обновите существующее правило переадресации, чтобы оно указывало на серверную службу. ИЛИ
• Создайте новую переадресацию, указывающую на бэкэнд-сервис. Для этого необходимо создать новый IP-адрес для интерфейса балансировщика нагрузки. Затем измените настройки DNS, чтобы обеспечить плавный переход со старого IP-адреса целевого балансировщика нагрузки на основе пула на новый IP-адрес.

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

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

Примечание: Вы можете легко получить доступ к Cloud Console, запомнив ее URL-адрес: console.cloud.google.com .

Запомните идентификатор проекта (Project ID) — уникальное имя для всех проектов Google Cloud (указанное выше имя уже занято и вам не подойдёт, извините!). В дальнейшем в этом практическом занятии оно будет обозначаться как PROJECT_ID .

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

2. Далее вам потребуется включить оплату в Cloud Console, чтобы использовать ресурсы Google Cloud.

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

Запустить Cloud Shell

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

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

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

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

Войдите в Cloudshell и укажите свой идентификатор проекта.

gcloud config list project
gcloud config set project [YOUR-PROJECT-ID]

Perform setting your projectID:
projectid=YOUR-PROJECT-ID

echo $projectid

4. Создайте сеть VPC.

Сеть VPC

Из Cloud Shell

gcloud compute networks create network-lb --subnet-mode custom

Создать подсеть

Из Cloud Shell

gcloud compute networks subnets create network-lb-subnet \
        --network network-lb --range 10.0.0.0/24 --region us-central1

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

Из Cloud Shell

gcloud compute --project=$projectid firewall-rules create www-firewall-network-lb --direction=INGRESS --priority=1000 --network=network-lb --action=ALLOW --rules=tcp:80 --source-ranges=0.0.0.0/0 --target-tags=network-lb-tag

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

Создайте по 2 экземпляра на зону: us-central1-a и us-central1-c.

Создайте экземпляр 1 в Cloud Shell.

gcloud compute instances create www1 \
--subnet network-lb-subnet \
--image-family debian-9 \
--image-project debian-cloud \
--zone us-central1-a \
--tags network-lb-tag \
--metadata startup-script="#! /bin/bash
sudo apt-get update
sudo apt-get install apache2 -y
sudo service apache2 restart
echo '<!doctype html><html><body><h1>www1</h1></body></html>' | tee /var/www/html/index.html"

Создайте экземпляр 2 в Cloud Shell.

gcloud compute instances create www2 \
--subnet network-lb-subnet \
--image-family debian-9 \
--image-project debian-cloud \
--zone us-central1-a \
--tags network-lb-tag \
--metadata startup-script="#! /bin/bash
sudo apt-get update
sudo apt-get install apache2 -y
sudo service apache2 restart 
echo '<!doctype html><html><body><h1>www2</h1></body></html>' | tee /var/www/html/index.html"

Создайте экземпляр 3 в Cloud Shell.

gcloud compute instances create www3 \
--subnet network-lb-subnet \
--image-family debian-9 \
--image-project debian-cloud \
--zone us-central1-c \
--tags network-lb-tag \
--metadata startup-script="#! /bin/bash
sudo apt-get update 
sudo apt-get install apache2 -y 
sudo service apache2 restart 
echo '<!doctype html><html><body><h1>www3</h1></body></html>' | tee /var/www/html/index.html"

Создайте экземпляр 4 в Cloud Shell.

gcloud compute instances create www4 \
--subnet network-lb-subnet \
--image-family debian-9 \
--image-project debian-cloud \
--zone us-central1-c \
--tags network-lb-tag \
--metadata startup-script="#! /bin/bash
sudo apt-get update 
sudo apt-get install apache2 -y 
sudo service apache2 restart
echo '<!doctype html><html><body><h1>www4</h1></body></html>' | tee /var/www/html/index.html"

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

Из Cloud Shell

gcloud compute --project=$projectid firewall-rules create www-firewall-network-lb --direction=INGRESS --priority=1000 --network=network-lb --action=ALLOW --rules=tcp:80 --source-ranges=0.0.0.0/0 --target-tags=network-lb-tag

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

Из Cloud Shell

gcloud compute addresses create network-lb-ip-1 \
    --region us-central1

Добавить ресурс проверки работоспособности устаревшего HTTP-протокола

Из Cloud Shell

gcloud compute http-health-checks create basic-check

5. Создайте правило пересылки и пул целевых объектов.

Создайте пул целей

gcloud compute target-pools create www-pool \
            --region us-central1 --http-health-check basic-check

Добавьте свои экземпляры в целевой пул us-central1-a.

gcloud compute target-pools add-instances www-pool \
--instances www1,www2 \
--instances-zone us-central1-a

Добавьте свои экземпляры в целевой пул us-central1-c.

gcloud compute target-pools add-instances www-pool \
--instances www3,www4 \
--instances-zone us-central1-c

Добавить правило пересылки

gcloud compute forwarding-rules create www-rule \
--region us-central1 \
--ports 80 \
--address network-lb-ip-1 \
--target-pool www-pool

Проверьте функциональность целевого пула.

Определите IP-адрес внешнего интерфейса, выбрав «Балансировщики нагрузки» → «Внешние интерфейсы» (www-rule).

Используйте команду curl на терминале вашей рабочей станции, чтобы получить доступ к внешнему IP-адресу и понаблюдать за балансировкой нагрузки между четырьмя целевыми экземплярами. Закройте терминал после подтверждения.

while true; do curl -m1 IP_ADDRESS; done

6. Переведите сетевой балансировщик нагрузки из целевого пула в бэкэнд-сервис.

Создайте единые проверки работоспособности для вашего бэкэнд-сервиса.

gcloud compute health-checks create tcp my-tcp-health-check --port 80 --region us-central1

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

gcloud compute --project=$projectid instance-groups unmanaged create www-instance-group-central1a --zone=us-central1-a

gcloud compute --project=$projectid instance-groups unmanaged add-instances www-instance-group-central1a --zone=us-central1-a --instances=www1,www2

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

gcloud compute --project=$projectid instance-groups unmanaged create www-instance-group-central1c --zone=us-central1-c

gcloud compute --project=$projectid instance-groups unmanaged add-instances www-instance-group-central1c --zone=us-central1-c --instances=www3,www4

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

gcloud compute backend-services create my-backend-service --region us-central1 --health-checks my-tcp-health-check --health-checks-region us-central1 --load-balancing-scheme external

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

gcloud compute backend-services add-backend my-backend-service --instance-group www-instance-group-central1a --instance-group-zone us-central1-a --region us-central1

gcloud compute backend-services add-backend my-backend-service --instance-group www-instance-group-central1c --instance-group-zone us-central1-c --region us-central1

Обновите существующее правило переадресации для поддержки внутренних служб.

Запишите имя правила переадресации «www-rule» и связанный с ним IP-адрес, выполнив следующие действия:

Выберите Балансировщик нагрузки → Интерфейсы

Также были отмечены четыре целевых пула.

Выберите «Балансировщик нагрузки» → Выберите «www-pool»

Направляйте трафик к внутренним службам, обновив существующее правило переадресации.

gcloud compute forwarding-rules set-target www-rule --region=us-central1 --backend-service my-backend-service --region us-central1

Убедитесь, что балансировщик нагрузки 'www-pool' больше не настроен с использованием интерфейса 'www-rule' (см. скриншот ниже).

Выберите балансировщик нагрузки → www-pool

Правило переадресации для проверки внешнего интерфейса теперь связано с балансировщиком нагрузки 'my-backend-service'.

Выберите Балансировщик нагрузки → Интерфейсы

Обратите внимание, что IP-адрес с именем правила 'www-rule' сохранен, а балансировщик нагрузки 'my-backend-service' теперь используется.

Используйте команду curl на терминале вашей рабочей станции, чтобы получить доступ к внешнему IP-адресу и понаблюдать за балансировкой нагрузки между недавно подключенными серверными службами. Закройте терминал после подтверждения.

while true; do curl -m1 IP_ADDRESS; done

7. Этапы уборки

gcloud compute forwarding-rules delete www-rule --region=us-central1 --quiet
 
gcloud compute backend-services delete my-backend-service --region us-central1 --quiet
 
gcloud compute target-pools delete www-pool --region us-central1 --quiet
 
gcloud compute addresses delete network-lb-ip-1 --region us-central1 --quiet

gcloud compute firewall-rules delete www-firewall-network-lb --quiet
 
gcloud compute instances delete www4 --zone us-central1-c --quiet
 
gcloud compute instances delete www3 --zone us-central1-c --quiet
 
gcloud compute instances delete www2 --zone us-central1-a --quiet

gcloud compute instances delete www1 --zone us-central1-a --quiet
 
gcloud compute networks subnets delete network-lb-subnet --region us-central1 --quiet

gcloud compute networks delete network-lb --quiet

gcloud compute instance-groups unmanaged delete www-instance-group-central1a --zone us-central1-a --quiet

gcloud compute instance-groups unmanaged delete www-instance-group-central1c --zone us-central1-c --quiet

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

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

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

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