Отказоустойчивость кластера: предотвращение split-brain с fencing и quorum

Почему без fencing и quorum ваш кластер не отказоустойчив

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

Кластерные системы, такие как Pacemaker с Corosync, Kubernetes для stateful-приложений или отказоустойчивые конфигурации TrueNAS, полагаются на консенсус между узлами. Когда этот консенсус нарушается, возникает катастрофическое состояние, известное как split-brain (разделение мозга).

Что такое split-brain и почему он разрушает данные

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

Технически split-brain возникает при сетевом сбое, который разделяет кластер на две или более изолированные группы узлов. Каждая группа, не видя другую, считает себя единственной рабочей частью кластера и берет под контроль общие ресурсы: диски, IP-адреса, базы данных.

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

Fencing (STONITH) - единственный способ гарантированной изоляции

Остановки служб или soft-reboot недостаточно для гарантии изоляции. «Зависший» узел может продолжать работать с общими дисками на уровне контроллера или ядра ОС. Решение - STONITH (Shoot The Other Node In The Head).

Цель fencing - гарантировать, что узел, признанный неисправным, физически или логически не сможет работать с общими ресурсами. Существует два основных типа:

• Аппаратное fencing: прямое воздействие на физический сервер. Примеры: отключение питания через IPMI, iDRAC, iLO или управляемый PDU (источник бесперебойного питания APC). Агент fence_ipmilan.
• Программное fencing: изоляция на уровне платформы виртуализации или облака. Примеры: выключение виртуальной машины через API гипервизора (KVM, VMware), остановка облачного инстанса (AWS EC2, Azure VM). Агенты fence_virt, fence_vmware_soap, fence_aws.

Без работающего fencing механизм quorum не может безопасно принять решение о перераспределении ресурсов.

Quorum - механизм коллективного принятия решений

Quorum (кворум) - это правило большинства голосов в кластере. Его основная задача - разрешать операции, влияющие на общее состояние, только той части кластера, которая имеет большинство голосов и, следовательно, вероятно, обладает актуальной информацией.

Правило простое: операции разрешены только при наличии quorum. Рассмотрим кластер из 3 узлов, где quorum = 2 (большинство от 3).

1. Если один узел теряет связь, два оставшихся имеют quorum (2 из 3). Они могут безопасно выполнить fencing отключенного узла и продолжить работу.
2. Если кластер распадается на группы 2 и 1, группа из двух узлов имеет quorum и продолжает работу. Одиночный узел не имеет quorum (1 из 3) и должен полностью остановить все кластерные службы, чтобы не вызвать split-brain.

Quorum и fencing работают в тандеме: quorum решает, *кто* имеет право действовать, а fencing гарантирует, что те, кто права не имеют, не смогут помешать.

Как работает защита: последовательность событий при отказе узла

Понимание последовательности событий критично для диагностики и уверенности в работе системы. Вот как кластер на Pacemaker/Corosync реагирует на сбой.

