Высокая доступность
Резервирование сервера приложений
Описание
Для обеспечения высокой доступности вы можете запустить несколько экземпляров сервера приложений ТехноДок на разных серверах.
- Для каждого экземпляра сервера приложений необходимо указать его приоритет
Cluster:Priority
и адреса других серверов ТехноДокCluster:ServersAddresses
в файлеtechnodoc.settings.ini
. - В Системе может быть только один
ведущий
сервер и неограниченное количествоведомых
серверов приложений.
- Сервера приложений ТехноДок запускают процесс голосования и назначают серверу с наибольшим приоритетом роль
ведущий
, остальным серверам назначается рольведомый
.- Частота голосования определяется настройкой
Cluster:PollingRate
в файлеtechnodoc.settings.ini
. Значение по умолчанию -1 минута
. - Если в процессе голосования сервер меняет роль с
ведомого
наведущего
, то происходит повышение приоритета сервера на значение, равное количеству секунд, прошедших с 1 января 1970 года. - После того, как
ведомый
сервер сталведущим
, обратного переключения не произойдет до тех пор, пока новыйведущий
сервер корректно функционирует.
- Частота голосования определяется настройкой
- В случае выполнения аварийного переключения пользователь будет видеть информационное окно.
- Сервер приложений в роли
ведущий
использует настройкиtechnodoc.settings.json
из основной секции настроек. - Сервер приложений в
ведомый
использует настройкиtechnodoc.settings.json
из секцииStandby
.- Предполагается, что большая часть периодических задач (создание отчетов по расписанию, пересчет отчетов, отправка по почте и т.д.) будут работать только на основном сервере, на резервном сервере они будут простаивать.
- Чтобы указать, что определенная настройка должна примениться только для
ведомого
сервера, необходимо перед настройкой добавить префиксStandby
. Например, для отключения всех периодических задач, необходимо в файлеtechnodoc.settings.ini
в секции[Standby:JobScheduler]
раскомментировать строкуIsEnabled=false
.
- Клиентское приложений ТехноДок может отправлять запросы на чтение как
ведущему
серверу, так иведомому
.- В зависимости от настройки
Cluster:RequestHandleType
вtechnodoc.settings.json
будет выбрана одна из стратегий обработки запросов на сервере с рольюведомый
:Cluster:RequestHandleType=Forbid
- для запросов на изменение данных (POST, PUT, DELETE) будет возвращена ошибка405 Method Not Allowed
.Cluster:RequestHandleType=RedirectToPrimary
- запросы на изменение данных будут перенаправлены наведущий
сервер.- Режим
Cluster:RequestHandleType=RedirectToPrimary
гарантированно поддерживается в панели Каскад. В других браузерах могут быть установлены политики безопасности, которые в настоящий момент не позволяют корректно выполнять пе ренаправление запросов.
- В зависимости от настройки
Настройка
Для примера рассмотрим схему, состоящую из 2-х серверов reports.server1
(ведущий) и reports.server1
(ведомый).
Действия выполняемые на хосте reports.server1
:
- Открыть файл
technodoc.settings.ini
на хостеreports.server1
. - В секции
[Cluster]
указать настройкуPriority=1
, что сделает данный серверведущим
, так как это будет максимальный приоритет среди серверов в данной конфигурации. - В секции
[Cluster]
указать настройкуServersAddresses:0=http://reports.server2
. Данная нас тройка задает адрес второго сервера для его опроса. - В результате настройки в секции
[Cluster]
на хостеreports.server1
будут выглядеть следующим образом:
[Cluster]
Priority = 1
ServersAddresses:0 = http://reports.server2
При переходе сервера в режим ведомый
необходимо отключить периодические задачи чтобы избежать возможные конфликты, связанные с одновременной модификацией данных. Для этого необходимо выполнить следующие действия:
- Открыть файл
technodoc.settings.ini
на хостеreports.server1
. - Отключить задачи для
ведомого
сервера как показано ниже:
[Standby:Reports:Jobs:UploadReportValuesJob] # Задача загрузки значений отчетов
IsEnabled = False
[Standby:Reports:Jobs:ProcessReportsCreationRulesJob] # Задача создания отчетов
IsEnabled = False
[Standby:Reports:Jobs:ProcessReportsRulesJob] # Задача обработки правил отчетов
IsEnabled = False
[Standby:OperationTime:Jobs:CalculateOperationTimeJob] # Задача расчета наработки
IsEnabled = False
[Standby:Mail:Jobs:SendMailsJob] # Задача отправки почты
IsEnabled = False
[Standby:Mail:Jobs:DeleteMailsJob] # Задача удаления устаревших писем
IsEnabled = False
Действия выполняемые на хосте reports.server2
:
- Открыть файл
technodoc.settings.ini
на хостеreports.server2
. - В секции
[Cluster]
указать настройкуPriority=0
, что сделает данный серверведомым
, так как это будет мини мальный приоритет среди серверов в данной конфигурации. - В секции
[Cluster]
указать настройкуServersAddresses:0=http://reports.server1
. Данная настройка задает адрес второго сервера. - В результате, настройки в секции
[Cluster]
на хостеreports.server2
будут выглядеть следующим образом:
[Cluster]
Priority = 0
ServersAddresses:0 = http://reports.server1
- Для режима
ведомого
сервера отключить выполнение задач как показано ниже:
[Standby:Reports:Jobs:UploadReportValuesJob] # Задача загрузки значений отчетов
IsEnabled = False
[Standby:Reports:Jobs:ProcessReportsCreationRulesJob] # Задача создания отчетов
IsEnabled = False
[Standby:Reports:Jobs:ProcessReportsRulesJob] # Задача обработки правил отчетов
IsEnabled = False
[Standby:OperationTime:Jobs:CalculateOperationTimeJob] # Задача расчета наработки
IsEnabled = False
[Standby:Mail:Jobs:SendMailsJob] # Задача отправки почты
IsEnabled = False
[Standby:Mail:Jobs:DeleteMailsJob] # Задача удаления устаревших писем
IsEnabled = False
- После завершения настроек выше, надо перезагрузить оба сервера приложений ТехноДок.
Резервирование БД
ТехноДок может использовать одну из следующих СУБД для создания реплицированной БД:
- PostgreSQL.
- MariaDB.
- Microsoft SQL Server.
PostgreSQL
PostgreSQL имеет несколько вариантов организации высокой доступности. Подробнее с вариантами и информацией по настройке можно ознакомиться: High Availability, Load Balancing, and Replication.
MariaDB
MariaDB поддерживает режим репликации Master-Master что позволяет вести запись данных как в основной, так и в резервный сервер БД. Ниже приведены шаги настройки репликации Master-Master.
На первом сервере:
- В секцию [mysqld] конфигурационного файла БД MariaDB добавить следующие настройки:
sql-mode = "ANSI_QUOTES"
datadir = путь к данным
server-id = 1
log-bin = bin-log
bind-address = 0.0.0.0
auto_increment_increment = 2
auto_increment_offset = 1
- Перезапустить службу БД MariaDB, выполнив в терминале команду:
Для linux:
systemctl restart mariadb
Для windows:net start mariadb
- Установить соединение с БД MariaDB, выполнив в терминале команду:
mysql -u root –p
, где root – пользователь, а после ключа -p пароль (если был указан) - Создать пользователя, который будет ответственен за репликацию БД MariaDB, выполнив в терминале команды:
create user 'replication_user'@'%' identified by 'replication_user';
grant replication slave on *.* to 'replication_user'@'%';
- Проверить состояние бинарного лога, выполнив в терминале команду:
show master status;
Значение полейPosition
иFile
будут использоваться для конфигурации репликации на втором сервере.
| File | Position
| mariadb-bin.000001 | 314
На втором сервере:
- В секцию [mysqld] конфигурационного файла БД MariaDB добавить следующие настройки:
sql-mode = "ANSI_QUOTES"
datadir = путь к данным
server-id = 2
log-bin = bin-log
bind-address = 0.0.0.0
auto_increment_increment = 2
auto_increment_offset = 2
- Выполнить пункты 2-4 аналогично первому серверу.
- Остановить репликацию, выполнив в терминале команду:
stop slave;
- Настраиваем репликацию, указав второму серверу, где нужно искать файл журнала:
CHANGE MASTER TO MASTER_HOST='master1', MASTER_USER='replication_user', MASTER_PASSWORD='replication_user_password', MASTER_LOG_FILE='mariadb-bin.000001', MASTER_LOG_POS=314;
гдеMASTER_HOST
– ip первого мастера,MASTER_USER/ MASTER_PASSWORD
– логин/пароль пользователя с правами репликации, которого создали ранее,MASTER_LOG_FILE
иMASTER_LOG_POS
- название журнала и номер позиции из пункта 5 подраздела На первом сервере соответственно. - Запустить репликацию, выполнив в терминале команду:
start slave;
- Проверить статус сервера на наличие ошибок, выполнив команду:
show slave status \G
Наличие числовых значений вRead_Master_Log_Pos
иRelay_Log_Pos
указывает, что ошибок нет. - Проверить состояние бинарного лога, выполнив в терминале команду:
show master status;
Значение полей Position и File будут использоваться для конфигурации репликации на первом сервере.
| File | Position
| mariadb-bin.000002 | 8196
На первом сервере:
- Остановить репликацию, выполнив в терминале команду:
stop slave;
- Настраиваем репликацию, указав первому серверу, где нужно искать файл журнала:
CHANGE MASTER TO MASTER_HOST='server2', MASTER_USER='replication_user', MASTER_PASSWORD='replication_user_password', MASTER_LOG_FILE='mariadb-bin.000002', MASTER_LOG_POS=8196;
где MASTER_HOST – ip второго мастера,MASTER_USER
/MASTER_PASSWORD
– логин/пароль пользователя с правами репликации, которого создали ранее,MASTER_LOG_FILE
иMASTER_LOG_POS
- название журнала и номер позиции из пункта 7 подраздела На втором сервере соответственно. - Запустить репликацию, выполнив в терминале команду:
start slave;
- Проверить статус сервера, выполнив в терминале команду:
show slave status \G
Наличие числовых значений вRead_Master_Log_Pos
иRelay_Log_Pos
указывают, что ошибок нет. Если нет ошибок, то репликация настроена. В секции [Database] конфигурационного файлаtechnodoc.settings.ini
ТехеноДок указать корректную строку подключения к БД MariaDB и установить значениеRoundRobin
для ключаFailoverStrategy
. При возникновении проблем с восстановлением репликации при переключении или аварийной остановки, необходимо запустить репликацию повторно, выполнив в терминале команду: start slave;
# Пример строки подключения
Type = MariaDb # Тип БД - MariaDb
ConnectionString = Server=localhost;Database=technodoc;Uid=root;Password=password # Строка соединения с БД
Microsoft SQL Server
Microsoft SQL Server имеет несколько вариантов организации высокой доступности. Подробнее с вариантами и информацией по настройке можно ознакомиться: Business continuity and database recovery - SQL Server.
Резервированный проект КАСКАД
В данном разделе описана конфигурация, состоящая из 2 резервированных серверов ТехноДок и КАСКАД. Для примера будем использовать следующие адреса:
reports.server1
иreports.server2
– основной и резервный сервер ТехноДок. База данных ТехноДок на ходится на тех же серверах. В качестве резервируемой БД может выступать MariaDB, PostgreSQL или Microsoft SQL Server.kaskad.server1
иkaskad.server2
- основной и резервный сервер КАСКАД.
Для обмена данными между ТехноДок и КАСКАД используется протокол XMLRPC. Для отображения графического интерфейса ТехноДок используется панель с компонентом WebView. Для настройки взаимодействия ТехноДок и КАСКАД необходимо выполнить следующие действия:
- Настроить кластер БД ТехноДок.
- Настроить кластер ТехноДок.
- Добавить и настроить скрипты взаимодействия КАСКАД с ТехноДок в проекте КАСКАД в настроенный резервируемый проект.
- Добавить в ТехноДок внешнее соединение с настройками подключения для каждой из пар проекта КАСКАД.
- Добавить и настроить в проекте КАСКАД панель отображения ТехноДок с автоматическим выбором основного сервера.