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

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

Примечание

Перед выполнением действий из статьи должен быть настроен 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/replication/reset_slave_replication.py --all-types --all-teams

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

sudo python3 script/update.py

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

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

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

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

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

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

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

sudo systemctl status keepalived

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

  • Если служба остановлена или есть ошибки, их нужно устранить перед следующим шагом, иначе VIP-адрес не перейдёт на резервный сервер.

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

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

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

sudo systemctl restart keepalived

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

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

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

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

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

Далее перед обновлением серверной части на основном сервере необходимо сбросить репликацию, выполнив следующую команду:

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

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

sudo python3 script/update.py

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

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

На основном сервере проверьте статус репликации на отсутствие ошибок:

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

После завершения репликации выполните перезапуск keepalived на резервном сервере, чтобы основной сервер снова стал активным:

sudo systemctl restart keepalived

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

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/create_team.py

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

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

    while true; do sudo docker ps | grep mysql-<порт нового пространства> \
  && break; sleep 2; done

    Дождитесь, когда команда отобразит результат - контейнер mysql с указанным портом.

  4. Запустите на неактивном сервере скрипт для создания mysql-пользователя для репликации:

    sudo python3 script/replication/create_mysql_user.py --type team

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

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

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

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

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

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

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

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, чтобы получить индивидуальную демонстрацию функционала и помощь по вопросам интеграции мессенджера в вашей компании.