Что такое высокая доступность (HA) Socket

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

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

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

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

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

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

  • Сайт AWS vSocket

  • Сайт Azure vSocket

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

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

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

Вы не можете использовать 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. Вторичный (Standby) Socket постоянно отслеживает состояние (жизнеспособность) основного Socket, прослушивая периодические keepalive сообщения, которые отправляет основной Socket. Сообщения Keepalive отправляются через указанное интерфейсом назначения LAN & VRRP или VRRP (см. ниже LAN Connectivity and 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:

image.png

Элемент

Описание

1

Роль HA Socket - Primary или Secondary

2

Статус HA Socket - Master или Standby

3

HA Статус - Готов или Не готов

4

Специфические условия для общего статуса HA

  • Подключено - Подключение к WAN сети Socket

    • GreenCheck.png- И основной, и вторичный Socket имеют по крайней мере один рабочий туннель, подключенный к Cato Cloud

    • Red_X.png- Socket не имеет рабочих туннелей, подключенных к Cato Cloud

  • Keepalive - состояние HA keepalive канала между Sockets

    • GreenCheck.png- Вторичный Socket получает HA keepalive сообщения от основного Socket

    • Red_X.png- Вторичный Socket не получает HA keepalive сообщения от основного Socket

  • Совместимая версия - И основной, и вторичный Sockets работают под управлением совместимых версий Socket OS

    • GreenCheck.png- Оба Socket работают на совместимой (той же основной) версии Socket, например, 14.0.13986 и 14.0.12764

    • Red_X.png- Socket имеют разные основные версии Socket, например, 14.0.13986 и 13.0.48732

    Примечание: Переключение HA на другой Socket происходит, даже если Sockets работают на разных основных версиях. Однако сайт может столкнуться с проблемами функциональности, если версия вторичного Socket не поддерживает функции, поддерживаемые в основной версии Socket.

    Например, если основной Socket работает на версии 18.0, а вторичный Socket на версии 15.0, при переключении, функции, которые были внедрены в версиях 16 - 18, не будут работать, пока активен вторичный Socket.

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

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

Socket_HA_Regular.png
Socket_HA_Failure.png

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 для отправки трафика на сайт. В случае отказа HA события Socket, вторичный Socket становится новым Master, а PoP перемещает трафик с неудачных туннелей первичного Socket на туннели вторичного Socket. PoP поддерживает состояние потока и состояние NAT, чтобы убедиться, что все пользовательские приложения продолжают работать во время и после отказа.

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

PhysicalLogicalTopology.png

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

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

WAN_Connectivity_Router_Switch.png

Заметка

Note: Использование асимметричной топологии может создать проблемы и не поддерживается Cato. Например, когда порт WAN1 первичного Socket подключен к ISP1, а порт WAN1 вторичного Socket подключен к ISP2.

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 с одним LAN-портом на каждом Socket, подключенным к коммутатору:

HA_LAN_switch.png

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

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

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

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

LAN_VRRP.png

Для получения дополнительной информации об изменении 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 с коммутатором:

SocketHA_LAG.png

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

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

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

Direct_HA_Link.png

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

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

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

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

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

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

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

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

Socket_HA_-_Direct_Port_for_HA_Traffic.png
Socket_HA_-_via_Switch_Port_for_HA.png

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

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

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

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

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

  • LAN-соединение (нет keepalive более трех секунд)

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

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

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

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

Socket_HA_LAN_Failure.png

Вызывают ли проблемы интернет-соединения аварийное переключение 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 показывает статус HA Socket для каждого сайта.

Сеть > Сайты

Сокет

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

Сеть > Сайты > <название сайта> > Конфигурация сайта > Socket

Аналитика сети

Показывает сетевые данные для сайта и Статус HA.

Сеть > Сайты > <название сайта> > Мониторинг сайта > Аналитика сети

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

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

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

Failover.png

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

Вы можете использовать страницу Правила здоровья связи (Сеть > Правила здоровья связи) для создания Правила здоровья соединения, чтобы отправлять email-уведомления для событий переключения Socket HA. Электронные уведомления отправляются всем получателям из Списка рассылки, который вы настраиваете в Cato Управление Приложением. Список рассылки может включать email-адреса, которые не определены для пользователей и администраторов в Cato Управление Приложением.

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

Socket_Failover_Alert.png

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

Была ли эта статья полезной?

Пользователи, считающие этот материал полезным: 15 из 17

0 комментариев