Высокая доступность — это не просто добавление второго устройства, а обеспечение нахождения правильного VIP на правильном узле.
Наличие второго устройства в уровне ADC само по себе не означает высокой доступности. Критические вопросы: какой узел владеет VIP при отказе, используют ли оба узла одну конфигурацию, и выживают ли stick tables и счётчики безопасности при failover. Когда эти части не работают вместе, failover происходит — но пользовательский опыт и поведение безопасности ломаются.
Классический VRRP достаточен для большинства сценариев, но не решает каждую проблему. Узел может казаться работающим, VRRP peer может ещё быть живым, но соответствующий интерфейс может потерять link или шлюз стал недостижим. Если устройство продолжает удерживать VIP в таком состоянии, трафик течёт к узлу, который выглядит живым, но не может достичь внешнего мира.
В вручную управляемых развёртываниях синхронизация конфигурации — отдельный риск. Был ли перенос изменения, сделанного на одном узле, на другой, равны ли наборы сертификатов и правил, на каком устройстве остались логи — всё это требует постоянной проверки. Если нет чёткого ответа на «действительно ли два узла идентичны?», кластер — не надёжная конструкция, а отложенная точка отказа.
Несоответствие оборудования — одна из наиболее опасных тихих неисправностей. Обновлённый узел с другим именем сетевого интерфейса, другим набором ядер CPU или другой ёмкостью памяти может сломать поведение кластера в самый неподходящий момент. Эти различия должны выявляться при присоединении к кластеру, а не во время события failover.
TR7 HA-кластеризация вместе адресует все эти риски: VIP failover, TR7-controlled link/gateway решения, синхронизация, контролируемый рабочий процесс обслуживания и проверки совместимости оборудования — всё управляется в одной модели.
Наш подход
TR7 реализует двухузловую кластеризацию с плоскостью VIP, активным мониторингом, синхронизацией, валидацией оборудования и контролируемым управлением изменениями, работающими совместно.
Два узла управляются как единый логический ADC
Настройки кластера определяются с общей топологией между обоими узлами. Интерфейс управления показывает этот узел и peer-узел в одной модели; изменения правил, сертификатов и сервисов управляются с учётом поведения кластера.
VIP failover определяется VRRP и опциями мониторинга TR7
Владение VIP может управляться классическим VRRP или дополняться link, gateway или link+gateway решениями мониторинга TR7. Это позволяет failover на основе реальной сетевой достижимости, а не только жизнеспособности peer.
Совместимость оборудования валидируется при присоединении к кластеру
Список ядер CPU, имена сетевых интерфейсов и размер памяти сравниваются между обоими узлами. Несоответствия оборудования выявляются при присоединении узла к кластеру — не оставляются проявляться во время события failover.
Режим ручной синхронизации обеспечивает контролируемые изменения при обслуживании
Автоматическая синхронизация может быть временно приостановлена. Оператор вносит изменение на одном узле, тестирует результат и, после проверки, намеренно отправляет все изменения на peer-узел.
Возможности
HA-кластеризация управляет поведением локальной высокой доступности — от владения VIP до репликации состояния — в едином интерфейсе.
VRRP-based VIP failover сохраняет стабильность адресов сервисов
TR7 использует VRRP-модель для управления тем, какой узел владеет каждым VIP-адресом. Поведение MASTER и BACKUP генерируется автоматически для каждого соответствующего интерфейса. Когда активный узел уходит в offline, VIP перемещается на peer и пользовательский трафик продолжается на том же адресе. Эта модель делает проверенную Linux-инфраструктуру доступной через управляющую модель TR7.
Режим переключения выбирается для каждой службы, а не для устройства
Пара устройств TR7 не обязана иметь один характер. Чувствительное к задержкам приложение может работать в режиме active-active на обоих узлах, а стоящее рядом унаследованное приложение с привязкой к лицензии — в active-passive: тот же кластер, та же консоль. Именно это делает миграцию переносимой: службы переходят в active-active по одной, каждая после того, как себя показала, вместо того чтобы поведение всей инфраструктуры менялось за одну ночь и все узнавали результат одновременно.
Link и gateway мониторинг закрывают слепые зоны VRRP
TR7 не ограничивает cluster IP failover одним только VRRP; также доступны методы link, gateway или link+gateway. В режиме link оценивается состояние carrier интерфейса; в режиме gateway проверяется достижимость upstream. В режиме link+gateway оба сигнала оцениваются вместе для более надёжного решения о failover. Это помогает предотвратить нахождение VIP на узле, который кажется живым, но имеет неработающий сетевой путь.
Топологии Active-Passive и Active-Active работают в одной кластерной модели
В Active-Passive один узел несёт сервисные VIP, тогда как другой ожидает в режиме standby. В Active-Active разные VIP могут распределяться по обоим узлам, так что оба устройства несут живой трафик. При падении узла другой берёт владение его VIP. Этот подход позволяет стратегии failover и утилизации ёмкости устройства формироваться в зависимости от архитектурных предпочтений.
Изменения конфигурации и данных автоматически распространяются на peer
При включённой автоматической синхронизации каждая операция insert, update и delete отправляется на peer-узел. Операторам не нужно писать отдельную автоматизацию, выполнять ручное копирование файлов или планировать задания синхронизации. Поддержание согласованности правил, сертификатов и конфигураций сервисов на обоих узлах становится простым. Это снижает неопределённость «действительно ли peer идентичен?» во время failover.
Stick tables и счётчики сохраняются через репликацию на peer
Stick tables, счётчики rate-limiting и IP-state источника могут реплицироваться на peer-узел. При failover поведение пользователя не перезапускается с нуля. Решения captcha, rate-limit или сессионной маршрутизации продолжаются более последовательно после события отказа. Эта функция нацелена не только на передачу VIP, но и на сохранение состояния решений.
Несоответствия оборудования обнаруживаются заблаговременно при присоединении
Набор ядер CPU, сетевые интерфейсы и RAM узлов, присоединяющихся к кластеру, сравниваются. Другое имя интерфейса, отсутствующий NIC или несоответствие памяти рассматриваются как ошибка с самого начала. Это помогает предотвратить проявление тихих аппаратных различий во время failover. Это снижает операционный риск особенно при обновлении оборудования и замене резервных узлов.
Режим ручной синхронизации открывает безопасное тестовое пространство для планового обслуживания
Когда ручная синхронизация включена, автоматическое распространение изменений приостанавливается. Оператор может тестировать новое правило, сертификат или поведение сервиса на одном узле. После завершения валидации изменение отправляется на peer через поток syncAll или requestSyncAll. Эта модель предотвращает мгновенное распространение неправильного изменения по всему кластеру.
IP управления кластером хранятся отдельно от пользовательского трафика
IP из управляющей сети 241.0.1.0/24 назначается для каждого кластерного ID. Внутрикластерная коммуникация концептуально отделена от пользовательского сервисного трафика. Значение кластерного ID используется в диапазоне 1-254, при этом каждый ID соответствует выделенному управляющему IP. Это разделение делает трафик синхронизации и peer-коммуникации более предсказуемо управляемым.
Операционная глубина
HA-кластеризация планируется вместе со слотами VRRP, unicast-коммуникацией, парами управляющих IP, дифференцированием конфигурации, поведением failback и интеграцией с GTM.
Управление слотами VRRP
В сценариях Active-Active 2 слота VRRP, представляющих поведение MASTER и BACKUP, могут генерироваться per интерфейс. Значения virtual_router_id и priority устанавливаются в соответствии с ролью кластера. Эта структура позволяет управлять владением VIP в пределах одной подсети без конфликтов.
Unicast VRRP
В современных сетях дата-центров мультикастный VRRP-трафик может фильтроваться определёнными политиками коммутаторов. TR7 снижает этот риск, управляя информацией peer-узла через unicast peer-подход. VRRP-трафик затем течёт контролируемым образом через ожидаемый IP peer-узла.
Режим принятия решений link и gateway
Метод cluster IP может быть установлен на vrrp, link, gw или link+gw. Метод link принимает решения на основе состояния интерфейса, gw — на основе достижимости шлюза, link+gw — на основе комбинации обоих сигналов. Эти опции делают поведение VIP более реалистичным в разных сетевых дизайнах.
Пара управляющих IP
Синхронизация кластера выполняется через определённую пару IP для каждого интерфейса. Эти IP рассматриваются отдельно от производственных VIP. Это операционно разделяет трафик синхронизации от пользовательского трафика.
Контролируемое поведение failback
Режим nopreempt предотвращает автоматическое возвращение VIP к старому master при его возвращении в online. Это позволяет избежать ping-pong failover в сценариях с временным восстановлением, за которым следует ещё один отказ. Решение о failback принимается намеренно оператором.
Интеграция локального кластера с GTM
Локальный кластер обеспечивает VIP failover в пределах одного дата-центра. Если весь дата-центр уходит в offline, уровень GTM может перенаправить DNS к удалённому дата-центру. Это позволяет обрабатывать локальный отказ узла и отказ дата-центра на двух отдельных уровнях.
Когда применять
Непрерывное владение VIP в финансовых приложениях
Финансовые организации могут запускать VIP мобильного и интернет-банкинга в высокодоступной конфигурации на двух узлах TR7 ADC. Когда узел уходит в offline из-за обслуживания или отказа, другой узел берёт владение VIP и доступ к сервису продолжается на том же адресе.
Интеллектуальная передача VIP при потере шлюза
Сетевые команды могут обеспечить перемещение VIP к другому узлу при потере доступа к шлюзу — даже если сам узел ещё работает. В этом сценарии failover основан на реальной достижимости upstream, а не только на жизнеспособности устройства.
Безопасные изменения при плановом обслуживании с ручной синхронизацией
Государственные органы или операторы критичного бизнеса могут включить режим ручной синхронизации и сначала протестировать изменение на одном узле. После валидации изменение отправляется на peer, предотвращая неконтролируемое распространение по всему кластеру.
Проверка совместимости при обновлении оборудования
Команды operations могут видеть различия CPU, интерфейсов и памяти во время присоединения при удалении старого узла и добавлении нового оборудования в кластер. Предупреждение выдаётся до того, как неправильно сконфигурированный сервер входит в кластер, снижая риск failover.
Часто задаваемые вопросы
В чём разница между топологиями Active-Active и Active-Passive?
Что можно использовать, когда одного VRRP недостаточно?
Как работает синхронизация конфигурации?
Сохраняются ли состояние сессий и rate-limit при failover?
Что происходит при добавлении нового аппаратного узла в кластер?
Как работает failover при совместном использовании с GTM?
Запустите ваш ADC-кластер в единой управляющей модели
VRRP VIP failover, синхронизация конфигурации, валидация оборудования и контролируемый рабочий процесс обслуживания — давайте пройдёмся по всему вместе в живой настройке.