Перейти к основному содержимому

Высокая доступность

Резервирование сервера приложений​

Описание​

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

  • Для каждого экземпляра сервера приложений необходимо указать его приоритет Cluster:Priority и адреса других серверов ТехноДок Cluster:ServersAddresses в файле application.conf.
  • В Системе может быть только один ведущий сервер и неограниченное количество ведомых серверов приложений.

Кластер серверов приложений

Кластер серверов приложений

  • Сервера приложений ТехноДок запускают процесс голосования и назначают серверу с наибольшим приоритетом роль ведущий, остальным серверам назначается роль ведомый.
    • Частота голосования определяется настройкой Cluster:PollingRate в файле application.conf. Значение по умолчанию - 1 минута.
    • Если в процессе голосования сервер меняет роль с ведомого на ведущего, то происходит повышение приоритета сервера на значение, равное количеству секунд, прошедших с 1 января 1970 года.
    • После того, как ведомый сервер стал ведущим, обратного переключения не произойдет до тех пор, пока новый ведущий сервер корректно функционирует.

Выбор нового ведущего сервера приложений

Выбор нового ведущего сервера приложений

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

Информационное окно о возникшем аварийном переключении

Информационное окно о возникшем аварийном переключении

  • Сервер приложений в роли ведущий использует настройки application.conf из основной секции настроек.
  • Сервер приложений в ведомый использует настройки application.conf из секции Standby.
    • Предполагается, что большая часть периодических задач (создание отчетов по расписанию, пересчет отчетов, отправка по почте и т.д.) будут работать только на основном сервере, на резервном сервере они будут простаивать.
    • Чтобы указать, что определенная настройка должна примениться только для ведомого сервера, необходимо перед настройкой добавить префикс Standby. Например, для отключения всех периодических задач, необходимо в файле application.conf в секции [Standby:JobScheduler] раскомментировать строку IsEnabled=false.
  • Клиентское приложений ТехноДок может отправлять запросы на чтение как ведущему серверу, так и ведомому.
    • В зависимости от настройки Cluster:RequestHandleType в application.conf будет выбрана одна из стратегий обработки запросов на сервере с ролью ведомый:
      • Cluster:RequestHandleType=Forbid - для запросов на изменение данных (POST, PUT, DELETE) будет возвращена ошибка 405 Method Not Allowed.
      • Cluster:RequestHandleType=RedirectToPrimary - запросы на изменение данных будут перенаправлены на ведущий сервер.

Настройка​

Для примера рассмотрим схему, состоящую из 2-х серверов reports.server1 (ведущий) и reports.server1 (ведомый).

Пример кластера из 2-х серверов

Пример кластера из 2-х серверов

Действия выполняемые на хосте reports.server1:​
  • Открыть файл application.conf на хосте reports.server1.
  • В секции [Cluster] указать настройку Priority=1, что сделает данный сервер ведущим, так как это будет максимальный приоритет среди серверов в данной конфигурации.
  • В секции [Cluster] указать настройку ServersAddresses:0=http://reports.server2. Данная настройка задает адрес второго сервера для его опроса.
  • В результате настройки в секции [Cluster] на хосте reports.server1 будут выглядеть следующим образом:
[Cluster]
Priority = 1
ServersAddresses:0 = http://reports.server2

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

  • Открыть файл application.conf на хосте 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:​
  • Открыть файл application.conf на хосте 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.

В качестве примера настройки резервирования рассмотрим вариант настройки метода потоковой репликации.

Замечание

Данный раздел описывает настройку резервирования и действия по восстановлению работоспособности кластера PostgreSQL для версий PostgreSQL 13+. Автоматическое переключение резервного сервера в режим основного сервера при недоступности основного сервера и восстановление работоспособности кластера PostgreSQL при ошибках данная инструкция не рассматривает.

Настройка потоковой репликации​

