Использование внешнего гибридного балансировщика нагрузки HTTP(s) для доступа к группе конечных точек сети

1. Введение

Гибридная стратегия — это прагматичное решение, позволяющее адаптироваться к меняющимся требованиям рынка и постепенно модернизировать ваши приложения. Гибридная поддержка внешних и внутренних балансировщиков нагрузки HTTP(s) Google Cloud расширяет балансировку нагрузки в облаке на серверные части, расположенные локально и в других облаках, и является ключевым фактором реализации вашей гибридной стратегии. Это может быть временным решением, позволяющим перейти к современному облачному решению или к постоянному компоненту ИТ-инфраструктуры вашей организации.

3312e69c63b02f73.png

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

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

  • Создайте собственный VPC
  • Создайте две виртуальные машины (VM), используемые в качестве группы конечных точек сети (NEG).
  • Создайте гибридный балансировщик нагрузки, серверную службу и связанные проверки работоспособности.
  • Создайте правило брандмауэра, разрешающее доступ к балансировщику нагрузки.
  • Cloud Router и NAT будут созданы, чтобы разрешить обновление пакетов из Интернета.
  • Проверка доступности группы конечных точек сети

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

  • Знание балансировщиков нагрузки

Самостоятельная настройка среды

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

96a9c957bc475304.png

b9a10ebdf5b5a448.png

a1e3c01a38fa61c2.png

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

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

Запустить Cloud Shell

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

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

bce75f34b2c53987.png

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

f6ef2b5f13479f3a.png

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

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

В Cloud Shell убедитесь, что идентификатор вашего проекта настроен.

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

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

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

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

Сеть VPC

Из Cloud Shell

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

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

Из Cloud Shell

gcloud compute networks subnets create network-endpoint-group-subnet --network hybrid-network-lb --range 192.168.10.0/24 --region us-west1

Создать экземпляр Cloud NAT

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

В этой задаче вы создадите экземпляр Cloud Router и NAT, который обеспечит подключение к Интернету экземпляров виртуальных машин.

Создать облачный маршрутизатор

Из Cloud Shell

gcloud compute routers create crnat --network hybrid-network-lb --region us-west1

Создать облачный NAT

Из Cloud Shell

gcloud compute routers nats create cloudnat --router=crnat --auto-allocate-nat-external-ips --nat-all-subnet-ip-ranges --enable-logging --region us-west1

4. Создайте два экземпляра виртуальной машины.

В этом задании вы создадите два экземпляра виртуальных машин под управлением Apache. Позже в ходе лабораторной работы эти экземпляры виртуальных машин станут группой конечных точек сети (NEG).

В Cloud Shell создайте первый локальный экземпляр on-prem-neg-1

gcloud compute instances create on-prem-neg-1 \
    --zone=us-west1-a \
    --tags=allow-health-check \
    --image-family=debian-9 \
    --image-project=debian-cloud \
    --subnet=network-endpoint-group-subnet --no-address \
    --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)"
filter="{print \$NF}"
vm_zone="$(curl -H "Metadata-Flavor:Google" \
http://169.254.169.254/computeMetadata/v1/instance/zone \
| awk -F/ "${filter}")"
echo "Page on $vm_hostname in $vm_zone" | \
tee /var/www/html/index.html
systemctl restart apache2'

В Cloud Shell создайте первый локальный экземпляр on-prem-neg-2

gcloud compute instances create on-prem-neg-2 \
    --zone=us-west1-a \
    --tags=allow-health-check \
    --image-family=debian-9 \
    --image-project=debian-cloud \
    --subnet=network-endpoint-group-subnet --no-address \
    --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)"
filter="{print \$NF}"
vm_zone="$(curl -H "Metadata-Flavor:Google" \
http://169.254.169.254/computeMetadata/v1/instance/zone \
| awk -F/ "${filter}")"
echo "Page on $vm_hostname in $vm_zone" | \
tee /var/www/html/index.html
systemctl restart apache2'

5. Создайте NEG, содержащий вашу локальную конечную точку.

Сначала создайте NEG с именем on-prem-neg-1 и on-prem-neg-2. Вы также укажете, что LB должен учитывать, что для целей маршрутизации и балансировки нагрузки эти конечные точки находятся в зоне us-west1-a GCP. Мы рекомендуем, чтобы настроенная зона соответствовала любой зоне, связанной с регионом межсоединения или VPN-шлюза, для измерений балансировки нагрузки на основе близости, используемых для балансировки нагрузки.

