Голоса выбирают сторону, которой разрешено продолжать работу. Подтверждённая изоляция исключает конфликтующее исполнение старого владельца; достаточный кворум не превращается в результат команды.
Кластеризация и доступность
Fencing (изоляция узла)
Определение
Fencing, или изоляция узла, — принудительное отключение неисправного участника кластера от общего ресурса: ему снимают питание либо перекрывают сеть и доступ к хранилищу. Так защищают общие данные при раздвоении кластера (split brain), но отправленная команда ещё не доказывает, что узел действительно потерял доступ.
Также ищут: Fencing · STONITH · изоляция узла · cluster fencing
Зачем это знать
Потеря служебной связи не доказывает остановку записи. Перед запуском нового владельца нужно знать, какой узел и ресурс исключены, доступен ли механизм изоляции и чем подтверждён его результат.
Связи из словаря
Карта понятия
Fencing (изоляция узла)
Доказательная часть
Что подтверждено
Изоляция узла лишает его возможности выполнять ресурсы: например, отключает питание или перекрывает необходимые сетевые пути и доступ к хранилищу.
Граница применимости: Конкретные агенты, устройства, пути управления и способ подтверждения зависят от платформы.
Изоляция узла защищает общие данные от неисправного узла и раздвоения кластера, не позволяя двум конфликтующим экземплярам ресурса работать одновременно.
Граница применимости: Правило важно для ресурсов, у которых не может быть двух владельцев; сервисы без состояния могут использовать другие гарантии согласованности.
Отправленная команда изоляции не является подтверждением её успешного результата. Для ресурса с одним владельцем решение о новом запуске связывают с поддержанной гарантией, что прежний владелец больше не может конфликтовать с ним.
Граница применимости: Редакторская граница между запросом и результатом изоляции Pacemaker и передачей кластерной роли. Способ подтверждения зависит от агента и платформы; один универсальный ответ устройства не задаётся.
Учебный узел потерял только служебную связь с кластером, но его путь к общему хранилищу остаётся рабочим. Потеря этой связи не доказывает прекращение записи и не является подтверждённой изоляцией ресурса с одним владельцем.
Граница применимости: Редакторский сценарий с раздельными служебным и рабочим путями. Не утверждается, что любой сетевой разрыв сохраняет запись: доступ к общему ресурсу задан явно.
В учебной схеме единственный путь команды изоляции проходит через отказавший коммутатор, а остановка целевого узла не подтверждена. Наличие настроенного агента ещё не доказывает возможность завершить изоляцию в этом сценарии.
Граница применимости: Редакторская проверка общей зависимости механизма защиты. Другого независимого канала или уже доказанного отключения узла нет; конкретный альтернативный способ не предписывается.
В Proxmox VE узел с HA-управляемыми гостями, который не восстановил связь Corosync с кворумной частью кластера, самоизолируется перезапуском. Стек HA использует кластерные блокировки и watchdog, чтобы оставшаяся часть кластера восстанавливала гостей после изоляции прежнего узла.
Граница применимости: Proxmox VE HA для гостей под управлением службы высокой доступности. Точную задержку, выбранный сторожевой таймер и пригодность общего хранилища проверяют в фактической конфигурации. Механизм не следует отождествлять с политикой потери кворума Pacemaker или переносить на любую виртуальную машину.
Граница терминов
Не путать
У механизма изоляции есть собственный путь управления и общие зависимости. Их доступность нужно проверить для того отказа, после которого защита потребуется.
Перед спецификацией
Что проверить
- Укажите ресурс и условие единственного владельца.
- Свяжите команду с точным целевым узлом.
- Проверьте, какие пути или возможности исключает выбранный механизм.
- Отделите потерю служебной связи от потери доступа к данным.
- Проверьте доступность пути управления после выбранного отказа.
- Получите предусмотренное платформой подтверждение результата.
- В согласованном испытании проверьте безопасный запуск нового владельца.
Открытые основания
Первоисточники
- Failover Clustering in Windows Server and Azure Local
Описывает nodes, clustered roles, health monitoring, failover и quorum в failover cluster.
Утверждения: 03
- Failover Clustering topologies
Определяет fault domains и показывает границу single-rack HA, stretch cluster и multi-site DR.
- Proxmox VE High Availability — ha-manager.adoc
Полностью открыт файл из официального зеркала. Проверены How It Works (LRM/CRM locks и watchdog), Fencing, How Proxmox VE Fences, Configure Hardware Watchdog, Recover Fenced Services и Fencing & Watchdog Status. URL ветки не закреплён на commit, поэтому при следующей редакции источник перечитывают.
Утверждения: 06