1C:SRE-Suite — разворачиваем отказоустойчивый кластер PostgreSQL на базе Patroni и etcd с помощью Ansible без HAProxy

В предыдущих частях нашего цикла публикаций мы подробно разобрали автоматизацию сборки приложений, развертывание сквозного CI/CD конвейера и безопасное потоковое маскирование баз данных для сред разработки. Все эти шаги позволяют исключить человеческий фактор на этапе подготовки и доставки кода.

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

Важно: все механизмы, описанные в статье, действуют исключительно на уровне целого экземпляра СУБД (физическая потоковая репликация PostgreSQL, штатный механизм pg_rewind, сетевой virtual IP) и являются стандартной, документированной функциональностью PostgreSQL и официально рекомендуемыми параметрами для 1С. Материал не выполняет прямых SQL-обращений к таблицам информационной базы 1С, не изменяет поведение платформы и не подменяет регламентные процедуры платформы SQL-скриптами — вся работа с объектами конфигурации по-прежнему выполняется исключительно средствами сервера 1С:Предприятие.

В четвертой части нашей серии мы перейдем к автоматизации развертывания отказоустойчивой СУБД. Мы детально разберем структуру нашего Ansible-плейбука для автоматического создания трехнодового высокодоступного кластера PostgreSQL под управлением Patroni и etcd, а также покажем, как избавиться от лишнего и ненадежного звена в виде HAProxy с помощью утилиты vip-manager.

Архитектурный выбор: почему мы отказываемся от схемы с HAProxy

Классическая и наиболее распространенная схема построения высокой доступности PostgreSQL, рекомендуемая во многих учебных материалах, включает в себя три ключевых компонента: СУБД с агентами Patroni, распределенный реестр etcd и балансировщик HAProxy в качестве точки входа.

При такой архитектуре HAProxy непрерывно опрашивает REST API агентов Patroni на портах 8008, определяет текущего лидера и перенаправляет на него весь входящий трафик от сервера приложений 1С.

Данная схема имеет два фундаментальных недостатка в контексте эксплуатации систем «1С:Предприятие»:

• Снижение производительности: рабочие процессы 1С не поддерживают разделение транзакционного трафика на чтение и запись на уровне платформы. Весь поток запросов всегда идет на мастер-ноду. В этих условиях HAProxy выполняет роль простого переключателя трафика, который, по результатам тестов в высоконагруженных средах, вносит дополнительную задержку на сетевом уровне в размере от 1% до 10% в зависимости от характеристик оборудования.
• Дополнительная точка отказа: сам узел балансировщика HAProxy становится критическим элементом инфраструктуры. Для обеспечения его отказоустойчивости приходится разворачивать еще одну пару серверов с утилитами Keepalived и виртуальным IP-адресом, что лавинообразно увеличивает сложность администрирования и вероятность ошибок при эксплуатации.

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

🎯 Инженерное решение: виртуальный IP-адрес и vip-manager от CYBERTEC

Для создания единой точки входа без использования внешних балансировщиков мы интегрировали в наш SRE-пакет утилиту vip-manager (мы используем современную версию v5.0.0, переведенную на etcd v3 API).

Принцип работы этой схемы предельно прост и надежен:

1. Для кластера СУБД выделяется один свободный виртуальный IP-адрес (VIP) в локальной сети.
2. Демон vip-manager запускается на каждом сервере баз данных в кластере и непрерывно опрашивает распределенное хранилище etcd по ключу /db/cluster-1c/leader.
3. Узел, который в данный момент признан etcd активным лидером Patroni, получает сигнал от локального vip-manager, и утилита мгновенно вешает виртуальный IP-адрес на свой сетевой интерфейс.
4. В случае аварии лидера и переключения роли мастера на другой узел, vip-manager на упавшем сервере мгновенно удаляет виртуальный адрес со своего интерфейса (в версии v5.0.0 это происходит автоматически даже при полной потере связи с DCS), а на новом мастере локальный демон vip-manager поднимает этот же IP-адрес на сетевом интерфейсе.
5. Сервер приложений 1С всегда подключается к базе данных по единому виртуальному IP-адресу, не замечая физических переключений серверов «под капотом» СУБД.

Такой подход гарантирует прямое сетевое соединение с активным сервером СУБД с нулевыми задержками на проксирование.

📂 Структура автоматизации: обзор Ansible-модуля развертывания

Наш готовый модуль развертывания полностью автоматизирует процесс установки и конфигурации всех элементов ОУК на операционных системах Linux (включая Astra Linux, Ред ОС и Ubuntu). Вся логика плейбука разделена на детерминированные стадии:

1. Подготовка операционной системы

Для корректной работы виртуального IP-адреса на всех серверах СУБД необходимо разрешить демонам связываться с адресами, которые физически еще не подняты на локальных сетевых картах. Плейбук автоматически прописывает параметр ядра net.ipv4.ip_nonlocal_bind = 1 в системный файл /etc/sysctl.conf и немедленно применяет изменения. Также на этом этапе устанавливаются базовые системные утилиты, включая транслятор сетевых имен, менеджер пакетов pip и драйверы СУБД.

2. Развертывание кластера etcd

Плейбук устанавливает службу etcd, генерирует уникальные токены инициализации для каждого сервера и настраивает конфигурационные файлы. Настройки etcd жестко выверены: интервал отправки сигналов активности (heartbeat) зафиксирован на уровне 1000 мс, а таймаут выборов лидера (election timeout) равен 5000 мс. Это исключает ложные срабатывания кластера при кратковременных сетевых колебаниях.

3. Установка СУБД и инициализация Patroni

Наш скрипт останавливает и полностью отключает стандартную системную службу PostgreSQL (например, postgrespro-1c-16), так как отныне управлением жизненным циклом процессов СУБД будет заниматься исключительно агент Patroni.

В конфигурационный шаблон Patroni автоматически закладываются параметры, критически важные для высоконагруженных баз данных 1С:

• max_connections: 250 — для обеспечения бесперебойной работы большого пула фоновых заданий и сеансов пользователей.
• max_locks_per_transaction: 256 — для исключения переполнения таблицы блокировок при проведении тяжелых документов.
• use_pg_rewind: true — для автоматического восстановления согласованности данных при возврате упавшего мастера в кластер в роли реплики.

На уровне СУБД автоматически создаются три выделенные учетные записи с четким разграничением прав: patroni_superuser (администратор), patroni_replication (пользователь репликации) и patroni_rewind (пользователь с точечными правами на системные функции для автоматического отката расходящихся транзакций). Все три учетные записи используются исключительно служебными процессами Patroni для оркестрации кластера (запуск, остановка, переключение ролей, ресинхронизация реплик) — ни одна из них не применяется для чтения или изменения данных информационной базы 1С, эта область по-прежнему остается зоной ответственности платформы.

4. Запуск vip-manager и настройка автозапуска

Ansible скачивает официальный релиз vip-manager, устанавливает его в систему, генерирует конфигурационный файл с указанием целевого виртуального IP-адреса и маски подсети, связывает его с ключами etcd и регистрирует службу в менеджере systemd с настроенным автозапуском.

🛠 Quick Start: практическое руководство по запуску

Весь описанный инфраструктурный код уже оформлен в виде готового плейбука и шаблонов в файле ansible-patroni-ha.txt в нашем репозитории. Чтобы запустить автоматическое развертывание в своей сети, выполните три простых шага:

1. Подготовьте три виртуальные или физические машины с установленной ОС Linux и настройте SSH-доступ по ключам.
2. Отредактируйте файл инвентаря hosts.ini, указав IP-адреса ваших серверов, имя сетевого интерфейса и целевой виртуальный IP-адрес, который станет точкой входа для 1С.
3. Запустите выполнение плейбука:

ansible-playbook -i hosts.ini deploy-cluster.yml

Ansible последовательно пройдет по всем узлам, настроит параметры ядра, соберет кластер etcd, инициализирует Patroni, настроит пользователей базы данных и запустит vip-manager. На выходе вы получите отказоустойчивую среду хранения данных «под ключ».

🤝 Roadmap: развитие инфраструктурного модуля

Развертывание кластера по декларативным сценариям — это важная часть концепции Infrastructure as Code (IaC) нашего открытого проекта 1C:SRE-Suite.

В наших ближайших планах по развитию этого модуля:

• Интеграция автоматического резервного копирования на базе утилиты pg_probackup с хранением архивов в S3-совместимых облачных хранилищах.
• Добавление сценариев оптимизации операционной системы Linux на серверах СУБД (настройка параметров работы с виртуальной памятью, отключение Transparent Huge Pages) — речь идет исключительно о штатных параметрах ядра ОС, а не о внутренних объектах СУБД.
• Разработка плейбуков автоматического обновления версий СУБД PostgreSQL в кластере с нулевым простоем системы (Rolling Updates).

Вы можете найти готовый сборочный файл ansible-patroni-ha.txt со всеми конфигурациями в репозитории проекта. Приглашаем вас тестировать решение на своих стендах, делиться результатами, открывать новые Issue и присылать свои пул-реквесты в наш репозиторий NickScherbakov/1c-sre-suite!