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

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


pacemaker_theory

Это старая версия документа!


Pacemaker, теория

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

  • Кластеронезависимый уровень - на этом уровне располагаются сами ресурсы и их скрипты, которыми они управляются и локальный демон, который скрывает от других уровней различия в стандартах, использованных в скриптах (на рисунке зеленый).
  • Менеджер ресурсов(Pacemaker), который предстовляет из себя «мозг». Он регирует на события происходящие в кластере: отказ или присоединение узлов, ресурсов, переход узлов в сервисный режим и другие административные действия. Pacemaker исходя из сложившейся ситуации делает рассчет наиболее оптимального состояния кластера и дает команды на выполнения действий для достижения этого состояния(остановка/перенос ресурсов или узлов). На рисунке обозначен синим.
  • Информационный уровень - на этом уровне осуществляется сетевое взаимодействие узлов, т.е. передача сервисных команд(запуск/остановка ресурсов, узлов и т.д.), обмен информацией о полноте состава кластера(quorum)и т.д. На рисунке обозначен красным. Как правило на этом уровне работает Corosync/OpenAIS.

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

  • CIB(Cluster Information Base)
  • CRMd(Cluster Resource Management daemon)
  • PEngine (PE or Policy Engine)
  • STONITHd

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.

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

  • Primitive - самый простой тип ресурса, например apache или ip-адрес.
  • Clone - ресурс, который может выполняться на нескольких узлах, т.е. чтобы не создавать несоклько однотипных примитивов на разных узлах, используют клоны. Бывает трех подвидов: Anonymous, Globally Unique, Stateful. Anonymous - самый простой, это копии ресурсов с одинаковой функциональностью, они полностью идентичны на всех узлах, поэтому на каждом узле может выполняться не более одного такого клона. Globally Unique - клоны такого типа имеют разную сущность на узлах. Копия запущенная на одном узле не может быть идентична копии запущенной на другом узле. Даже две копии запущенные на одном узле не будут идентичны. Stateful - это специальный тип клона, описан ниже.
  • Multi-state - специальный тип Clone-ресурса(его расширение). У этих ресурсов каждый экземпляр ресурса(сущность) может быть только в двух состояниях: Master и Slave. Кол-во сущностей, которое может функционировать в режиме Master конфигурируется(параметр master-max), по-умолчанию 1. У ресурсов такого типа есть два действия: demote и promote, т.е. повышение и понижение. Вначале, после запуска ресурса, все сущности находятся в состоянии Slave и только потом выполняется promote для одной(или нескольких) из сущностей. С помощью дополнителных параметров можно указывать предпочтительную ноду для роли Master.

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

pacemaker_theory.1370433509.txt.gz · Последнее изменение: 2022/03/25 17:04 (внешнее изменение)