Хабрахабр

Кластер pacemaker/corosync без валидола

Представьте ситуацию. Субботний вечер. Вы — администратор PostgreSQL, после тяжелой трудовой недели уехали на дачу за 200 км от любимой работы и чувствуете себя прекрасно… Пока Ваш покой не нарушает смс от системы мониторинга Zabbix. Произошел сбой на сервере СУБД, база данных с текущего момента недоступна. На решение проблемы отводится короткое время. И Вам ничего не остается, как с тяжелым сердцем оседлать служебный гироскутер и мчаться на работу. Увы!

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

Мы расскажем о построении отказоустойчивого кластера СУБД PostgreSQL с помощью программного обеспечения Pacemaker&Corosync. Как бы то ни было, стоит подумать о технологиях отказоустойчивы кластеров с СУБД PostgreSQL.

Отказоустойчивый кластер СУБД PostgreSQL на основе Pacemaker

Сегодня в ИТ-системах уровня «business critical» спрос на широкую функциональность отходит на второй план. На первое место выходит спрос на надежность ИТ-систем. Для отказоустойчивости приходится вводить избыточность компонентов системы. Ими управляет специальное программное обеспечение.

Работает Pacemaker под управлением широкого спектра операционных Unix-систем – RHEL, CentOS, Debian, Ubuntu. Примером такого программного обеспечения является Pacemaker – решение компании ClusterLabs, позволяющее организовать отказоустойчивый кластер (ОУК).

Сфера применения Pacemaker&Corosync значительно шире. Это программное обеспечение не создавали специально для работы с PostgreSQL или других СУБД. Но рассматриваемый в статье кластер PostgreSQL на основе Pacemaker/Corosync, достаточно популярен и подходит по соотношению простоты и надежности к стоимости владения для немалого числа ситуаций. Есть специализированные решения, заточенные под PostgreSQL, например multimaster, входящий в состав Postgres Pro Enterprise (компания Postgres Professional), или Patroni (компания Zalando). Сравнение решений не входит в задачи этой статьи. Все зависит от конкретных задач.

Его главная задача — достижение максимальной доступности ресурсов, которыми он управляет, и защита их от сбоев. Итак: Pacemaker — мозг и по совместительству менеджер ресурсов кластера.

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

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

Итак, перейдем к сущностям Pacemaker.

Сущности pacemaker – узлы кластера Рисунок 1.

Узел (нода, node) кластера представляет собой физический сервер или виртуальную машину с установленным Pacemaker.
Первая и самая важная сущность – это узлы кластера.

То есть, если ресурс postgresql предполагается запускать на узлах node1, node2, и он расположен в нестандартных путях установки, то на этих узлах должны быть одинаковые конфигурационные файлы, пути установки PostgreSQL, и конечно же, одинаковая версия PostgreSQL. Узлы, предназначенные для предоставления одинаковых сервисов, должны иметь одинаковую конфигурацию софта.

Вообще для Pacemaker ресурс — это скрипт, написанный на любом языке. Следующая важная группа сущностей Pacemaker – ресурсы кластера. Скрипт управляет сервисами в операционной системе. Обычно эти скрипты пишутся на bash, но ничто не мешает писать их на Perl, Python, C или даже на PHP. Главное требование к скриптам — уметь выполнять 3 действия: start, stop, monitor и делиться некоторой метаинформацией.

Правда в нашем случае — кластера PostgreSQL — к этим действиям добавляются promote, demote и другие специфичные для PostgreSQL команды.
Примеры ресурсов:

  • IP адрес;
  • сервис, запускаемый в операционной системе;
  • блочное устройство
  • файловая система;
  • другие.

Ресурсы имеют множество атрибутов, которые хранятся в конфигурационном XML-файле Pacemaker'а. Наиболее интересные из них: priority, resource-stickiness, migration-threshold, failure-timeout, multiple-active.
Рассмотрим их более подробно.

Если узлы кластера не одинаковы по производительности или доступности, то можно увеличить приоритет одного из узлов, чтобы он был активным всегда, когда работает. Атрибут priority — приоритет ресурса, который учитывается, если узел исчерпал лимит по количеству активных ресурсов (по умолчанию 0).

