Настройка Corosync + Pacemaker для HA-кластера Linux

Кластер Corosync + Pacemaker: где ломается отказоустойчивость

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

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

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

И последнее — ручное восстановление сервиса под нагрузкой. Если изоляция узла не настроена, при расщеплении остаётся гасить половину кластера руками и сверять данные построчно. Собранный правильно кластер такие сценарии отрабатывает сам — разбираем, как это закрывается.

Что даёт управляемая отказоустойчивость: эффект в цифрах

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

Доля отказов, уходящих в автоматику, — главная метрика внедрения. Пока переключение делают руками, каждый инцидент держит сервис недоступным до прихода инженера; после настройки Pacemaker отказ диска, сети или процесса закрывается сам, и заявка в дежурную смену не открывается вовсе. Простой сервиса перестаёт зависеть от того, кто из команды на связи и как быстро он прочитает уведомление.

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

Отдельно измеряем ложные срабатывания. Кворум, интервалы проверок и политики восстановления подбираются так, чтобы кластер не переключался на короткой деградации сети: иначе автоматика вредит сильнее, чем помогает. Отказоустойчивость linux — это баланс между скоростью реакции и устойчивостью к кратковременным сбоям, и в отчёте мы показываем оба числа.

Способы организации отказоустойчивости: сравнение подходов

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

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

Дальше разбираем, как это собирается: конфигурация кворума, политики ограждения и порядок запуска ресурсов — те места, где схема либо держит отказ, либо разваливается сама.

Этапы настройки: от аудита до передачи в эксплуатацию

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

Последовательность работ

1. Обследование. Фиксируем состав узлов, общих томов и сетевых сегментов, собираем требования по времени восстановления для каждого сервиса.
2. Проектирование схемы. Определяем топологию, число колец связи, наличие кворум-устройства, состав ресурсов и правила их размещения по узлам.
3. Подготовка узлов. Синхронизация времени, служебная сеть, аутентификация между узлами, разметка общих хранилищ — база, на которой кластер ведёт себя предсказуемо.
4. Настройка Corosync и Pacemaker. Ресурсы, группы, ограничения порядка запуска, политики восстановления, fencing-агент под конкретную инфраструктуру.
5. Проверка переключений. Прогоняем плановую миграцию, отказ узла, обрыв канала связи и потерю кворума — до того, как это случится в бою.
6. Регламенты и документация. Схема кластера, карта ресурсов, порядок штатного обслуживания узла, сценарии диагностики.
7. Передача в эксплуатацию. Разбираем с командой поведение кластера на стенде, показываем, как читать состояние и что делать при срабатывании fencing.

Конфигурации, схемы и регламенты: комплект передачи

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

• Конфигурации кластера в системе контроля версий: параметры Corosync, описания ресурсов Pacemaker, правила кворума и таймауты — с историей изменений и пометкой, почему выбран каждый параметр.
• Политики доступа: роли администраторов и дежурных, права на перезапуск ресурсов, правку конфигурации и ручной вывод узла в обслуживание.
• Схема отказоустойчивости: какие узлы, диски и сетевые пути резервируют друг друга, где точка отказа оставлена сознательно, как кластер ведёт себя при потере кворума.
• Инструкция для дежурной смены: пошаговые действия при типовых событиях — узел не вернулся после перезагрузки, ресурс переехал не туда, состояния узлов разошлись.
• План восстановления: порядок подъёма кластера с нуля, возврат конфигурации из репозитория, проверка целостности данных после аварийного переключения.
• Регламент проверок: плановые учения с отключением узла, контроль срабатывания защитных механизмов, обновление схем после изменений в инфраструктуре.
• Журнал решений: какие сценарии отработаны на учениях, какие ограничения остались и что сознательно вынесено за границы настройки.

Кейс: как сократили простой при отказе узла

Заказчик — сервис с непрерывным потоком заявок: три узла, реплика базы, балансировщик. Отказоустойчивость формально была — ресурсы описаны в Pacemaker, служба синхронизации следила за доступностью узлов. Но переключение оставалось ручным: дежурный замечал отказ по мониторингу, поднимал сервис на уцелевшем узле и уже потом разбирался с причиной.

Замеры за полгода до переделки: среднее время простоя при отказе узла — 47 минут, из них около десяти уходило на обнаружение, остальное — на ручные шаги с проверкой состояния базы. Руководитель смены тратил на восстановление сервиса примерно час, и часть отказов приходилась на часы пик, когда каждая минута простоя видна клиентам.

Что изменили

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

После перевода схемы в автоматический режим среднее время восстановления сервиса — около 25 секунд: две-три на обнаружение, остальное на передачу ресурсов и подъём приложения. За девять месяцев ни один отказ узла не потребовал ручного вмешательства, а плановые проверки — поочерёдная перезагрузка узлов в непиковые окна — проходят без потери заявок. Отказ узла из происшествия превратился в штатное событие, о котором команда узнаёт из журнала, а не от клиентов.

Чем отличается кластер из двух узлов от трёх?

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

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

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

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

Типовая ошибка — выбирать по принципу «меньше машин, меньше хлопот», не проверив, переживёт ли пара узлов разрыв связи. Обратная ошибка — три узла, загруженные почти под предел: после отказа одного оставшиеся не вытягивают трафик. Считать стоит не машины, а отказы, которые сервис обязан переживать.

Технические сомнения: разбираем частые вопросы

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

Можно ли обойтись без разделяемого хранилища?

Да. Репликацию данных берёт на себя сервис — реплика базы или распределённое хранилище, — а кластер управляет ролью и плавающим адресом. Настраиваем порядок запуска, проверку готовности и запрет поднимать копию на узле с устаревшими данными. Разделяемый том нужен там, где приложение репликацию не умеет.

Как убедиться, что переключение действительно работает?

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

Обсудим задачу: что уточним перед началом работ

Чтобы оценка опиралась на факты, а не на предположения, разбор задачи начинаем с вводных по инфраструктуре и сервисам. Нам нужны не общие слова, а конкретика: сколько узлов планируется, какие сервисы должны переживать отказ узла, за какое время переключение обязано укладываться. По этим данным мы считаем объём работ и состав кластера Corosync + Pacemaker.

Что уточняем на первом разговоре:

• состав сервисов: что переводим в кластер, что обязано работать без перерыва, а что допускает короткий простой;
• число узлов и топология: распределение по стойкам и зонам, отдельный интерфейс под служебный трафик;
• изоляция отказавшего узла: управляемые блоки питания, контроллеры удалённого управления или средства гипервизора — без неё кворум не спасает от разделения;
• хранилище: дисковый массив, репликация на уровне блочного устройства или распределённая файловая система;
• требования к переключению: целевое время восстановления сервиса и допустимая потеря данных;
• текущее состояние: дистрибутив и актуальная ветка, схема сети, мониторинг, доступы, окна для работ.

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