6.1. Отказоустойчивый кластер Boro

В данной главе описано создание отказоустойчивого кластера из двух серверов с установленным ПО Boro Solution. Отказоустойчивый кластер — группа серверов, которая обеспечивает высокий уровень доступности и минимальное время простоя при сбоях. Кластер состоит из двух узлов — активного или первичного (primary) сервера и резервного (standby) сервера. Если на первичном узле происходит сбой, функционирование приложения переключается на резервный сервер.

Возможности кластера:

  • Максимальное число серверов в кластере — 2 (primary/standby).

  • Горячее резервирование. Время переключения — менее 5с.

  • Глубина потери статистики при переключении — до 5 минут.

  • Идентичная функциональность обоих серверов, после переключения приложение Boro Solution полностью сохраняет работоспособность без каких-либо ограничений.

  • Полная репликация данных: настройки сервера, метрики, журналы, эскизы и пр.

  • Ручное переключение (из командной строки) или API для переключения. Требуется внешняя система мониторинга состояния серверов.

  • Можно добавить резервирование для ранее установленного и находящегося в эксплуатации Boro Solution (необходимо обновление).

Для создания кластера необходимо:

  • Написать обращение в техническую поддержку.

  • Подготовить два близких по производительности сервера, с одинаковым дисковым пространством (выделенным для работы приложения Boro Solution). Требования к производительности серверов идентичны требованиям к серверу без High Availability. В разделе Подготовка сервера можно найти рекомендации по выбору сервера и установке ОС.

  • Организовать прямую сетевую связанность серверов. Требования к минимальной скорости передачи данных между двумя серверами можно охарактеризовать как «на порядок больше, чем входящий битрейт от всех зондов». Однако необходимо понимать, что при первом подключении резервного сервера к первичному или после восстановления связи между серверами кластера, запустится процесс репликации БД. Скорость выполнения репликации в первую очередь будет зависеть от пропускной способности сети.

  • Обязательно использовать NTP для всех серверов в кластере.

6.1.1. Создание и настройка кластера

Установка Boro Solution

Чтобы создать отказоустойчивый кластер, потребуется два сервера Boro Solution.

  1. Установите ПО Boro Solution на серверы. Подробнее в разделе Установка Boro Solution Server.

    Примечание

    1. Установка Boro Solution на узлах будущего кластера должна происходить при одних и тех же условиях (набор переменных, задаваемый в boro_install_variables.sh). Переменная SERVER_PUBLIC_NAME должна иметь одинаковое значение у всех узлов. Это имя хоста, указывающее на первичный сервер.

    2. Первичный и резервный серверы должны находиться в прямой сетевой видимости. Использование NAT не позволит установить соединение между ними.

    3. Синхронизация времени по NTP должна работать корректно на обоих узлах.

  2. Загрузите на серверы сертификаты.

    Определите, какой из серверов будет первичным, создайте CSR сертификат. Перейдите на резервный узел и также создайте CSR сертификат. Запросите выпуск сертификатов в технической поддержке и установите их на обоих серверах. Создание и загрузка сертификатов подробно описаны в разделе Установка сертификатов.

    Примечание

    Рекомендуется загружать сертификаты сразу после установки Boro Solution, поскольку после регистрации узлов кластера все запросы с резервного сервера будут перенаправляться на первичный узел, и загрузка сертификатов станет проблематичной.

Загрузка дополнения для создания кластера

Дополнение для создания отказоустойчивого кластера предоставляется инженером компании Элекард в виде архива. Архив нужно загрузить на оба узла кластера. После каждой загрузки необходимо выполнить команду от имени root-пользователя:

TMP_DIR=$(mktemp -d)
tar -C $TMP_DIR -xf /PATH/TO/install_HA.2024-xx-xx.01.tgz
$TMP_DIR/install_HA.sh
[ "${TMP_DIR#/}" -a -d "$TMP_DIR" ] && rm -rf "$TMP_DIR"

Вместо /PATH/TO укажите путь к архиву, заменив install_HA.2024-xx-xx.01.tgz на фактическое имя архива.

Инициализация узлов отказоустойчивого кластера

На сервере, который выбран в качестве первичного, выполните команду от имени root-пользователя:

/opt/elecard/boro/bin/HA_ctrl register

Примечание

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

Зарегистрируйте второй Boro-сервер в качестве резервного. Для этого выполните следующие шаги:

  1. Скопируйте SSH-ключ:

    • На резервном сервере запустите команду:

      cat ~root/.ssh/id_ed25519-HA.pub

    Скопируйте и сохраните строку, полученную в ответ.

    • На первичном сервере выполните следующую команду, добавив скопированную строку:

      echo "ssh-ed25519 ...." >>~root/.ssh/authorized\_keys

      Если не добавить строку, дальнейшая регистрация сервера завершится преждевременно с мини-инструкцией.

  2. От имени root-пользователя запустите команду, чтобы зарегистрировать резервный сервер:

    /opt/elecard/boro/bin/HA_ctrl register <PRIMARY_IP_OR_HOSTNAME>

    Вместо <PRIMARY_IP_OR_HOSTNAME> задайте IP-адрес или имя хоста первичного узла.

    Запустится процесс репликации БД между серверами кластера.

    Примечание

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

