Управление процессом отказоустойчивости

Переключение трафика между серверами

Примечание

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

Внимание

Обратите внимание, что переключение домена со старого IP на VIP требует времени. В этом случае не рекомендуется переключать или отключать keepalived на текущем мастер-сервере.

Рассмотрим конфигурацию, где:

  • Основной сервер является активным и обрабатывает трафик;

  • Резервный сервер является неактивным и находится в режиме горячего резерва.

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

Процедура ручного переключения трафика состоит из следующих этапов:

  1. Проверка состояния репликации на неактивном сервере;

  2. Перезапуск keepalived на активном сервере;

  3. Проверка перехода VIP и активного сервера;

  4. Проверка логов и репликации на двух серверах.

Ниже приведено подробное описание каждого этапа.

  1. Проверка состояния репликации на неактивном сервере.

    Перед переключением убедитесь, что репликация данных завершена. На неактивном сервере проверьте статус репликации (см. Проверка статуса репликации).

  2. Перезапуск keepalived на активном сервере.

    Чтобы инициировать переключение, необходимо на текущем активном сервере (в рассматриваемой конфигурации — основной сервер) перезапустить службу keepalived.

    Выполните команду на активном сервере:

    sudo systemctl restart keepalived

  3. Проверка перехода VIP и активного сервера.

    Убедитесь, что VIP успешно переключился. Для этого выполните команду на обоих серверах и сравните вывод:

    ip a | grep <VIP IP>

    VIP-адрес должен отображаться только на сервере, который стал активным (резервном сервере).

    Также можно явно проверить, какой сервер сейчас является активным, с помощью скрипта:

    sudo python3 script/replication/check_current_master_server.py

    Интерпретация результатов:

    На активном сервере (резервный сервер) вы увидите сообщение:

    Данный сервер является активным мастер сервером

    На сервере, который стал неактивным (основной сервер), вы увидите сообщение:

    Данный сервер НЕ является активным мастер сервером

  4. Проверка логов и репликации на двух серверах.

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

    sudo tail -n 100 /var/log/keepalived-state.log

    В случае некорректного переключения рекомендуется проверить логи rsync:

    sudo tail -n 100 /var/log/rsync-replication/rsync_files.log

    После переключения убедитесь, что репликация продолжает работать корректно. На неактивном сервере проверьте статус репликации (см. Проверка статуса репликации).

После выполнения всех шагов роли серверов меняются следующим образом:

  • резервный сервер становится активным и начинает обрабатывать трафик;

  • основной сервер переходит в состояние неактивного.

Изменение конфигурационных файлов

Изменения в конфигурационные файлы Compass необходимо вносить только на активном сервере. После сохранения они автоматически синхронизируются с неактивным сервером, где необходимо лишь проверить их наличие. Чтобы применить изменения, нужно запустить обновление на обоих серверах: сначала на активном, затем на неактивном.

Процедура внесения изменений состоит из следующих этапов:

  1. Определите активный сервер;

  2. Внесите и примените изменения на активном сервере;

  3. Проверьте и примените изменения на неактивном сервере.

Ниже приведено подробное описание каждого этапа.

  1. Определите активный сервер.

    Изменения конфигурации всегда выполняйте на активном сервере. Чтобы определить, на каком сервере вы находитесь, выполните команду:

    sudo python3 script/replication/check_current_master_server.py

    • Если вы видите сообщение Данный сервер является активным мастер сервером — вы на активном сервере, можно продолжать.

    • Если сообщение Данный сервер НЕ является активным мастер сервером — перейдите на активный сервер.

  2. Внесите и примените изменения на активном сервере.

    Отредактируйте необходимые конфигурационные файлы. Сохраните изменения и запустите скрипт обновления:

    sudo python3 script/update.py

  3. Проверьте и примените изменения на неактивном сервере.

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

    sudo python3 script/update.py

Процесс обновления серверной части приложения

При обновлении серверной части Compass необходимо выполнить обновление на обоих серверах: сначала на активном, затем на неактивном.

Процедура обновления состоит из следующих этапов:

  1. Определите активный сервер;

  2. Обновите установщик и запустите обновление на активном сервере;

  3. Проверьте состояние неактивного сервера;

  4. Обновите установщик и запустите обновление на неактивном сервере;

  5. Проверьте состояние репликации на неактивном сервере;

  6. При возникновении ошибок репликации выполните сброс и повторный запуск.

