Выбор решения по отказоустойчивости на PostgreSQL

Целью данной статьи является описание возможных способов построения отказоустойчивого кластера на PostgreSQL для систем на базе «1С:Предприятие» по аналогии с группами доступности Always On для MS SQL Server.

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

В рамках данной статьи будут обзорно описаны возможные варианты реализации отказоустойчивого кластера с автоматическим переключением на базе Patroni и Postgres Pro BiHA и инструменты для создания единой точки входа со стороны «1С:Предприятие». Кроме того, будут рассмотрены возможные варианты переключения на резервный сервер вручную, т.к. в автоматическом переключении может не быть особой потребности.

Статья может быть полезна для принятия решения о том, какие инструменты оптимальнее использовать для реализации отказоустойчивости в зависимости от потребностей бизнеса.

Определение потребностей и ценности для бизнеса

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

• требования к доступности системы (допустимое время простоя, размер технологических окон);
• требования к допустимой потере данных при отказе основного сервера;
• необходимость планового переключения на резервный сервер, например для апгрейда оборудования;
• уменьшение риска потери данных за счет дополнительного резервирования;
• возможность отката изменений на произвольный момент времени при использовании реплики с отставанием;
• снижение нагрузки на основной сервер за счет переноса части административных задач и запросов на резервный сервер (резервное копирование, использование механизма 1С для создания копий баз данных).

Ответы на пункты из списка выше в сочетании с анализом критериев выбора, описанных далее, позволят выбрать более подходящий вариант решения по отказоустойчивости с точки зрения затрат и ценности для бизнеса.

Имеются два варианта переключения на резервный сервер: ручное и автоматическое. Основные критерии выбора приведены ниже.

Критерии для выбора решения с ручным переключением на резервный сервер

• Возможно наличие только одного резервного сервера (экономия на ресурсах).
• Не критично влияние человеческого фактора на время переключения.
• Допустимое время простоя является достаточно длительным (сеанс пользователя может быть аварийно завершен, и пользователь не сможет быстро зайти в базу повторно).
• Режим работы системы совпадает с графиком работы администраторов, сопровождающих СУБД.
• Более простая настройка и администрирование, требуется знание только типового механизма репликации Postgres (меньше требований к квалификации администраторов СУБД).

Критерии для выбора решения с автоматическим переключением на резервный сервер

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

Примеры:

• система работает в режиме 24/7, финансовые потери в случае простоя очень велики. В этом случае решение по отказоустойчивости с ручным переключением не сможет закрыть потребности бизнеса в плане доступности системы, т. к. с учетом человеческого фактора время простоя может быть достаточно большим. При этом системы с автоматическим переключением могут восстановить работу системы за достаточно короткое время и без влияния человеческого фактора. Второй вариант будет дороже, но возможно не кардинально за счет того, что современные решения по отказоустойчивости позволяют настраивать упрощенную конфигурацию и, таким образом, экономить на аппаратных ресурсах;
• система предназначена для работы финансового отдела, например, бухгалтерии. Основные требования к системе — это сохранность данных и минимизация потерь при сбоях. При этом не критично, если система будет неработоспособна какое-то время, например, 10–15 минут. Для обеспечения таких требований возможностей физической репликации с ручным переключением будет вполне достаточно и использование более сложных систем с автоматическим переключением может быть избыточным.

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

Сценарии использования

Реплики могут создаваться для различных задач, и их настройка в зависимости от предназначения может меняться. Ниже представлены настройки сценариев горячего резерва (для целей высокой доступности) и оптимальные настройки для переноса части читающей нагрузки на реплику.

Обеспечение высокой доступности

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

При использовании таких решений как Patroni или Postgres Pro BiHA синхронная репликация настраивается автоматически для всего отказоустойчивого кластера путем включения и настройки параметров самих инструментов.

При использовании только типового функционала Postgres, параметры нужно будет настраивать вручную для каждого узла:

• на ведущем сервере нужно включить синхронную репликацию synchronous_commit = on;
• на реплике установить max_standby_streaming_delay в небольшое значение, для того чтобы не откладывать применение журнальных записей и применять их сразу;
• на реплике выключить hot_standby_feedback = off, для того чтобы запросы к ней не могли негативно влиять на основной сервер;
• если запросы к реплике не предполагаются, то можно отключить возможность их выполнения на реплике hot_standby = off.

Исполнение длительных запросов на реплике

Основная цель – перенос на резервный сервер длительных запросов на чтение, например, формирование отчетов с помощью механизма 1С создания копий баз данных.

Механизм копий БД можно настроить на реплику, т.е. обновление реплики будет выполняться средствами PostgreSQL, а не платформой 1С, пример настройки такого решения будет рассмотрена в рамках отдельной статьи.

Конфигурация отказоустойчивого кластера с ручным переключением

В данном случае предполагается ручное переключения на резервный сервер, например, силами администраторов. Самой сложной частью здесь является создание единой точки входа со стороны клиентских приложений, т. е. чтобы «1С: Предприятие» могло без перенастройки подключаться к текущему мастеру. Для этих целей могут использоваться такие инструменты как PgBouncer или HAProxy.

При использовании PgBouncer сервер 1С подключается не к конкретному серверу Postgres, а к PgBouncer, который может быть установлен на том же самом хосте, далее PgBouncer перенаправляет запрос на нужный сервер баз данных. Путь к текущему ведущему серверу задается в файле конфигурации PgBouncer.

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