Липкость (stickiness) указывает на то, насколько ресурс «хочет» оставаться там, где он есть сейчас. Атрибут resource-stickiness — липкость ресурса (по умолчанию 0). Например, после сбоя узла его ресурсы переходят на другие узлы (точнее — стартуют на других узлах), а после восстановления работоспособности сбойного узла, ресурсы могут вернуться к нему или не вернуться, и это поведение как раз и описывается параметром липкость.

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

Поскольку по умолчанию липкость всех ресурсов 0, то Pacemaker сам располагает ресурсы на узлах «оптимально» на свое усмотрение.

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

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

По умолчанию также этот параметр равен 0, т. Атрибут migration-threshold — сколько отказов должно произойти, чтобы Pacemaker решил, что узел непригоден для данного ресурса и перенёс (мигрировал) его на другой узел. при любом количестве отказов автоматического переноса ресурсов не будет происходить. е.

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

По умолчанию, равен 0. Атрибут failure-timeout — количество секунд после сбоя, до истечения которых Pacemaker считает, что отказа не произошло, и не предпринимает ничего, в частности, не перемещает ресурсы.

Может принимать следующие значения: Атрибут multiple-active – дает указание Pacemaker, что делать с ресурсом, если он оказался запущен более чем на одном узле.

  • block — установить опцию unmanaged, то есть деактивировать
  • stop_only — остановить на всех узлах
  • stop_start — остановить на всех узлах и запустить только на одном (значение по-умолчанию).

По умолчанию, кластер не следит после запуска, жив ли ресурс. Чтобы включить отслеживание ресурса, нужно при создании ресурса добавить операцию monitor, тогда кластер будет следить за состоянием ресурса. Параметр interval этой операции – интервал, с каким делать проверку.

Процесс «перемещения» ресурсов на другой узел происходит быстро и незаметно для конечного клиента. При возникновении отказа на основном узле, Pacemaker «перемещает» ресурсы на другой узел (на самом деле, Pacemaker останавливает ресурсы на сбойнувшем узле и запускает ресурсы на другом).

Группы ресурсов

Ресурсы можно объединять в группы — списки ресурсов, которые должны запускаться в определенном порядке, останавливаться в обратном порядке и исполняться на одном узле.
Все ресурсы группы запускаются на одном узле и запускаются последовательно, согласно порядку в группе. Но нужно учитывать, что при сбое одного из ресурсов группы, вся группа переместится на другой узел.

Например, ресурс PostgreSQL, имеющий тип pgsql, и ресурс Virtual-IP, имеющий тип IPaddr2, могут быть объединены в группу. При выключении какого-либо ресурса группы, все последующие ресурсы группы тоже выключатся.

Последовательность запуска в этой группе такая – сначала запускается PostgreSQL, и при его успешном запуске вслед за ним запускается ресурс Virtual-IP.

Кворум (quorum)

Что такое кворум? Говорят, что кластер имеет кворум при достаточном количестве «живых» узлов кластера. Достаточность количества «живых» узлов определяется по формуле ниже.
n > N/2, где n – количество живых узлов, N – общее количество узлов в кластере.

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

Рисунок 2 – Отказоустойчивый кластер с кворумом

По умолчанию, если нет кворума, Pacemaker останавливает ресурсы. Как вы, наверное, понимаете, в кластере, состоящем из двух узлов, при сбое на одном из 2-х узлов не будет кворума.

Делается это с помощью опции no-quorum-policy=ignore. Чтобы этого избежать, нужно при настройке Pacemaker указать ему, чтобы наличие или отсутствие кворума не учитывалось.

Архитектура Pacemaker

Архитектура Pacemaker представляет собой три уровня:

Рисунок 3 – Уровни Pacemaker

  • Кластеронезависимый уровень – ресурсы и агенты. На этом уровне располагаются сами ресурсы и их скрипты. На рисунке обозначен зеленым цветом.
  • Менеджер ресурсов (Pacemaker), это «мозг» кластера. Он реагирует на события, происходящие в кластере: отказ или присоединение узлов, ресурсов, переход узлов в сервисный режим и другие административные действия. На рисунке обозначен синим цветом.
  • Информационный уровень (Corosync) — на этом уровне осуществляется сетевое взаимодействие узлов, т.е. передача сервисных команд (запуск/остановка ресурсов, узлов и т.д.), обмен информацией о полноте состава кластера (quorum) и т.д. На рисунке он обозначен красным.

