Отказоустойчивость:
Подготовка серверов¶
Эта статья описывает необходимые действия и подготовку перед настройкой отказоустойчивости для серверной части мессенджера Compass.
Примечание
Начиная с версии 6.9.0 основной и резервный серверы не объединяются в общий кластер Docker Swarm: каждый сервер работает в собственном кластере, а данные между серверами передаются по внутренним IP-адресам. Если отказоустойчивость была настроена на версии ниже 6.9.0, обновите её в соответствии с инструкцией по обновлению.
Предупреждение
Механизм отказоустойчивости в данный момент доступен для DEB-based систем (Debian/Ubuntu).
Если вы используете RPM-based системы (RHEL, CentOS, Fedora и другие), рекомендуем получить консультацию у специалистов Compass. Пожалуйста, напишите нам в пространстве поддержки On-premise, Telegram или на почту support@getcompass.ru
Предварительные требования¶
Перед настройкой отказоустойчивости убедитесь, что:
У вас есть два сервера:
основной— подготовленный в соответствии с инструкцией по подготовке сервера и
с развернутым Compass on-premise в соответствии с инструкцией по установке;резервный— подготовленный в соответствии с инструкцией по подготовке сервера.
Оба сервера находятся в одной сети и им доступно минимум 3 адреса:
один внутренний IP-адрес для основного сервера;
один внутренний IP-адрес для резервного сервера;
один внешний и внутренний IP-адрес, используемый как виртуальный IP (VIP).
Пример схемы размещения серверов и использования VIP:
основной сервер: внутренний IP —
192.168.1.4;резервный сервер: внутренний IP —
192.168.1.5;виртуальный IP (VIP) —
192.168.1.6, на который настроен DST-NAT с внешнего адреса188.124.51.150.
Примечание
Виртуальный IP (VIP) — это дополнительный IP-адрес, который используется для балансировки и автоматического переключения трафика между основным и резервным серверами. VIP должен быть выделен в вашей внутренней сети. В процессе настройки Отказоустойчивости VIP будет привязан к вашему домену, используемому для доступа к Compass.
Предупреждение
Если у вас ранее уже был установлен сервер, подключать домен к внешнему IP VIP на этом шаге не требуется.
Для сценария отказоустойчивости Compass использует встроенные базы данных в Docker. Подключение к внешним базам данных в этом режиме не поддерживается.
Настройка Docker¶
Если ваша версия Compass on-premise ниже 6.9.0, то обновите окружение в соответствии с инструкцией по обновлению.
На основном и резервном серверах проверьте, что версия Docker совпадает:
На обоих серверах убедитесь, что Docker работает в Swarm-режиме:
Команда должна вернуть
active.Если команда вернула inactive
Переведите Docker в Swarm-режим, указав внутренний IP-адрес сервера:
Команда выведет подсказку о подключении других нод к кластеру - выполнять её не нужно.
Примечание
При настройке отказоустойчивости для второго сервера будут открыты порты:
3306и порты баз данных пространств (по умолчанию35150–35164) - для репликации MySQL;9312,9360,9361- для репликации Manticore.
Доступ к этим портам установщик настраивает автоматически и разрешает только со второго сервера, добавлять их в список разрешённых фаервола не требуется.
Настройка репликации баз данных¶
На основном сервере откройте конфигурационный файл
configs/replication.yamlдля редактирования любым текстовым редактором и заполните поля:Предупреждение
Рекомендуем оставлять значение
master_state_changed_disable: true, если при отказе основного сервера выполняется переключение на резервный, и обратный перевод VIP с резервного сервера на основной должен выполняться только вручную.Обратите внимание: эта блокировка действует только для основного (primary) сервера.
Дальнейшие действия зависят от того, первая ли это установка приложения Compass на серверах или выполняете обновление имеющегося приложения.
Если это первая установка основного сервера с нуля (ранее сервер не поднимался для установки приложения)
На основном сервере выполните установку приложения:
Дождитесь завершения установки приложения на основном сервере.
Если ранее приложение уже было установлено
Выполните обновление основного сервера, чтобы применить изменения конфигурационного файла
configs/replication.yaml:Примечание
При запуске скрипта появится предупреждение, что приложение будет недоступно для пользователей некоторое время. Необходимо подтвердить дальнейшее выполнение.
Дождитесь завершения обновления основного сервера.
На основном сервере создайте mysql-пользователя для репликации баз данных:
Если у вас больше одной компании - выберете пункт «Все».
На основном сервере запустите скрипт для старта репликации данных Manticore:
Примечание
В параметре master-mysql-server-id укажите значение поля mysql_server_id из конфигурационного файла
configs/replication.yamlосновного сервераСкопируйте данные баз данных основного сервера на резервный.
Для переноса данных на другой сервер требуется прокинуть ключ без passphrase с основного сервера на резервный.
На основном сервере сгенерируйте ключ доступа, оставив passphrase пустым:
Затем на основном сервере выполните команду, чтобы скопировать созданный ключ на другой сервер, где:
remote_server_user — логин для подключения к резервному серверу;
remote_server_ip — IP-адрес резервного сервера.
Для сохранения и отправки данных приложения на основном сервере необходимо выполнить скрипт
script/backup_all_data.pyиз директории установщика.В скрипт передается параметр -dst, в котором:
remote_server_user — логин для подключения к резервному серверу;
remote_server_ip — IP-адрес резервного сервера;
remote_backup_folder — абсолютный путь до папки на резервном сервере, в которую необходимо сохранить копию данных (например,
/home/compass_backup).
Предупреждение
Убедитесь, что директория
remote_backup_folderимеет права для сохранения файлов от лицаremote_server_user.После выполнения скрипта резервная копия данных будет сохранена по пути remote_backup_folder на резервном сервере.
На резервном сервере добавьте пользователя
www-data, если тот отсутствует:На резервном сервере скопируйте данные приложения в новую директорию:
И поменяйте права для директорий:
Скопируйте инсталлятор по новому пути (например,
/home/on-premise/onpremise-installer) и перейдите в новую директорию с ним:Подготовьте скопированные конфигурационные файлы для дальнейшей работы:
На резервном сервере в
configs/global.yamlзамените внутренний IP основного сервера на внутренний IP резервного:Удалите файл с лейблом, скопированный с основного сервера:
На резервном сервере откройте конфигурационный файл
configs/replication.yamlдля редактирования любым текстовым редактором и заполните поля:Примечание
Установите лейблы: «primary» (на основном сервере) и «reserve» (на резервном).
Замените значения в файле
src/values.compass.yaml:Примечание
В команду ниже подставьте те значение, которые указали в конфигурационном файле
Перенесите ключ-секрет шифрования базы данных на резервный сервер.
Примечание
Если на основном сервере не включено шифрование сообщений, этот пункт нужно пропустить.
Перенос ключа-секрета шифрования базы данных
Ключ-секрет хранится в кластере Docker Swarm основного сервера и на резервный автоматически не переносится.
Проверьте, включено ли шифрование. На резервном сервере выполните в директории инсталлятора:
Если команда вернула
mode: "none", шифрование выключено — пропустите этот пункт.На основном сервере сохраните ключ-секрет в файл:
Отправьте файл на резервный сервер и удалите его на основном. Подставьте те же значения
remote_server_user,remote_server_ipиremote_backup_folder, что и при создании резервной копии:На резервном сервере создайте ключ-секрет из файла и удалите файл:
Проверьте, что ключ-секрет создан — в списке должен быть
compass_database_encryption_secret_key:На резервном сервере добавьте сертификат в список доверенных, затем обновите системное хранилище доверенных сертификатов:
На резервном сервере запустите скрипт для восстановления данных.
При запуске скрипта вам будет предложено:
Выбрать нужный бэкап из списка доступных копий.
Подтвердить удаление текущих данных и завершение работы приложения. Если на резервном сервере не было установлено приложение Compass, то ничего удалено не будет.
Дождитесь завершение выполнение скрипта. После этого проверьте состояние развертывания с помощью команды:
Запустите скрипт для обновления портов в сервисе
go_databaseна резервном сервере:На резервном сервере инвалидируйте порты, на которых были созданы компании:
При запуске скрипта вам будет предложено:
Выбрать идентификатор сервера с базой данных. Если используется односерверная установка, выберите d1.
Выбрать порты, которые необходимо инвалидировать (выберите все по очереди).
Примечание
Если скрипт показывает, что порты с нужным статусом отсутствуют — пропустите этот пункт.
Восстановите компании на резервном сервере:
Запустите на резервном сервере скрипты для создания mysql-пользователя для репликации баз данных:
Предупреждение
Скрипты репликации баз данных НЕ работают с пользовательскими базами данных.
Если у вас больше одной компании - выберете пункт «Все».
Перед началом запуска репликации на резервном сервере выполните сброс репликации:
Далее на резервном сервере запустите скрипт для старта репликации:
Дождитесь завершения репликации.
Если в выводе скрипта получаете «No» для одной из позиций (IO, SQL, или другое),
значит репликация не может завершиться успешно. В этом случае рекомендуется использовать скрипты из раздела управление процессом отказоустойчивости.Затем на резервном сервере запустите скрипт для старта репликации данных
Manticore:Примечание
В параметре master-mysql-server-id укажите значение поля mysql_server_id из конфигурационного файла
configs/replication.yamlосновного сервера.Для проверки состояния репликации на резервном сервере запустите команду:
Внимание
Перед выполнением переключения необходимо убедиться, что репликация завершила синхронизацию данных.
Критерием готовности является значение поляSeconds_Behind_Masterравное нулю, что указывает на отсутствие отставания реплики от мастера.На резервном сервере добавьте удалённый репозиторий к новому инсталлятору: