Заметки ИТ инженера

В рамках проработки вопроса по импортозамещению СУБД Microsoft SQL Server на СУБД PostgresPro от компании Postgres Professional (решение СУБД на базе PostgreSQL из реестра российского ПО) изучал вопрос постороения системы, обеспечивающей высокую доступность.

Т.к. задача уже поглотила существенное время, то решил сделать пометки в блог. В последнее время я для себя всё больше приоткрываю мир Open Source и философию UNIX way и тут такое творится.. , как говорится, — «каждый суслик в поле агроном».

Проблема в основном состоит в том, что имеем очень большое разнообразие всевозможных компонентов, модулей, утилит, решений, из которых как из кирпичиков каждый строит себе более сложные конструкции и типа законченные Решения. Но это пол беды. Вторая половина беды заключается в компетенции того, кто это всё собирает воедино, а качество «сборки» прямо пропорционально этой компетенции и в итоге … «чем больше шкаф, — тем громче падает»…

Из коробки ни PostgreSQL ни PostgresPro не предлагают решений по обеспечению высокой доступности СУБД (к слову, у PostgresPro редакции Enterprise всё же есть высокодоступное решение, но оно по факту ограничивается одной базой данных.. Извините, но это, на мой взгляд, не серьёзно для Enterprise уровня.) ни собственными средствами ни рекомендованными примерами решений.

Цель данной статьи зафиксировать рабочие конфигурации, которые я протестировал и счёл жизнеспособными в моих проектах, а также некоторые заметки к ним.

Протестированные решения:

1. PostgresPro в Microsoft Windows Server Failover Cluster = работоспособно
   СУБД
   PostgresPro (редакции Standard, Enterprise) (тестировалась версия 13).

   Операционная система
   Windows Server SE\DE (тестировалось на версии 2016, но уверен, что подойдет любая, начиная с Windows Server 2008 R2).

   * Данная конфигурация вполне работоспособна, — подтверждаю лично.
   * Это по сути полный аналог старой доброй классики — кластеризованного экземпляра (Failover Cluster Instance) SQL Server.
   * Да, тут нужно будет всё вручную сделать — создать кластерную группу ресурсов, учетку компьютера в домене, сетевое имя, сетевой адрес, сервис PostgresPro, диски, зависимости.
   * PostgreSQL также должен заработать в такой конфигурации, т.к. по сути разницы никакой.
   * Есть ещё вот такая отсылка к компетентным товарищам — https://postgrespro.ru/list/id/006c01cd8c6f$bd274ba0$3775e2e0$@devshock.com .
   * ну и от себя добавлю (получено опытным путём): у роли «generic service» включите опцию «Run this resourcein separate Resource Monitor», это предотвратит сбой сервиса при отработке отказа и переключении с узла на узел. Причина сбоя пока мне не ясна до конца, вопрос ждёт своего исследователя.. 

2. (PostgresPro + Patroni) * AstraLinux = работоспособно
   СУБД
   PostgresPro (редакции Standard, Enterprise) (тестировалась версия 14.1 для AstraLinux CE Orel)
   или PostgreSQL (в дистрибутиве AstraLinux CE Orel присутствует версия 9.6).

   Операционная система
   AstraLinux Common Edition Орёл (Debian например, не рассматривается в принципе, т.к. не в реестре отечественного ПО) — использовалась для всех ролей и компонентов Решения, включая для машины под Ansible.

   Система управления конфигурациями Ansible
   Ansible
   Ansible 2.7.7 Входит в состав AstraLinux.

   Решение по обеспечению высокой доступности
   Изучив актуальные в данное время решения и практики по обеспечению высокой доступности для PostgreSQL я остановил свой выбор на решении Patroni и в частности на набор Ansible playbook «PostgreSQL High-Availability Cluster» для автоматизации развёртывания всего решения в целом.

   Компоненты высокой доступности:
   # Patroni — это шаблон, чтобы создать собственное индивидуальное решение высокой доступности с использованием Python и — для максимальной доступности — распределенного хранилища конфигураций, такого как ZooKeeper, etcd, Consul или Kubernetes.
   MIT License.
   Используется для автоматизации управления экземплярами PostgreSQL и автоматического переключения при отказе.

   # etcd — это надежное распределенное хранилище ключей и значений для наиболее важных данных распределенной системы.
   Apache License 2.0
   etcd написан на Go и использует алгоритм консенсуса Raft (https://raft.github.io) для управления высокодоступным реплицированным журналом. Он используется Patroni для хранения информации о состоянии кластера и параметров конфигурации PostgreSQL.

   Компоненты балансировки нагрузки:
   # HAProxy — это бесплатное, очень быстрое и надежное решение, обеспечивающее высокую доступность, балансировку нагрузки и проксирование для приложений на основе TCP и HTTP.  Входит в состав дистрибутива AstraLinux.

   # confd управляет файлами конфигурации локальных приложений, используя шаблоны и данные из etcd или consul.
   MIT License
   Используется для автоматизации управления файлом конфигурации HAProxy.

   # Keepalived предоставляет виртуальный высокодоступный IP-адрес (VIP) и единую точку входа для доступа к базам данных.
   GNU General Public License v2.0
   Реализация VRRP (протокол резервирования виртуального маршрутизатора) для Linux. В нашей конфигурации keepalived проверяет статус службы HAProxy и в случае сбоя делегирует VIP другому серверу в кластере.

   # PgBouncer — это пулер подключений для PostgreSQL.
   ISC License https://github.com/pgbouncer/pgbouncer/blob/master/COPYRIGHT
   Если планируется что к базам будет много (>500-1000) одновременных подключений, то необходимо использовать пулер соединений, т.к. PostgreSQL на каждое соединение создает отдельный процесс и общая производительность СУБД начинает деградировать.

   # vip-manager — обеспечение единой точки входа (VIP) для доступа к базам данных.
   BSD 2-Clause «Simplified» License https://github.com/cybertec-postgresql/vip-manager/blob/master/LICENSE
   Данный компонент используется для сценария, когда HAProxy в Решении не используется.
   Сервис, который запускается на всех узлах кластера и подключается к DCS. Если локальный узел владеет лидером-ключом, vip-manager запускает настроенный VIP. В случае аварийного переключения (failover) vip-manager удаляет VIP на старом лидере и запускает его соответствующий сервис на новом лидере. Написано на Go. Cybertec Schönig & Schönig GmbH https://www.cybertec-postgresql.com

   Дополнительные компоненты:
   # Ansible Role: Firewall (iptables)
   MIT License
   Штатный в AstraLinux брандмауэр ufw выключается, взамен ему настраивается Ansible Role: Firewall (iptables).

   Дополнительные материалы:
   Позже, планирую тут добавить информацию по настроенным Ansible playbooks под развёртывание с учётом нюансов СУБД PostgresPro и AstraLinux.

   Если это хоть кого-то заинтересовало, то можете мне поддать пинка в комментариях, чтобы я не затягивал :).

Инструменты:
* CYBERTEC PostgreSQL Configurator — link
* PGTune (https://habr.com/ru/post/217073/) — link
* postgres-checkup — automated PostgreSQL health checks — link
* Explain PostgreSQL (анализ Планов запросов) — link

Исследования:
* Автономное будущее СУБД — https://habr.com/ru/company/oleg-bunin/blog/456580/