Настройка надежности (HA) для площадок GCP vSocket с использованием Terraform

Эта статья описывает, как развернуть конфигурацию надежности (HA) для сайта GCP vSocket.

Обзор.

Вы можете настроить Высокую Доступность (HA) для Cato vSockets в Google Cloud Platform (GCP) путём развёртывания двух vSockets в разных зонах и размещения балансировщика нагрузки Google Cloud перед их интерфейсами ЛВС. Балансировщик нагрузки предоставляет один статический IP-адрес, который внутренние ресурсы используют для подключения к vSockets. Он постоянно мониторит состояние каждого vSocket и пересылает трафик только на активный (главный) vSocket. Это может быть либо основной Socket или, в случае отказа, вторичный.

Дополнительно, vSockets используют Протокол Резервирования Виртуального Маршрутизатора (VRRP) для обмена информацией о состоянии между ними. Когда вторичный Socket находится в режиме ожидания, он сообщает балансировщику нагрузки о неблагоприятных условиях, чтобы трафик перенаправлялся только на активный vSocket. Вместе, проверки состояния балансировщика нагрузки и VRRP обеспечивают автоматическое переключение с минимальными нарушениями. Типичное время переключения составляет примерно 3–5 секунд.

Заметка:

Минимальная поддерживаемая версия vSocket для HA в GCP — 24.0.20395.

Конфигурации HA vSocket в GCP полагаются исключительно на балансировщик нагрузки для направления трафика на активный vSocket.

Рабочий процесс отказа GCP vSocket

Это рабочий процесс, когда основной активный vSocket передается вторичному в режиме ожидания на сайте GCP.

1. В нормальной операции основной vSocket имеет активную роль, а вторичный vSocket имеет роль ожидания.

   1. Балансировщик нагрузки проверяет сокеты на предмет их состояния. Основной сообщает, что он здоровый, вторичный сообщает, что он неблагополучный.

   2. Основной и вторичный сокеты общаются через ЛВС, используя протокол VRRP.

   3. IP балансировщика нагрузки направляет трафик на IP основного vSocket.

   4. Префиксы таблицы маршрутизации ЛВС используют IP балансировщика нагрузки как следующий переход.

2. Основной (активный) vSocket падает.

   1. Вторичный (ожидающий) vSocket прекращает получение пакетов Keepalive от основного vSocket.

   2. Вторичный vSocket принимает роль активного (главного) и начинает сообщать балансировщику нагрузки о здоровом состоянии.

   3. Балансировщик нагрузки прекращает получать ответы от основного vSocket, и теперь направляет весь трафик только на вторичный vSocket.

3. Теперь вторичный vSocket является активным vSocket и передает трафик на сайт в обоих направлениях.

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

Предварительные требования для развертывания Terraform

• Проект GCP с разрешениями на создание следующих ресурсов:

  • ВПС и подсети

  • Инстанции вычисления

  • Правила файервола

  • Балансировщик нагрузки

  • Проверки состояния

  • Статические IP-адреса

  • Сервисные аккаунты

• Terraform установлен и аутентифицирован в GCP

• Данные учетной записи Cato или токены, необходимые для модуля Terraform

• Две зоны доступности в целевом регионе (например, us-central1-a и us-central1-b)

• (Необязательно) Зарезервированное имя DNS, указывающее на статический IP-адрес балансировщика нагрузки

• Минимальная версия vSocket: 24.0.20395

Ссылочная архитектура

• Каждый vSocket включает три интерфейса: MGMT, WAN и ЛВС. Интерфейсы ЛВС участвуют в VRRP для синхронизации состояния.

• Балансировщик нагрузки работает на стороне ЛВС, чтобы обеспечить постоянный IP-адрес для внутренних клиентов.

• Проверки состояния исследуют интерфейс ЛВС каждого vSocket. Только экземпляры, которые сообщают балансировщику нагрузки о благополучии, получают трафик.

• VRRP обеспечивает синхронизацию состояния между двумя vSockets.

Использование Terraform для развертывания HA для сайта GCP vSocket

Все необходимые ресурсы (ВПС, vSockets, балансировщик нагрузки и проверки состояния) должны быть определены в одном стеке Terraform.

Официальные модули Terraform vSocket Cato, доступные в реестре Terraform, включают подробную документацию и примеры для vSockets в конфигурации высокой доступности. Для получения дополнительной информации о модуле HA GCP см. здесь.

Чтобы расширить конфигурацию HA в GCP:

1. Разверните два vSockets в разных зонах, используя тот же подход

2. Добавьте ресурс балансировщика нагрузки на стороне ЛВС для защиты обоих vSockets

3. Разрешите связь VRRP между двумя vSockets для синхронизации состояния 

Заметка:

Обратитесь к официальной документации модуля vSocket Terraform Cato для получения подробной информации о входных и выходных данных модуля, а также расширенных параметрах конфигурации

Настроить сетевой интерфейс vSocket в качестве источника пиринга BGP

Для GCP HA площадок vSocket вы можете настроить интерфейс vSocket в качестве источника пиринга BGP. Только активный vSocket устанавливает и поддерживает сессию пиринга BGP в любое данное время. Когда происходит отказ, вторичный vSocket создает свою сессию пиринга BGP и берет на себя роль активного пиринга BGP.

Для получения дополнительной информации о настройке соседей BGP для сайта, см. Настройка соседей BGP для сокета Cato.

• Требуется Socket версии v27.0.24419 или выше