6.1.2. Работа с кластером

Общая информация

Все запросы зондов перенаправляются с резервного сервера к первичному. HTTP-запросы от браузеров, кроме тех, что содержат путь, начинающийся с /HA/, также перенаправляются с резервного сервера на первичный. Ответы на такие запросы содержат заголовок X-HA-Proxy: <NODE_NAME>. HTTP-запросы, в которых путь начинается с /HA/, не перенаправляются и выполняются на запрошенном узле. К таким путям относятся:

  • /HA/health_check — возвращает JSON-объект с информацией о состоянии узла. Объект содержит следующие параметры:

    • node — имя узла;

    • state — роль узла в кластере, например primary, standby или unknown;

    • health — параметр, который показывает, работоспособен ли узел; принимает значение true или false;

    • last_promotion — последнее повышение узла до роли первичного сервера (в формате Unix-времени). Если уровень узла никогда не повышался, значение равно 0.

    Даже если узел неработоспособен, в ответ должен возвращаться HTTP код 200.

  • /HA/metrics — метрики для Prometheus, ПО для отслеживания событий и отправки оповещений;

При использовании трех перечисленных выше путей аутентификация не производится, но вы можете разрешить или ограничить доступ, отредактировав настройки в файле /etc/nginx/sites-include/boro_HA.conf.

Кроме HTTP-запросов, работать с кластером можно с помощью команды /opt/elecard/boro/bin/HA_ctrl. Если выполнить команду без указания аргументов/параметров, отобразится текущее состояние узла. Чтобы вывести справочное сообщение, передайте аргумент -h: /opt/elecard/boro/bin/HA_ctrl -h.

Просмотр состояния узла

Проверить состояние узла можно следующим образом:

  • Выполнив команду от имени root-пользователя:

    /opt/elecard/boro/bin/HA_ctrl status

    Пример ответа:

    Boro HA state, node2:
      node state:                        primary
    last change:      2024-01-23T20:53:07+07:00
  last promotion:      2024-01-23T20:53:07+07:00
    remote node:                        visible

  PostgreSQL cluster info:
  ID | Name  | Role    | Status    | Upstream | Location | Priority | Timeline | Connection string
----+-------+---------+-----------+----------+----------+----------+----------+--------------------------------------------------------
  1  | node1 | standby |   running | node2    | default  | 100      | 48       | host=node1 user=repmgr dbname=repmgr connect_timeout=2
  2  | node2 | primary | * running |          | default  | 100      | 48       | host=node2 user=repmgr dbname=repmgr connect_timeout=2

  nginx usual mode

  • Отправив HTTP-запрос:

    NODE_IP_OR_HOSTNAME=<NODE_IP_OR_HOSTNAME>

curl $<NODE_IP_OR_HOSTNAME>/HA/health_check

    Замените <NODE_IP_OR_HOSTNAME> на фактическое значение IP-адреса или имя хоста, к которому отправляется запрос.

    Пример ответа:

    {
  "node": "node1",
  "state": "standby",
  "health": true,
  "last_promotion": 1706017165
}
{
  "node": "node2",
  "state": "primary",
  "health": true,
  "last_promotion": 1706017987
}

Переключение на резервный сервер

Внимание

При переключении между серверами возможна потеря статистики глубиной до 5 минут.

Примечание

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

Переключиться на резервный сервер можно одним из способов ниже:

  • Командой от имени root-пользователя на резервном сервере:

    /opt/elecard/boro/bin/HA_ctrl switchover

  • Запросом Control API к резервному узлу:

    NODE_IP_OR_HOSTNAME=<NODE_IP_OR_HOSTNAME>
USER_ID=<USER_ID>

curl \
  -H "Content-Type: application/json" \
  --data "{\"user_id\":$USER_ID,\"methods\":[{\"method\":\"HASwitchOver\"}]}" \
  http://$NODE_IP_OR_HOSTNAME/HA/ctrl_api/v1/json

    Замените <USER_ID> и <NODE_IP_OR_HOSTNAME> фактическими значениями. Метод HASwitchOver должен использоваться без параметров.

    Пример ответа:

    {"reply":[{"method":"HASwitchOver","result":"ok"}]} # переключение выполнено успешно

{"reply":[{"method":"HASwitchOver","error":"is primary already!"}]} # узел уже является первичным