Введение
Отказоустойчивая система ЕССМ выполняется по схеме резервирования Active-Active с использованием VIP-адреса — Virtual IP, — что позволяет использовать единый адрес для доступа к каждому узлу системы и хранить на них актуальные данные. Для настройки отказоустойчивой схемы требуется выделить не менее трех серверов. В схеме резервирования также предусмотрено разделение ЕССМ на сервер с БД и сервер с ЕССМ, использующим данную базу — для таких случаев требуется выделить 5 серверов.
Общая схема отказоустойчивой системы
Общая схема отказоустойчивой системы представляет из себя кластер, состоящий из трех узлов: master-, slave-, witness-ноды. Взаимодействие с WEB-интерфейсом происходит при помощи VIP, находящего на текущем мастере Keepalived. За состоянием баз данных PostgreSQL и Redis наблюдает узел witness и переключает мастерство Repmgr и Redis Sentinel при необходимости.
Схема отказоустойчивой системы при запуске БД на отдельном сервере
Отказоустойчивая система с запуском базы данных на отдельном сервере представляет из себя совокупность двух кластеров:
- Кластер приложений;
- Кластер баз данных.
Кластер баз данных включает в себя три сервера:
- Master база данных PostgreSQL — база данных для всех операций;
- Slave база данных PostgreSQL — база данных для операций чтения и репликации с Master;
- Witness-нода — сервер для отслеживания состояния PostgreSQL и Redis с переключением мастерства Repmgr и Redis Sentinel по необходимости.
Сервис Redis находится в кластере приложений, поэтому доступ до Witness также должен быть обеспечен.
Кластер приложений включается в себя запуск ЕССМ с использованием внешних баз данных. Для доступа к WEB-интерфейсу необходимо использовать VIP, который находится на текущем мастере Keepalived.
Подготовка серверов
Перед запуском ЕССМ в отказоустойчивой системе по любой из ранее представленных схем, необходимо подготовить конфигурационные и вспомогательные файлы.
Настройка файла .env.cluster
Перед запуском ЕССМ в отказоустойчивой системе, необходимо подготовить конфигурационный файл .env.cluster, находящийся в корневой директории проекта.
.env.cluster описано в статье Инструкция по установку и запуску.Подготовка конфигурационного файла для запуска ЕССМ по общей схеме отказоустойчивой системы
Необходимо открыть файл .env.cluster на Master-ноде при помощи любого текстового редактора и для минимальной настройки заполнить следующие переменные:
ALLOWED_HOSTS— переменная, указывающая разрешенные IP-адреса. Значение переменной должно соответствовать IP-адресам всех используемых нод;MASTER_HOST— переменная, указывающая IP-адрес Master-ноды;SLAVE_HOST— переменная, указывающая IP-адрес Slave-ноды;WITNESS_HOST— переменная, указывающая IP-адрес Witness-ноды;SENTINEL_MASTER_NAME— переменная, содержащая уникальное произвольное имя, присваиваемое кластеру баз данных для их мониторинга;SENTINEL_PASSWORD— переменная, содержащая пароль, используемый службой мониторинга для подключения к кластеру баз данных и получения информации о состоянии серверов.
Если не указывать данные переменные — база данных PostgreSQL на сервере не будет запущена и завершится с ошибкой.
Подготовка конфигурационного файла для запуска ЕССМ при запуске БД на отдельном сервере
Для каждого кластера необходимо настроить конфигурационный файл по-разному.
Для кластера приложений необходимо открыть файл .env.cluster на Master-ноде при помощи любого текстового редактора и для минимальной настройки заполнить следующие переменные:
ALLOWED_HOSTS— переменная, указывающая разрешенные IP-адреса. Значение переменной должно соответствовать IP-адресам всем серверам, участвующим в работе отказоустойчивой системы;MASTER_HOST— переменная, указывающая IP-адрес Master-ноды ECCM приложения;SLAVE_HOST— переменная, указывающая IP-адрес Slave-ноды ECCM приложения;WITNESS_HOST— переменная, указывающая IP-адрес Witness-ноды из кластера баз данных;SENTINEL_MASTER_NAME— переменная, содержащая уникальное произвольное имя, присваиваемое кластеру баз данных для их мониторинга;SENTINEL_PASSWORD— переменная, содержащая пароль, используемый службой мониторинга для подключения к кластеру баз данных и получения информации о состоянии серверов.
Содержимое файла должно находиться на узлах кластера приложений, в ином случае система не запуститься в режиме резервирования.
Для кластера баз данных необходимо открыть файл .env.cluster на Master-базе данных при помощи любого текстового редактора и для минимальной настройки заполнить следующие переменные:
ROLE— переменная, указывающая роль БД в кластере. Допустимые значения переменной: master, slave;ALLOWED_HOSTS— переменная, указывающая разрешенные IP-адреса. Значение переменной должно соответствовать IP-адресам всем серверам, участвующим в работе отказоустойчивой системы;MASTER_HOST— переменная, указывающая IP-адрес Master-базы данных;SLAVE_HOST— переменная, указывающая IP-адрес Slave-базы данных;WITNESS_HOST— переменная, указывающая IP-адрес Witness-ноды;SENTINEL_MASTER_NAME— переменная, содержащая уникальное произвольное имя, присваиваемое кластеру баз данных для их мониторинга;SENTINEL_PASSWORD— переменная, содержащая пароль, используемый службой мониторинга для подключения к кластеру баз данных и получения информации о состоянии серверов.
Содержимое файла должно находиться на узлах кластера баз данных, в ином случае система не запуститься в режиме резервирования.
Синхронизация файлов конфигурации
Для синхронизации файлов конфигурации между серверами, необходимо воспользоваться утилитой rsync. Пример установки утилиты:
apt install rsync
Для передачи файлов конфигурации кластера используйте следующую команду:
sudo rsync -av --delete --rsync-path="sudo rsync" <полный_путь_до_директории_eccm>/.env.cluster <имя_пользователя_сервера>@<IP-адрес_сервера_назначения>:<полный_путь_до_директории_eccm>
После выполнения команды для каждого сервера назначения, файл конфигурации будет соответствовать настроенному ранее.
Настройка SSL/TLS для связи узлов кластера
Репликация между базами данных PostgreSQL и Redis происходит по умолчанию в безопасном режиме. Для настройки безопасности репликации необходимо настроить сертификаты шифрования. Предусмотрено как генерация таких сертификатов, так и использование уже готовых.
Создание самоподписанного сертификата
В отсутствии корпоративного сертификата, предусмотрен скрипт root-ca-generator/generate-cluster-cert.sh. Перед запуском предварительно отредактируйте файл root-ca-generator/cluster.cnf: пропишите IP-адреса всех узлов кластера в формате "IP.<№> = <IP-адрес узла>".
После этого запустите скрипт root-ca-generator/generate-cluster-cert.sh, который сгенерирует все необходимые сертификаты и ключи в директорию cluster-cert/, а именно:
- ca.crt — корневой CA-сертификат;
- cluster.crt — сертификат кластера, подписанный CA;
- cluster.key — приватный ключ кластера.
При запуске ЕССМ будет также сгенерирован Java Truststore: Java-сервисы ECCM не читают ca.crt напрямую — они используют Java KeyStore в формате PKCS12. Сервис truststore-initer автоматически конвертирует ca.crt из cluster-cert/ в truststore.p12 и сохраняет его.
Использование корпоративного CA
Если предусмотрен корпоративный CA, необходимо переместить все файлы безопасносного соединения в директорию cluster-cert/ на Master-ноде, а именно:
- ca.crt — корневой CA-сертификат;
- cluster.crt — сертификат кластера, подписанный CA;
- cluster.key — приватный ключ кластера.
При наличии файла Java Truststore, также поместите его в директорию cluster-cert/.
.env.cluster. Подробнее о назначении переменных в конфигурационном файле .env.cluster описано в статье Инструкция по установку и запуску.Синхронизация сертификатов безопасности
Для синхронизации файлов из директории cluster-cert/ между узлами отказоустойчивой системы необходимо воспользоваться утилитой rsync. Пример установки утилиты:
apt install rsync
Для передачи сертификатов кластера используйте следующую команду:
sudo rsync -av --delete --rsync-path="sudo rsync" <полный_путь_до_директории_eccm>/cluster-cert/* <имя_пользователя_сервера>@<IP-адрес_сервера_назначения>:<полный_путь_до_директории_eccm>/cluster-cert
После выполнения команды для каждого сервера назначения, сертификаты на узлах будут соответствовать друг другу .
Настройка VIP
Для получения доступа к WEB-интерфейсу необходимо установить утилиту Keepalived на каждой ноде с сервисами ЕССМ. Пример установки утилиты:
apt install keepalived
В директории eccm/keepalived подготовлены конфигурационные файлы для утилиты:
keepalived.conf— конфигурационный файл Keppalived, настраивающий VRRP для отказоустойчивой системы;check_app.sh— скрипт, проверяющий состояние сервисов ЕССМ. При падении сервиса снижает приоритет сервера для последующей смены мастерства.
После установки скопируйте все конфигурационные файлы из директории eccm/keepalived/ в директорию /etc/keepalived/:
cp <путь_до_директории_eccm>/keepalived/* /etc/keepalived/
Убедитесь, что у скрипта check_app.sh есть права на выполнение. Если данного права нет, используйте следующую команду:
chmod +x /etc/keepalived/check_app.sh
При помощи любого текстового редактора откройте конфигурационный файл /etc/keepalived/keepalived.conf. На сервере, где будет находиться приложение ЕССМ с ролью мастер, измените следующие параметры:
INTERFACE_NAME— сетевой интерфейс, на котором будет находится ЕССМ. Выставляется индивидуально для каждого сервера;ROUTER_ID— идентификатор виртуального маршрутизатора, принимающий значения от 0 до 255. Одинаковый на всех серверах;PRIORITY— приоритет текущей ноды, принимающий значения от 0 до 255. Необходимо, чтобы данное значение было больше параметраweight,в ином случае мастерство переключаться не будет;PASSWORD— пароль VRRP-аутентификации. Одинаковый на всех серверах;VIP_IP_ADDRESS— Виртуальный IP-адрес, через который будет получаться доступ к WEB-интерфейсу. Одинаковый на всех серверах.
Далее перейдите на сервер, где будет находится приложение ЕССМ с ролью слейв, и измените ранее описанные параметры.
Если необходимо, чтобы при переключении мастерства и восстановлении исходного мастера мастерство возвращалось исходному — на Master-узле выставьте приоритет на 1 больше, чем на Slave-узле. Если такая опция не нужна — установите одинаковое значение на каждом узле.
Рекомендуемые значения:
- Если необходимо, чтобы мастерство возвращалось исходному мастеру:
- Master-узел должен иметь приоритет 101;
- Slave-узел должен иметь приоритет 100;
- Если нет необходимости в возвращении мастерства исходному мастеру:
- На всех узлах выставить приоритет 100.
После этого запустите Keepalived на каждом узле. Пример запуска и добавления в автозагрузку:
sudo systemctl start keepalived sudo systemctl enable keepalived
Убедитесь, что роли между узлами были распределены при помощи следующей команды:
sudo systemctl status keepalived
В журнале вы должны увидеть Entering BACKUP STATE и Entering MASTER STATE.
Запуск ЕССМ в отказоустойчивой системе по общей схеме
Для запуска ЕССМ в отказоустойчивой системе по общей схеме необходимо перейти на сервер будущего Master-узла. При помощи bash-скрипта произвести запуск мастера с необходимыми параметрами, пример запуска:
./compose-tools.sh -s <MASTER_HOST> --cluster master
После того, как мастер будет инициализирован и готов к работе, перейдите на сервер Slave-узла. При помощи bash-скрипта произвести запуск слейва с необходимыми параметрами, пример запуска с обязательными параметрами:
./compose-tools.sh -s <SLAVE_HOST> --cluster slave
Одновременно с запуском Slave-ноды, перейдите на сервер Witness-узла. При помощи bash-скрипта произвести запуск наблюдателя с необходимыми параметрами, пример запуска с обязательными параметрами:
./compose-tools.sh -s <WITNESS_HOST> --cluster witness
После инициализации перейдите по ранее установленному VIP адресу в формате http://<VIP>/ — будет доступен WEB-интерфейс ЕССМ.
Запуск ЕССМ в отказоустойчивой системе при запуске БД на отдельном сервере
Убедитесь, что значение переменной ROLE на Master-базе данных и Slave-базе данных различается и соответствует их роли.
Для запуска ЕССМ в отказоустойчивой системе при запуске БД на отдельном сервере необходимо перейти на сервер будущей Master-базы данных. Перейдите в директорию postgres/ и запустите базу данных:
cd postgres/ docker compose --env-file=.env --env-file=../.env.cluster -f docker-compose.cluster.yml up -d
После того, как база данных на Master-db будет проинициализирована, перейдите на сервер Slave-db. Перейдите в директорию postgres/ и запустите базу данных:
cd postgres/ docker compose --env-file=.env --env-file=../.env.cluster -f docker-compose.cluster.yml up -d
Во время инициализации Slave-db, запустите Witness-узел, перейдя на сервер Witness-node. При помощи bash-скрипта произвести запуск наблюдателя с необходимыми параметрами, пример запуска с обязательными параметрами:
./compose-tools.sh -s <WITNESS_HOST> --cluster witness
После полной инициализации всего кластера баз данных, перейдите на сервер Master-ECCM. При помощи bash-скрипта произвести запуск наблюдателя с необходимыми параметрами, пример запуска с обязательными параметрами:
./compose-tools.sh -s <MASTER_ECCM_HOST> --cluster master --database-host <MASTER_DB_HOST> --database-port <MASTER_DB_PORT> --backup-database-host <SLAVE_DB_HOST> --backup-database-port <SLAVE_DB_PORT>
После инициализации перейдите по ранее установленному VIP адресу в формате http://<VIP>/ — будет доступен WEB-интерфейс ЕССМ.