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

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

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

Описание​

Резервирование сервера приложений реализовано в виде кластера серверов. Конфигурирование кластера серверов осуществляется посредством указания приоритета каждого сервера (настройка Cluster:Priority) и адреса других серверов (настройка Cluster:ServersAddresses) в файле technodoc.settings.ini.

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

При работе сервера в качестве основного, настройки Системы загружаются из основной секции файла technodoc.settings.json. При работе сервера в качестве резервного сервера настройки Системы загружаются из секции Standby. Предполагается, что большая часть периодических задач (задача по созданию, обновлению, отправке отчетов по почте и др.) будут работать только на основном сервере, на резервном сервере они будут отключены. Таким образом, при работе Системы в качестве кластера серверов, каждый из которых взаимодействует с одной и той же базой данных, целостность данных не будет нарушена. Пользователь может работать с Системой как при помощи основного сервера, так и при помощи резервного. Однако, в случае подключения к резервному серверу все операции, связанные с обновлением данных, будут запрещены.

Кластер серверов

Кластер серверов

Чтобы указать, что определенная настройка должна примениться только в том случае если сервер работает в качестве резервного, необходимо перед ней добавить префикс Standby. Например, для отключения всех периодических задач, в том случае, если сервер работает в качестве резервного, необходимо в конфигурационном файле technodoc.settings.ini, в секции [JobScheduler] раскомментировать строку IsEnabled=false.

В случае отключения основного сервера, другие сервера в кластере определяют, кто возьмет на себя роль нового основного сервера. Определение основного сервера происходит за счет сравнения приоритетов серверов. Сервер с наивысшим значением приоритета из оставшихся становится основным.

Важно заметить, что в случае аварийного переключения, сервер, который стал основным, повышает свой приоритет на значение, равное количеству секунд, прошедших с 1 января 1970 года. Соответственно, после того, как резервный сервер стал основным, обратного переключения не произойдет до тех пор, пока он корректно функционирует. Определение нового основного сервера будет произведено при следующем расчете статуса всех серверов в кластере. Период расчета статуса сервера задается при помощи настройки PollingRate секции Cluster в файле technodoc.settings.ini.

Переключение приложения с основного сервера на резервный

Переключение приложения с основного сервера на резервный

При работе на резервном сервере есть 2 варианта работы:

  • Все запросы на изменение данных запрещаются.
  • Все отличные от GET запросы к резервным серверам перенаправляются на основной сервер.

Данное поведение настраивается с помощью настройки RequestHandleType секции Cluster в файле technodoc.settings.ini, которая может принимать следующие значения:

  • Forbid - все запросы на изменение данных к резервным серверам отклоняются (вариант по умолчанию).
  • RedirectToPrimary - все отличные от GET запросы к резервным серверам перенаправляются на основной сервер.
Режим RedirectToPrimary

В некоторых браузерах установлены политики безопасности, которые в настоящий момент не позволяют корректно выполнять перенаправление запросов. В будущих версиях данный момент будет исправлен. При этом перенаправление запросов по умолчанию работает во встроенном браузере КАСКАД.

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

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

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

Настройка​

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

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

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

Действия выполняемые на хосте reports.server1:

  • Открыть файл technodoc.settings.ini на хосте reports.server1.
  • В секции [Cluster] указать настройке Priority значение равное 1, что сделает данный сервер основным, так как это будет максимальный приоритет среди серверов в данной конфигурации (можно указать любое число, которое будет больше чем на резервном сервере).
  • В секции [Cluster] задать для настройки ServersAddresses:0 значение равное http://reports.server2. Данная настройка задает адрес второго сервера для его опроса и определения состояния сервера.
  • Для сервера в режиме резервного сервера есть 2 варианта поведения, которые настрагиваются с помощью опции RequestHandleType:
    • Forbid - все запросы на изменение данных к резервным серверам отклоняются
    • RedirectToPrimary - все отличные от GET запросы к резервным серверам перенаправляются на основной сервер Выберем для примера вариант по умолчанию Forbid.
  • В результате настройки в секции [Cluster] на хосте reports.server1 будут выглядеть следующим образом:
[Cluster]
Priority              = 1                          # Приоритет текущего сервера. Сервер с наивысшим приоритетом является основным
ServersAddresses:0    = http://reports.server2     # Адреса серверов в кластере в формате [http|https]://[IP|доменное имя]:[порт]
RequestHandleType     = Forbid                     # Тип обработки запросов

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

  • Открыть файл technodoc.settings.ini на хосте reports.server1.
  • Отключить задачи для режима резервного сервера: UploadReportValuesJob, ProcessReportsCreationRulesJob, ProcessReportsRulesJob, CalculateOperationTimeJob, SendMailsJob и DeleteMailsJob. Для этого необходимо добавить в конфигурацию для каждой задачи секцию конфигурирования с префиксом Standby и указать значение настройки IsEnabled равным False:
# Список допустимых названий задач:
[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. Данная настройка задает адрес второго сервера для его опроса и определения состояния сервера.
  • Для сервера в режиме резервного сервера есть 2 варианта поведения, которые настрагиваются с помощью опции RequestHandleType:
    • Forbid - все запросы на изменение данных к резервным серверам отклоняются
    • RedirectToPrimary - все отличные от GET запросы к резервным серверам перенаправляются на основной сервер Выберем для примера вариант по умолчанию Forbid.
  • В результате настройки в секции [Cluster] на хосте reports.server2 будут выглядеть следующим образом:
[Cluster]
Priority              = 0                         # Приоритет текущего сервера. Сервер с наивысшим приоритетом является основным
ServersAddresses:0    = http://reports.server1    # Адреса серверов в кластере в формате [http|https]://[IP|доменное имя]:[порт]
RequestHandleType     = Forbid                    # Тип обработки запросов

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

  • Открыть файл technodoc.settings.ini на хосте reports.server2.
  • Отключить задачи для режима резервного сервера: UploadReportValuesJob, ProcessReportsCreationRulesJob, ProcessReportsRulesJob, CalculateOperationTimeJob, SendMailsJob и DeleteMailsJob. Для этого необходимо добавить для каждой задачи секции конфигурирования с префиксом Standby и указать значение настройки IsEnabled равным False:
# Список допустимых названий задач:
[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.

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

  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] конфигурационного файла 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. Для настройки взаимодействия ТехноДок и КАСКАД необходимо выполнить следующие действия:

  1. Настроить кластер БД ТехноДок.
  2. Настроить кластер ТехноДок.
  3. Добавить и настроить скрипты взаимодействия КАСКАД с ТехноДок в проекте КАСКАД в настроенный резервируемый проект.
  4. Добавить в ТехноДок внешнее соединение с настройками подключения для каждой из пар проекта КАСКАД.
  5. Добавить и настроить в проекте КАСКАД панель отображения ТехноДок с автоматическим выбором основного сервера.

Настройка реплицируемой БД ТехноДок​

ТехноДок может использовать одну из следующих СУБД для создания реплицированной БД:

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

  • Открыть файл technodoc.settings.ini на хосте reports.server1.
  • В секции [Database:Connections:Primary] раскомментировать следующие строки и указать корректные данные авторизации:
# Настройки для MariaDb
Type = MariaDb # Тип БД – MariaDb
ConnectionString=Server=reports.server1;Database=technodoc;Uid=root;Password=password # Строка соединения с БД;
# Настройки для PostgreSql
Type = PostgreSql # Тип БД – PostgreSql
ConnectionString=Server=reports.server1;Database=technodoc;User Id=postgres;Password=postgres;SearchPath=td# Строка соединения с БД;
# Настройки для Microsoft SQL Server
Type = MsSql # Тип БД – MS SQL Server
ConnectionString=Server=reports.server1;Database=technodoc;User Id=sa;Password=password # Строка соединения с БД;
  • В секции [Database:Connections: Standby] раскомментировать следующие строки и указать корректные данные авторизации:
# Настройки для MariaDb
Type = MariaDb # Тип БД – MariaDb
ConnectionString=Server=reports.server2;Database=technodoc;Uid=root;Password=password # Строка соединения с БД;
# Настройки для PostgreSql
Type = PostgreSql # Тип БД – PostgreSql
ConnectionString=Server=reports.server2;Database=technodoc;User Id=postgres;Password=postgres;SearchPath=td # Строка соединения с БД;
# Настройки для Microsoft SQL Server
Type = MsSql # Тип БД – MS SQL Server
ConnectionString=Server=reports.server2;Database=technodoc;User Id=sa;Password=password # Строка соединения с БД;
  • В секции [Database] установить настройку FailoverStrategy в значение RoundRobin (используется по умолчанию).
FailoverStrategy = RoundRobin
  • Повторить настройки в таком же порядке на сервере reports.server2.
Дополнение для PostgreSQL

Альтернативный вариант задать строку подключения к БД, в которой будут сразу указаны все сервера для подключения и приоритетная БД для подключения, за выбор БД для подключения будет отвечать драйвер, для этого:

  • Открыть файл technodoc.settings.ini на хосте reports.server1.
  • В секции [Database:Connections:Primary] раскомментировать следующие строки и указать корректные данные авторизации:
Type = PostgreSql # Тип БД – PostgreSql
ConnectionString=Server=reports.server1,reports.server2;Database=technodoc;User Id=postgres;Password=postgres;SearchPath=td;Target Session Attributes=primary # Строка соединения с БД;
  • Повторить настройки в таком же порядке на сервере reports.server2. В данном случае с помощью задания опции подключения Target Session Attributes=primary драйвер автоматически будет искать и подключаться к главной БД без необходимости явного указанию второй строки соединения.
Дополнение для Microsoft SQL Server

При выборе в качестве опции резервирования группы доступности Always On будет нужна только одна строка подключения, соответственно настройки подключения будут выглядеть следующим образом (в качестве адреса кластера для примера зададим cluster.server):

  • Открыть файл technodoc.settings.ini на хосте reports.server1.
  • В секции [Database:Connections:Primary] раскомментировать следующие строки и указать корректные данные авторизации:
Type = MsSql # Тип БД – MS SQL Server
ConnectionString=Server=cluster.server;Database=technodoc;User Id=sa;Password=password # Строка соединения с БД;
  • Повторить настройки в таком же порядке на сервере reports.server2. В данном отвечать за выбор главной БД будет настроенный кластер, в составе которого работают группы доступности.

Настройка кластера ТехноДок.​

Подробная информация о работе кластера ТехноДок описана в разделе Резервирование сервера приложений. В данном разделе будет приведен пример настройки кластера. Действия выполняемые на хосте reports.server1:

  • Открыть файл technodoc.settings.ini на хосте reports.server1.

  • В секции [Cluster] указать настройке Priority значение равное 1, что сделает данный сервер основным, так как это будет максимальный приоритет среди серверов в данной конфигурации (можно указать любое число, которое будет больше чем на резервном сервере).

  • В секции [Cluster] задать для настройки ServersAddresses:0 значение равное http://reports.server2. Данная настройка задает адрес второго сервера для его опроса и определения состояния сервера.

  • Для сервера в режиме резервного сервера есть 2 варианта поведения, которые настрагиваются с помощью опции RequestHandleType:

    • Forbid - все запросы на изменение данных к резервным серверам отклоняются.
    • RedirectToPrimary - все отличные от GET запросы к резервным серверам перенаправляются на основной сервер.

    Выберем для примера вариант по умолчанию Forbid.

  • В результате настройки в секции [Cluster] на хосте reports.server1 будут выглядеть следующим образом:

[Cluster]
Priority              = 1                          # Приоритет текущего сервера. Сервер с наивысшим приоритетом является основным
ServersAddresses:0    = http://reports.server2     # Адреса серверов в кластере в формате [http|https]://[IP|доменное имя]:[порт]
RequestHandleType     = Forbid                     # Тип обработки запросов

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

  • Открыть файл technodoc.settings.ini на хосте reports.server1.
  • Отключить задачи для режима резервного сервера: UploadReportValuesJob, ProcessReportsCreationRulesJob, ProcessReportsRulesJob, CalculateOperationTimeJob, SendMailsJob и DeleteMailsJob. Для этого необходимо добавить в конфигурацию для каждой задачи секцию конфигурирования с префиксом Standby и указать значение настройки IsEnabled равным False:
# Список допустимых названий задач:
[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. Данная настройка задает адрес второго сервера для его опроса и определения состояния сервера.

  • Для сервера в режиме резервного сервера есть 2 варианта поведения, которые настрагиваются с помощью опции RequestHandleType:

    • Forbid - все запросы на изменение данных к резервным серверам отклоняются.
    • RedirectToPrimary - все отличные от GET запросы к резервным серверам перенаправляются на основной сервер.

    Выберем для примера вариант по умолчанию Forbid.

  • В результате настройки в секции [Cluster] на хосте reports.server2 будут выглядеть следующим образом:

[Cluster]
Priority              = 0                         # Приоритет текущего сервера. Сервер с наивысшим приоритетом является основным
ServersAddresses:0    = http://reports.server1    # Адреса серверов в кластере в формате [http|https]://[IP|доменное имя]:[порт]
RequestHandleType     = Forbid                    # Тип обработки запросов

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

  • Открыть файл technodoc.settings.ini на хосте reports.server2.
  • Отключить задачи для режима резервного сервера: UploadReportValuesJob, ProcessReportsCreationRulesJob, ProcessReportsRulesJob, CalculateOperationTimeJob, SendMailsJob и DeleteMailsJob. Для этого необходимо добавить для каждой задачи секции конфигурирования с префиксом Standby и указать значение настройки IsEnabled равным False:
# Список допустимых названий задач:
[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                          # Включена ли задача

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

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

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

Настройка обмена данными ТехноДок и КАСКАД​

ТехноДок выполняет обмен данными с КАСКАД по протоколу XMLRPC. Для настройки коммуникации между ТехноДок выполните следующие действия на каждом узле из резервированной пары (подробнее об интеграции смотрите КАСКАД Цифра):

  1. Скопируйте в проект КАСКАД CONTROL скрипты из папки components/kaskad/scripts установленного экземпляра ТехноДок.
  2. В скрипте technodoc.ctl при необходимости измените порт, изменив значение переменной TECHNODOC_XMLRPC_HTTP_PORT (по умолчанию используется 8242).
  3. Добавьте новый менеджер сценариев, указав в опциях запуска скрипт technodoc.ctl.
  4. Запустите добавленный менеджер. В консоли проекта должна появиться запись XMLRPC-сервер запущен на порту ХХХХ.

Запуск скрипта взаимодействия ТехноДок и КАСКАД

Запуск скрипта взаимодействия ТехноДок и КАСКАД

Далее необходимо добавить в ТехноДок внешнее соединение:

  1. Перейти в пункт меню Внешние соединения.
  2. Добавить источник данных КАСКАД и указать 2 опции подключения с адресами до каждой резервной пары серверов КАСКАД - kaskad.server1 и kaskad.server2 (подробнее о настройке данного источника данных см. Настройки источника КАСКАД).

Настройка внешнего соединения с источником данных КАСКАД

Настройка внешнего соединения с источником данных КАСКАД

Замечание

Строки подключения можно указать в любом порядке, ТехноДок выполнит подключение к первому доступному источнику, а КАСКАД автоматически перенаправит запрос к основному серверу.

Настройка панели КАСКАД при работе ТехноДок в кластере​

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

  1. В проекте КАСКАД открыть скрипт на каждом из серверов открыть scripts\libs\Technodoc\Core\technodocServerSettings.ctl.
  2. Для переменной TECHNODOC_CLUSTER_URLS задать в виде строк список адресов (URL) экземпляров ТехноДока в кластере.
// Массив адресов серверов Технодока
dyn_string TECHNODOC_CLUSTER_URLS = makeDynString("http://reports.server1", "http://reports.server2");
  1. Если проект был запущен, то перезагрузить проект.

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