В Cloud Shell создайте on-prem-neg-1

gcloud compute network-endpoint-groups create on-prem-neg-1 \
    --network-endpoint-type NON_GCP_PRIVATE_IP_PORT \
    --zone "us-west1-a" \
    --network hybrid-network-lb

В Cloud Shell создайте on-prem-neg-2

gcloud compute network-endpoint-groups create on-prem-neg-2 \
    --network-endpoint-type NON_GCP_PRIVATE_IP_PORT \
    --zone "us-west1-a" \
    --network hybrid-network-lb

В лаборатории кода группа конечных точек сети представляет собой экземпляр GCE, на котором работает Apache в GCP. Альтернативно вы можете указать локальную конечную точку или конечную точку Интернета в качестве конечной точки сети.

В Cloud Shell определите IP-адреса GCE.

gcloud compute instances list | grep -i on-prem

Свяжите группу конечных точек сети с IP-адресом экземпляра GCE, ранее определенным на предыдущем шаге; для каждого отрицания: on-prem-neg-1 & on-prem-neg-2.

От партнера Cloud Shell on-prem-neg-1 обновите xxxx, указав свой идентифицированный IP-адрес.

gcloud compute network-endpoint-groups update on-prem-neg-1 \
    --zone="us-west1-a" \
    --add-endpoint="ip=x.x.x.x,port=80"

От партнера Cloud Shell on-prem-neg-2 обновите xxxx, указав свой идентифицированный IP-адрес.

gcloud compute network-endpoint-groups update on-prem-neg-2 \
    --zone="us-west1-a" \
    --add-endpoint="ip=x.x.x.x,port=80"

6. Создайте http-проверку работоспособности, серверную службу и брандмауэр.

На этом этапе вы создадите глобальную серверную службу с именем on-prem-backend-service. Эта серверная служба определяет, как ваша плоскость данных будет отправлять трафик на ваш NEG.

Сначала создайте проверку работоспособности с именем on-prem-health-check, чтобы отслеживать работоспособность любых конечных точек, принадлежащих этому NEG (то есть вашей локальной конечной точки).

Из Cloud Shell

gcloud compute health-checks create http on-prem-health-check

Создайте серверную службу под названием on-prem-backend-service и свяжите ее с проверкой работоспособности.

Из Cloud Shell

gcloud compute backend-services create on-prem-backend-service \
    --global \
    --load-balancing-scheme=EXTERNAL \
    --health-checks on-prem-health-check

Внешний балансировщик нагрузки и серверная часть HTTP(S) выполняют проверки работоспособности, исходящие из подсетей 35.191.0.0/16 и 130.211.0.0/22; поэтому требуется правило брандмауэра, позволяющее балансировщику нагрузки выполнять внутреннюю маршрутизацию.

Из Cloud Shell

gcloud compute firewall-rules create fw-allow-health-check \
    --network=hybrid-network-lb \
    --action=allow \
    --direction=ingress \
    --source-ranges=130.211.0.0/22,35.191.0.0/16 \
    --target-tags=allow-health-check \
    --rules=tcp:80

7. Свяжите NEG и серверную службу.

Добавьте NEG on-prem-neg-1 в эту серверную службу.

Из Cloud Shell

gcloud compute backend-services add-backend on-prem-backend-service \
    --global \
    --network-endpoint-group on-prem-neg-1 \
    --network-endpoint-group-zone us-west1-a \
    --balancing-mode RATE \
    --max-rate-per-endpoint 5

Добавьте NEG on-prem-neg-2 в эту серверную службу.

Из Cloud Shell

gcloud compute backend-services add-backend on-prem-backend-service \
    --global \
    --network-endpoint-group on-prem-neg-2 \
    --network-endpoint-group-zone us-west1-a \
    --balancing-mode RATE \
    --max-rate-per-endpoint 5

Зарезервируйте статический IP-адрес IPv4, используемый для доступа к конечной точке вашей сети.

Из Cloud Shell

gcloud compute addresses create hybrid-lb-ip --project=$projectid --global

Мы закончили настройку CLI. Давайте завершим настройку из Cloud Console.

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

В облачной консоли перейдите в раздел «Балансировка нагрузки» и выберите «Создать балансировщик нагрузки».

Определите балансировку нагрузки HTTP(S) и нажмите «Начать настройку».

