Рекомендации по обеспечению отказоустойчивости СУБД PostgreSQL для DirectumRX

23 3

При разворачивании системы 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.

 

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

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

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

Достоинства

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

Достоинства

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

Недостатки

  • Требуется отказоустойчивая СХД, например, SAN или NAS.
  • Нельзя распределять нагрузку между серверами.
  • Переключение на резервный узел выполняется до нескольких минут

Недостатки

  • Требуется дополнительный объем дискового пространства, т.к. БД развернута на каждом сервере.
  • Синхронизируются все БД кластера PostgreSQL. Это увеличивает сетевой трафик и другие накладные расходы.
  • При интенсивной работе с БД возможны задержки в передаче журналов предзаписи при асинхронной репликации. В результате данные на резервном сервере становятся неактуальными. При синхронной репликации данные на резервном сервере всегда актуальны, но скорость выполнения запросов может снизиться.
  • Согласно лицензионной политике компании Postgres Professional для использовании Postgres Pro в отказоустойчивой архитектуре требуется лицензия на каждый сервер СУБД

Примечание. В случае необходимости использования версии СУБД, которая зарегистрирована в реестре российского ПО и/или сертифицирована органами ФСТЭК, на текущий момент должна быть использована версия 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 или повышения ее доступности, то приведенная в статье ссылка на инструкцию позволит сэкономить время по настройке выбранного варианта;
  • если же у вас есть опыт реального применения альтернативных вариантов, то делитесь в комментариях вариантами используемыми в вашей организации. Это будет хорошим поводом к обсуждению!
Юрий Юсупбаев

Привет. 

SBD  - дорого в эксплуатации и сложно в обслуживании. Необходимо сам кворум строить отказоустойчивым, следить за его состоянием. Переключение мастер-слейв можно производить не только PaceMaker, но и через Slony-I, Pgpool-I/II, Bucardo, Pglogical, BDR.

На мой взгляд, наилучшее решение это потоковая репликация (асинхронная) и частое резерервное копирование базы данных. Даже если мастер умрет, можно из слейва сделать мастер и рядом поднять новый слейв, реплицировав на него БД. Займет это не больше 25 минут. Главное держать наготове чистую настроенную ВМ.

Неплохой продукт Repmgr https://repmgr.org/

Repmgr — набор инструментов для управления потоковой репликацией и восстановления после сбоя кластера PostgreSQL серверов. Он автоматизирует настройку резервных серверов, мониторинг репликации, а также помогает выполнять задачи администрированию кластера, такие как отказоустойчивость (failover) или переключение мастера-слейва (слейв становится мастером, а мастер - слейвом). Repmgr работает с версии PostgreSQL 9.3 и выше.

В качестве резервного копирования как вариант использовать Barman. Он умеет бекапить на отдельный сервер с нескольких нод PSQL.

По дистрибутивам работы с PSQL больше всего понравилась Ubuntu 18.04. Очень много материала в интернете и чуть меньше Centos.

Алексей Зубин

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

Хотелось бы узнать, а в реальности из всего списка, что именно использовали на продуктивной системе?

С какими плюсами/минусами/особенностями сталкивались?

Алексей Зубин: обновлено 21.11.2019 в 09:24
Алексей Зубин

Что-то пошло не так и в первом ответе потерялась часть моих комментариев, поэтому дополню ниже:

>>SBD  - дорого в эксплуатации и сложно в обслуживании. Необходимо сам кворум строить отказоустойчивым, следить за его состоянием.

Все-таки на дворе 2019 и СХД есть у большинства крупных организаций. При этом сами СХД достаточно надежны, а у многих еще реализовано и дублирование данных. С другой стороны, если все-таки СХД нет, то согласен с вами, что можно просто увеличить число узлов в кластере до 3 для обеспечения кворума.

>>Переключение мастер-слейв можно производить не только PaceMaker, но и через Slony-I, Pgpool-I/II, Bucardo, Pglogical, BDR.

>>Неплохой продукт Repmgr https://repmgr.org/

Тут также соглашусь, что вариантов которые позволяют организовать отказоустойчивость СУБД достаточно много. Но у многих есть особенности, либо они "заточены" на работу именно с PostgreSQL. Pacemaker же в этом плане более универсален и с помощью него можно построить недорогие High Availability решения для того же Redis или RabbitMQ (либо вообще сторонней службы), которые также потребуются для построения отказоустойчивой инфраструктуры DirectumRX

>>По дистрибутивам работы с PSQL больше всего понравилась Ubuntu 18.04. 

Действительно сейчас можно выделить 3 основных ОС на которые достаточно документации в сети. Это Ubuntu, SLES и RHEL, при этом мануалы для последних двух, как правило применимы и для их бесплатных вариаций, таких как OpenSuse и Centos. Ну и дополню, что в пошаговой инструкции, ссылка на которую дана в статье, также приведен пример в том числе и на Ubuntu.

Алексей Зубин: обновлено 21.11.2019 в 09:39

Авторизуйтесь, чтобы написать комментарий