Настройка сервера 1С для работы с HAProxy аналогичная, т.е. сервер 1С подключается к HAProxy, затем соединения переадресуется на нужный сервер баз данных.

Отличие HAProxy от PgBouncer в том, что HAProxy с помощью проверочного скрипта может автоматически понять к какому серверу нужно подключаться, т.е. не нужно вносить изменения и файл настроек. Но здесь есть один важный момент - во избежание Split Brain (разделения данных в кластере), доступным для подключения должен быть только один мастер, поэтому скрипт в случае доступности нескольких серверов должен это учитывать, например, делать недоступными для подключения оба мастера.

Непосредственно репликация в данном случае реализована стандартными средствами PostgreSQL и каких-то особенностей при ее настройке для работы с «1С: Предприятие» здесь нет.

Конфигурация отказоустойчивого кластера с автоматическим переключением

Для реализации автоматического переключения на резервный сервер можно использовать такие инструменты как Patroni и BiHA, а также HAProxy или расширенный формат строки подключения для создание единой точки входа со стороны «1С: Предприятие».

Отказоустойчивый кластер на основе Patroni

Patroni является внешним сервисом по отношению к Postgres и выполняет роль менеджера кластера. Основной задачей Patroni является обеспечение надежного переключения роли ведущего узла на резервный узел.

Для максимальной доступности СУБД в кластере Patroni необходимо хранить и при необходимости изменять информацию о роли узлов. Для этого используется DCS (Distributed Configuration System), которое реализуется с помощью etcd или consul и представляет собой распределенное хранилище конфигурации ключ/значение.

Ключевые особенности:

• для организации кластера нужно минимум три узла etcd, узлов Patroni может быть два (мастер + реплика). Кроме того, с помощью параметра nofailover можно ограничить переключение на резервный сервер (сервер не сможет стать мастером, но может использоваться как архив актуальной резервной копии);
• необходимо обеспечить отказоустойчивость внешних компонент, поэтому Patroni и etcd устанавливаются на все сервера Postgres. Если узлов Patroni может быть два (мастер и реплика), то узлов распределенного хранилища конфигурации etcd должно быть минимум три, поэтому еще один узел etcd должен быть установлен на сервер 1С, либо отдельный сервер, например виртуальный;
• во избежание ложных срабатываний при переключении на резервные сервера, необходимо чтобы сервера на которых расположены узлы etcd и Patroni не были перегружены и всегда имели запас по производительности;
• поддерживается синхронная и асинхронная репликация, может быть задана в целом для отказоустойчивого кластера;
• удобное управление кластером с помощью утилиты patronictl (просмотр состояния узлов, ручное переключение на мастер, создание реплик, перезагрузка узлов и т.д.).

Отказоустойчивый кластер на основе Postgres Pro BiHA:

BiHA - это расширение Postgres Pro, которое управляется утилитой bihactl и функциями из состава расширения. В сочетании с доработками ядра, SQL интерфейсом и служебным процессом biha-worker, координирующим узлы кластера, BiHA превращает несколько узлов в кластер с физической репликацией Postgres и встроенным аварийным переключением узлов, отказоустойчивостью и автоматическим восстановлением после отказа.

Ключевые особенности:

• для организации кластера нужно минимум три сервера, но третий узел можно настроить как рефери, который используется только в роли наблюдателя для обеспечения кворума, т.е. он не может стать лидером;
• не требуется наличие внешних компонент, для которых также нужно обеспечить отказоустойчивость и доступность;
• удобное управление кластером с помощью утилиты bihactl (инициализация и добавление узлов) и запросам к функциям и представлениям расширения biha (просмотр состояний узлов, ручное переключение на мастер, установка параметров кластера);
• поддержка синхронной и асинхронной репликации, может быть задано для кластера в целом;
• реализовано в Postgres Pro Enterprise, начиная с версии 16.

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

BiHA существует внутри PostgreSQL ,и поэтому вероятность ложных срабатываний ниже, т. к. она может гораздо точнее отлеживать текущее состояние каждого узла кластера.

Создание единой точки входа со стороны 1С

Единая точка входа со стороны 1С при использовании Patroni может быть настроена через HAProxy, используя REST API Patroni (через проверку hhtp-статуса patroni в конфигурационном файле haproxy.cfg)

По аналогии с Patroni для BiHA в качестве единой точки входа можно использовать HAProxy, но для определения текущего состояния узлов кластера нужно использовать возможность HAProxy выполнять в качестве проверки внешний скрипт. Скрипт должен возвращать «0» для разрешенных подключений и «1» для реплик, а также недоступных серверов.

При этом существует и более простой вариант подключения со стороны 1С к отказоустойчивым кластерам Patroni или BiHA, без использования дополнительного программного обеспечения, с помощью формата расширенной строки библиотеки libpq.

Информация из документации по расширенной строке подключения:

В строке подключения можно задать несколько узлов (host), к которым клиент будет пытаться подключиться в заданном порядке. Первый доступный узел становится выбранным для подключения, остальные узлы уже не рассматриваются. Кроме того, могут быть указаны дополнительные параметры подключения, например, target_session_attrs.

1С поддерживает такую возможность в формате ключ/значение, но формат будет несколько отличаться от того, что описан в документации. Для отказоустойчивого кластера, состоящего из трех узлов (pgnode-01, pgnode-02, pgnode-03), в качестве строки подключения к серверу нужно указать:

Параметр target_session_attrs=read-write позволяет выполнять подключение только к серверам, которые находятся в режиме чтения-записи, игнорируя реплики.