Что такое Socket HA

В этой статье обсуждаются конфигурации высокой доступности (HA) и условия переключения для сайтов, использующих пару физических Socket от Cato.

Обзор высокой доступности Socket для сайта

Для повышения устойчивости сайта, Cato настоятельно рекомендует развертывать каждый сайт с парой Sockets, работающих в режиме высокой доступности (HA). Этот режим работы обеспечивает непрерывность обслуживания сайта в случае отказа одного Socket. В процессе перехода Cato Cloud поддерживает состояние потоков, и влияние на работу конечных пользователей минимально.

Поддерживаемые сайты с высокой доступностью Socket

Cato поддерживает HA Socket для следующих сред:

• Физический сайт Socket

• Сайт AWS vSocket

• Сайт Azure vSocket

В этой статье объясняется, как работает HA для физического сайта Socket. Для получения дополнительной информации о настройке Socket HA в несколько кликов смотрите Использование Sockets в развертывании HA.

• Для подробностей об AWS vSocket HA смотрите Настройка HA для AWS vSockets

• Для подробностей об Azure vSocket HA смотрите Настройка высокой доступности для Azure vSockets

Высокая доступность Socket и различные модели Socket

Площадки HA могут использовать два Сокета одного и того же типа Socket X1500, X1600, X1600 LTE или X1700. Однако, нельзя использовать разные типы Сокетов, поэтому сайт с Сокетом X1600 и Сокетом X1700 не поддерживается.

• Можно использовать Сокет X1500 и Сокет X1500B на одном и том же участке HA.

• Вы не можете использовать Socket X1600 и X1600 LTE на одном сайте HA.

Понимание высокой доступности Socket и аварийного переключения

В развертывании HA Socket две Socket Cato назначаются одному сайту. Первый Socket, назначенный сайту, идентифицируется как основной Socket, второй - как вторичный Socket. Socket работают в режиме HA Active/Standby. Во время нормальной работы сайта основной Socket имеет статус HA Master, в то время как вторичный Socket имеет статус HA Standby. Только Socket с статусом HA Master обрабатывает трафик.

1. Вторичный (Резервный) Socket постоянно контролирует состояние (активность) Главного Socket, прослушивая периодические keepalive-сообщения, которые Главный Socket отправляет. Keepalive-сообщения отправляются через назначенный интерфейс с адресатом, установленным на LAN & VRRP или VRRP (см. ниже Соединение LAN и Socket HA).

2. Как только вторичный (Standby) Socket обнаруживает, что основной Socket вышел из строя, он изменяет свой статус HA на Master и начинает обрабатывать трафик. Это происходит после трех секунд пропущенных keepalive сообщений HA.  

3. Вторичный Socket отправляет GARP сообщение в локальные сети для ускорения сходимости уровня 2.

4. Когда основной Socket восстанавливается и возвращается к регулярной функциональности, он превентивно становится Master, а вторичный Socket возвращается в режим Standby.

Следующее изображение показывает страницу настройки HA для Socket X1500 в приложении управления Cato в Сеть > Сайты > {site name} > Конфигурация сайта > Socket:

Пример аварийного переключения Socket HA

Следующие диаграммы показывают пример проблемы основного Socket, которая вызывает переключение на вторичный Socket. Когда вторичный Socket обнаруживает, что первичный Socket вышел из строя, он изменяет свой статус на Master. Cato Cloud передает потоки трафика на WAN каналы во вторичном Socket.

Socket HA и состояние Split-Brain

Состояние split-brain возникает, когда оба Sockets одновременно имеют роль Master. Это может происходить из-за проблемы с соединением LAN между Sockets, при которой HA keepalive сообщения не достигают вторичного Socket.

Вы можете определить состояние split-brain, проверив страницу Socket (показано выше) в Cato Management Application.

• Основной и вторичный Sockets будут отображены как статус Master (элемент 2)

• Состояние Keepalive (в элементе 4) будет показано как Failed, и это вызывает отображение HA Статуса (элемент 3) как НЕ ГОТОВ

После устранения проблемы с соединением LAN, вторичный Socket определяет, что основной Socket является Master, и вторичный Socket возвращается в статус Stand-by.

Трафик сайта в состоянии Split-Brain

Следующий процесс обеспечивает, что во время split-brain состояния только вторичный Socket обрабатывает трафик для сайта (даже если есть состояние split-brain).

• Для нисходящего трафика (от PoP к сайту):

  1. PoP обнаруживает, что вторичный Socket теперь является Master.

  2. PoP устанавливает предпочтительную метрику для туннелей вторичного Socket.

     Нисходящий трафик теперь маршрутизируется только во вторичный Socket.

• Для восходящего трафика (от сайта к PoP):

  1. Когда вторичный Socket меняет состояние HA с Standby на Master, он отправляет GARP сообщение в LAN, чтобы обновить таблицы ARP и MAC, что теперь он является Master.

     Восходящий трафик из LAN теперь маршрутизируется только в вторичный Socket.

Подключение-HA Socket Cato Cloud