Соображения по настройке и известные ограничения

Прежде чем настроить пиринг BGP для сайта GCP HA, ознакомьтесь со следующим:

• Требуются два резервных интерфейса Cloud Router - GCP требует два отдельных, резервных интерфейса Cloud Router для пиринга BGP маршрутизаторов, где на каждом интерфейсе настроен один пир BGP. Это требование платформы GCP применяется независимо от конфигурации Cato.

• Требуются две сессии BGP (по одной на vSocket) - Каждый vSocket ведет свою собственную сессию BGP через свой интерфейс Cloud Router. Вы должны применить одинаковую конфигурацию BGP к обоим сессиям, одну для каждого vSocket. Это ожидаемое поведение и не является ошибкой дублирующей конфигурации.

• Пиринг BGP во время отказа - Только активный vSocket поддерживает установленную сессию пиринга BGP. Во время отказа вторичный vSocket создает сессию пиринга BGP, чтобы стать активной. Повторное установление пиринга BGP на вторичном vSocket не происходит мгновенно, поэтому мы рекомендуем вам проверить ожидаемое время и поведение отказа в вашей среде.

• Маршрутизация между проектами и VPC - Когда пиринг BGP охватывает несколько проектов GCP, вы должны вручную настроить следующее, чтобы маршруты, рекламируемые vSocket, достигли целевой VPC:

  • Включите экспорт пользовательских маршрутов на стороне пиринга VPC vSocket

  • Включите импорт пользовательских маршрутов в пиринге VPC в целевом проекте или VPC

Управление высокой доступностью GCP

Этот раздел объясняет, как управлять HA для сайта GCP:

• Отобразите статус HA для каждого vSocket

• Измените IP-адрес балансировщика нагрузки для сайта

• Измените IP-адреса управления для vSockets

• Отключите HA для сайта и удалите вторичный vSocket

Показ информации о высокой доступности и статусе

Страница Сеть > Сайты > Socket для сайта отображает статус HA для основного и вторичного vSockets.

Изменение настроек IP для сайта

Если вы измените настройки IP-адресов для vSockets в GCP, вам нужно обновить те же настройки в приложении управления Cato. Вот те настройки, которые вы можете конфигурировать:

• Собственный диапазон подсети - используйте раздел Сети для сайта.

• IP балансировщика нагрузки - используйте раздел Сети или Высокая доступность для сайта (новое значение автоматически обновляется в другом разделе)

• IP управления - используйте раздел Высокая доступность для сайта

Изменение собственного диапазона подсети

Используйте раздел Сети для изменения собственного диапазона подсети.

Чтобы изменить собственный диапазон подсети для сайта:

1. Из меню навигации нажмите Сеть > Сайты и выберите сайт GCP.

2. Из меню навигации выберите Конфигурация сайта > Сети.

3. Отредактируйте свой диапазон, введите новое значение для Подсеть.

4. Нажмите Применить. Панель Редактировать диапазон IP закрывается.

5. Нажмите Сохранить.

Изменение IP балансировщика нагрузки и IP управления

Используйте раздел Высокая доступность для изменения IP балансировщика нагрузки и IP управления. Вы также можете изменить IP балансировщика нагрузки в разделе Сети.

Чтобы изменить IP балансировщика нагрузки или IP управления для сайта:

1. Из меню навигации нажмите Сеть > Сайты и выберите сайт GCP.

2. В меню навигации нажмите Конфигурация сайта > Socket.

3. Разверните раздел Конфигурации Высокой Доступности.

4. Введите новый Основной IP управления.

5. Введите новый Вторичный IP управления.

6. Введите новый IP балансировщика нагрузки ЛВС.

7. Нажмите Сохранить.

Отключение высокой доступности для сайта GCP

Вы можете удалить вторичный vSocket из сайта GCP и отключить HA для этого сайта. После удаления вторичного vSocket из приложения управления Cato, развернутый vSocket больше не сможет подключиться к Cato Cloud. Настройки сайта восстанавливаются к конфигурации для одного vSocket:

• Раздел Высокая доступность отключён и больше не показывается на странице

• В разделе Сети локальный IP заменяет IP балансировщика нагрузки

Заметка:

Примечание: вы не можете отменить действие Отвязать сокет. Серийный номер вторичного vSocket больше не действителен.

Если вы хотите добавить вторичный vSocket снова, вам необходимо установить новый vSocket на ВМ с новым серийным номером.

Чтобы отключить HA для сайта GCP:

1. Из меню навигации нажмите Сеть > Сайты и выберите сайт GCP.

2. В меню навигации нажмите Конфигурация сайта > Socket.

3. Из меню Действия для Вторичный vSocket нажмите Отвязать сокет.

4. В окне Предупреждение нажмите ОК. HA отключена для сайта, и вторичный vSocket удален из него.

Известные Ограничения услуг

• В GCP HA развёртываниях Задержка возврата на основной vSocket может занимать больше времени, чем переход на вторичный vSocket. Во время возврата на основной путь, Трафик может быть прерван в течение до 8 секунд.

• Во время состояния "смешанного мозга" в GCP HA развёртывании, Имеющийся непрерывный пинг-трафик может продолжаться как через основной, так и через вторичный vSockets. Это может привести к тому, что GCP проверка состояния балансировщика нагрузки будет показывать оба vSockets здоровыми, и валидация принудительного переключения будет менее понятной, хотя новый Трафик, инициированный после состояния "смешанного мозга", маршрутизируется только через вторичный vSocket.