Pacemaker, теория

Pacemaker - менеджер ресурсов кластера(Cluster Resource Manager). Его главная задача - достижение максимальной доступности управляемых им ресурсов и защита их от сбоев как на уровне самих ресурсов, так и на уровне целых узлов кластера. Архитектура pacemaker состоит из трех уровней:

Сам pacemaker состоит из четырех ключевых компонентов:

CIB - это база данных в формате XML, которая содержит в себе конфигурацию кластера и состояние всех ресурсов кластера. Эта база автоматически реплицируется на весь кластер и ее можно редактировать с любого узла. Она используется PEngine для вычисления идеального состояния кластера и действий, которые приведут к этому состоянию. Этот список действий затем передается DC(Designated Co-ordinator). DC - это главный CRMd, выбранный путем голосования. Если он вдруг становитс недоступен, быстро выбирается другой. Как только DC получил инструкции(список действий) от PEngine, он начинает их распространять в нужном порядке по всему кластеру. На своем узле инструкции сразу попадают к LRMd(Local Resource Manager daemon), на удаленных узлах через информационный уровень(Corosync) они передаются CRMd, который в свою очередь передает их своим локальным LRMd. LRMd через RA(Resource Agent) выполняет все необходимые действия с ресурсом. Узлы, после выполнения полученных инструкций, возвращают результат обратно DC, тот в свою очередь, основываясь на ожидаемых и реально полученных результатах, либо выполняет следующие инструкции, которые ждали завершения предыдущих, либо останавливает выполнение инструкций, если предыдущие не были выполнены корректно. В этом случае DC снова обращается к PEngine за рассчетом новой конфигурации кластера и получением новых инструкций на основне ранее полученных результатов.

Ресурс с точки зрения pacemaker - это все, что можно заскриптовать. Т.е. любой сервис или программа, которая может управляться через скрипты, начиная с простых сервисов типа apache, ip-адрес, и т.д., заканчивая сложными, которые могут работать в разных режимах(primary/secondary, master/slave), например DRBD. RA - это и есть скрипт, который выполняет запуск/останоку ресурса и может возвращать состояние ресурса, т.е. запущен/остановлен и т.д. Кластеризованные ресурсы никогда не должны управляться вручную, т.е. запускаться/останавливаться, а только через административный интерфейс управления кластером. Также они не должны автоматически запускаться при старте системы, т.е. CRMd сам запускает и останавливает ресурсы, когда и где это надо. Существует несколько стандартов RA скриптов, но самый продвинутый и популярный OCF(Open Cluster Framework)

Иногда бывает необходимо физически выключить(обесточить) узел для предотвращения порчи разделяемых данных, либо для завершения каких-либо процедур восстановления. Для этого у pacemaker есть STONITHd. STONITH - это абривиатура от Shoot-The-Other-Node-In-The-Head. Проще говоря, это механизм, который позволяет кластеру выключать/включать/перезагружать узлы физически, если это необходимо, например узел не отвечает, тогда его ресурсы передаются другим узлам, а сам он отключается или если какой-либо ресурс дал сбой и не может быть перезапущен, тогда выполняются те же действия. Обычно это реализуется через сетевые «пилоты» с удаленным управлением или через специальные платы управления сервером. В pacemaker устройства STONITH конфигурируются как ресурсы и также хранятся в CIB.

Pacemaker не делает никаких предположений о вашем окружении, это позволяет поддерживать практически любые отказоустойчивые конфигурации, включая Активный/Активный, Активный/Пассивный, N+1, N+M, N-to-1 и N-to-N.

Ресурсы бывают трех типов:

Таким образом у ресурса может быть три состояния: Started, Slave или Master(последние два только у Multi-state). С помощью правил(rules) можно настроить поведение ресурсов. Например у ресурса есть такой параметр как липкость(stickness), этот параметр указывает на то, насколько ресурс «хочет» оставаться там, где он есть сейчас. Например после сбоя узла его ресурсы переходят на другие узлы, а после восстановления работоспособности сбойного узла, ресурсы могут вернуться к нему или не вернуться, это поведение как раз и описывается параметром липкость. Т.е. насколько желательно или не желательно(а может не приемлемо), чтобы ресурс вернулся на восстановленный узел. Нежежелательно или неприемлемо это может быть тогда, когда переход ресурса на другой узел влечет за собой некоторый простой в работае ресурса. Липкость ресурса можно воспринимать как «стоимость» простоя ресурса(во время перемещения), чем выше стоимость, тем больше ресурс будет стараться оставаться там, где он есть. По-умолчанию липкость всех ресурсов нулевая, если другое не задано явно. Соответственно pacemaker сам расоплогает ресурсы на узлах «оптимально» с его точки зрения, но это не всегда может быть оптимально с точки зрения администратора. Липкость ресурса можно задать глобально, т.е. дефолтное значение для всех ресурсов или индивидуально. С помощью правил можно задавать разную липкость ресурса в зависимости от времени суток и дня недели, таким образом можно обеспечить переход ресурса на исходный узел в нерабочее время. Еще один вариант использование правил - перемещение ресурсов по узлам в зависимости от времени.