Ниже приведено подробное описание каждого этапа.

  1. Определите активный сервер.

    Обновление всегда начинайте с активного сервера. Чтобы определить, на каком сервере вы находитесь, выполните команду:

    sudo python3 script/replication/check_current_master_server.py

    • Если вы видите сообщение Данный сервер является активным мастер сервером — вы на активном сервере, можно продолжать.

    • Если вы видите сообщение Данный сервер НЕ является активным мастер сервером — перейдите на активный сервер.

  2. Обновите установщик и запустите обновление на активном сервере.

    Перейдите в директорию ранее загруженного установщика Compass и выполните:

    git pull

    Затем запустите скрипт обновления:

    sudo python3 script/update.py

  3. Проверьте состояние неактивного сервера.

    Перед обновлением неактивного сервера убедитесь, что он находится в корректном состоянии:

    • Проверьте статус репликации (см. Проверка статуса репликации).

    • Проверьте, что служба keepalived работает корректно:

      sudo systemctl status keepalived

      Статус должен быть active (running). Если служба остановлена или есть ошибки, устраните их перед продолжением.

  4. Обновите установщик и запустите обновление на неактивном сервере.

    В директории установщика Compass выполните:

    git pull

    Затем выполните:

    sudo python3 script/update.py

  5. Проверьте состояние репликации на неактивном сервере.

    На неактивном сервере снова проверьте статус репликации (см. Проверка статуса репликации).

  6. При возникновении ошибок репликации выполните сброс и повторный запуск.

    Если после обновления появились ошибки репликации, выполните на неактивном сервере:

    sudo python3 script/replication/reset_slave_replication.py --all-types --all-teams
sudo python3 script/replication/start_slave_replication.py --all-types --all-teams

Предупреждение

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

Создание нового пространства

Процедура создания нового пространства состоит из следующих этапов:

  1. Проверьте состояние репликации на неактивном сервере;

  2. Настройте права на директорию на неактивном сервере;

  3. Запустите создание пространства с активного сервера;

  4. Восстановите базу данных из резервной копии на неактивном сервере;

  5. Восстановите команду на неактивном сервере;

  6. Запустите репликацию для нового пространства на неактивном сервере;

  7. Проверьте результат.

Ниже приведено подробное описание каждого этапа.

  1. Проверьте состояние репликации на неактивном сервере.

    Убедитесь, что на неактивном сервере репликация работает корректно (см. Проверка статуса репликации).

  2. Настройте права на директорию на неактивном сервере.

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

    sudo chown root:rider <root_mount_path>/backups/
sudo chmod 2775 <root_mount_path>/backups/

    Примечание

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

  3. Запустите создание пространства с активного сервера.

    На активном сервере выполните команду, указав IP-адрес и директорию хранения данных неактивного сервера:

    sudo python3 script/create_team.py -dst rider@<reserve_server_ip>:<root_mount_path>/backups/

  4. Восстановите базу данных из резервной копии на неактивном сервере.

    На неактивном сервере запустите скрипт восстановления базы данных:

    sudo python3 script/restore_db.py --force-update-company-db 0

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

  5. Восстановите команду на неактивном сервере.

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

    sudo python3 script/replication/repair_team.py

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

  6. Запустите репликацию для нового пространства на неактивном сервере.

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

    sudo python3 script/replication/start_slave_replication.py -t team

    Выберите новое пространство из списка и дождитесь завершения работы скрипта.

  7. Проверьте результат.

    Убедитесь, что новое пространство создано корректно и реплицируется:

    • На неактивном сервере проверьте статус репликации (см. Проверка статуса репликации).

    • В приложении Compass проверьте, что новое пространство отображается и доступно для работы.

Диагностика ошибок репликации

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

Проверьте значение лейблов на обоих серверах:

grep service_label src/values.compass.yaml

Ответ команды для настроенных на отказоустойчивость серверов должен выдать:

service_label: primary        # лейбл для сервера primary
master_service_label: primary # лейбл сервера, который выступает активным для других

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