И основной, и вторичный Sockets устанавливают DTLS туннели к тому же Cato Cloud PoP на каждом из WAN портов. В восходящем направлении только Master Socket отправляет трафик в PoP. В нисходящем направлении PoP использует только туннели Master Socket для отправки трафика на сайт. В случае сбоя Socket HA, второй Сокет становится новым Основным, и PoP перенаправляет трафик с туннелей сбойного основного Сокета на туннели второго Сокета. PoP поддерживает состояние потока и состояние NAT, чтобы убедиться, что все пользовательские приложения продолжают работать во время и после отказа.

Развертывание по умолчанию использует маршрутизаторы между Socket и Провайдер интернет-услуг. Однако возможно настроить развертывание площадки, чтобы подключить Socket к PoP без маршрутизатора - пожалуйста, свяжитесь с вашим официальным представителем Cato для получения дополнительной информации.

Ниже приведены примеры физических и логических топологий для HA Socket:

Для оптимального подключения WAN, производительности и функциональности HA, Cato рекомендует симметричную (зеркальную) схему кабеля для обоих Сокетов. Например, если порт WAN1 первичного Socket подключен к ISP1, а порт WAN2 подключен к ISP2, вторичный Socket должен иметь такие же порты, подключенные к тем же ISP, что и первичный Socket.

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

Заметка:

Для стандартных конфигураций HA компания Cato рекомендует использовать симметричную компоновку как для Основного, так и для Вторичного Socket.
При использовании LTE могут возникнуть ситуации, когда необходимо использовать SIM-карты от различных операторов для обеспечения лучшего покрытия или использовать SIM-карту только на вторичном Socket.

LAN-подключение и Socket HA

Cato требует, чтобы и первичный, и вторичный Sockets имели симметричную (отраженную) конфигурацию кабелей для LAN-связи. Например, порт LAN 1 как на первичном, так и на вторичном Socket подключен к LAN-коммутатору (или порты LAN 1 и 2 для конфигураций с несколькими LAN-портами).

В этом разделе обсуждаются следующие варианты LAN-связи для HA Socket:

1. Один LAN порт

2. Несколько LAN портов

3. Агрегация LAN ссылок (рекомендуемый вариант)

4. Выделенный порт для сообщений keepalive HA

Некоторые из этих опций требуют дополнительных настроек сайта в Cato Management Application. Например, порт LAN настроен для LAN & VRRP или VRRP.

Socket HA с одним портом LAN

Есть конфигурации, которые используют один LAN-порт для подключения первичного и вторичного Sockets к LAN-коммутатору. С этой конфигурацией, один и тот же номер порта должен использоваться на обоих Sockets. Пользовательский трафик и сообщения keepalive HA проходят по одной связи. Эта топология не обеспечивает избыточность LAN-связи.

Отказоустойчивость HA Socket (где вторичный Socket становится Master) происходит только при выполнении обоих следующих условий:

1. Вторичный Socket прекращает получение сообщений keepalive HA от первичного Socket на период три секунды.

2. Порт LAN на вторичном Socket (который используется для сообщений keepalive HA) находится в состоянии CONNECTED.

Если порт LAN Вторичного Socket отключен, он не станет Master, чтобы избежать возможности состояния split-brain.

На диаграмме ниже показана примерная топология HA Socket с одним LAN-портом на каждом Socket, подключенным к коммутатору:

Socket HA с несколькими портами LAN

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

По умолчанию самый низкий номер LAN-порта используется как для трафика HA Keepalive, так и для пользовательского трафика. Оставшиеся LAN-порты переносят только пользовательский трафик.

Вы можете выбрать любой LAN-порт для трафика keepalive HA, изменив назначение порта Назначение с LAN на LAN & VRRP. Следующий скриншот показывает порт 3 для пользовательского трафика LAN и порт 4 для трафика keepalive HA и пользовательского трафика.

Для получения дополнительной информации об изменении LAN-порта для трафика keepalive HA смотрите Использование Sockets в развертывании HA. Эта топология не обеспечивает избыточность LAN-связи.

Отказоустойчивость HA Socket (где вторичный Socket становится Master) происходит только при выполнении обоих следующих условий:

1. Вторичный Socket прекращает получение сообщений keepalive HA от первичного Socket на период три секунды.

2. Порт LAN & VRRP на вторичном Socket находится в состоянии CONNECTED.

Если порт LAN Вторичного Socket отключен, он не станет Master, чтобы избежать возможности состояния split-brain.

Socket HA с агрегированием LAN-портов (рекомендуемая конфигурация)

И основной, и Вторичный Socket подключены к коммутаторам LAN через два или более LAN-порта, собранных в агрегирование каналов (LAG). С этой конфигурацией одни и те же порты должны использоваться на обоих Socket для LAN-соединения. Эта топология обеспечивает резервирование LAN соединений как для передачи пользовательского трафика, так и для сообщений HA keepalive. Если один из портов-членов LAG выходит из строя, остальные порты продолжают нести пользовательский трафик и трафик HA keepalive.

Эта топология обеспечивает как устойчивость соединений, так и устойчивость Socket и считается лучшей практикой.

