Из-за чего автоматическое переключение на резервный узел без fencing может вызвать split-brain?
Fencing предотвращает работу старого узла после переключения роли. Без него при сетевом разделении старый и резервный узлы могут одновременно считать себя активными и принимать записи, что приводит к split-brain, конфликтующим изменениям и потенциальной потере данных.
Высокодоступные системы используют автоматический failover, чтобы заменить неисправный узел резервным без ручного вмешательства. Исходная проблема состоит в том, что отказ узла трудно отличить от временной недоступности по сети: узел может быть жив, но не видеть кластер или управляющий компонент.
Одного решения о назначении нового лидера недостаточно. Нужно ещё гарантировать, что прежний лидер больше не сможет изменять общее состояние.
Предположим, основной узел потерял связь с управляющим сервисом, но продолжает работать и обслуживать клиентов. Резервный узел не получает от него подтверждений, объявляет его неисправным и становится новым основным.
Если старый узел не изолирован, оба узла могут принимать записи. Клиенты, подключённые к разным узлам, увидят разные версии данных, а последующая синхронизация не сможет однозначно определить, какая запись является правильной.
Ошибочная проверка состояния особенно опасна при сетевом разделении: отсутствие ответа не доказывает остановку процесса. Перезапуск или назначение нового лидера без блокировки старого лишь увеличивает вероятность конфликта.
Fencing — это принудительное лишение старого узла возможности обслуживать запросы или изменять данные до того, как резервный узел получит активную роль. На практике применяют отключение питания через управляющее оборудование, отзыв доступа к общему хранилищу, блокировку сетевых портов или механизм аренды с подтверждением владельца.
Типичная безопасная последовательность такова:
Quorum помогает принять решение о лидерстве только при наличии большинства участников, но сам по себе не всегда изолирует старый узел. Поэтому для систем с общим хранилищем или внешними клиентами quorum часто дополняют fencing.
Аренда, или lease, ограничивает срок действия роли лидера. Она снижает риск длительной работы устаревшего узла, однако требует корректно настроенных таймаутов и надёжного механизма продления. Если часы, сеть или хранилище ведут себя неожиданно, одной аренды может быть недостаточно.
Fencing должен быть безопаснее самой операции failover: ошибочное отключение исправного узла ухудшит доступность, но отсутствие fencing может нарушить целостность данных. Поэтому проверяют не только доступность узла, но и возможность гарантированно запретить ему запись.
В кластере базы данных основной узел потерял связь с управляющим сервисом из-за сетевого сбоя, но сохранил доступ к клиентам и диску. Резервный узел был автоматически повышен до основного, после чего две группы клиентов начали записывать заказы в разные узлы.
Рассматривались три варианта. Увеличение таймаута уменьшало число ложных переключений, но продлевало простой при настоящем отказе. Только quorum не гарантировал остановку старого узла, который всё ещё имел доступ к данным. Ручное переключение было надёжнее, но не соответствовало требованию автоматического восстановления.
Выбрали quorum вместе с fencing через управляющий контроллер питания. Новый лидер становился активным только после подтверждения отключения старого узла. Это увеличило время failover, зато исключило одновременную запись двух лидеров; при неполадке контроллера система предпочитала временно оставаться недоступной, а не рисковать целостностью данных.
Достаточно ли quorum, чтобы полностью исключить split-brain?
Нет, не всегда. Quorum предотвращает одновременное получение права лидерства несколькими группами участников, если все решения проходят через единый механизм большинства. Но узел, потерявший связь с quorum, может продолжать принимать клиентские запросы и писать в общее хранилище.
Поэтому quorum отвечает за согласованное принятие решения, а fencing — за физическое или логическое прекращение действий старого лидера. В критичных системах эти механизмы дополняют друг друга.
Почему остановка процесса на старом узле не всегда является достаточным fencing?
Команда остановки может не выполниться, процесс может зависнуть, управляющий агент может потерять связь, а сам узел может продолжить работу из-за ошибки операционной системы или виртуализации. Кроме того, между отправкой команды и фактической остановкой остаётся окно, в котором старый узел способен выполнить запись.
Более надёжный fencing выполняется внешним доверенным механизмом: отключением питания, блокировкой доступа к хранилищу или сетевой изоляцией. Важно, чтобы новый лидер не считался безопасно активным до подтверждения результата этой операции.
Почему безопасная система иногда предпочитает недоступность риску потери данных?
При невозможности подтвердить, что старый лидер изолирован, автоматическое продолжение работы может создать две независимые истины. Восстановление доступности после этого потребует разрешать конфликты, откатывать записи или терять часть подтверждённых операций.
Поэтому для систем, где важнее целостность, применяют принцип fail-closed: при сомнении узел не принимает записи. Это увеличивает время простоя и может ухудшить доступность, но ограничивает радиус повреждения данных. Выбор зависит от SLO, допустимой модели потери данных и бизнес-цены простоя.