Mitigator в режиме кластера

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

Между экземплярами должна быть сетевая связность, взаимодействие осуществляется по TCP и UDP.

Существует несколько принципиальных схем внедрения.

  • Общее нерезервированное хранилище:

    + простота настройки;
    − при выключении главного экземпляра теряется управление и мониторинг;
    − при отказе диска главного экземпляра теряются данные.

  • Внутреннее отказоустойчивое хранилище:

    + отказоустойчивость за счет репликации БД;
    + нет потребности в дополнительном сервере для хранилища;
    − ресурсы экземпляров Mitigator´а расходуются на нужды хранилища;
    − повышенные требования к квалификации администратора;
    − отсутствие гибкости настройки.

  • Внешнее отказоустойчивое хранилище:

    + полный контроль и гибкость (отказоустойчивость, тонкая настройка);
    + снимается нагрузка с экземпляров Mitigator´а;
    − требуется квалификация администратора;
    − нужен дополнительный сервер для хранилища;
    − необходимо запускать миграцию вручную при обновлении.

После установки и запуска настроить систему для её стабильной и безопасной работы.

Общее нерезервированное хранилище

Общие базы данных для всех экземпляров Mitigator´а физически хранятся на сервере одного из них. К базовому экземпляру должны быть разрешены подключения с остальных экземпляров по следующим портам TCP: 8888, 2003, 3080, 5432.

Общее нерезервированное хранилище

Установка базового экземпляра выполняется по шагам, описанным в разделе «Установка».

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

  1. Скачать docker-compose.worker.yml:

    wget https://docs.mitigator.ru/dist/multi/docker-compose.worker.yml \
    -O docker-compose.worker.yml

  2. В файле .env задать переменную COMPOSE_FILE так:

    COMPOSE_FILE=docker-compose.yml:docker-compose.worker.yml

    Если требуются дополнительные настройки, например, при использовании карт Mellanox, поместить их в docker-compose.override.yml и добавить его в список:

    COMPOSE_FILE=docker-compose.yml:docker-compose.override.yml:docker-compose.worker.yml

  3. В файле .env задать переменную MITIGATOR_STORAGE_HOST=192.0.2.1. Здесь 192.0.2.1 – адрес базового экземпляра.

  4. В файле .env задать переменную MITIGATOR_OWN_NAME=mitigator-1. Здесь mitigator-1 – имя экземпляра. Имя каждого экземпляра должно быть уникально.

  5. В файле .env задать переменную MITIGATOR_OWN_ADDRESS=192.0.2.1. Здесь 192.0.2.1 – адрес хоста для данного экземпляра.

Внутреннее отказоустойчивое хранилище

В целях отказоустойчивости синхронизированные копии БД должны физически храниться на разных серверах (реплицироваться). При данной схеме реплики БД хранятся на тех же серверах, где работают экземпляры Mitigator´а. Это позволяет сэкономить ресурсы и не требует знаний по настройке PostgreSQL.

Внутреннее отказоустойчивое хранилище

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

Отказоустойчивая БД на двух узлах

Если лидер недоступен, pgfailover делает лидером одну из ведомых реплик в заданной очередности. Mitigator-лидер кластера и PostgreSQL-лидер репликации не обязаны совпадать.

Предполагается, что между узлами надежная связь. Если группа экземпляров окажется отрезана от лидера репликации, среди них будет выбран новый лидер (split-brain). После восстановления связи придется вручную удалить данные на отрезанной части экземпляров и заново ввести их в кластер.

Метрики для графиков пишутся Mitigator´ом-лидером на все экземпляры для сохранности. Это задается списком серверов FWSTATS_GRAPHITE_ADDRESS.

Настройка