Для примера будет представлена конфигурация их двух узлов. При необходимости может расширена для большего количества. В примере будут использоваться адреса серверов 192.168.0.101 (основной) и 192.168.0.102 (резервный), которые нужно будет заменить на свои.

На основном сервере​
  • Выполните SQL команды:
ALTER SYSTEM SET listen_addresses TO '*'
ALTER SYSTEM SET synchronous_commit TO 'remote_apply'
SELECT * FROM pg_create_physical_replication_slot('__slot')
ALTER SYSTEM SET synchronous_standby_names TO '*'
ALTER SYSTEM SET wal_level TO 'replica'
ALTER SYSTEM SET wal_log_hints TO 'on'
ALTER SYSTEM SET max_wal_senders TO '10'
ALTER SYSTEM SET wal_keep_size  TO '16MB'
ALTER SYSTEM SET hot_standby TO 'on'
  • Отредактируйте файл pg_hba.conf, добавив следующие записи:
host all all 192.168.0.101/32 scram-sha-256
host all all 192.168.0.102/32 scram-sha-256
host replication all 192.168.0.101/32 scram-sha-256
host replication all 192.168.0.102/32 scram-sha-256
  • Перезапустите сервер PostgreSQL.
На резервном сервере​
  • Остановите сервер PostgreSQL.
    • На Linux можно воспользоваться командой sudo systemctl stop postgresql, где postgresql - имя сервиса. Имя сервиса может отличаться в зависимости от версии PostgreSQL.
  • Очистите каталог PG_DATA.
  • Выполните команду в командной строке: pg_basebackup -D "PG_DATA" -h ip_master -p port_master -X stream -c fast -U username -W -R, где:
    • pg_basebackup - встроенная в поставку PostgreSQL утилита, расположенная в паке bin установленного сервера БД;
    • PG_DATA - каталог данных PostgreSQL;
    • ip_master - IP-адрес или имя хоста, на котором расположен основной сервер БД (в примере это 192.168.0.101);
    • port_master - порт основного сервера БД (по умолчанию 5432);
    • username - имя пользователя с ролью репликации или суперпользователь. Этот пользователь должен иметь возможность подключаться к основной базе данных. Для создания такого пользователя на основном серевере можно воспользоваться командой:
    CREATE ROLE username WITH REPLICATION LOGIN PASSWORD 'replica_password';
  • После окончания работы команды запустите сервер PostgreSQL.
    • на Linux можно воспользоваться командой sudo systemctl start postgresql.
Замечание
  • Утилита pg_basebackup должна выполняться от пользователя, который запускает сервер PostgreSQL.
  • Если вы видите сообщение об ошибке "Не удалось подключиться к серверу" ("Could not connect to server") или "Нет маршрута к хосту" ("No route to host") при выполнении команды выше, то проверьте настройки вашего брандмауэра и файл pg_hba.conf.
Ручное переключение резервного сервера PostgreSQL в режим основного сервера​

При проблемах с основным сервером БД для продолжения работы с резервным сервером необходимо на резервном сервере выполнить команды:

CHECKPOINT;
ALTER SYSTEM SET synchronous_standby_names TO ''
SELECT * FROM pg_create_physical_replication_slot('__slot');
SELECT pg_reload_conf()
Восстановление сервера PostgreSQL в качестве резервного​

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

  • Остановить, если сервер запущен или не запускать его.
  • После остановки выполнить следующую команду: pg_rewind --target-pgdata=PG_DATA --source-server="user=ip_master port=port_master host=master_host dbname=postgres" -R, где:
    • pg_rewind - встроенная в поставку PostgreSQL утилита, расположенная в паке bin установленного сервера БД;
    • PG_DATA - каталог данных PostgreSQL;
    • ip_master - IP-адрес или имя хоста, на котором расположен основной сервер БД (в примере это теперь новый основной сервер 192.168.0.102);
    • port_master - порт основного сервера БД (по умолчанию 5432);
    • username - имя пользователя с ролью репликации или суперпользователь.
  • Запустите сервер.
