Что такое pacemaker linux

Настройка кластера Pacemaker на CentOS 7

Подготовка серверов

Обновляем систему.

Настраиваем время.

Необходимо, чтобы на всех нодах было одинаковое время.

Устанавливаем утилиту для синхронизации даты и времени:

yum install ntpdate

Настраиваем синхронизацию по расписанию:

0 0 * * * /usr/sbin/ntpdate ru.pool.ntp.org

Выставляем нужный часовой пояс:

\cp /usr/share/zoneinfo/Europe/Moscow /etc/localtime

* в моем примере московское время.

Настройка брандмауэра.

Выполняется следующими 2-я командами:

firewall-cmd —permanent —add-service=high-availability

Установка пакетов для работы с кластером

Установка выполняется на всех узлах следующей командой:

yum install pacemaker pcs resource-agents

Если возникнут проблемы, читаем подробную инструкцию по установке Pacemaker.

Задаем пароль для учетной записи hacluster, которая была создана автоматически при установке pacemaker:

Разрешаем сервис pcsd и запускаем его:

systemctl enable pcsd

systemctl start pcsd

Сборка кластера

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

Первым делом, авторизовываемся на серверах следующей командой:

pcs cluster auth node1 node2 -u hacluster

* где node1 и node2 — имена серверов, hacluster — служебная учетная запись (создана автоматически при установке пакетов).

pcs cluster setup —force —name NLB node1 node2

* где NLB — название для кластера; node1 и node2 — серверы, которые должны входить в кластер.

После успешного выполнения команды мы увидим, примерно, следующее:

Synchronizing pcsd certificates on nodes node1, node2.
node2: Success
node1: Success

* также, будет создан конфигурационный файл /etc/corosync/corosync.conf.

Разрешаем автозапуск и запускаем созданный кластер:

pcs cluster enable —all

pcs cluster start —all

* опция —all говорит, что необходимо выполнить команду для всех нод, к которым мы подключились (вместо этой опции можно перечислить ноды вручную).

При использовании 2-х нод (как в данном примере) отключаем stonith (нужен для «добивания» серверов, которые не смогли полностью завершить рабочие процессы) и кворум:

pcs property set stonith-enabled=false

pcs property set no-quorum-policy=ignore

Просмотреть состояние можно командой:

Настройка виртуального IP

Рассмотрим самый распространенный вариант использования Pacemaker. Он заключается в использовании виртуального IP-адреса, который будет назначаться активному узлу кластера.

Для этого создаем ресурс командой:

pcs resource create virtual_ip ocf:heartbeat:IPaddr2 ip=192.168.0.15 cidr_netmask=24 op monitor interval=60s

* где virtual_ip — название ресурса (может быть любым); 192.168.0.15 — виртуальный IP, который будет назначен кластеру; 24 — префикс сети (соответствует маске 255.255.255.0); 60s — критическое время простоя, которое будет означать недоступность узла.

Мы должны увидеть, примерно такую строку:

virtual_ip (ocf::heartbeat:IPaddr2): Started node1

Для проверки, перезагружаем активную ноду (node1) командой:

Через небольшой промежуток времени должен смениться узел с virtual_ip:

virtual_ip (ocf::heartbeat:IPaddr2): Started node2

Для смены активной ноды ресурса, вводим команду:

pcs resource move virtual_ip node1

Отказоустойчивость сервисов

Кластеризация по виртуальному IP-адресу позволит обеспечить высокую доступность на уровне работы сервера. Но если необходимо более тонкая настройка, позволяющая менять активную ноду при отказе службы, выполняем действия, описанные ниже.

Список всех поддерживаемых сервисов можно посмотреть командой:

crm_resource —list-agents ocf

Разберем кластеризацию на базе postfix.

Подключаемся к кластеру и создаем следующий ресурс:

pcs cluster auth node1 node2 -u hacluster

pcs resource create postfix ocf:heartbeat:postfix op monitor interval=30s timeout=60s

Удаление ноды

