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

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

Перед настройкой кластера необходимо настроить виртуальную сеть (VPN). Для ее работы нужна сетевая связность между экземплярами. Подробные сведения по настройке и необходимым доступам описаны по ссылке.

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

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

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

Если кластер собирается из экземпляров MITIGATOR, которые ранее уже работали независимо, то в ходе интеграции могут возникнуть конфликты. Поэтому на всех экземплярах кроме будущего лидера необходимо выполнить команду:

docker-compose down -v
Информация

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

Экземпляры 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 задать переменную MITIGATOR_HOST_ADDRESS=192.0.2.1. Здесь 192.0.2.1 – адрес MGMT-интерфейса для данного экземпляра.

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

    Информация
    Идентификаторы очередности `MITIGATOR_OWN_INDEX` не соотносятся с идентификаторами
экземпляров кластера `own_id`.

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

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

  5. Создать docker-compose.failover.yml на базе шаблона:

    wget https://docs.mitigator.ru/v24.08/dist/multi/docker-compose.failover.yml

    Редактирование нужно, если используется больше двух экземпляров. Расширение делается по аналогии с двумя имеющимися в шаблоне.

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

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

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

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

    docker-compose up -d

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

    docker-compose run --rm -e PGPORT=15432 postgres standby

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

    docker-compose up -d

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

Восстановление Standby из Active

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

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

    docker-compose rm -fsv postgres

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

    docker-compose run --rm -e PGPORT=15432 postgres standby

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

    docker-compose up -d

Конфликт лидерства

В случае split brain в каждой изолированной части кластера будет выбран свой лидер репликации, то есть кластер распадется на несколько меньших (возможно, из единственной машины).

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

В логах каждого бэкенда-лидера (docker-compose logs backend) будет сообщение такого вида:

time="2021-03-03T19:32:47+03:00" level=error msg=multi-conflict data="{\"primary\":0,\"rivals\":[1],\"sender\":0}" hook=on-multi-conflict

В поле data:

  • sender — индекс экземпляра, который оповещает о произошедшем (MITIGATOR_OWN_INDEX, -index у pgfailover).
  • primary — индекс того экземпляра, который sender читает корректным лидером репликации.
  • rivals — список индексов экземпляров, на которых PostgreSQL работает как лидер репликации, помимо primary.

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