Что нужно для работы Pacemaker?

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

  • Синхронизация времени между узлами в кластере
  • Разрешение имен узлов в кластере
  • Стабильность сетевых подключений
  • Наличие у узлов кластера функции управления питанием/перезагрузкой с помощью IPMI(ILO) для организации «фенсинга» (fencing – изоляция) узла.
  • Разрешение прохождения трафика по протоколам и портам

Рассмотрим эти требования подробнее.

Синхронизация времени – нужно, чтобы все узлы имели одно и то же время, обычно это реализуется установкой в локальной сети сервера времени (ntpd).

Если нет возможности установить сервер DNS, нужно на всех узлах кластера внести записи в файл /etc/hosts с именами хостов и IP-адресами. Разрешение имен – реализуется установкой в локальной сети сервера DNS.

Необходимо избавиться от ложных срабатываний. Стабильность сетевых соединений. В таком случае, Pacemaker будет считать сбоем пропадание линка более, чем на 5 секунд. Представьте, что у вас нестабильная локальная сеть, в которой каждые 5-10 секунд происходит потеря линка между узлами кластера и коммутатором. Потом линк восстановился. Пропал линк, ваши ресурсы «переехали». При следующем сбое, Pacemaker «перенесет» ресурсы на следующий узел, и так далее, пока не закончатся все узлы, и возникнет отказ в обслуживании. Но Pacemaker уже считает узел в кластере «сбойнувшим», он уже «перенес» ресурсы на другой узел. Таким образом, из-за ложных срабатываний весь кластер может перестать функционировать.

Необходимо для того, чтобы при сбое узла изолировать его от остальных узлов. Наличие у узлов кластера функции управления питанием/перезагрузкой с помощью IPMI (ILO) для организации «фенсинга». «Фенсинг» исключает ситуацию возникновения split-brain (когда появляются одновременно два узла, выполняющих роль Мастера СУБД PostgreSQL).

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

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

Таблица 1 – Перечень протоколов и портов, необходимых для функционирования ОУК

Также подразумевается, что узлы кластера и интерфейсы управления питанием узлов (IPMI) находятся в разных подсетях. В таблице приведены данные для случая отказоустойчивого кластера из 3-х узлов – node1, node2, node3.

Как видно из таблицы, необходимо обеспечить не только доступность соседних узлов в локальной сети, но и доступность узлов в сети IPMI.

Особенности использования виртуальных машин для ОУК

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

  • fsync. Отказоустойчивость СУБД PostgreSQL очень сильно завязана на возможность синхронизировать запись в постоянное хранилище (диск) и корректное функционирование этого механизма. Разные гипервизоры по-разному реализуют кеширование дисковых операций, некоторые не обеспечивают своевременного сброса данных из кеша в систему хранения.
  • realtime corosync. Процесс corosync в ОУК на основе Pacemaker отвечает за обнаружение сбоев узлов кластера. Для того, чтобы он корректно функционировал, нужно, чтобы ОС гарантированно планировала его исполнение на процессоре (ОС выделяет процессорное время). В связи с этим этот процесс имеет приоритет RT (realtime). В виртуализированной ОС нет возможности гарантировать такое планирование процессов, что приводит к ложным срабатываниям кластерного ПО.
  • фенсинг. В виртуализированной среде механизм фенсинга (fencing) усложняется и становится многоуровневым: на первом уровне нужно реализовать выключение виртуальной машины через гипервизор, а на втором — выключение всего гипервизора (второй уровень срабатывает, когда на первом уровне фенсинга корректно не отработал). К сожалению, у некоторых гипервизоров нет возможности фенсинга. Рекомендуем не использовать виртуальные машины при построении ОУК.

Особенности использования PostgreSQL для ОУК