При необходимости исключить одну из нод кластера, выполняем следующую команду:

pcs cluster node remove node_name

* где node_name — имя узла, который хотим удалить.

Источник

Linux HA на основе Pacemaker

Pacemaker

Согласно официальной документации, Pacemaker — это менеджер ресурсов кластера со следующими основными фичами:

• Обнаружение и восстановление сбоев на уровне узлов и сервисов;
• Независимость от подсистемы хранения: общий диск не требуется;
• Независимость от типов ресурсов: все что может быть заскриптовано, может быть кластеризовано;
• Поддержка STONITH (Shoot-The-Other-Node-In-The-Head) — лекарства от Split-Brain ;);
• Поддержка кластеров любого размера;
• Поддержка и кворумных и ресурсозависимых кластеров;
• Поддержка практически любой избыточной конфигурации;
• Автоматическая репликация конфига на все узлы кластера;
• Возможность задания порядка запуска ресурсов, а также их совместимости на одном узле;
• Поддержка расширенных типов ресурсов: клонов (запущен на множестве узлов) и с дополнительными состояниями (master/slave и т.п.);
• Единый кластерный шелл (crm), унифицированный, скриптующийся.

Проект кроме собственно своих демонов, поддерживающих конфиг кластера и указанный выше шелл, также использует сторонние, тот же heartbeat и corosync. Я лично (собственно авторы тоже) рекомендую использовать corosync. В общем-то он поддерживает скрипты от heartbeat, поэтому проблем возникнуть не должно.

Установка

На RHEL/CentOS нет ничего проще.

Затем редаектируем /etc/corosync/corosync.conf (там есть corosync.conf.sample) и стартуем.

Да, крайне необходимо иметь правильно настроенный DNS, чтобы резолвились в обе стороны все узлы.

Как добавить узлы? Нет ничего проще, ставим Pacemaker, копируем /etc/corosync/corosync.conf и /etc/ais/authkeys (если настраивали) и запускаем. Узел будет автоматически включен в кластер. Конфиг кластера будет также автоматически скопирован.

Если узел вышел из строя и вы заменили железо? Тоже самое, даем новому узлу то же имя, копируем конфиги и стартуем. Лепота.

Конфигурация

Конфигурация кластера представляет собой простой XML. Однако вручную его править НЕЛЬЗЯ. Все изменения конфига подвергаются автоматическому версионированнию, узлы получают не весь конфиг разом, а только дельты от того, о чем они знают. Т.е. если узел вышел из строя, а в это время вы поменяли конфиг, то когда он вернется, он получит все изменения, которые вы сделали.

Для работы с конфигом можно использовать либо cibadmin, либо собственно сам шелл crm. Посмотреть конфиг можно например так:

Кроме собственно опций кластера, конфигурированию подлежат также:

• Узлы (Nodes);
• Ресурсы (Resources);
• Связи (Constraints).

Как добавлять узлы мы уже разобрались. Удаляются узлы не многим сложнее: останавливаем corosync на узле, а затем удаляем узел из конфига.

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

Ресурсы

Что есть ресурс с точки зрения corosync? Все, что может быть заскриптовано! Обычно скрипты пишутся на bash, но ничто не мешает вам писать их на Perl, Python или даже на C. Все, что требуется от скрипта, это выполнять 3 действия: start, stop и monitor. В общем-то скрипты должны соответствовать LSB (Linux Standard Base) или OCF (Open Cluster Framework) — последнее несколько расширяет LSB, требуя также передачи параметров через переменные окружения с особым названием.

Как мы видим, довольно много уже готовых агентов (Resource Agents). Впрочем, написать самому новый тоже вряд ли составит большого труда.

При создании ресурса нам потребуется задать его класс, тип, провайдера и собственно имя с дополнительными параметрами. В списке выше: ocf — класс, heartbeat — провайдер, IPaddr — тип агента.