70ccd168957e89d9.png

Выберите «Из Интернета на мои виртуальные машины» на снимке экрана ниже, чтобы разрешить публичный доступ к вашей виртуальной машине.

a55cd31dbeadfecc.png

Укажите «xlb» в качестве имени балансировщика нагрузки и выберите ранее созданную серверную службу «on-prem-backend-service», затем «ok», как показано на приведенном снимке экрана.

f1589df43bf9e3e8.png

Выберите конфигурацию внешнего интерфейса, обновите имя «xlb-fe» и выберите ранее созданный статический IPv4-адрес, обязательно отразите предоставленный снимок экрана. b47cd48c7c1ccfc3.png

Выберите «Просмотр и завершение», чтобы соответствовать предоставленному снимку экрана, и выберите «Создать».

bfa39f7dc3ad91e1.png

Серверная проверка работоспособности

В облачной консоли убедитесь, что серверная часть «xlb» исправна (зеленый цвет, как показано на приведенном снимке экрана).

131bbfc955d6166c.png

9. Убедитесь, что NEG доступен из Интернета.

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

Из Cloud Shell

gcloud compute forwarding-rules describe xlb-fe --global | grep -i IPAddress:

Вывод (ваш IP-адрес будет отличаться)

Вывод из облачной оболочки

$ gcloud compute forwarding-rules describe xlb-fe --global | grep -i IPAddress:
IPAddress: 34.96.103.132

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

На локальной рабочей станции запустите терминал и выполните закручивание IP-адреса балансировщика нагрузки.

На своей рабочей станции выполните сверку с IP-адресом внешнего интерфейса. Обратите внимание на 200 OK и сведения о странице, состоящие из имени и региона экземпляра neg.

myworkstation$ curl -v 34.96.103.132

* Trying 34.96.103.132...

* TCP_NODELAY set

* Connected to 34.96.103.132 (34.96.103.132) port 80 (#0)

> GET / HTTP/1.1

> Host: 34.96.103.132

> User-Agent: curl/7.64.1

> Accept: */*

>

< HTTP/1.1 200 OK

< Date: Tue, 10 Aug 2021 01:21:54 GMT

< Server: Apache/2.4.25 (Debian)

< Last-Modified: Tue, 10 Aug 2021 00:35:41 GMT

< ETag: "24-5c929ae7384f4"

< Accept-Ranges: bytes

< Content-Length: 36

< Content-Type: text/html

< Via: 1.1 google

<

Page on on-prem-neg-2 in us-west1-a

* Connection #0 to host 34.96.103.132 left intact

* Closing connection 0

Поздравляем, вы успешно развернули гибридный балансировщик нагрузки L7 с NEG.

Поздравляем с завершением работы над кодом!

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

  • Создайте собственный VPC
  • Создайте две виртуальные машины (VM), используемые в качестве группы конечных точек сети (NEG).
  • Создайте гибридный балансировщик нагрузки, серверную службу и связанные проверки работоспособности.
  • Создайте правило брандмауэра, разрешающее доступ к балансировщику нагрузки.
  • Проверка доступности группы конечных точек сети

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

В пользовательском интерфейсе Cloud Console определите и отметьте балансировщик нагрузки «xlb» и выберите «Удалить» через «Сетевые службы» → «Балансировка нагрузки». После выбора отметьте «локальная серверная служба» и «локальная проверка работоспособности», затем выберите «Удалить».

53d7463fe354fe66.png

В пользовательском интерфейсе Cloud Console выберите Compute Engine → Группы конечных точек сети. После выбора отметьте «on-prem-neg-1» и «on-prem-neg-2», затем выберите «Удалить».

4d8f04264b44d03c.png

Удаление компонентов лаборатории из облачной оболочки

gcloud compute routers nats delete cloudnat --router=crnat --region us-west1 --quiet

gcloud compute routers delete crnat  --region us-west1 --quiet

gcloud compute instances delete on-prem-neg-1 --zone=us-west1-a --quiet

gcloud compute instances delete on-prem-neg-2 --zone=us-west1-a --quiet

gcloud compute firewall-rules delete fw-allow-health-check --quiet

gcloud compute networks subnets delete network-endpoint-group-subnet --region=us-west1 --quiet

gcloud compute networks delete hybrid-network-lb --quiet

gcloud compute addresses delete hybrid-lb-ip --global --quiet