Замечание

При критических проблемах со старым сервером утилита pg_rewind может не сработать и тогда нужно будет выполнить настройку согласно разделу На резервном сервере

Подключение ТехноДок к кластеру PostgreSQL​

В конфигурационном файле application.conf необходимо задать строку подключения в следующем формате (имя пользователя и пароль при необходимости заменить на свои, также можно создать нового пользователя, он автоматически появится на всех узлах кластера):

Type                  = PostgreSql                                                                                                                                              # Database type - PostgreSQL
ConnectionString      = Host=192.168.0.101:5432,192.168.0.102:5432; Database=databaseName;User Id=postgres;Password=postgres;SearchPath=td;Target Session Attributes=primary;      # PostgreSQL Database connection string

При данном формате ТехноДок будет автоматически выбирать для подключения главный узел кластера БД.

MariaDB​

MariaDB поддерживает режим репликации Master-Master что позволяет вести запись данных как в основной, так и в резервный сервер БД. Ниже приведены шаги настройки репликации Master-Master.

На первом сервере:​

  1. В секцию [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
  1. Перезапустить службу БД MariaDB, выполнив в терминале команду: Для linux: systemctl restart mariadb Для windows: net start mariadb
  2. Установить соединение с БД MariaDB, выполнив в терминале команду: mysql -u root –p , где root – пользователь, а после ключа -p пароль (если был указан)
  3. Создать пользователя, который будет ответственен за репликацию БД MariaDB, выполнив в терминале команды: create user 'replication_user'@'%' identified by 'replication_user'; grant replication slave on *.* to 'replication_user'@'%';
  4. Проверить состояние бинарного лога, выполнив в терминале команду: show master status; Значение полей Position и File будут использоваться для конфигурации репликации на втором сервере.
|	File			|	Position 
|	mariadb-bin.000001	|	314

На втором сервере:​

  1. В секцию [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
  1. Выполнить пункты 2-4 аналогично первому серверу.
  2. Остановить репликацию, выполнив в терминале команду: stop slave;
  3. Настраиваем репликацию, указав второму серверу, где нужно искать файл журнала: 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 подраздела На первом сервере соответственно.
  4. Запустить репликацию, выполнив в терминале команду: start slave;
  5. Проверить статус сервера на наличие ошибок, выполнив команду: show slave status \G Наличие числовых значений в Read_Master_Log_Pos и Relay_Log_Pos указывает, что ошибок нет.
  6. Проверить состояние бинарного лога, выполнив в терминале команду: show master status; Значение полей Position и File будут использоваться для конфигурации репликации на первом сервере.
|	File			|	Position 
|	mariadb-bin.000002	|	8196

На первом сервере:

  1. Остановить репликацию, выполнив в терминале команду: stop slave;
  2. Настраиваем репликацию, указав первому серверу, где нужно искать файл журнала: 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 подраздела На втором сервере соответственно.
  3. Запустить репликацию, выполнив в терминале команду: start slave;
  4. Проверить статус сервера, выполнив в терминале команду: show slave status \G Наличие числовых значений в Read_Master_Log_Pos и Relay_Log_Pos указывают, что ошибок нет. Если нет ошибок, то репликация настроена. В секции [Database] конфигурационного файла application.conf ТехноДок указать корректную строку подключения к БД MariaDB и установить значение RoundRobin для ключа FailoverStrategy. При возникновении проблем с восстановлением репликации при переключении или аварийной остановки, необходимо запустить репликацию повторно, выполнив в терминале команду: start slave;
# Пример строки подключения
Type = MariaDb  # Тип БД - MariaDb
ConnectionString  = Server=localhost;Database=databaseName;Uid=root;Password=password  # Строка соединения с БД

Microsoft SQL Server​

Microsoft SQL Server имеет несколько вариантов организации высокой доступности. Подробнее с вариантами и информацией по настройке можно ознакомиться: Business continuity and database recovery - SQL Server.