Инструменты пользователя

Инструменты сайта


pacemaker_theory

Различия

Показаны различия между двумя версиями страницы.

Ссылка на это сравнение

Предыдущая версия справа и слева Предыдущая версия
Следующая версия
Предыдущая версия
pacemaker_theory [2013/06/05 17:48]
metallic
pacemaker_theory [2022/03/25 17:00] (текущий)
Строка 41: Строка 41:
 По-умолчанию кластер не обеспечивает работоспособность ресурсов, т.е. не следит после запуска, жив ли ресурс. Чтобы это происходило, нужно добавлять операцию monitor, тогда кластер будет следить за состоянием ресурса. Параметр interval этой операции - интервал с каким делать проверку. По-умолчанию кластер не обеспечивает работоспособность ресурсов, т.е. не следит после запуска, жив ли ресурс. Чтобы это происходило, нужно добавлять операцию monitor, тогда кластер будет следить за состоянием ресурса. Параметр interval этой операции - интервал с каким делать проверку.
  
 +Иногда нужно, чтобы некоторый набор ресурсов выполнялся на одном узле, но не все эти ресурсы являются примитивами, поэтому их нельзя сгруппировать. В этом случае используется **colocation** - это принуждение к размещению ресурсов на одном узле или наоборот на разных узлах. У colocation есть параметр score, который указывает на то, насколько желательно разместить данный набор ресурсов на одном узле или на разных узлах, соответственно положительное и отрицательное значение(цифра). Но есть специальные значения данного параметра - отрицательная бесконечность и положительная беспонечность(-INFINITY и INFINITY или -inf и inf). При использовании данных ключевых слов, указывается, что ресурсы ОБЯЗАНЫ или НЕ ОБЯЗАНЫ выполнятся на одном узле и никак иначе. При использовании colocation нужно помнить, что порядок указания ресурсов имеет значение, т.к. чтобы знать куда разместить ресурс Б, вначале надо узнать где находится ресурс А. Т.е. вначале запускает ресурс А, исходя из его предпочтений, затем на том же узле размещается ресурс Б. При использовании INFINITY есть некоторые особенности: например указано, что ресурс А и Б обязаны выполняться на узле1 вместе. Но ресурс Б по каким-либо другим ограничениям
 +или принуждениям не может быть запущен на узле1, тогда оба ресурса не будут запущены.
 +
 +Также может понадобится запускать/останавливать ресурсы в строго заданном порядке, например apache обслуживает сайты, расположенные на файловой системе, соответственно, чтобы apache начал работать, вначале нужно примонтировать файловую систему, а уже потом запускать его. Тут нам поможет **ordering** - определение зависимости ресурсов друг от друга и определение порядка их запуска(останавливаются они в обратном порядке). Если один из зависимых ресурсов останавливается - останавливаются все. Зависимые ресурсы не обязательно должны выполняться на одном узле.
 +
 +Ну и наконец **location** - насколько мы хотим или не хотим, чтобы какой-либо ресурс выполнялся на каком-либо узле. Также, положительное значение - желательно выполнение на данном узле, отрицательное - соответственно не желательно выполнять ресурс на данном узле. Аналогично с INFINITY и -INFINITY, т.е. ресурс должен или не должен выполнятся на указанном узле. Если два узла имеют одинаковый приоритет для ресурса, то кластер сам выберет где запускать ресурс. Есть два подхода определения на каких узлах будут выполнятся какие ресурсы:
 +  * **opt-out** - создавать все ресурсы с дефолтным расположением на любой доступной ноде, а затем фильтровать не желательные ноды параметром location.
 +  * **opt-in** - т.е. ресурсы по дефолту не могут выполняться ни на каких узлах, а потом разрешать нужные узлы.
 +
 +При расчете приоритетов, кластер руководствуется следующими формулами:
 +  * Any value + INFINITY = INFINITY
 +  * Any value - INFINITY = -INFINITY
 +  * INFINITY - INFINITY = -INFINITY
 +
 +У кластера есть такое понятие как **quorum**, насколько кластер является правомочным, т.е. может корректно функционировать. Кластер считает себя правочным при наличии более 50% живых узлов(если быть точным, вычисляется по формуле: кол-во_живых_узлов * 2 > всего_узлов, если уравнение истинно, то считается, что кластер имеет quorum). Если кластер не имеет кворума, то по-умлчанию поведение таково: кластер считает себя развалившимся и прекращает функционирование, т.е. останавливает все связанные с кластером ресурсы. Такое поведение не совсем желаемо в некоторых конфигурациях, например кластер состоящий из двух узлов, в этом случае при выходе из строя одного из двух узлов, весь кластер перестает функционировать, в чем тогда смысл кластера? :-) В таких конфигурация меняют поведение кластера по-умолчанию, указывая, что подобные ситуации(потеря кворума) нужно игнорировать, делается это с помощью опции no-quorum-policy=ignore.
 +
 +===== Полезные команды =====
 +Тут список некоторых полезных команд администрирования кластера.
 +  * crm resource migrate resource1 node1 - миграция ресурса resource1 на узел node1
 +  * crm resource unmigrate resource1 - отмена миграции и возврат ресурса на исходный узел
 +  * crm resource move resource1 node2 - принудительно переместить ресурс resource1 на node2
 +  * crm resource stop resource1 - остановка ресурса resource1
 +  * crm resource start resource1 - соответственно запуск
 +  * crm node standby node1 - перевод узла в сервисный режим, т.е. все ресурсы с него будут перенесены на другие узлы и с ним можно выполнять любые сервисные задачи, в т.ч. выключать.
 +  * crm node online node1 - возврат узла в нормальное состояние после сервисного режима
 +  * crm node fence node1 - убить (выключить) при помощи STONITH node1
 +  * crm resource cleanup resource1 - удалить счетчики сбоев ресурса resource1 со всех узлов
 +  * crm resource cleanup resource1 node2 - удалить счетчики сбоев ресурса resource1 с узла node2
 +  * crm resource status - просмотр списка ресурсов, запущенных и остановленных
 +  * crm configure delete resource1 - удалить ресурс
 +  * cibadmin --query > config.xml - бекап конфигурации кластера
 +  * cibadmin --replace --xml-file config.xml - восстановление конфигурации из бекапа
 +  * stonith -L - просмотр всех доступных драйверов stonith
 +  * stonith -t type -n - просмотр параметров конкретного драйвера stonith
 +  * crm_mon -1 - смотрим список нод в кластере и их состояние. И текущую главную ноду по результатам голосования (Current DC)
 +  * crm_mon -nr - посмотреть ресурсы, сгруппировав их по узлам, плюс показать не активные ресурсы
 +  * crm_verify -L - проверка конфигурации кластера
 +  * crm configure show - просмотр конфигурации кластера
 +  * crm_simulate -sL - просмотр и симулирование размещения ресурсов по узлам на основе их приоритетов и прочих параметров
pacemaker_theory.1370440097.txt.gz · Последнее изменение: 2022/03/25 17:04 (внешнее изменение)