Создание балансировщика нагрузки HTTP в Google Cloud Platform

Question

Балансировщик нагрузки HTTP в GCP имеет множество движущихся частей, таких как глобальные правила пересылки, целевые прокси, карта URL, внутренние службы и группы экземпляров.

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

Этот вопрос является частью ответа другого вопроса о построении автомасштабируемого и сбалансированного бэкэнда.

Answer 1

Во-первых, GCP предлагает два типа балансировщика нагрузки, а именно балансировщик нагрузки сети и HTTP(s). Вы можете найти различия между балансировщиком нагрузки сети и HTTP здесь. С этого момента я буду называть HTTP-балансировщик нагрузки HLB(потому что это слишком долго).

Вот архитектура HLB, взятая из GCP:

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

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

Lets assume the instance template to be sample-template.

2. Группа управляемых экземпляров: пожалуйста, пройдите шаги по созданию группы управляемых экземпляров и автомасштабированию здесь. Автомасштабирование и балансировка нагрузки не зависят друг от друга. Оба предлагают проверку здоровья. С моей точки зрения, настройка проверки работоспособности как для балансировщика нагрузки, так и для автоматического масштабирования является излишней, и я думаю, что проверка работоспособности только для балансировщика нагрузки будет полезна.

Lets assume the managed instance group to be autoscale-managed-instance group, which is autoscaled and created based on sample-template.

3. Конечная точка службы: необходимо указать конечную точку службы, которая будет использоваться HLB. Команда для настройки конечной точки службы в gcloud:

gcloud compute instance-groups managed \
set-named-ports \
autoscale-managed-instance group \
--named-ports http:80 \
--region asia-northeast1

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

4. Проверка работоспособности. Это необходимо для того, чтобы HLB направлял трафик только в исправные экземпляры. Команда для создания проверки работоспособности:

gcloud compute http-health-checks create sample-health-check

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

gcloud compute backend-services create \
sample-backend-service \
--http-health-checks sample-health-check

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

gcloud compute backend-services add-backend sample-backend-service \
--instance-group \
sample-managed-instance-group \
--balancing-mode RATE \
--max-rate-per-instance 100 \
--instance-group-region asia-northeast1

Приведенная выше команда присоединяет группу экземпляров к backend-service, а также распределяет нагрузку на основе количества запросов с использованием флага режима балансировки. max-rate-per-instance используется autoscaler, если вы установили политику autoscaler, основанную на использовании балансировщика нагрузки.

6. Карта URL: Создание карты URL, которая сопоставляет URL-адрес HTTP-запроса с вашей серверной службой. Команда для создания карты URL:

gcloud compute url-maps create sample-map \
--default-service sample-backend-service

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

7. Целевой HTTP-прокси. Этот шаг связывает целевой прокси с картой URL. Команда для создания целевого HTTP-прокси:

gcloud compute target-http-proxies \
create sample-target-proxy \
--url-map sample-map

8. Правила пересылки: это последний шаг, который дает глобальный внешний IP-адрес HLB.

gcloud compute forwarding-rules \
create sample-forward \
--global \
--ports 80 \
--target-http-proxy sample-target-proxy

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

Это третья часть серии из трех статей о построении автомасштабированного и сбалансированного бэкэнда.