Практикум по кластерной приёмке
RHEL HA: потеря связи, кворум и изоляция узла
Разберите поведение RHEL 9.0 при потере связи и кворума. Практикум разделяет решение кворума, фактическую изоляцию узла и проверку приложения после переключения.
Что вы сможете сделать
- Отличать потерю связи от подтверждённой изоляции узла.
- Читать no-quorum-policy как версионное правило поведения ресурсов, а не как универсальную гарантию.
- Составлять проверку отказа: кворум, изоляция старого владельца, запуск роли и контроль операции приложения.
1. Потеря связи — ещё не изоляция
Сначала разделите наблюдение и результат: недоступный по сети узел может продолжать работать с общими данными.
Failover-кластер следит за узлами и управляемыми ролями, но факт потери связи сам по себе не подтверждает состояние доступа узла к данным.
В RHEL 9.0 при потере связи нужен внешний способ ограничить доступ сбойного узла к общим ресурсам или жёстко перезапустить его.
Без такого устройства нельзя надёжно подтвердить освобождение прежних ресурсов; документация Red Hat предупреждает о риске повреждения и потери данных.
2. Отделите кворум от политики ресурсов
Кворум отвечает на вопрос, какой раздел кластера имеет право продолжать управление. no-quorum-policy задаёт действия Pacemaker над ресурсами стороны без кворума.
Кворум задаёт минимальное число голосов, необходимое кластеру для работы; конкретный подсчёт зависит от реализации.
В RHEL 9.0 no-quorum-policy по умолчанию равен stop: Pacemaker останавливает ресурсы затронутого раздела без кворума.
Значение ignore, наоборот, продолжает всё управление ресурсами. Это другой режим, а не синоним значения по умолчанию.
3. Прочитайте режим буквально
Значения no-quorum-policy меняют действия Pacemaker. Их нельзя сокращать до «работает» или «не работает».
freeze продолжает управление, но не восстанавливает ресурсы с узлов вне затронутого раздела.
suicide предписывает изолировать все узлы затронутого раздела кластера.
demote при потере кворума понижает ресурсы в роли Promoted и останавливает остальные.
4. Принимайте цепочку целиком
Безопасное переключение — это не один зелёный статус. Нужно проверить изоляцию, действие кластера и результат приложения.
Во время изоляции RHEL 9.0 не разрешает другие кластерные операции; штатная работа продолжается после завершения изоляции либо возвращения перезагруженного узла.
Red Hat требует тестировать настроенное устройство изоляции: устройство и агент, вызов из конфигурации кластера и затем фактический сценарий отказа.
Запуск кластерной роли ещё не подтверждает операцию клиента: после переключения отдельно проверяют данные, зависимости и согласованное действие приложения.
Проверьте инженерное мышление
Вопросы проверяют не память на аббревиатуры, а умение не делать лишних выводов.
Следующий шаг
Сформулируйте задачу и уточните требования к своей системе.
Подготовить состав проектаОткроется черновик вопроса. Отправьте его, когда будете готовы.
Источники курса
Ссылки приведены один раз для всего курса, чтобы не мешать чтению каждого тезиса.
- Официальная документация
Failover Clustering in Windows Server and Azure Local
Microsoft · Microsoft Learn, обновлено 25 июня 2025 года
Описывает nodes, clustered roles, health monitoring, failover и quorum в failover cluster.
Открыть первоисточник - Официальная документация
Red Hat Enterprise Linux 9.0 Configuring and managing high availability clusters
Red Hat · Red Hat Enterprise Linux 9.0
Проверены 1.2.1–1.2.2, 10.2–10.5 и таблица 23.1. Страницы с fencing/quorum и no-quorum-policy просмотрены изображением; сведения ограничены RHEL 9.0.
Открыть первоисточник - Официальная документация
Contingency Planning Guide for Federal Information Systems
National Institute of Standards and Technology · NIST SP 800-34 Rev. 1, update от 11 ноября 2010 года
Первичный planning guide по BIA, recovery strategies, RPO/RTO, contingency и disaster recovery plans.
Открыть первоисточник