Обзор кластеризации GCP #

В этой статье описывается, как настроить расширенная балансировка нагрузки и высокая доступность используя RELIANOID Балансировщик нагрузки in Облачная платформа Google (GCP).
Мы продемонстрируем полный процесс развертывания и настройки RELIANOID Кластер с виртуальный IP (VIP) для отказоустойчивости и ферма внутренних серверов для балансировки нагрузки HTTP.
Цель состоит в том, чтобы гарантировать, что в случае отказа или перезагрузки одного узла (главного) виртуальный IP-адрес и службы автоматически переключатся на вторичный узел, обеспечивая бесперебойную доступность приложений.

Кластерная среда Cloud Load Balancer #

Мы собираемся продемонстрировать, как это можно реализовать в Виртуальная платформа Google (GCP) Используя собственные сервисы GCP. На следующей диаграмме показана архитектура, которую мы планируем развернуть для балансировки веб-нагрузки с помощью RELIANOID Контроллер доставки приложений в GCP для обеспечения высокой доступности и отказоустойчивости.

Диаграмма архитектуры #

Каждый RELIANOID Виртуальная машина будет сконфигурирована с одним сетевой интерфейс (nic0) подключен к сеть VPC и назначили обоим в нашей внутренней среде, и статический внешний IP.

• ЛБ1:
• Внутренний IP: 10.0.1.9
• Внешний IP-адрес: 34.122.145.90
• ЛБ2:
• Внутренний IP: 10.0.1.8
• Внешний IP-адрес: 35.233.210.70

Вдобавок вторичный внутренний IP (VIP) будет создан на сетевом интерфейсе LB1:

• VIP (для виртуального обслуживания):10.0.1.11
• Этот IP-адрес будет автоматически перемещаться между узлами (главный/подчиненный) при отказе.
• Он будет опубликован через внешний статический IP-адрес, например 34.172.119.80, для доступа пользователя к виртуальному сервису.

серверные серверы (реальные приложения) развернуты в одной и той же частной сети (10.0.1.0/24) и не имеют прямого доступа к Интернету.

Реализация кластеризации Cloud Load Balancer в GCP #

1. Развертывание RELIANOID Экземпляры балансировщика нагрузки #

Вы можете развернуть RELIANOID Образ балансировщика нагрузки непосредственно из Google Cloud Marketplace.

1. Перейдите на Google Cloud Console → Compute Engine → Экземпляры виртуальных машин → Создать экземпляр.
2. Выберите RELIANOID Изображение балансировщика нагрузки в разделе «Пользовательские изображения», затем «Торговая площадка».
3. Настройка:
• Тип аппарата: e2-micro (достаточно для тестирования; для производства используйте n2-standard)
• Регион/Зона: один и тот же регион для обоих узлов
• Сетевой интерфейс:
• Сети: relianoid-vpc
• Подсеть: relianoid_subnet
• Внешний IP: Статический (назначить новый статический IP)
• межсетевой экран:Разрешить TCP 22 (SSH), TCP 444 (веб-интерфейс) и TCP 80 (для HTTP-сервисов).
4. Нажмите Дополнительные параметры → Безопасность → Области доступа
• Выбирайте Разрешить полный доступ ко всем облачным API or настроить учетную запись пользовательской службы (рекомендуемые).
• Назначьте Учетная запись службы с Compute Admin и Compute Network Admin роли.

Разверните оба узла (LB1 и LB2) в одном VPC и подсети.

2. Включение и настройка учетных записей служб (доступ к удостоверениям) #

RELIANOID использует Google Cloud API для управления отказоустойчивостью, аналогично Azure Managed Identities.

• Перейдите на IAM и администрирование → Учетные записи служб.
• Создайте новая учетная запись службы названный relianoid-cluster-sa.
• Назначьте следующие роли:
• Compute Instance Admin (v1)
• Compute Network Admin
• Service Account User

Прикрепите это учетная запись службы в как LB1, так и LB2 Виртуальные машины (редактировать → изменить учетную запись службы).

