В этой статье обсуждаются конфигурации высокой доступности (HA) и условия переключения для сайтов, использующих пару физических Socket от Cato.
Для повышения устойчивости сайта, Cato настоятельно рекомендует развертывать каждый сайт с парой Sockets, работающих в режиме высокой доступности (HA). Этот режим работы обеспечивает непрерывность обслуживания сайта в случае отказа одного Socket. В процессе перехода Cato Cloud поддерживает состояние потоков, и влияние на работу конечных пользователей минимально.
Поддерживаемые сайты с высокой доступностью Socket
Cato поддерживает HA Socket для следующих сред:
-
Физический сайт Socket
-
Сайт AWS vSocket
-
Сайт Azure vSocket
В этой статье объясняется, как работает HA для физического сайта Socket. Для получения дополнительной информации о настройке HA для Sockets в несколько кликов смотрите Использование Sockets в развертывании HA.
-
Для подробностей об AWS vSocket HA смотрите Настройка HA для AWS vSockets
-
Для подробностей об Azure vSocket HA смотрите Настройка высокой доступности для Azure vSockets
Сайты HA Socket могут использовать два Socket одного типа X1500, X1600, X1600 LTE или X1700. Однако нельзя использовать разные типы Socket, поэтому сайт с Socket X1600 и X1700 не поддерживается.
Вы не можете использовать Socket X1600 и X1600 LTE на одном сайте HA.
В развертывании HA Socket две Socket Cato назначаются одному сайту. Первый Socket, назначенный сайту, идентифицируется как основной Socket, второй - как вторичный Socket. Socket работают в режиме HA Active/Standby. Во время нормальной работы сайта основной Socket имеет статус HA Master, в то время как вторичный Socket имеет статус HA Standby. Только Socket с статусом HA Master обрабатывает трафик.
-
Вторичный (Standby) Socket постоянно отслеживает состояние (жизнеспособность) основного Socket, прослушивая периодические keepalive сообщения, которые отправляет основной Socket. Сообщения Keepalive отправляются через указанное интерфейсом назначения LAN & VRRP или VRRP (см. ниже LAN Connectivity and Socket HA).
-
Как только вторичный (Standby) Socket обнаруживает, что основной Socket вышел из строя, он изменяет свой статус HA на Master и начинает обрабатывать трафик. Это происходит после трех секунд пропущенных keepalive сообщений HA.
-
Вторичный Socket отправляет GARP сообщение в локальные сети для ускорения сходимости уровня 2.
-
Когда основной Socket восстанавливается и возвращается к регулярной функциональности, он превентивно становится Master, а вторичный Socket возвращается в режим Standby.
Следующее изображение показывает страницу настройки HA для Socket X1500 в приложении управления Cato в Сеть > Сайты > {site name} > Конфигурация сайта > Socket:
Следующие диаграммы показывают пример проблемы основного Socket, которая вызывает переключение на вторичный Socket. Когда вторичный Socket обнаруживает, что основной Socket вышел из строя, он меняет свой статус на Master. Cato Cloud передает потоки трафика на WAN-связи во вторичном Socket.
|
|
Состояние 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 состояния только вторичный Socket обрабатывает трафик для сайта (даже если есть состояние split-brain).
-
Для нисходящего трафика (от PoP к сайту):
-
PoP обнаруживает, что вторичный Socket теперь является Master.
-
PoP устанавливает предпочтительную метрику для туннелей вторичного Socket.
Нисходящий трафик теперь маршрутизируется только во вторичный Socket.
-
-
Для восходящего трафика (от сайта к PoP):
-
Когда вторичный Socket меняет состояние HA с Standby на Master, он отправляет GARP сообщение в LAN, чтобы обновить таблицы ARP и MAC, что теперь он является Master.
Восходящий трафик из LAN теперь маршрутизируется только в вторичный Socket.
-
И основной, и вторичный Sockets устанавливают DTLS туннели к тому же Cato Cloud PoP на каждом из WAN портов. В восходящем направлении только Master Socket отправляет трафик в PoP. В нисходящем направлении PoP использует только туннели Master Socket для отправки трафика на сайт. В случае отказа HA события Socket, вторичный Socket становится новым Master, а PoP перемещает трафик с неудачных туннелей первичного Socket на туннели вторичного Socket. PoP поддерживает состояние потока и состояние NAT, чтобы убедиться, что все пользовательские приложения продолжают работать во время и после отказа.
Ниже приведены примеры физических и логических топологий для HA Socket:
Для оптимальной WAN-связи, производительности и функциональности HA, Cato требует симметричной (отраженной) прокладки кабелей для обоих Sockets. Например, если порт WAN1 первичного Socket подключен к ISP1, а порт WAN2 подключен к ISP2, вторичный Socket должен иметь такие же порты, подключенные к тем же ISP, что и первичный Socket.
Эти симметричные топологии могут включать прямые подключения к маршрутизаторам ISP или использовать стек коммутаторов.
Заметка
Note: Использование асимметричной топологии может создать проблемы и не поддерживается Cato. Например, когда порт WAN1 первичного Socket подключен к ISP1, а порт WAN1 вторичного Socket подключен к ISP2.
Cato требует, чтобы и первичный, и вторичный Sockets имели симметричную (отраженную) конфигурацию кабелей для LAN-связи. Например, порт LAN 1 как на первичном, так и на вторичном Socket подключен к LAN-коммутатору (или порты LAN 1 и 2 для конфигураций с несколькими LAN-портами).
В этом разделе обсуждаются следующие варианты LAN-связи для HA Socket:
-
Один LAN порт
-
Несколько LAN портов
-
Агрегация LAN ссылок (рекомендуемый вариант)
-
Выделенный порт для сообщений keepalive HA
Некоторые из этих опций требуют дополнительных настроек сайта в Cato Management Application. Например, порт LAN настроен для LAN & VRRP или VRRP.
Есть конфигурации, которые используют один LAN-порт для подключения первичного и вторичного Sockets к LAN-коммутатору. С этой конфигурацией, один и тот же номер порта должен использоваться на обоих Sockets. Пользовательский трафик и сообщения keepalive HA проходят по одной связи. Эта топология не обеспечивает избыточности LAN-связи.
На диаграмме ниже показана примерная топология HA Socket с одним LAN-портом на каждом Socket, подключенным к коммутатору:
В этом разделе обсуждается момент, когда как первичные, так и вторичные Sockets подключены к LAN-коммутаторам через два или более независимых LAN-порта. С этой конфигурацией, одни и те же порты должны использоваться на обоих Sockets для LAN-связи.
По умолчанию, порт LAN с наименьшим номером используется как для keepalive HA, так и для пользовательского трафика. Оставшиеся LAN-порты передают только пользовательский трафик.
Вы можете выбрать любой LAN-порт для keepalive HA, изменив Destination порта с LAN на LAN & VRRP. На следующем скриншоте показан порт 3 для LAN пользовательского трафика и порт 4 для keepalive HA и пользовательского трафика.
Для получения дополнительной информации об изменении LAN-порта для трафика Keepalive HA, смотрите Использование Sockets в развертывании HA. Эта топология не обеспечивает избыточность LAN-связи.
Отказоустойчивость HA Socket (где вторичный Socket становится Master) происходит только при выполнении обоих следующих условий:
-
Вторичный Socket прекращает получение сообщений keepalive HA от первичного Socket на период три секунды.
-
Порт LAN & VRRP на вторичном Socket находится в состоянии CONNECTED.
Если порт LAN Вторичного Socket отключен, он не станет Master, чтобы избежать возможности состояния split-brain.
Оба Socket, как основной, так и вторичный, подключены к коммутаторам LAN через два или более портов LAN, объединенных в агрегацию каналов (LAG). С этой конфигурацией необходимо использовать одинаковые порты на обоих Socket для соединения LAN. Эта топология обеспечивает резервирование LAN соединений как для передачи пользовательского трафика, так и для сообщений HA keepalive. Если один из портов-членов LAG выходит из строя, остальные порты продолжают нести пользовательский трафик и трафик HA keepalive.
Эта топология обеспечивает как устойчивость соединений, так и устойчивость Socket и считается лучшей практикой.
Чтобы узнать больше о LAN LAG, смотрите Настройка агрегирования ссылок для Socket.
Следующая схема является примером топологии подключения LAN к HA Socket, использующей LAN LAG с коммутатором:
В этой конфигурации вы изолируете трафик HA Keepalive от трафика LAN. Вы можете выделить один порт (LAN, WAN или USB-порты) только для трафика HA Keepalive, используя один или несколько оставшихся LAN-портов для трафика LAN.
Чтобы задать выделенный LAN-порт для трафика HA Keepalive, установите Destination порта на VRRP. Затем установите опцию HA link between sockets на Direct или Via Switch.
Это настройки выделенного порта:
-
Direct (кабель back-to-back между Socket) – в данной конфигурации, если вторичный Socket перестает получать HA Keepalive сообщения, он становится Master независимо от состояния порта VRRP.
-
Через коммутатор – в данной конфигурации порт VRRP на обоих Socket подключен к коммутатору. Поведение при failover зависит от состояния порта VRRP вторичного Socket:
-
Когда состояние порта вторичного Socket подключено, но keepalive сообщения не получены – вторичный Socket становится Master.
Вторичный Socket предполагает, что состояние вызвано отказом первичного Socket.
-
Когда состояние вторичного порта Socket Отключено - вторичный Socket не становится Master (предполагая, что это локальная проблема между ним и коммутатором).
Вторичный Socket предполагает, что первичный Socket работает правильно, и не становится Master, чтобы избежать возможности состояния split-brain.
-
Это схемы настроек выделенного порта с использованием прямого и переключаемого каналов:
|
|
Этот раздел описывает условия, вызывающие аварийное переключение с первичного Socket на вторичный Socket.
Этот сценарий аварийного переключения вызван неисправностью первичного Socket. Socket считается находящимся в нерабочем состоянии по одной из этих причин:
-
Общая неисправность Socket или потеря питания
-
LAN-соединение (нет keepalive более трех секунд)
-
Нет соединения с Интернетом более десяти секунд
Существует также сценарий аварийного переключения, вызванный тем, что вторичный Socket не получает keepalive сообщения от первичного Socket в течение трех секунд.
Когда вторичный Socket обнаруживает, что первичный Socket вышел из строя, он изменяет свой статус на Master. Cato Cloud передает потоки трафика на WAN каналы во вторичном Socket. Следующая схема иллюстрирует этот сценарий.
Socket используют механизм зондирования для определения состояния подключения к Интернету. Если основной Socket определяет, что соединение с Интернетом не работает по всем интернет-связям (Cato-связям) более 10 секунд, он перестает передавать keepalive-сообщения HA. Это вызывает переключение на вторичный Socket.
Заметка
Примечание: возможна ситуация, когда основной Socket имеет интернет-соединение, однако все DTLS-туннели находятся в состоянии ОТКЛЮЧЕНО. Поскольку Sockets имеют механизмы восстановления интернет и WAN, эта ситуация не вызывает переключение на вторичный Socket. Эти механизмы восстановления позволяют Socket повторно подключиться к другому PoP в Cato Облаке.
В этом разделе обсуждаются разные страницы в Cato Управление Приложением, которые вы можете использовать для мониторинга состояния и событий для Socket HA.
Существуют разные страницы в Cato Управление Приложением, которые показывают статус HA Socket для сайта.
Название страницы |
Описание |
Путь |
---|---|---|
Сайты |
Показывает все сайты в учетной записи. Столбец Статус HA показывает статус HA Socket для каждого сайта. |
Сеть > Сайты |
Сокет |
Показывает детали HA Socket для сайта. См. выше Понимание высокой доступности Socket и аварийного переключения. |
Сеть > Сайты > <название сайта> > Конфигурация сайта > Socket |
Аналитика сети |
Показывает сетевые данные для сайта и Статус HA. |
Сеть > Сайты > <название сайта> > Мониторинг сайта > Аналитика сети |
Каждый раз, когда происходит переключение Socket, когда вторичный Socket активен более 35 секунд, генерируется событие Socket Fail-Over. Например, если основной Socket обновляется до новой версии Socket, и процесс обновления занимает 20 секунд, событие Socket Fail-Over НЕ генерируется, поскольку вторичный Socket был активен только 20 секунд.
Вы можете увидеть событие в Cato Управление Приложением на странице Главная > События. Вот пример события, показывающего переключение с основного на вторичный Socket.
Вы можете использовать страницу Правила здоровья связи (Сеть > Правила здоровья связи) для создания Правила здоровья соединения, чтобы отправлять email-уведомления для событий переключения Socket HA. Электронные уведомления отправляются всем получателям из Списка рассылки, который вы настраиваете в Cato Управление Приложением. Список рассылки может включать email-адреса, которые не определены для пользователей и администраторов в Cato Управление Приложением.
Это пример правила здоровья соединения для переключения Socket:
Для получения дополнительной информации о настройке правила здоровья подключения смотрите Работа с правилами здоровье ссылки.
0 комментариев
Войдите в службу, чтобы оставить комментарий.