1. Детекция сбоя. Corosync постоянно обменивается heartbeat-сообщениями между узлами. Если узел не отвечает в течение заданного таймаута (например, token и consensus в corosync.conf), он считается недоступным. Pacemaker также мониторит состояние ресурсов (демонов, IP-адресов, файловых систем).
2. Проверка quorum. Немедленно после детекции потери связи каждый узел вычисляет, имеет ли его сегмент кластера кворум. Этот расчет основан на конфигурации expected_votes в Corosync.
3. Принятие решения. Узлы в сегменте, обладающем quorum, инициируют голосование. Решение о необходимости fencing принимает кластерный менеджер Pacemaker на узле с ролью Designated Coordinator (DC).
4. Выполнение fencing. Pacemaker запускает сконфигурированный fencing-агент (STONITH resource) с целевым параметром - адресом отказавшего узла. Агент выполняет команду изоляции (power off, stop instance).
5. Подтверждение и восстановление. После получения подтверждения об успешном fencing (агент возвращает код 0) Pacemaker отмечает узел как очищенный (stonith'd). Затем он пересчитывает конфигурацию и запускает ресурсы, которые были на отказавшем узле, на одном из оставшихся здоровых узлов.

Если fencing не удается (таймаут, ошибка аутентификации), Pacemaker будет повторять попытку согласно политике stonith-max-attempts. До успешного fencing ресурсы не будут перемещены.

Детекция сбоя: что и как отслеживает кластер

Основной механизм - обмен пакетами multicast или unicast через Corosync. Параметры token и consensus в наносекундах определяют, как быстро кластер объявляет узел мертвым. Слишком короткие таймауты приводят к ложным срабатываниям из-за временной загрузки сети или CPU. Слишком длинные - увеличивают время восстановления (RTO).

Принятие решения: роль quorum и кластерного менеджера

Решение принимает Pacemaker на узле, избранном в роль DC. Этот узел координирует все изменения в кластере. Если DC оказывается в сегменте без quorum, он теряет право принимать решения, и кластерная работа в этом сегменте останавливается.

Выполнение fencing: от команды до подтверждения

Pacemaker вызывает fencing-агент как отдельный процесс, передавая ему параметры из конфигурации ресурса STONITH. Агент должен вернуть код 0 при успехе. Весь процесс контролируется таймаутом stonith-timeout. Превышение таймаута трактуется как ошибка.

Практическая настройка fencing в Pacemaker/Corosync

Перейдем к конкретным командам. Предполагается, что базовый кластер Pacemaker/Corosync уже развернут. Если вам нужна полная инструкция по развертыванию, ознакомьтесь с проверенным руководством по развертыванию высокодоступного кластера с Corosync и Pacemaker.

Выбор fencing-агента для вашей инфраструктуры

Определите среду и установите соответствующий пакет fence-агента. Вот основные варианты:

• Физические серверы (IPMI): fence-agents-ipmilan. Универсальный агент для управления по IPMI LAN.
• Гипервизор KVM/QEMU (libvirt): fence-agents-virsh. Использует fence_virt или fence_xvm.
• VMware vSphere: fence-agents-vmware-soap. Требует доступ к SOAP API vCenter или ESXi.
• Microsoft Azure: fence-agents-azure-arm. Использует Azure Resource Manager API.
• Amazon AWS: fence-agents-aws. Останавливает (stop) EC2 инстанс через API.

Конфигурация fencing устройства с помощью pcs (практический пример)

Используем утилиту pcs для управления кластером. Пример для сервера с IPMI.

# Создаем STONITH ресурс для узла с именем node1
pcs stonith create fence-node1 fence_ipmilan \
    pcmk_host_list="node1" \
    ipaddr="10.0.1.101" \
    login="ADMIN" \
    passwd="secret_password" \
    lanplus="1" \
    action="off" \
    op monitor interval="60s"

# Создаем аналогичный ресурс для node2
pcs stonith create fence-node2 fence_ipmilan \
    pcmk_host_list="node2" \
    ipaddr="10.0.1.102" \
    login="ADMIN" \
    passwd="secret_password" \
    lanplus="1" \
    action="off" \
    op monitor interval="60s"

# Разрешаем узлам выполнять fencing друг против друга
pcs constraint location fence-node1 avoids node1
pcs constraint location fence-node2 avoids node2

Для автоматизации развертывания подобных сложных конфигураций можно использовать готовые playbook Ansible для кластеров Pacemaker.

Настройка таймаутов и политик для надежной работы

Неправильные таймауты - частая причина проблем.

# Устанавливаем общий таймаут на операцию fencing (по умолчанию может быть 60s)
pcs property set stonith-timeout=120s

# Устанавливаем количество попыток перед тем, как объявить fencing неудачным
pcs property set stonith-max-attempts=3

# Устанавливаем таймаут для мониторинга fencing-устройства
pcs resource update fence-node1 op monitor interval=60s timeout=120s

Рассчитывайте stonith-timeout, учитывая: время сети до устройства управления (IPMI, гипервизора), время выполнения команды (выключение питания может занимать 10-30 секунд), запас на случай задержек. Для облачных API добавляйте дополнительное время (иногда 30-60 секунд).

Тестирование fencing: как проверить без риска для производства

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

# Тестовый вызов fencing-агента без реального воздействия на узел
pcs stonith test fence-node1

# Просмотр результатов теста в журналах
journalctl -u pcsd -f
# Или
pcs status --full

Убедитесь, что в логах виден успешный вызов агента и симуляция возвращает код успеха. Только после этого можно планировать безопасное тестирование на реальном узле в maintenance-окне, предварительно остановив на нем все критичные сервисы.

Настройка и управление quorum

Quorum в Corosync настраивается автоматически, но требует понимания для корректировки.

Базовые параметры quorum в Corosync

Основной параметр в /etc/corosync/corosync.conf:

quorum {
    provider: corosync_votequorum
    expected_votes: 3
}

expected_votes обычно равно количеству узлов в кластере. Quorum рассчитывается как floor(expected_votes/2) + 1. Для 3 узлов quorum = 2.

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

Это самый рискованный сценарий. Два узла не могут иметь классическое большинство (51% = 1.5, округляется до 2). Простое отключение quorum (no-quorum-policy=ignore) смертельно опасно - оно разрешает split-brain.

Безопасное решение - дать кластеру возможность получить «внешний голос». Используется ресурс ping для проверки связи с внешним устройством, например, маршрутизатором или шлюзом по умолчанию.

# Создаем ресурс ping для проверки связи с маршрутизатором 192.168.1.1
pcs resource create ping-check ocf:pacemaker:ping \
    dampen=5s \
    multiplier=1000 \
    host_list="192.168.1.1" \
    op monitor interval=10s timeout=5s

# Настраиваем votequorum на использование ping
pcs quorum device add model net \
    algorithm=ffsplit \
    host=192.168.1.1 \
    ping_interval=2s \
    ping_timeout=1s

# Включаем auto tie-breaker для двухузлового кластера
pcs quorum device update model net algorithm=ffsplit tie_breaker=lowest

Логика: если узел теряет связь и с другим узлом, и с внешним маршрутизатором, он точно находится в изоляции и должен остановиться.

Диагностика состояния quorum: ключевые команды

# Показать статус кластера и quorum
pcs status
# В выводе ищите строку:
# Quorum:      Yes/No

# Детальная информация о quorum
corosync-quorumtool -s
# Покажет expected_votes, total_votes, quorum, активные узлы.

# Альтернативный вид
crm_mon -1

Адаптация под вашу платформу: VMware, KVM, облака, Kubernetes

Гипервизоры (VMware vSphere, KVM/QEMU, Hyper-V)

VMware: используйте fence_vmware_soap. Требуется учетная запись с правами на выключение ВМ. Параметры: ip (vCenter/ESXi), ssl, login, passwd, port (название ВМ), vmware_soap_port (обычно 443).

KVM/QEMU: fence_virt (работает через libvirt) или fence_xvm (через Xen/Hypervisor). Требуется доступ к socket libvirtd или SSH. Параметр port - это имя виртуальной машины.

Облачные провайдеры (AWS EC2, Azure VM)

AWS: агент fence_aws. Использует IAM credentials (ключ/секрет) или IAM роль. Действие action="off" останавливает (stop) инстанс, что сохраняет данные на EBS. Критично настроить правильные IAM политики.

Azure: агент fence_azure_arm. Использует Service Principal (tenant ID, client ID, client secret). Действие action="off" деаллоцирует VM. Таймауты API Azure могут быть значительными.

Kubernetes и операторы высокой доступности

В Kubernetes нет встроенного аналога STONITH, но проблема split-brain актуальна для StatefulSets с общими томами (RWM) или кластерных приложений (PostgreSQL, Redis).

Решения:

• Использование операторов, которые реализуют логику fencing. Например, PostgreSQL Operator (Crunchy Data, Zalando) или Patroni имеют встроенные механизмы лидерства и изоляции неисправных подов.
• Использование механизмов контроля жизненного цикла узлов (Node Controller). Если узел Kubernetes помечается как NotReady, можно запускать custom-скрипт (через DaemonSet), который выполняет логику изоляции приложения на этом узле.
• Интеграция с внешним кластером Pacemaker для управления виртуальными IP или внешними ресурсами.

Системы хранения (TrueNAS HA, кластерные файловые системы)

TrueNAS CORE/Enterprise: в режиме HA используется встроенная реализация fencing через IPMI или управление гипервизором. Конфигурация выполняется через веб-интерфейс TrueNAS. Важно обеспечить выделенную сеть для heartbeat и управления.

Ceph: использует собственный протокол консенсуса (Paxos-подобный) через мониторов. Понятие «fencing» заменяется маркировкой OSD как down/out и их перераспределением. Потеря quorum мониторов (большинства) останавливает операции записи в кластер.

GlusterFS: полагается на внешние механизмы quorum и fencing на уровне узлов. Рекомендуется разворачивать поверх Pacemaker/Corosync или использовать мониторинг и скрипты ручного вмешательства.

Шпаргалка и лучшие практики

Сводная таблица fencing-агентов

5 обязательных правил для безопасного кластера

1. Всегда тестируйте fencing в изолированной среде перед внедрением в production. Используйте pcs stonith test и плановые окна обслуживания.
2. Никогда не отключайте quorum в рабочем кластере. Для двух узлов используйте механизм внешнего голоса (ping) с auto_tie_breaker.
3. Предпочитайте аппаратное fencing программному, если это возможно. Прямое управление питанием надежнее, чем вызов API гипервизора, который может зависнуть.
4. Настройте мониторинг состояния fencing-устройств и quorum в вашей системе (Zabbix, Prometheus). Оповещение о потере quorum - это критический инцидент.
5. Имейте письменный план восстановления после fencing. Что делать, если узел был отключен, но проблема была временной? Как безопасно вернуть его в кластер.

Безопасность кластера - часть общей безопасности инфраструктуры. Для комплексного подхода изучите практическое руководство по харденингу Linux-сервера.

Диагностика: если fencing не работает

Последовательность проверок:

1. Проверьте связь с fencing-устройством. Для IPMI: ping <ipaddr>. Для облака/гипервизора: проверьте доступность API и учетные данные.
2. Проверьте логи fencing-агента. Включите отладку: pcs stonith test fence-node1 --debug. Смотрите journalctl -u pcsd или /var/log/pacemaker.log.
3. Проверьте таймауты Pacemaker. Убедитесь, что stonith-timeout больше времени реального выполнения команды fencing.
4. Проверьте права и учетные данные. Агент должен иметь достаточные привилегии для выполнения действия (например, права Power Control для IPMI, IAM политики в AWS).

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

pcs status --full
pcs stonith show --full
pcs property list
corosync-quorumtool -s
crm_verify -L -V

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

Работа с кластерами высокой доступности часто связана с обработкой инцидентов, в том числе DDoS-атак на управляющие интерфейсы. Актуальные методы защиты описаны в сравнении методов защиты от DDoS атак в 2026 году.

Для автоматизации работы с различными ИИ-моделями, которые могут помочь в анализе логов или генерации скриптов для управления инфраструктурой, рассмотрите использование агрегатора AiTunnel, который предоставляет единый API к более чем 200 моделям.