Затем проверьте доступ с каждого узла:

sudo systemctl status google-guest-agent
gcloud auth list
gcloud projects get-iam-policy <YOUR_PROJECT_ID>

Если агент не установлен, выполните:

sudo apt-get install google-cloud-sdk google-compute-engine

3. Настройте сетевые интерфейсы и виртуальный IP #

В GCP вторичные внутренние IP-адреса можно добавлять вручную через консоль или CLI.

На LB1 (главный узел):

• Перейдите на Сеть VPC → Экземпляры виртуальных машин → LB1 → Редактировать → Сетевой интерфейс → Добавить дополнительный внутренний IP-адрес
• Назначать:
• IP: 10.0.1.11
• Имя: vip-lb
• Тип Static

На LB2 (резервный узел):

• Не назначайте этот вторичный IP-адрес.
• RELIANOID кластерная служба автоматически переназначит его при отказе.

4. Правила безопасности (настройка брандмауэра) #

In Сеть VPC → Межсетевой экран, создать правила, позволяющие:

протокол	Порт отгрузки	Цель
TCP	22	Доступ к SSH
TCP	444	Веб-интерфейс
TCP	80	Внутренние HTTP-сервисы

Применить эти правила к экземплярам, ​​помеченным как relianoid-lb.

5. Активировать RELIANOID Лицензия #

Доступ к каждому узлу:

• ЛБ1: https://34.122.145.90:444
• ЛБ2: https://35.233.210.70:444

Использование:

• Имя пользователя: root
• Пароль: ID экземпляра

Получить имя хоста и ключ сертификата → Посетить
https://www.relianoid.com/activate-enterprise-edition-cloud-evaluation/
Загрузите скачанное .pem файл лицензии для каждого узла.

6. конфигурировать RELIANOID Кластер #

С Веб-интерфейс LB1 → Система → Кластер, заполните:

Поиск	Значение
Локальный IP	Выберите nic0 (10.0.1.9)
Удаленный IP	10.0.1.8
Пароль удаленного узла	(Идентификатор экземпляра LB2)

Нажмите Создать.

LB1 становится Мастер, LB2 становится Раб автоматически.

Создайте службу балансировки нагрузки в GCP #

Теперь давайте настроим простую ферму балансировки веб-нагрузки.
Перейти к:
LSLB → Фермы → Создать ферму

Параметры:

• Название фермы: веб-ферма
• VIP: 10.0.1.11
• Порт: 80
• Алгоритм: соревнования по круговой системе
• Упорство: Исходный IP (60 сек)
• Проверка здоровья: check_tcp

Добавить внутренние серверы:

• Бэкэнд 1: 10.0.1.20:80
• Бэкэнд 2: 10.0.1.21:80

Применить конфигурацию.

Теперь вы можете получить доступ к виртуальному сервису по адресу:

http://34.172.119.80/

Трафик будет распределяться между вашими внутренними серверами через RELIANOID .

Для проверки отказоустойчивости:

• Перезагрузите главный узел (LB1).
• Обратите внимание, что LB2 становится активным, беря под контроль VIP (10.0.1.11).
• Подключение через публичный IP остается бесперебойным.

Устранение неполадок: этому хосту не назначена учетная запись службы #

Если вы получили сообщение:

    «Этому хосту не назначена учётная запись службы. Настройте её в консоли GCP».

Это указывает на GCP учетная запись службы не настроен или Гостевой агент Google отсутствует.

Проверять:

sudo systemctl status google-guest-agent
gcloud auth login --brief
gcloud auth print-access-token

Если агент или SDK отсутствует:

sudo apt-get install google-cloud-sdk google-compute-engine

Убедиться, что:

• Экземпляр имеет допустимый Учетная запись службы прилагается.
• Учетная запись службы имеет Администратор вычислений и Network Admin роли.

Наслаждайтесь расширенной балансировкой нагрузки и кластеризацией в GCP с RELIANOID! #