Кластерная терминология

MITIGATOR может быть собран в кластер различных конфигураций, с разным набором подсистем и их взаимосвязей в зависимости от решаемой задачи и ограничений. В статье перечислены ключевые термины, описывающие кластеризацию MITIGATOR на различных уровнях.

Уровни кластеризации

В таблице представлен пример кластера из четырех экземпляров MITIGATOR, в котором на разных уровнях экземпляры выполняют разные роли. Под экземпляром понимается устройство, на котором развернута одна или несколько подсистем MITIGATOR. Обычно на экземпляре как минимум развернут Backend, но в некоторых случаях это могут быть другие подсистемы, например Colleсtor или Graphite.

Частный случай кластеризации

В частном случае кластеризации:

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

Кластеризация на уровне системы

Когда несколько экземпляров MITIGATOR объединяются в кластер, каждый из них начинает отображаться в списке экземпляров в разделе «Настройки системы».

Экземпляры в кластере бывают:

• активными,
• неактивными.

Активные экземпляры “готовы к работе” в кластере. Для таких экземпляров возможно указание лицензионной полосы, они могут участвовать в выборе Backend-лидера, к ним применяются общие для всего кластера параметры защиты, – это полноценные участники кластера.

Перевод экземпляра в состояние неактивности означает деактивацию экземпляра, как если бы он был физически удален из кластера. Экземпляр освобождает лицензионную полосу и не участвует во взаимодействии с другими экземплярами или в обработке трафика.

Кластеризация на уровне Backend

Для того, чтобы все экземпляры кластера управлялись централизованно и обрабатывали поступающий трафик одинаково, каждому из них должны передаваться одинаковые настройки из единого источника. За управление кластером отвечает подсистема Backend.

Кластеризация на уровне Backend предполагает, что на каждом из экземпляров кластера Backend находится в одной из трех возможных ролей:

• лидер – экземпляр системы, управляющий работой всего кластера в текущий момент времени,
• резервный лидер – ведомый экземпляр, который может стать новым лидером в случае отказа текущего лидера,
• не может быть лидером – ведомый экземпляр, который не может стать лидером и не участвует в процедуре выбора лидера в случае его отказа.

Графики

Под Graphite понимается набор подсистем для построения графиков. По умолчанию все данные для построения графиков в кластерной инсталляции записываются во все доступные Graphite. Данные вычитываются из Graphite только одного экземпляра, который в данный момент является Backend-лидером. Можно настроить балансировку запросов к нескольким Graphite.

В конкретный Graphite, либо только записываются данные (W), либо записываются и читаются из него (R/W).

Репликация Postgres

В целях повышения отказоустойчивости базы данных может быть настроено ее резервирование по схеме потоковой репликации active — hot standby. В такой схеме создается кластер базы данных, в котором одна из инсталляций базы выполняет роль основной, а остальные являются резервными.

Поэтому на уровне Postgres все базы данных в кластере имеют один из двух возможных статусов:

• Primary,
• Standby.

За отслеживание состояний баз и переход статуса Primary в MITIGATOR отвечает компонент системы pgfailover. С точки зрения pgfailover, добавляются дополнительные статусы:

• Primary – pgfailover считает базу данных основной,
• Standby – pgfailover считает базу данных резервной,
• Конкурирующая – pgfailover уже считает другую базу основной, но текущая база заявляет о себе как об основной,
• Недоступна – связь с базой данных отсутствует.

При нормальном функционировании кластера роли баз данных на уровне pgfailover должны совпадать.

Синхронизация таблиц между экземплярами

При работе в кластере возможны сценарии, когда организуются резервные пути прохождения и обработки трафика. Резервные экземпляры MITIGATOR не наполняют таблицы аутентифицированных IP-адресов и списки временной блокировки, пока на них не поступает трафик. Чтобы при переключении обеспечить переход на резервный экземпляр без разрыва соединений и пропуска атаки, предусмотрена синхронизация данных таблиц контрмер между обработчиками пакетов.

Экземпляры кластера разделены на зоны синхронизации, синхронизация данных между обработчиками пакетов выполняется в каждой зоне независимо. Экземпляр может входить только в одну зону синхронизации. Экземпляры, не включенные ни в одну зону, не синхронизируют данные.

В рамках механизма синхронизация таблиц между экземплярами, экземпляр может обладать состояниями:

• мастер синхронизации зоны (Master),
• участник синхронизации в составе зоны (Member),
• экземпляры, не принадлежащие зоне.

Активная синхронизация

При работе в кластере может потребоваться синхронизировать данные об установленных сессиях между несколькими экземплярами. Например в случае, когда трафик одной сессии проходит через несколько экземпляров, и все экземпляры должны обрабатывать этот трафик одинаково.

Все экземпляры можно разделить на две категории:

• использующие активную синхронизацию;
• не использующие активную синхронизацию.

Для правильной работы синхронизации все синхронизируемые экземпляры должны как отправлять, так и принимать сообщения. При необходимости синхронизировать состояния каждый экземпляр, использующий активную синхронизацию, отправляет по копии сообщения каждому другому участнику синхронизации. Таким образом, у сообщения есть:

• экземпляр-отправитель,
• экземпляры-получатели.

VRRP

MITIGATOR поддерживает взаимодействие по VRRP (Virtual Router Redundancy Protocol) при способе подключения «L3-роутер» на сетевом уровне. В этом режиме интерфейсы экземпляров MITIGATOR для внешних устройств представляются одним виртуальным IP-адресом (vIP) и одним виртуальным MAC-адресом (vMAC). При получении ARP-запроса на vIP-адрес VRRP-мастер сообщает сетевому устройству vMAC. Трафик маршрутизируется только на один экземпляр кластера, который в настоящий момент является VRRP-мастером. В случае его отказа статус мастера переходит к другому экземпляру согласно указанным приоритетам. Для внешней и внутренней сетей статусом VRRP-мастера могут обладать разные экземпляры.

На уровне взаимодействия по VRRP, все экземпляры делятся на:

• VRRP Master,
• VRRP Backup,
• все прочие, не участвующие в VRRP.

Collector

Для горизонтального масштабирования задачи обработки Flow могут быть развернуты несколько экземпляров с Collector. Эти экземпляры принципиально не отличаются друг от друга. Backend-лидер MITIGATOR обращается для получения метрик ко всем подключенным Collector и агрегирует статистику.