При разворачивании системы DirectumRX на СУБД PostgreSQL, следует уделить особое внимание выбору отказоустойчивого решения СУБД. Правильный выбор позволит обеспечить доступность системы с учетом заданного SLA при оптимальном уровне затрат на оборудование, лицензии и дальнейшее сопровождение.

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

Вариант 1. Система разворачивается в небольшой организации

Как правило, клиенты с такими входными данными характеризуются тем, что организация не готова вкладывать средства в дополнительное ПО, например, в лицензирование и поддержку СУБД.

В этом случае основным критерием будет минимальная стоимость владения решением. В качестве СУБД скорее всего будет использоваться свободная PostgreSQL. При этом часто можно обойтись без построения отказоустойчивой схемы.

Достаточно иметь резервную копию виртуальной машины (ВМ) на которой развернута СУБД и актуальную резервную копию БД. Недоступность системы в несколько часов может быть некритична для бизнеса.

Поддержка СУБД как услуга в этом случае чаще всего отсутствует, что не требует первоначальных вложений, но возможность задать вопрос относительно функционирования СУБД и получить ответ есть в сообществе https://www.postgresql.org/support/

Вариант 2. Достаточно крупная организация, время восстановления критично для обеспечения непрерывности процессов

Отказоустойчивость в этом случае может быть реализована как через разделяемые диски, так и с помощью потоковой репликации в зависимости от наличия/отсутствия системы хранения данных, при этом по-прежнему необходимо резервирование ВМ и БД. Сравнение вариантов отказоустойчивости приведено в таблице ниже.

В качестве СУБД возможен вариант использования как бесплатной версии PostgreSQL, так и использование коммерческой версии дистрибутива, например, PostgresPRO.

Поддержка версии PostgreSQL может осуществляться как хостинг-провайдерами в случае размещения СУБД в «облаке», так и сторонними организациями.

Как итог можно подобрать оптимальное решение между стоимостью поддержки, отсутствием необходимости лицензировать СУБД и отказоустойчивостью решения в целом.

Вариант 3. Крупная компания или группа компаний, холдинг

Как правило, клиенты с такими входными данными характеризуются тем, что работа пользователей зависит от функционирования системы, при этом критичные бизнес-процессы компании завязаны на систему DirectumRX.

В качестве СУБД оптимальным является вариант использования проприетарных версий СУБД, которые основаны на открытой PostgreSQL. Для данных СУБД вендоры осуществляют поддержку, выполняют соответствующие доработки, направленные на повышение производительности и стабильности в высоконагруженных системах, а также оперативно устраняют выявленные критичные дефекты и уязвимости. Примерами таких компаний являются отечественная PostgresPRO и зарубежные EnterpriseDB и 2ndQuadrant.

С учетом повышенных требований SLA к доступности системы DirectumRX оптимальным является архитектура отказоустойчивости, основанная на репликации средствами СУБД (достоинства и недостатки вариантов приведены в таблице ниже).

В случае готовности со стороны Клиента уменьшить требования SLA, отказоустойчивость может быть организована через разделяемые диски. Это позволит сэкономить на числе лицензий СУБД, но увеличит время недоступности системы в случае сбоя, с нескольких десятков секунд до нескольких минут.

Обе архитектуры не являются альтернативой или заменой резервному копированию ВМ и БД.

Сравнение реализаций отказоустойчивости

Если углубиться в технические детали, то наиболее подходящими вариантами обеспечения отказоустойчивости СУБД PostgreSQL для системы DirectumRX являются:

Отказоустойчивость через разделяемые диски

https://postgrespro.ru/docs/postgrespro/11/different-replication-solutions

Требуется минимум 2 сервера с СУБД и общий диск, доступный на этих серверах). Схема является классическим примером HighAvailability-кластера;

При проблемах на ведущем сервере 1, вся обработка данных через некоторый таймаут переносится на резервный сервер 2, путем переключения раздела системы хранения данных (СХД) с базой данных на резервный сервер.

Трансляция журнала предзаписи

https://postgrespro.ru/docs/postgrespro/11/different-replication-solutions

В данном случае используются встроенные возможности СУБД, в частности потоковая репликация.

При проблемах на ведущем сервере 1, вся обработка данных через некоторый таймаут переносится на резервный сервер 2, при этом на резервном сервере есть свой экземпляр базы данных.

Автоматизация переключения, в обоих случаях, как правило, осуществляется специализированным ПО. Примером такого ПО является PaceMaker (аналогичные рекомендации приводит и компания PostgresPRO в статье).

Еще больше технических деталей и пошаговые инструкции по разворачиванию приведены в документе, доступном на сайте поддержке компании DIRECTUM.

Таблица сравнения вариантов

Примечание. В случае необходимости использования версии СУБД, которая зарегистрирована в реестре российского ПО и/или сертифицирована органами ФСТЭК, на текущий момент должна быть использована версия Postgres Pro Standard или Postgres Pro Enterprise от компании PostgresPRO.

Multimaster от PostgresPRO

Multimaster — это расширение для версии Postgres Pro Enterprise, которое позволяет организовать синхронный кластер без разделения ресурсов, который обеспечивает масштабируемость OLTP для читающих транзакций, а также высокую степень доступности с автоматическим восстановлением после сбоев. В качестве аналогии можно привести технологию AlwaysOn от компании Microsoft для SQL Server. 

На текущий момент использование расширения multimaster возможно только для обеспечения высокой доступности системы DirectumRX. Т.е. для тех клиентов у кого уже развернут multimaster допустимо его задействовать для DirectumRX с учетом ограничений расширения, которые могут оказывать существенное влияние на функционирование системы. Полный список ограничений приведен в официальной документации PostgresPRO.

Для функционирования кластера потребуется минимум 2 узла кластера и 1 узел рефери, либо 3 полноценных узла кластера.

Вместо заключения

В качестве резюме к статье хотелось бы отметить следующее:

• если вы на практике не сталкивались с отказоустойчивостью, то прочитав статью, можно сформировать некий первоначальный "взгляд сверху" исходя из которого можно планировать дальнейшие шаги по повышению доступности системы DirectumRX. При этом стоит явно понимать, что список приведенный выше по вариантам реализации отказоустойчивости не конечный и в каждом конкретном случае схема может измениться;
• если вы находитесь на этапе разворачивания системы DirectumRX или повышения ее доступности, то приведенная в статье ссылка на инструкцию позволит сэкономить время по настройке выбранного варианта;
• если же у вас есть опыт реального применения альтернативных вариантов, то делитесь в комментариях вариантами используемыми в вашей организации. Это будет хорошим поводом к обсуждению!