Ресурсы поддерживают множество дополнительных параметров, вроде привязки к узлу (resource-stickiness), роли по умолчанию (started, stoped, master) и т.д. Есть возможности по созданию групп ресурсов, клонов (работающих на нескольких узлах) и т.п.

Связи

Начнем с того, что любая связь имеет свой вес — целое число в пределах от -INFINITY до +INFINITY. При этом если вес связи ± INFINITY, то она считается жесткой, в противном случае — мягкой, т.е. если веса других связей окажутся выше, она может быть проигнорирована.

Связи определяют привязку ресурсов к узлу (location), порядок запуска ресурсов (ordering) и совместное их проживание на узле (colocation).

Здесь мы создали еще один ресурс — WebSite, задали совместное проживание его с ClusterIP (кстати, -INFINITY означало бы, что ресурсы НЕ должны находиться на одном узле), определили порядок запуска: сначала ClusterIP, потом WebSite, а потом задали, что WebSite очень желательно находиться на узле pcmk-1, с весом 50. При задании порядка также можно указать, можно ли стартовать ресурсы параллельно или делать это последовательно.

В общем таким образом можно строить довольно сложные цепочки зависимостей ресурсов. Все становиться еще интереснее, если учесть, что можно задавать более сложные правила (rules), срабатывающие, например, только в определенное время суток или в зависимости от состояния компонентов кластера.

Кстати, для облегчения понимая авторы наделили Pacemaker возможностью строить графики в формате Graphviz — см. утилиту ptest.

Источник

Техническая база знаний

Материал от эксперта

Corosync + Pacemaker

Портировать стаью для CentOS

Общие сведения

В информационной сети кластер представлен тремя IP адресами:

• IP адрес управляющего интерфейса резервируемого сервера — используется для управления MASTER сервером в аварийном режиме работы кластера.
• IP адрес управляющего интерфейса резервирующего сервера — используется для управления SLAVE сервером в штатном режиме работы кластера.
• «Виртуальный IP адрес» кластера — используется всем клиентское оборудование (IP телефоны) для работы с системой вне зависимости от режима работы кластера. Данный адрес мигрирует в автоматическом режиме с одной системы на другую в зависимости от режима работы кластера.

Каждый сервер (MASTER и SLAVE) должен иметь своё уникальное имя в сети. Это имя определяется командой `hostname` в терминале ОС. На каждом сервере в файле /etc/hosts должна присутствовать одна и та же пара строк, каждая их которых содержит IP адрес сервера в кластере и его сетевое имя. Например, если сервер MASTER имеет в сети имя ‘node-a’ с управляющим интерфейсом ‘192.168.1.101’, а SLAVE сервер имеет в сети имя ‘node-b’ с управляющим интерфейсом ‘192.168.1.102’, то как на MASTER, так и на SLAVE сервере в файле /etc/hosts должны присутствовать следующие записи:

Для синхронизации работы кластера в сети, на узлах должен быть разрешен приём трафика, направляемый по multicast адресам. Ядро кластера будет рассылать пакеты в рамках multicast «сети» по порту 5405. Таким образом, необходимо заранее разрешить приём трафика по указанному порту, а также порту меньшем на единицу; а также разрешить обмен трафиком по протоколу IGMP (http://serverfault.com/questions/418634/secure-iptables-rules-for-corosync):

Установка и настройка ядра кластеризации

Перед началом установки необходимо настроить окружение ОС. В частности,

В качестве ядра сервиса кластеризации будем использовать Corosync + Pacemaker. На момент написано документации, в репозитории CentOS присутствовали следующие версии пакетов:

• corosync 1.4.7-2.el6
• pacemaker 1.1.12-8.el6_7.2

К сожалению, в CentOS по-умолчанию не доступен crmsh, поэтому его нужно скачивать из репозитория OpenSUSE. После того как crmsh будет установлен, репозиторий SUSE лучше отключить:

Задаём переменные окружения, которые будут использоваться при дальнейшей настройке. Обращаю внимание, что переменные будут использоваться только при настройке, в работе самого сервиса кластеризации используются значения заданных переменных:

Далее необходимо задать адрес сети, в которой будет работать corosync. Это должен быть адрес сетевого интерфейса, который соединяет два сервера напрямую. Последний октет адреса должен отличаться. Получить адрес можно так (строка универсальна как для master, так и для slave сервера):

Если в результате выполнения команды был отображен адрес сети, которая установлена между серверами напрямую, то вышеуказанную команду можно использовать для установки переменной:

Отобразить полученные значения переменных можно выполнив следующую команду:

Необходимо проверить полученный адрес сети ais_addr с реальный требуемым, т.к. в некоторых случая команда получения адреса сети возвращает не верный результат (например, для сети /22). Проверить адрес сети можно любым сетевым калькулятором, например тут: http://ip-calculator.ru/ Если адрес сети будет указан не верно, узлы не найдут друг друга в составе кластера.

Далее мы создам файл конфигурации Corosync:

Необходимо разрешить сервису corosync работать с правами root. Для этого надо добавить в конфигурационный файл соответствующие строки, выполнив следующую команду:

Также необходимо указать, что corosync должен работать с Pacemaker-ом, но НЕ должен его запускать самостоятельно. Если файл /etc/corosync/service.d/pacemaker существует, то нужно убедиться, что в нём значение параметра ver: 1.

Если файл /etc/corosync/service.d/pacemaker отсутствует, то в конфигурационный файл /etc/corosync/corosync.conf, добавлением соответствующие параметры:

Параметр ver может принимать значения:

Еще раз повторюсь, указанная выше конфигурация для pacemaker может присутствовать в файле /etc/corosync/service.d/pacemaker. Необходимо избежать дублирования данных параметров.

Полученный конфигурационный файл можно смело копировать на вторую ноду (или выполнить все те же самые команды на втором узле).

После того как конфигурация присутствует на двух узлах, можно запустить Corosync и Pacemaker на MASTER сервере. Порядок в данном случае важен.

Только после того, как сервисы будут запущены, необходимо выполнить те же самые команды на SLAVE сервере.

Проверить состояние работы кластера можно выполнив команду. Не имеет значения, на каком узле была выполнена команда.

В результате вывода оба узла должны быть помечены как ONLINE.

Настройка менеджера ресурсов

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

Общие параметры

В первую очередь, необходимо выключить опцию STONITH в конфигурации менеджера ресурсов. Для этого на любом сервере нужно выполнить команду в Linux.

Результат выполнения команды внесёт изменение в конфигурацию менеджера ресурсов как на MASTER, так и на SLAVE сервере автоматически.

Можно посмотреть текущую конфигурацию pacemaker, выполнив команду

В результате вывода должны быть строки со следующими значениями параметров:

Если эти параметры не присутствуют в конфигурации, их нужно добавить по аналогии с параметром STONITH выше. Но, на самом деле, в конфигурации по-умолчанию опции есть и ничего добавлять самому не нужно, однако их наличие очень важно.

Типы ресурсов

• lsb — это init скрипты. При описании ресурса LSB указываются только общие для всех ресурсов параметр.
• ocf — это скрипты ядра кластера. При описании указываются индивидуальные параметры для каждого ресурса. Набор параметров всегда разный. В интернете есть подробное описание параметров.

Структура ресурсов

В кластере ресурсы могут быть объединены в группы, между ресурсами могут быть установлены зависимости, порядок запуска и много чего еще. Ниже представлена схема для упрощенного понимания структуры объединения ресурсов кластера серверов телефонии на базе DRBD. Отображены не все ресурсы, но суть такая:

В виду того, что ресурсы и их объединения зависят друг от друга, необходимо соблюдать порядок их создания в конфигурации менеджера ресурсов. Для того чтобы понимать, что от чего зависит (опять же, не все связи отражены, но всё же), ниже представлена схема последовательности определения ресурсов в кластере.

Ресурс DRBD

Если выполнять команды crm configure , то они применяются на кластере моментально. Однако для ресурсов, использующих DRBD важна доступность самого DRBD, поэтому конфигураить их лучше всего в теневом инстансе. Для этого надо зайти в консоль управления кластером `crm` и выполнить команд для создания теневой конфигурации (позволит работать с конфигурацией до того, как будет применена в кластер):

Изменение crm(live) на crm(drbd) говорит о том, что работа ведётся в теневом инстансе.

Далее необходимо описать ресурс `drbd_res` (имя ресурса) и конфигурацию `master_slave` (`drbd_master_slave` — имя конфигурации master_slave) для DRBD, после чего применить конфигурацию в `live` инстанс:

drbd_res — имя ресурса кластера, которым мы будем оперировать в дальнейшем.

drbd_resource — указывает имя ресурса DRBD, который описан в соответствующем конфигурационном файле /etc/drbd.d/

Для конфигурации ресурса drbd используется ocf скрип, который обеспечивает переключение primary/secondary режимов сервиса DRBD узлов кластера в автоматическом режиме.

Конфигурация master-slave обеспечивает работу сервиса DRBD в состоянии primary только на одном узле в кластере.

Ресурс FileSystem

После того как ресурс DRBD определён, можно указать подключение раздела drbd к файловой системе, для этого будет также использоваться соответствующий ocf скрипт. Кстати, данный ocf скрипт можно использовать не только для раздела drbd, но и для любого другого раздела.

Подключение раздела к файловой системе тесно зависит от того, какой узел на текущий момент является DRBD primary. Поэтому необходимо создать привязку ресурса filesystem к активному DRBD узлу. Если этого не сделать, ресурс drbd может быть активен на одном узле, а примонтирование раздела к файловой системы произойдёт на другом узле, что привёдет к ошибке. Поэтому необходимо также в теневом инстансе создать описание ресурсов и конфигурации, а затем применить инстанс в текущую конфигурацию кластера.

• fs_res — название ресурса подключение раздела DRBD к файловой системе;
• device — указывает на блочный девайс раздела drbd
• directory — указывает на директорию, куда нужно монтировать раздел
• fstype — указывает на тип файловой системы, которой размечен раздел drbd

Конфигурация расположения ресурса вместе с другим ресурсом тесно связана с конфигурацией описания порядка загрузки ресусов. Т.е. мало того, что ресурсы должны находится вместе (colocation), необходимо также указать, в каком порядке их следует запускать (order). Здесь:

fs_drbd_colo — название конфигурации colocaion;

drbd_master_slave:Master — состояние конфигурации master_slave равное Master, к которой привязывается расположение ресурса. ;

fs_after_drbd — название конфигурации order;

drbd_master_slave:promote — состояние конфигурции master_slave равное promote (i.e. the DRBD resource is promoted to master before the filesystem resource is started and any mount occurs);

fs_res:start — состояние ресурса start.

В данной конйигурации правило INFINITY и mandatory (говорят, тоже самое, что и INFINITY) указывает, что ресурсы должны располагаться на одном узле без исключения.

ВАЖНО: после описания конфигурации она была применена в текущую конфигурацию кластера.

Согласен, мы уже описали colocation и order правила, и включили сюда только ресурс filesystem, в то время как у нас должна быть группа ресурсов в том числе и последовательность запуска внутри группы. Но т.к. других ресурсов еще не описано, а конфигурация drbd неразрывно связана с конфигурацией файловой системы, мы описали правила расположения уже сейчас. В дальнейшем, когда мы опишем группу ресурсов и порядок загрузки ресурсов в группе, произойдёт автоматическая конвертация правил в конфигурции, таким образом мы сможем достичь последовательной загрузки ресрусов в зависимости от состояния кластера.

Ресурс Виртуального IP адреса

При переключении кластера из штатного режима функционирования в аварийный режим и обратно, между узлами должен мигрировать виртуальный IP адрес кластера, чтобы устройства в сети могли продолжать работать. Для этого необходимо описат соответствующий ресурс. Ресурс может быть описан двумя путями: через ocf (предпочтительней) в качестве alias и через lsb отдельным интерфейсом. Отдельный интерфейс менее желателен, т.к. сложнее контролировать доступность его подключения.

В качестве alias

Для создания виртуального IP адреса в качестве alias на существующем интерфейсе (предпочтительный вариант), необходимо добавит ocf ресурс IPaddr2, выполнив следующую команду:

Где обязательными параметрами кластера ресурса являются:

• ip — указывается выделенный виртуальный IP адрес кластера;
• cidr_netmask — маска подсети выделенного виртуального IP адреса кластера;
• nic — имя сетевого интерфейса, на котором указан должен быть создан alias.

Отдельным интерфейсом

На основе ресурса lsb

Ресурс динамического маршрута

При переключении кластера можно также добавлять маршруты. В этом есть необходимость только в том случае, если статические маршруты, отличающиеся от маршрутов по-умолчанию, назначены на виртуальный интерфейс кластера, сеть которого отличается от сети управляющего интерфейса. Например, управляющая сеть имеет адрес 192.168.1.0/24, а сеть виртуального интерфейса имеет адрес 192.168.2.0/24. В противном случае, статические маршруты могут быть добавлены в конфигурацию сетевого интерфейса в операционной системе (см. настройка сетевых интерфейсов).

Для каждого маршрута нужно добавить отдельный ocf ресурс. Для это необходимо выполнить следующую команду:

Где обязательными параметрами ресурса являются:

• destination — сеть или узел назначения, до которого прописывается маршрут. Может быть указан как ‘default’, так и конкретный IP адрес узла в сети, так и сеть в формате CIDR, т.е. с суффиксом /24, например.
• gateway — адрес шлюза, используемого для доступа к указанному назначению.
• device — сетевой интерфейс в системе (устройство), на котором должен быть прописан маршрут (не обязательный параметр)
• source — IP адрс сервера, с которого будут осуществляться подключения до указанного `destination` (не обязательный параметр, но указывается вместе с `gateway` или `device`)
• table — таблица, в которой должен присутствовать маршрут. Также может быть указан, но не является обязательным.

Ресурсы сервисов

Проще всего описываются ресурсы сервисов, для которых есть init скрипты. Достаточно для каждого сервиса прописать LSB ресурс. В частности, для кластера на DRBD мы описываем ресурсы MySQL, Asterisk, Apache. Однако, перед добавлением ресурсов в кластер необходимо остановить сервисы, иначе менеджер ресурсов в кластере выдаст ошибку при добавлении, из-за того, что сервис работает. Для этого, сначала производится остановка сервисов:

Затем добавляются сами ресурсы. Для этого нужно выполнить по одной команде создания ресурса для каждого init скрипта:

После добавления ресурсов, сервисы сразу будут запущены.

Также могут быть добавлены ресурсы tftp и rsync:

Создание группы ресурсов

После того как в конфигурации кластера определены ресурсы под все необходимые нам сервисы, ресурсы можно объединить в группы. Группа ресурсов — это комбинированое описание совместного расположения и порядка загрузки (colocation + order). Совместное расположение, понятно, определяется тем, какие ресурсы входят в группу. Порядок загрузки определяется тем, в какой последовательности они вписаны в группу. Итак, следует соблюдать следующую последовательность загрузки ресурсов:

1. Виртуальный IP адрес кластера.
2. Динамические маршруты.
3. Файловые системы.
4. MySQL
5. Asterisk
6. Apache
7. TFTPd
8. Rsyncd
9. .

Например, для кластера на DRBD достаточно прописать следующую конфигурацию группы:

В данном случае конфигурация группы будет называться TelephonyGroup (группа ресурсов для телефонии).

При выполнении данной команды, конфигурации order и colocation, созданные ранее на этапе описания ресурса файловой системы, в состав которых входят `fs_res`, будут автоматически заменены на конфигурации с `TelephonyGroup`, о чем сообщит система.

Ресурс проверки подключения

Во избежание рассинхронизации информации на узлах кластера, активный узел должен проверять, подключен ли он к сети, не потерял ли он физическое подключение. В случае, если узел понимает, что подключение к сети потеряно, он должен перейти в аварийный режим и остановить все активные ресурсы.

Для этого активный узел в должен периодически проверять, отвечают ли ему на ICMP запросы контрольные сетевые узлы. Данную операцию выполняет ocf ресурс ping. Однако ресурс сам по себе не обеспечивает переключение режима кластера или изменение статуса ресурса, зато ресурс изменяет значение переменной ядра кластера, на основе которой ядро может принять решение о текущем состоянии. Таким образом для определения, имеется ли физическое подключение узла к ЛВС, т.е. доступен ли контрольный узел в сети, необходимо определить следующий ресурс:

• multiplier — множетель переменной для каждого хоста.
• host_list — список контрольных узлов в сети, разделенных пробелом.
• name — имя переменной, которой будут задаваться значения в результате расчета, используя множетель.
• dampen — задержка перед внесением изменений в окружение кластера, указанная в секундах. Используется для того, чтобы ресурсы не прыгали между узлами, когда подключение теряется на очень маленькое время.

Данная конфигурация пингует хост. Каждый хост оценивается в 111 очков. Суммарное значение для каждой ноды хранится в переменной «ping_net». Эти значения можно и нужно использовать при определении места расположения ресурса.

Клон ресурса

Для того, чтобы данный ресурс был запущен одновременно на двух нодах, необходимо создать его клон. Клон задаётся соответствующим ресурсом:

Таким образом будет создан ресурс Cloned-Ping, который будет запускать ClusterPing на обоих узлах вне зависимости от их состояния в кластере. Данее необходимо указать менеджеру ресурсов, как работать со статусом подключения на основе данных от ресурса ClusterPing.

Расположение и приоритизация узлов

Чаще всего необходимо запретить узлу запускать на себе ресурсы, если узел определил, что он не имеет связи с контрольным узлом в сети. Т.е. данная конфигурация применима, если доступность определяется только по одному контрольному узлу в сети. Для это необходимо определить ресурса, предписывающий размещение ресурсов на основании значения переменной «ping_net»:

Данный ресурс NoConnectionNode, предписывающий расположение, запрещает размещать ресурс ClusterIP на узле, где пинг меньше либо равен 0 (lte — less then or equal) или не запущен ресурс пинга. Достигается это за счет того, что узел с отсутствующим подключением получает «»минус бесконечность» очков».

Для того, чтобы ресурс вернулся на резервируемую ноду после возвращения подключения, необходимо определить ресурс, предписывающий расположение, устанавливающий 50 очков резервируемому узлу по-умолчанию.

Данный ресурс PreferedNode, предписывает расположение ресурса ClusterIP на узле ‘node-a’, устанавливая узлу node-a на 50 очков больше.

Необходимо дополнить статью описанием таймеров!

Более сложные правила работы с доступностью контрольных узлов можно почитать на соответствующих тематических сайтах (ссылки внизу).

Конечная конфигурация

Посмотреть конечную конфигурацию кластера можно выполнив команду:

В результате её исполнения, должна отобразиться текущая конфигурация, примерно следующая:

В принципе, понимая что к чему на данную конфигурацию не так уж и страшно смотреть.

Текущее состояние кластера можно посмотреть выполнив команду `crm_mon -1` или просто `crm_mon`. Понятно, что не имеет значения, на каком узле выполняется данная команда кластера. Результат должен быть примерно следующим:

Выгрузка сервисов

Все LSB ресурсы, которые у нас прописаны в менеджере ресурсов pacemaker, должны быть исключены из автозагрузки. Конечно, это не касается сервиса DRBD, т.к. он описан OCF ресурсом, а сам сервис должен быть запущен одновременно на двух узлах для физической синхронизации данных.

Необходимо выполнить выгрузку сервисов на двух узлах:

Источник