Чтобы узнать больше о LAN LAG, смотрите Настройка агрегирования ссылок для Socket.

Следующая схема является примером топологии подключения LAN к HA Socket, использующей LAN LAG с коммутатором:

Выделенный порт для трафика Keepalive HA

В этой конфигурации вы изолируете трафик HA Keepalive от трафика LAN. Вы можете выделить один порт (LAN, WAN или USB-порты) только для трафика HA Keepalive, используя один или несколько оставшихся LAN-портов для трафика LAN.

Чтобы задать выделенный LAN-порт для трафика HA Keepalive, установите Destination порта на VRRP. Затем установите опцию HA link between sockets на Direct или Via Switch.

Это настройки выделенного порта:

1. Direct (кабель back-to-back между Socket) – в данной конфигурации, если вторичный Socket перестает получать HA Keepalive сообщения, он становится Master независимо от состояния порта VRRP.

2. Через коммутатор – в данной конфигурации порт VRRP на обоих Socket подключен к коммутатору. Поведение переключения зависит от состояния порта VRRP вторичного Socket:                                                             

   1. Когда состояние порта вторичного Socket подключено, но keepalive сообщения не получены – вторичный Socket становится Master.

      Вторичный Socket предполагает, что состояние вызвано отказом первичного Socket.

   2. Когда состояние вторичного порта Socket Отключено - вторичный Socket не становится Master (предполагая, что это локальная проблема между ним и коммутатором).

      Вторичный Socket предполагает, что первичный Socket работает правильно, и не становится Master, чтобы избежать возможности состояния split-brain.

Это схемы настроек выделенного порта с использованием прямого и переключаемого каналов:

Условия аварийного переключения для высокой доступности Socket

Этот раздел описывает условия, вызывающие аварийное переключение с первичного Socket на вторичный Socket.

Аварийное переключение из-за отказа основного Socket

Этот сценарий аварийного переключения вызван неисправностью первичного Socket. Socket считается в состоянии отключен по одной из этих причин:

• Общая неисправность Socket или потеря питания

• VRRP подключение (нет поддержания активного соединения более трёх секунд)
  Потеря соединения на стороне ЛВС не вызывает переключение, если VRRP объявления не обменяются через связь ЛВС.

• Нет соединения с Интернетом более десяти секунд

Аварийное переключение из-за сбоев Keepalive

Существует также сценарий аварийного переключения, вызванный тем, что вторичный Socket не получает keepalive сообщения от первичного Socket в течение трех секунд.

Когда вторичный Socket обнаруживает, что первичный Socket вышел из строя, он изменяет свой статус на Master. Cato Cloud передает потоки трафика на WAN каналы во вторичном Socket. Следующая схема иллюстрирует этот сценарий.

Вызывают ли проблемы интернет-соединения аварийное переключение Socket?

Socket используют механизм зондирования для определения состояния подключения к Интернету. Если основной Socket определяет, что соединение с Интернетом не работает по всем интернет-связям (Cato-связям) более 10 секунд, он перестает передавать keepalive-сообщения HA. Это вызывает переключение на вторичный Socket.

Заметка:

Возможна ситуация, когда основной Socket имеет интернет-соединение, однако все DTLS-туннели находятся в состоянии ОТКЛЮЧЕНО. Поскольку Sockets имеют механизмы восстановления интернет и WAN, эта ситуация не вызывает переключение на вторичный Socket. Эти механизмы восстановления позволяют Socket повторно подключиться к другому PoP в Cato Облаке.

Мониторинг высокой доступности Socket

В этом разделе обсуждаются разные страницы в Cato Управление Приложением, которые вы можете использовать для мониторинга состояния и событий для Socket HA.

Показ статуса HA Socket

Существуют разные страницы в Cato Управление Приложением, которые показывают статус HA Socket для сайта.

События аварийного переключения HA Socket

Каждый раз, когда происходит переключение Socket, когда вторичный Socket активен более 35 секунд, генерируется событие Socket Fail-Over. Например, если основной Socket обновляется до новой версии Socket, и процесс обновления занимает 20 секунд, событие Socket Fail-Over НЕ генерируется, поскольку вторичный Socket был активен только 20 секунд.

Вы можете увидеть событие в Cato Управление Приложением на странице Главная > События. Вот пример события, показывающего переключение с основного на вторичный Socket.

Определение уведомлений для переключения высокой доступности Socket

Вы можете использовать страницу "Правила здоровья соединения" (Сеть > Правила здоровья соединения), чтобы создать правило "Здоровье соединения" для отправки уведомлений о событиях переключения высокой доступности Socket.

Уведомления отправляются всем получателям, определенным в группе подписок, которую вы настраиваете в CMA. Группа подписки может включать разные цели уведомлений, такие как: Группа подписки   

• Списки рассылки с адресами электронной почты (включая адреса, не связанные с пользователями или администраторами Cato)

• Интеграции вебхуков такие как Slack или Jira

• Сторонние системы уведомлений

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

Это пример правила здоровья соединения для переключения Socket:

Для получения дополнительной информации о настройке правила состояния соединения смотрите Работа с правилами мониторинга состояния соединения.