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

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

Примечание

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

Внимание

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

Для переключения трафика с основного сервера на резервный достаточно, чтобы VIP на некоторое время перестал получать сигналы от keepalived.

  1. Как переключить трафик на резервный сервер.

    Примечание

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

    Команда для перезапуска keepalived, которая также переключает трафик с основного сервера на резервный (её необходимо выполнять на активном основном сервере):

    Внимание

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

    sudo systemctl restart keepalived

    На резервном сервере проверьте логи на наличие ошибок:

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

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

    Одновременно с переключением на основном сервере отключается lsyncd — файлы с этого сервера перестают отправляться на резервный.

    На резервном сервере в этот момент lsyncd запустится автоматически. Уже новые файлы с резервного сервера отправляются на основной.

  2. После переключения рекомендуется проверить состояние серверов, чтобы убедиться что переключение сработало корректно:

    Проверьте, что VIP IP переключился на резервный сервер:

    ip a | grep <VIP IP>

    Проверьте, является ли основной и резервный сервера текущим активным сервером:

    sudo python3 script/replication/check_current_master_server.py

    Примечание

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

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

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

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

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

    На основном сервере перейдите в директорию инсталлятора:

    cd <путь к инсталлятору Compass>

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

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

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

    Запуск скриптов старта репликации необходимо выполнять на тех серверах, которые НЕ являются активным.

    В случае ошибки репликации рекомендуется использовать скрипты из раздела «Диагностика ошибок репликации».

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

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

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

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

sudo python3 script/update.py

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

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

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

git pull

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

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

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

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

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

Проверить, является ли сервер основным, можно выполнив следующую команду:

sudo python3 script/replication/check_current_master_server.py

Если скрипт показал, что сервер является master, значит это основной сервер.

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

sudo python3 script/update.py

После чего на резервном сервере проверьте статус репликации на отсутствие ошибок:

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

Если ошибок нет и в поле Seconds_Behind_Master отображается 0 секунд - репликация работает корректно. Если значение больше нуля - подождите указанное количество секунд и проверьте ещё раз

На резервном сервере убедитесь, что служба keepalived работает корректно:

sudo systemctl status keepalived

  • Если статус active (running) — всё в порядке, можно продолжать.

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

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

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

На резервном сервере выполните обновление серверной части:

sudo python3 script/update.py

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

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/show_slave_replication_status.py --all-types --all-teams

  2. На неактивном сервере создайте директорию для временного хранения данных:

    sudo mkdir -p /home/<remote_server_user>/backups/

  3. На активном сервере выполните команду, указав в параметре -dst IP-адрес резервного сервера и путь для временного сохранения данных в домашней директории пользователя на неактивном сервере:

    sudo python3 script/create_team.py -dst <remote_server_user>@<reserve_server_ip>:/home/<remote_server_user>/backups/

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

  4. На неактивном сервере переместите созданные файлы из пользовательской директории в целевой каталог:

    sudo mv /home/<remote_server_user>/backups/* <root_mount_path>/backups/

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

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

    В списке бекапов выберите бекап новой созданной компании, которая имеет название reserve_company_<id>. Дождитесь завершения работы скрипта.

  6. Запустите на неактивном сервере скрипт восстановления команды:

    sudo python3 script/replication/repair_team.py

    Введите id команды, которую нужно восстановить. Дождитесь завершения работы скрипта.

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

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

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

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

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

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

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

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

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

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

  • резервный сервер, выступающий «горячим резервом».

Допустим, основной сервер по техническим неполадкам остановился. В этом случае весь трафик переключается на резервный сервер, который становится активным в этой ситуации.
На резервном сервере включается lsyncd для отправки новых файлов на основной сервер, когда тот станет исправным. Репликация на резервном сервере остановилась, на основном — сейчас недоступна.

Теперь, основной сервер снова стал доступным.

Важные моменты:

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

  • приложение lsyncd на основном сервере автоматически НЕ включается;

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

Примечание

lsyncd на основном сервере так и должен оставаться выключенным. Он включится автоматически при переключении активного сервера на основной.

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

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

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

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

Дождитесь завершения репликации.

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

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

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

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

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

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

Эти скрипты покажут информацию о статусе репликации в базах Pivot и команд.

Для просмотра статуса lsyncd используйте команду:

sudo systemctl status lsyncd

Примечание

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

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

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» для серверов выдаёт разный результат или пустую строку — значит что-то пошло не так.
В этом случае рекомендуется написать нам в пространстве поддержки On-premise, Telegram или на почту support@getcompass.ru, чтобы получить индивидуальную поддержку.

Примечание

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

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