Прежде чем настраивать Pacemaker, DRBD или GFS2, инженер обязан мыслить категориями отказов: где у системы единственная точка, которая уронит сервис целиком, и что произойдёт в момент, когда узел перестанет отвечать. Этот урок закладывает фундамент всего курса 306. Мы разберём типы кластерных архитектур, механику fencing и кворума, методику поиска единых точек отказа и расчёт целевых метрик RTO, RPO и доступности. Без этой базы любая практическая настройка превращается в копирование чужих конфигов без понимания, почему split-brain убивает данные.
Как это работает
Высокая доступность (HA) - это не магия, а избыточность плюс автоматика переключения. Если ресурс работает на одном узле, и узел падает, кластерный движок должен заметить отказ, принять решение и запустить ресурс в другом месте. Ключевое слово - решение: ошибочное решение опаснее самого отказа.
Архитектуры делятся на две большие группы. В active/passive один узел несёт нагрузку, второй простаивает в горячем резерве и подхватывает сервис при отказе. Это просто и предсказуемо, но половина железа простаивает. В active/active нагрузку несут все узлы одновременно (балансировщик раскидывает запросы), отказ одного снижает ёмкость, но не роняет сервис. Active/active требует, чтобы приложение умело работать в нескольких экземплярах согласованно - не каждый сервис на это способен.
Главная угроза кластера - split-brain. Сеть между узлами рвётся, но оба узла живы. Каждый считает соседа умершим и поднимает у себя общий ресурс - например, монтирует одну и ту же файловую систему или захватывает один плавающий IP. Два узла одновременно пишут в одни данные - это гарантированное разрушение. Защита строится на двух механизмах: кворум и fencing.
Кворум - это правило большинства. Кластер из N узлов разрешает работу только тому разделу, где собралось больше половины голосов. При разрыве сети меньшинство само себя останавливает, потому что понимает - оно не имеет права. Поэтому нечётное число узлов (3, 5) предпочтительнее чётного: при разрыве пополам ни одна половина не получит большинства и встанет весь кластер. Для двух узлов кворум сам по себе не работает, тут нужен арбитр - qdevice или quorum-диск.
Fencing - это физическое отсечение подозрительного узла. STONITH (Shoot The Other Node In The Head) - частный случай: контроллер питания, IPMI или гипервизор принудительно выключает или перезагружает зависший узел. Логика жёсткая: лучше выключить узел, который, может быть, ещё жив, чем позволить ему испортить данные. Кворум решает, кому работать, а fencing гарантирует, что отсечённый узел точно не пишет в общий ресурс. В кластерах с общим хранилищем fencing обязателен - без него Pacemaker откажется запускать ресурсы.
Единая точка отказа (SPOF, single point of failure) - любой элемент, отказ которого роняет весь сервис. Устранение SPOF означает избыточность на каждом уровне: два блока питания и два аплинка на сервере, два коммутатора, два узла, зеркалирование дисков, два независимых канала в интернет, дублирование DNS. Один незарезервированный коммутатор обесценивает кластер из десяти узлов.
Метрики измеряют качество HA в цифрах. RTO (Recovery Time Objective) - максимально допустимое время восстановления сервиса после сбоя. RPO (Recovery Point Objective) - максимально допустимый объём потерянных данных, измеряемый во времени: RPO=0 значит ни одной потерянной транзакции (синхронная репликация), RPO=15 минут значит готовы потерять последние 15 минут. Доступность считают в девятках: 99.9 процента (три девятки) - это около 8.7 часа простоя в год, 99.99 (четыре девятки) - около 52 минут, 99.999 (пять девяток) - около 5.3 минуты в год.
Команды и примеры
Базовый стек на современных системах - corosync (транспорт и кворум) плюс pacemaker (менеджер ресурсов). Установка различается по семействам.
Код: Выделить всё
# Debian 13 / Ubuntu 24.04
apt install pacemaker corosync pcs fence-agents-all
# RHEL 10 / Fedora 41+
dnf install pacemaker corosync pcs fence-agents-all
Код: Выделить всё
pcs status # общая картина: узлы, ресурсы, fencing
pcs quorum status # сколько голосов, есть ли большинство
corosync-quorumtool -s # детально по кворуму на уровне corosync
Код: Выделить всё
pcs property set stonith-enabled=true
pcs stonith create fence-node2 fence_ipmilan \
ip=10.0.0.12 username=admin password=secret \
pcmk_host_list=node2 lanplus=1
Код: Выделить всё
pcs property set no-quorum-policy=stop
Код: Выделить всё
# на отдельной третьей машине-арбитре
dnf install corosync-qnetd # RHEL/Fedora
apt install corosync-qnetd # Debian/Ubuntu
pcs qdevice setup model net --enable --start
# на узлах кластера
pcs quorum device add model net host=arbiter.local algorithm=ffsplit
Частые грабли
- Отключённый fencing (stonith-enabled=false) на проде. Без STONITH при split-brain оба узла поднимут ресурс и разрушат данные. Это первое, что проверяют на аудите.
- Двухузловой кластер без арбитра. При разрыве линка ни один узел не наберёт большинство, либо при two_node=1 оба сочтут себя кворумными - классический путь к split-brain.
- Путаница RTO и RPO. RTO - про время простоя сервиса, RPO - про объём потерянных данных. Синхронная репликация даёт RPO=0, но бьёт по latency.
- Незарезервированный нижний уровень: один коммутатор, один UPS, один аплинк. Кластер узлов есть, а SPOF остался ниже.
- Активный fencing-агент без проверки на реальном железе. IPMI с неверным паролем или недоступный PDU означает, что в час X отсечь узел не выйдет.
- Иллюзия, что active/active всегда лучше. Если приложение не умеет согласованно работать в нескольких экземплярах, вы получите гонки и порчу состояния, а не масштаб.
- Поднимите три виртуалки (node1, node2, node3) в одной сети, установите pacemaker, corosync и pcs.
- Авторизуйте узлы (pcs host auth) и соберите кластер: pcs cluster setup ha-lab node1 node2 node3, затем pcs cluster start --all.
- Посмотрите pcs quorum status - убедитесь, что для большинства нужно 2 из 3 голосов.
- Выключите node3 жёстко (power off ВМ) и проверьте, что кластер сохранил кворум и остался рабочим.
- Остановите ещё и node2 - кластер потеряет кворум; посмотрите, как no-quorum-policy остановит ресурсы на оставшемся узле.
- Настройте fence-агент fence_virt или fence_xvm для своего гипервизора, включите stonith-enabled=true и проверьте pcs stonith status.
- Посчитайте на бумаге, сколько минут простоя в год допускает SLA в 99.95 процента, и сравните с 99.9.
- Чем active/passive отличается от active/active и какие требования active/active предъявляет к приложению?
- Почему кворума недостаточно для защиты общего хранилища и зачем нужен fencing помимо него?
- Что произойдёт при разрыве сети в кластере из двух узлов без арбитра и как это предотвратить?
- В чём разница между RTO и RPO, и какой вид репликации даёт RPO, равный нулю?
- Сколько примерно минут простоя в год допускает доступность 99.99 процента и как вы это считаете?
- Почему нечётное число узлов предпочтительнее чётного с точки зрения кворума?
