Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

Глава 2. Управление кластером

В отказоустойчивом кластере Red Hat задачи управления его элементами и формирования кворума решает менеджер CMAN (Cluster MANager), работающий на всех узлах и реализующий распределенный механизм управления.
CMAN наблюдает за работой кластера, отслеживая поток сообщений между узлами. Если узел не отвечает на протяжении заданного периода времени, CMAN отключит его от кластера и сообщит об этом другим компонентам кластерной инфраструктуры, чтобы они смогли выбрать подходящую линию поведения.
CMAN следит за числом рабочих узлов, исходя из которого формируется кворум: если активно более половины узлов, кворум достигнут. Если кворума нет, работа кластера будет приостановлена. Также кворум поможет принять решение при расщеплении кластера на две равные части и избежать ситуации, в которой обе части будут продолжать работать, считая, что другая часть неработоспособна.

2.1. Кворум

CMAN определяет наличие кворума методом голосования.
По умолчанию каждый узел имеет один голос. Кворум достигается большинством голосов. Так, например, в кластере с 13 узлами кворум будет набран при наличии 7 активных узлов, но при отказе еще одного узла он будет потерян, и кластер не сможет продолжить работу.
Принуждение кворума помогает решить проблему, возникающую при распадении кластера на одинаковые сегменты вследствие потери связи между узлами. Оба сегмента будут продолжать работать и изменять данные независимо друг от друга, что может нарушить целостность данных в файловой системе. Правила кворума помогут выбрать сегмент, которому будет разрешено использовать общее пространство данных.
Такой подход не предотвращает подобные ситуации, но помогает принять решение о том, какой сегмент продолжит работу.
Активность узлов определяется наличием Ethernet-трафика между узлами, а кворум принимается большинством голосов, то есть в кластере должно быть активно 50% узлов плюс 1. Чтобы решить проблему распадения кластера на равные сегменты, можно дополнительно добавить кворумный диск.

Примечание

По умолчанию узел имеет один голос, но это можно изменить и выделить ему произвольное число голосов.

2.1.1. Кворумный диск

При расколе кластера кворумный диск (или раздел) поможет выбрать рабочий сегмент.
Представим кластер с двумя узлами. Если узел A вдруг перестал получать пакеты с узла B, причин этому может быть несколько: узел B вышел из строя; произошла ошибка на уровне сетевого коммутатора или шлюза; ошибка сетевого адаптера узла A; узел B просто сильно загружен (что не исключено в больших кластерах или при нестабильном сетевом соединении).
Узел A не знает, заключается ли причина в узле B или в нем самом. В результате оба узла могут попытаться изолировать друг друга.
В этой ситуации следует убедиться, действительно ли узел B вышел из строя. Для этого и нужен кворумный диск: если узел может записывать данные на этот диск, значит он работоспособен.
В кластере с двумя узлами кворумный диск выступает в роли арбитра: если узел успешно записывает данные на кворумный диск и у него есть доступ к сети, он получает дополнительный голос. Узел, набравший меньше голосов, будет отключен.
Если же узел действительно вышел из строя, он потеряет свой голос, и его можно будет изолировать.
Подробную информацию о кворумных дисках можно найти в руководстве Администрирование кластера.

2.1.2. Арбитражные алгоритмы

Арбитражные алгоритмы используют эвристические правила для проверки работоспособности узлов.
Один из таких алгоритмов использует ping для проверки связи с маршрутизатором, использующим те же каналы подключения, что и остальные узлы кластера. Если узлы не могут связаться друг с другом, выиграет тот, который сможет подключиться к маршрутизатору. Конечно, может оказаться так, что оба узла успешно подключаются к маршрутизатору, — именно поэтому необходимо верно настроить правила изоляции.
Другие алгоритмы используют общий раздел (кворумный диск). Например, clumanager 1.2.x в Red Hat Cluster Suite 3 не ограничивал работу узлов даже при отсутствии подключения к сети при условии, что они могли взаимодействовать через общий раздел.
Более сложные схемы, такие как QDisk (в составе linux-cluster), позволяют настроить эвристические правила для отдельных узлов. Подробную информацию можно найти на справочной странице qdisk(5).
У CMAN нет собственных арбитражных алгоритмов, но он может использовать внешние API, что позволит зарегистрировать кворумное устройство или получить доступ к исходному коду QDisk.
Арбитражный алгоритм требуется:
  • В схемах с двумя узлами, если сетевой путь к устройству изоляции отличается от пути к кластеру.
  • В схемах с двумя узлами, где изоляция неисправных узлов осуществляется на уровне коммутаторов (особенно с резервированием SCSI).
Стоит помнить, что арбитражный алгоритм значительно усложняет конфигурацию кластера.