Процесс настройки описан для двух экземпляров и одинаков на всех экземплярах, кроме конкретных значений MITIGATOR_OWN_INDEX. Для большего количества экземпляров нужно расширить по аналогии списки серверов pgfailover и FWSTATS_GRAPHITE_ADDRESS.

  1. В файле .env задать переменную COMPOSE_FILE так:

    COMPOSE_FILE=docker-compose.yml:docker-compose.failover.yml

    Если требуются дополнительные настройки, например, при использовании карт Mellanox, поместить их в docker-compose.override.yml и добавить его в список:

    COMPOSE_FILE=docker-compose.yml:docker-compose.override.yml:docker-compose.failover.yml

  2. В файле .env задать переменную MITIGATOR_OWN_ADDRESS=192.0.2.1. Здесь 192.0.2.1 – адрес хоста для данного экземпляра.

  3. В файле .env задать переменную MITIGATOR_OWN_INDEX=0. Здесь 0 – идентификатор очередности данного экземпляра стать Active-сервером PostgreSQL. Должен быть уникальным и последовательно возрастающим на каждом экземпляре.

  4. В файле .env задать переменные SERVER1=192.0.2.1 и SERVER2=192.0.2.2. Здесь 192.0.2.1 и 192.0.2.2– внешние адреса серверов, на которых запущены экземпляры.

  5. Создать файл docker-compose.failover.yml и задать конфигурацию, приведенную ниже.

    version: "2.2"
services:
  backend:
    environment:
      BACKEND_DATABASE_URI: "postgres://backend@pgfailover.mitigator/mitigator?sslmode=disable"

  fwstats:
    environment:
      FWSTATS_GRAPHITE_ADDRESS: "${SERVER1}:2003,${SERVER2}:2003"

  carbon-clickhouse:
    ports:
    - "2003:2003"

  pgfailover:
    image: docker.mitigator.ru/product/pgfailover:${VERSION:-latest}
    networks:
      default:
        aliases:
        - pgfailover.mitigator
    volumes:
    - failover:/trigger:rw
    command:
    - "/pgfailover/pgfailover"
    - "-index"
    - "${MITIGATOR_OWN_INDEX}"
    - "-server"
    - "postgres://repuser@${SERVER1}:5432/mitigator?sslmode=disable"
    - "-server"
    - "postgres://repuser@${SERVER2}:5432/mitigator?sslmode=disable"
    - "-trigger"
    - "/trigger/failover"

  postgres:
    volumes:
    - failover:/failover:rw
    depends_on:
    - pgfailover

volumes:
  failover:

Использование

  • Стенд с Active базой запускается как обычно:

    systemctl start mitigator

  • Стенд с Standby инициализируется репликой:

    docker-compose run --rm postgres standby

    после чего запускается как обычно:

    systemctl start mitigator

Если произойдет разрыв соединения с экземпляром-лидером (базы в режиме Active), экземпляр с базами в режиме Standby занимает его место и становится лидером. Механизма переключения баз бывшего лидера в режим Standby не предусмотрено штатной репликацией PostgreSQL. Для схемы из двух баз данных это означает прекращение репликации на другой сервер до ручной перенастройки схемы.

Поднятие Standby из бывшего Active

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

  1. Остановка сервиса PostgreSQL:

    docker-compose rm -fsv postgres

  2. Удаление локальных данных базы:

    docker volume rm mitigator_postgres

  3. Инициализация Standby аналогично первой инициализации:

    docker-compose run --rm postgres standby

    после чего запускается как обычно:

    systemctl start mitigator

Внешнее отказоустойчивое хранилище

Данная схема внедрения подразумевает физическое хранение общих для всех экземпляров Mitigator´а баз данных на внешнем сервере. Работоспособность и отказоустойчивость всех СУБД обеспечивается силами администратора внешнего сервера под конкретные требования.

Внешнее отказоустойчивое хранилище

Все экземпляры разворачиваются как worker´ы (см. выше).

Схема взаимодействия:

  • Mitigator подключается к Postgres для записи и чтения настроек и журналов;
  • Mitigator оправляет в graphite метрики и обращается к его API;
  • в качестве бэкенда Graphite рекомендуется ClickHouse.

Настройка Postgres

В качестве инструмента для миграции схемы и дальнейшего управления используется утилита SHMIG.