service_label: reserve        # лейбл для сервера reserve
master_service_label: primary # лейбл сервера, который выступает активным для других

Запустите следующую команду для проверки статуса репликации:

sudo python3 script/replication/show_slave_replication_status.py --all-types --all-teams

Скрипт выведет данные по статусу репликации, которые подскажут в чём может быть ошибка.

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

sudo python3 script/replication/reset_slave_replication.py --all-types --all-teams

После сброса требуется повторно запустить старт репликации:

sudo python3 script/replication/start_slave_replication.py --all-types --all-teams

Восстановление после сбоя основного сервера

Рассмотрим ситуацию, когда основной сервер вышел из строя. В этом случае:

  • трафик автоматически переключился на резервный сервер, который стал активным;

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

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

Примечание

После восстановления основного сервера:

  • трафик автоматически НЕ переключается обратно — активным остается резервный сервер;

  • репликация баз данных на основном сервере автоматически НЕ включается.

Процедура восстановления репликации на основном сервере:

  1. Сбросьте настройки репликации.

    На основном сервере (сейчас он неактивный) выполните сброс текущих настроек репликации:

    sudo python3 script/replication/reset_slave_replication.py --all-types --all-teams

  2. Запустите репликацию заново.

    На основном сервере запустите репликацию:

    sudo python3 script/replication/start_slave_replication.py --all-types --all-teams

  3. Дождитесь завершения синхронизации.

    Процесс репликации может занять некоторое время в зависимости от объема данных, накопившихся за время простоя. Отслеживать состояние можно командой из Проверка статуса репликации.

После выполнения этих шагов основной сервер снова содержит актуальные данные и готов выполнять роль «горячего резерва» для активного (резервного) сервера.

Примечание

Как вернуть трафик на основной сервер

Если вы хотите, чтобы основной сервер снова стал активным (обрабатывал трафик), после завершения синхронизации выполните процедуру ручного переключения трафика.

Доступные проверки отказоустойчивости

Для мониторинга состояния отказоустойчивой конфигурации доступны следующие проверки:

  1. Проверка активного сервера

    Чтобы узнать, какой сервер в данный момент является активным (обрабатывает трафик), выполните команду:

    ip addr show | grep <внутренний IP VIP>

    • Если команда вывела строку с IP-адресом — сервер, на котором она выполнена, является активным.

    • Если команда не выдала результат — сервер неактивный.

  2. Проверка статуса репликации баз данных

    Чтобы проверить состояние репликации баз данных, выполните скрипт на неактивном сервере:

    sudo python3 script/replication/show_slave_replication_status.py --all-types --all-teams

    В выводе будет информация о статусе репликации в базах Pivot и команд. Основные показатели:

    • Seconds_Behind_Master — отставание реплики от мастера в секундах. Значение 0 означает полную синхронизацию;

    • Slave_IO_Running: Yes — поток получения изменений от мастера работает;

    • Slave_SQL_Running: Yes — поток применения изменений работает;

    • Last_IO_Error: None и Last_SQL_Error: None — нет ошибок.

  3. Проверка логов синхронизации файлов (rsync)

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

    tail -n 100 /var/log/rsync-replication/rsync_files.log

    Примечание

    На сервере, который в данный момент является неактивным, rsync должен быть выключен. Это нормальное состояние.

  4. Проверка лейблов серверов

    Чтобы убедиться в корректности ролей серверов, выполните команду на каждом из них:

    grep service_label src/values.compass.yaml

    Для правильно настроенной отказоустойчивой конфигурации:

    • На основном сервере:

      service_label: primary        # лейбл для сервера primary
master_service_label: primary # лейбл сервера, который выступает активным для других

    • На резервном сервере:

      service_label: reserve        # лейбл для сервера reserve
master_service_label: primary # лейбл сервера, который выступает активным для других

    Если в ответе master_service_label на серверах выдает разный результат или пустую строку — значит конфигурация нарушена.

  5. Что делать при обнаружении проблем

    Если проверки выявили ошибки или несоответствия:

Примечание

Статьи по настройке отказоустойчивости:

Напишите нам в пространстве поддержки On-premise, Telegram или на почту support@getcompass.ru, чтобы получить индивидуальную демонстрацию функционала и помощь по вопросам интеграции мессенджера в вашей компании.