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

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

Резервирование серверов приложений. ТехноДок устанавливается на несколько серверов, подключённых к общей базе данных. Серверы равноправны: пользователи могут подключиться к любому из них, а каждая периодическая задача выполняется только на одном сервере.

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

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

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

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

Принцип работы

Серверы приложений в кластере равноправны: каждый из них самостоятельно обслуживает пользователей и работает с общей базой данных. Настройки, учётные записи и отчёты хранятся в базе данных, поэтому на любом сервере пользователю доступны одни и те же данные. Версия ТехноДок на всех серверах должна совпадать — кластер из разных версий неработоспособен.

Единая точка входа — адрес, по которому пользователи открывают ТехноДок, — настраивается вне приложения, средствами сетевой инфраструктуры. Допустимые варианты перечислены в разделе Выбор схемы подключения. Если ни один из них применить нельзя, остаётся встроенное переключение ТехноДок: оно настраивается в самом приложении, но действует с ограничениями.

Выбор схемы подключения

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

Вариант	Когда подходит
Виртуальный IP-адрес, например keepalived в Linux или Network Load Balancing в Windows Server	Подходит, когда серверы приложений стоят в одной подсети. Отдельной машины не требует: адрес переезжает между самими серверами приложений, и отказ сервера пользователи не замечают. Данная схема описана в статье Пошаговая настройка резервирования.
Запись DNS с небольшим временем жизни	Подходит, когда доступно управление зоной DNS, а виртуальный адрес развернуть нельзя. Запись меняет администратор, если только зона не обслуживается сервисом, который сам следит за доступностью серверов. После отказа работа возобновляется не сразу: браузер, операционная система и промежуточные серверы DNS держат прежний адрес в кэше и малое время жизни записи соблюдают не всегда.
Встроенное переключение в ТехноДок	Подходит, когда настроить сеть невозможно: серверы приложений стоят в разных подсетях, сеть не пропускает VRRP, а управлять зоной DNS нельзя. Единственный вариант, который настраивается средствами самого ТехноДок, но отказ сервера пользователь замечает: работает, только когда приложение уже открыто в браузере, а переход нужно подтвердить и войти на новом сервере заново. Порядок настройки и ограничения описаны в разделе Встроенное переключение вместо виртуального адреса.

Примечание

Если одного сервера приложений недостаточно для обработки запросов всех пользователей, рекомендуется добавить к выбранной схеме обратный прокси, например nginx или HAProxy. Он ставится поверх точки входа, распределяет запросы между серверами приложений и перестаёт отправлять их на сервер, который не отвечает. Настройка описана в разделе Распределение нагрузки на nginx.

Резервирование базы данных

Принцип работы

Резервирование базы данных работает с PostgreSQL и MariaDB. В файле application.conf задаются два подключения: основное в секции [Database:Connections:Primary] и резервное в секции [Database:Connections:Standby]. Сервер приложений работает с основной базой данных, а когда она перестаёт отвечать, продолжает работу с резервной. Переключение остаётся незаметным для пользователя. Если недоступны обе базы данных, пользователь увидит окно «Сервис недоступен».

На странице «Администрирование» → «Диагностика» → «Сервер» показано, какая база данных активна и доступна сейчас, а для MariaDB — актуальное состояние репликации. Репликацию между серверами администратор настраивает средствами СУБД.

Настройка Database:FailoverStrategy определяет, разрешено ли серверу вернуться на основную базу данных:

• RoundRobin — разрешено. Значение по умолчанию.
• Forbid — запрещено. Сервер, перешедший на резервную базу данных, остаётся на ней до перезапуска.

Примечание

Даже при значении RoundRobin сервер не возвращается на основную базу данных сразу после её восстановления. Он проверяет её доступность только тогда, когда перестанет отвечать резервная база данных. Чтобы вернуть сервер на основную базу данных, перезапустите его в удобное время.

Выбор СУБД

Резервирование устроено по-разному в зависимости от того, принимает ли запись только один сервер базы данных или оба.

СУБД	Как устроено резервирование
MariaDB	Рекомендуемый вариант. Репликация Master-Master. Запись принимают оба сервера базы данных, поэтому подключения задаются парой основное и резервное, а переключение между ними выполняет сам ТехноДок. Внешние средства не нужны. Порядок настройки описан в статье Резервирование MariaDB.
PostgreSQL	Потоковая репликация: запись принимает один сервер, резервный остаётся доступным только на чтение, пока его не повысят до основного. Повышение выполняет администратор вручную или менеджер кластера Patroni. Порядок настройки и оба способа повышения описаны в статье Резервирование PostgreSQL.

Для PostgreSQL подключение задаётся одной строкой соединения: перечислите оба сервера в секции [Database:Connections:Primary], а секцию [Database:Connections:Standby] не задавайте. Параметр Target Session Attributes=primary выбирает сервер, открытый на запись, поэтому после переключения драйвер PostgreSQL находит новый основной сервер сам. Так задаётся подключение при любом способе повышения — и автоматическом, и ручном. Настройка Database:FailoverStrategy при этом ни на что не влияет: выбор делает драйвер, а не ТехноДок. Пример приведён в статье Пошаговая настройка резервирования.