Миграции необходимо брать прямо из контейнера используемой версии:

  1. Развернуть полноценный стенд (временно закомментировать строку #COMPOSE_FILE= в файле .env).

  2. Выполнить команду:

    docker-compose create postgres

  3. Выполнить команду:

    docker cp mitigator_postgres_1:/schema schema

  4. Выполнить команду:

    docker-compose rm -sf postgres

  5. Восстановить состояние файла .env, раскомментировав строку #COMPOSE_FILE=.

На уровне Postgres необходимо создать базу mitigator. Скрипты миграций создадут пользователя backend и назначат ему необходимые права. После чего на уровне СУБД нужно разрешить подключение для этого пользователя.

Экземпляры Mitigator´а подключаются к порту 5432/tcp. Строку подключения можно явно переопределить, по умолчанию используется:

services:
  backend:
    environment:
      BACKEND_DATABASE_URI: "postgres://backend@${MITIGATOR_STORAGE_HOST}/mitigator?sslmode=disable"

Настройка Graphite

Mitigator отправляет метрики в формате Graphite plaintext protocol по адресу: ${MITIGATOR_STORAGE_HOST}:2003 (TCP). Если нужно отправлять их в несколько баз, адреса можно указать явно через запятую:

services:
  fwstats:
    environment:
      FWSTATS_GRAPHITE_ADDRESS: "${MITIGATOR_STORAGE_HOST}:2003,another-host:2003"

Mitigator обращается к Graphite API по URL: http://${MITIGATOR_STORAGE_HOST}:3080/render/.

Настройка ClickHouse

Только если ClickHouse используется в качестве бэкенда Graphite.

  1. Развернуть полноценный стенд (закомментировать строку #COMPOSE_FILE= в файле .env).

  2. Выполнить команду:

    docker-compose create clickhouse

  3. Выполнить команды:

    docker cp mitigator_clickhouse_1:/etc/clickhouse-server/config.d clickhouse-config
docker cp mitigator_clickhouse_1:/etc/clickhouse-server/users.d clickhouse-users
docker cp mitigator_clickhouse_1:/docker-entrypoint-initdb.d clickhouse

  4. Выполнить команду:

    docker-compose rm -sf clickhouse

  5. Восстановить состояние файла .env, раскомментировав строку #COMPOSE_FILE=.

  6. В файле .env задать переменную MITIGATOR_OWN_NAME=mitigator-1. Здесь mitigator-1 – имя экземпляра. Имя каждого экземпляра должно быть уникально.

  7. В файле .env задать переменную MITIGATOR_OWN_ADDRESS=192.0.2.1. Здесь 192.0.2.1 – адрес хоста для данного экземпляра.

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

Управление через web-интерфейс

Основным изменением в интерфейсе Mitigator´а при переходе на режим кластера стало разделение некоторых настроек на относящиеся к системе в целом и для конкретных экземпляров.

Вкладка «Система»

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

Страница «Экземпляры»

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

Страница «Экземпляр»

Разделы «Интеграция в сеть» и «GRE-туннель со сторонним сервисом» теперь также находятся на вкладке «Экземпляры», так как для корректной работы системы следует задать параметры внедрения в сеть для каждого экземпляра.

Mitigator позволяет использовать агрегацию каналов (LAG) между устройствами во внешней и внутренней сети. Настройки интеграции в сеть влияют на то, какие варианты агрегации каналов могут использоваться:

  • в режиме «L2-прозрачность» — статический или динамический (например, LACP);
  • в режиме «On-a-stick» — только статический LAG.

Mitigator позволяет балансировать нагрузку между несколькими экземплярами системы по ECMP за счет анонсирования по BGP каждым экземпляром одинаковых префиксов. Когда один из экземпляров отключается, анонс снимается и трафик автоматически распределяется между оставшимися экземплярами.

Карточка «Лицензия» разделена на две. В настройках системы задается значение лицензионного ключа, а в настройках экземпляра находятся элементы управления лицензированной полосой и сервисная информация.

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

Выбор экземпляра для показа графиков