При использовании PostgreSQL в отказоустойчивых кластерах следует учитывать следующие особенности:

  • Pacemaker при запуске кластера с PostgreSQL размещает файл блокировки LOCK.PSQL на узле с мастером СУБД. Обычно этот файл размещается в директории /var/lib/pgsql/tmp. Это делается с той целью, чтобы при сбое на Мастере запретить в дальнейшем автоматический запуск PostgreSQL. Таким образом, после сбоя на Мастере всегда требуется вмешательство администратора БД для устранения причин сбоя.
  • Поскольку в ОУК используется стандартная схема PostgreSQL Master-Slave, то при определенных сбоях возможна ситуация возникновения двух Мастеров – т.н. split-brain. Например, сбой Потеря сетевой связности между каким-либо из узлов и остальными узлами (о всех видах сбоев см. далее). Во избежание этой ситуации необходимо выполнение двух важных условий при построении отказоустойчивых кластеров:
    • наличие кворума в ОУК. Это означает, что в кластере должно быть не менее 3-х узлов. Причем, необязательно все три узла должны быть с СУБД, достаточно на двух узлах иметь Мастер и Реплику, а третий узел выступает в роли «голосующего».
    • Наличие устройств фенсинга на узлах с СУБД. При возникновении сбоя устройства «фенсинга» изолируют сбойнувший узел – посылают команду на выключение питания или перезагрузку (poweroff или hard-reset).
  • Архивы WAL-ов рекомендуется размещать на общих (shared) устройствах хранения, доступных как Мастеру, так и Реплике. Это позволит упростить процесс восстановления Мастера после сбоя и перевода его в режим Slave.

Команды управления Pacemaker

Приведем некоторые интересные команды управления Pacemaker (на самом деле команд гораздо больше).
Основная утилита управления кластером — pcs. Перед настройкой и первым запуском кластера необходимо один раз произвести авторизацию узлов в кластере.

  • #pcs cluster auth node1 node2 node3 -u hacluster -p 'пароль‘
  • Запуск кластера на всех узлах
  • #pcs cluster start --all

Запуск/останов на одном узле:

  • #pcs cluster start
  • #pcs cluster stop

Просмотр состояния кластера с помощью монитора Corosync:

  • #crm_mon -Afr

Очистка счетчиков сбоев:

  • #pcs resource cleanup

Очистку счетчиков сбоев следует выполнять, когда мы устранили причину сбоя и хотим вернуть узел в состав кластера. В противном случае, если причина сбоя не устранена, то PostgreSQL может не стартовать и данный узел для кластера будет в состоянии HS:alone или DISCONNECT (подробнее о состояниях узла в кластере ниже).

Мониторинг состояния кластера с помощью crm_mon

У Pacemaker есть встроенная утилита мониторинга состояния кластера. Системный администратор может с помощью нее видеть, что происходит в кластере, какие ресурсы на каких узлах расположены в настоящее время.

С помощью команды crm_mon можно контролировать состояние ОУК.

  • #crm_mon –Afr

На скриншоте отчет о состоянии кластера.

Рисунок 4 – Мониторинг состояния кластера с помощью команды crm_mon

Данный узел является мастером.
STREAMING:SYNC/ASYNC – показывает состояние репликации и тип репликации (SYNC/ASYNC)
DISCONNECT – реплика не может подключиться к мастеру. pgsql-status
PRI – состояние мастера
HS:sync – синхронная реплика
HS:async – асинхронная реплика
HS:alone – реплика не может подключится к мастеру
STOP – PostgreSQL остановлен
pgsql-data-status
LATEST – состояние, присущее мастеру. Линия времени меняется каждый раз после выполнения команды promote на узле-реплике. Обычно такое бывает, когда нет соединения от реплики к мастеру.
pgsql-master-baseline
Показывает линию времени. После этого СУБД начинает новый отсчет времени.

Виды сбоев на узлах кластера

От каких видов сбоев защищает отказоустойчивый кластер на базе Pacemaker?

  • Сбой по питанию на текущем мастере или на реплике. Сбой питания, когда пропадает питание и сервер выключается. Это может быть как Мастер, так и одна из Реплик.
  • Сбой процесса PostgreSQL. Сбой основного процесса PostgreSQL – система может завершить аварийно процесс postgres по разным причинам, например, нехватка памяти, либо недостаточное количество файловых дескрипторов, либо превышено максимальное число открытых файлов.
  • Потеря сетевой связности между каким-либо из узлов и остальными узлами. Это сетевая недоступность какого-либо узла. Например, её причиной может быть выход из строя сетевой карты, либо порта коммутатора.
  • Сбой процесса Pacemaker/Corosync. Сбой процесса Corosync/pacemaker аналогично сбою процесса PostgreSQL.

Виды планового обслуживания ОУК

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

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

И роль Мастера назначается всегда синхронной реплике. Важно! Прежде чем производить смену ролей или вывод Мастера из эксплуатации, необходимо с помощью команды #crm_mon –Afr убедиться, что в кластере присутствует синхронная реплика.

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

Автор статьи — Игорь Косенков, инженер Postgres Professional.
Рисунок — Наталья Лёвшина
.

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»