Ресурсы типа примитив(только их) можно объединять в группы(Group). Группа - это набор ресурсов, которые должны выполняться на одном узле и запускаться в указанном порядке(останавливаться в обратном). У группы тоже есть липкость, она равняется сумме липкостей всех активных ресурсов группы. Группой можно управлять как обычным ресурсом, т.е. запускать, останавливать и т.д.

Некоторые ресурсы, например виртуальные машины XEN, могут мигрировать(migrate) на другой узел без потери их состояния, т.е. без остановки работы. Не все ресурсы могут выполнять миграцию, необходимые условия таковы: ресурс должет быть активен и работоспособен на исходном узле и все необходимые условия для запуска ресурса должны быть выполнены на целевом узле. Также RA ресурса должен реализовывать два дополнительных действия: migrate_to и migrate_from. Есть еще другие ограничения: ресурс не должен быть клоном, агент ресурса должен соответствовать стандарту OCF, ресурс не должен прямо или косвенно зависеть от других ресурсов(примитивов или групп), ресурс должен иметь установленный атрибут allow-migrate(по-умолчанию это не так).

Ресурсы имеют множество атрибутов, наиболее интересные из них:

По-умолчанию кластер не обеспечивает работоспособность ресурсов, т.е. не следит после запуска, жив ли ресурс. Чтобы это происходило, нужно добавлять операцию monitor, тогда кластер будет следить за состоянием ресурса. Параметр interval этой операции - интервал с каким делать проверку.

Иногда нужно, чтобы некоторый набор ресурсов выполнялся на одном узле, но не все эти ресурсы являются примитивами, поэтому их нельзя сгруппировать. В этом случае используется colocation - это принуждение к размещению ресурсов на одном узле или наоборот на разных узлах. У colocation есть параметр score, который указывает на то, насколько желательно разместить данный набор ресурсов на одном узле или на разных узлах, соответственно положительное и отрицательное значение(цифра). Но есть специальные значения данного параметра - отрицательная бесконечность и положительная беспонечность(-INFINITY и INFINITY или -inf и inf). При использовании данных ключевых слов, указывается, что ресурсы ОБЯЗАНЫ или НЕ ОБЯЗАНЫ выполнятся на одном узле и никак иначе. При использовании colocation нужно помнить, что порядок указания ресурсов имеет значение, т.к. чтобы знать куда разместить ресурс Б, вначале надо узнать где находится ресурс А. Т.е. вначале запускает ресурс А, исходя из его предпочтений, затем на том же узле размещается ресурс Б. При использовании INFINITY есть некоторые особенности: например указано, что ресурс А и Б обязаны выполняться на узле1 вместе. Но ресурс Б по каким-либо другим ограничениям или принуждениям не может быть запущен на узле1, тогда оба ресурса не будут запущены.

Также может понадобится запускать/останавливать ресурсы в строго заданном порядке, например apache обслуживает сайты, расположенные на файловой системе, соответственно, чтобы apache начал работать, вначале нужно примонтировать файловую систему, а уже потом запускать его. Тут нам поможет ordering - определение зависимости ресурсов друг от друга и определение порядка их запуска(останавливаются они в обратном порядке). Если один из зависимых ресурсов останавливается - останавливаются все. Зависимые ресурсы не обязательно должны выполняться на одном узле.

Ну и наконец location - насколько мы хотим или не хотим, чтобы какой-либо ресурс выполнялся на каком-либо узле. Также, положительное значение - желательно выполнение на данном узле, отрицательное - соответственно не желательно выполнять ресурс на данном узле. Аналогично с INFINITY и -INFINITY, т.е. ресурс должен или не должен выполнятся на указанном узле. Если два узла имеют одинаковый приоритет для ресурса, то кластер сам выберет где запускать ресурс. Есть два подхода определения на каких узлах будут выполнятся какие ресурсы:

При расчете приоритетов, кластер руководствуется следующими формулами:

У кластера есть такое понятие как quorum, насколько кластер является правомочным, т.е. может корректно функционировать. Кластер считает себя правочным при наличии более 50% живых узлов(если быть точным, вычисляется по формуле: кол-во_живых_узлов * 2 > всего_узлов, если уравнение истинно, то считается, что кластер имеет quorum). Если кластер не имеет кворума, то по-умлчанию поведение таково: кластер считает себя развалившимся и прекращает функционирование, т.е. останавливает все связанные с кластером ресурсы. Такое поведение не совсем желаемо в некоторых конфигурациях, например кластер состоящий из двух узлов, в этом случае при выходе из строя одного из двух узлов, весь кластер перестает функционировать, в чем тогда смысл кластера? :-) В таких конфигурация меняют поведение кластера по-умолчанию, указывая, что подобные ситуации(потеря кворума) нужно игнорировать, делается это с помощью опции no-quorum-policy=ignore.

Полезные команды

Тут список некоторых полезных команд администрирования кластера.