|
|
|
pacemaker_theory [2013/06/05 15:00]
metallic |
pacemaker_theory [2022/03/25 17:00]
|
| ====== Pacemaker, теория ====== | |
| Pacemaker - менеджер ресурсов кластера(Cluster Resource Manager). Его главная задача - достижение максимальной доступности управляемых им ресурсов и защита их от сбоев как на уровне самих ресурсов, так и на уровне целых узлов кластера. Архитектура pacemaker состоит из трех уровней: | |
| * Кластеронезависимый уровень - на этом уровне располагаются сами ресурсы и их скрипты, которыми они управляются и локальный демон, который скрывает от других уровней различия в стандартах, использованных в скриптах (на рисунке зеленый). | |
| * Менеджер ресурсов(Pacemaker), который предстовляет из себя "мозг". Он регирует на события происходящие в кластере: отказ или присоединение узлов, ресурсов, переход узлов в сервисный режим и другие административные действия. Pacemaker исходя из сложившейся ситуации делает рассчет наиболее оптимального состояния кластера и дает команды на выполнения действий для достижения этого состояния(остановка/перенос ресурсов или узлов). На рисунке обозначен синим. | |
| * Информационный уровень - на этом уровне осуществляется сетевое взаимодействие узлов, т.е. передача сервисных команд(запуск/остановка ресурсов, узлов и т.д.), обмен информацией о полноте состава кластера(quorum)и т.д. На рисунке обозначен красным. Как правило на этом уровне работает Corosync/OpenAIS. | |
| |
| {{ :pacemaker_arch.png?nolink |}} | |
| |
| Сам 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. | |
