Pacemaker и Corosync

Не много о кластеризации

Pacemaker - это менеджер ресурсов кластера с открытым исходным кодом (CRM), который координирует ресурсы и службы, которые управляются и становятся доступными кластеру. По сути, Corosync позволяет серверам связываться как кластер, в то время как Pacemaker предоставляет возможность управлять тем, как ведет себя кластер.

Corosync - это программа с открытым исходным кодом, которая предоставляет возможности кластерного членства и обмена сообщениями, часто называемые уровнем обмена сообщениями, на клиентские серверы.

Архитектура pacemaker и сorosync состоит из трех уровней:

• CIB(Cluster Information Base)(Resources and Agents). Кластеронезависимый уровень — на этом уровне располагаются сами ресурсы и их скрипты, которыми они управляются и локальный демон, который скрывает от других уровней различия в стандартах, использованных в скриптах.
• Cluster Resource Management daemon. Менеджер ресурсов (Pacemaker), который представляет из себя мозг. Он реагирует на события, происходящие в кластере: отказ или присоединение узлов, ресурсов, переход узлов в сервисный режим и другие административные действия. Pacemaker исходя из сложившейся ситуации делает расчет наиболее оптимального состояния кластера и дает команды на выполнения действий для достижения этого состояния (остановка/перенос ресурсов или узлов).
• PEngine (PE or Policy Engine). Информационный уровень — на этом уровне осуществляется сетевое взаимодействие узлов, т.е. передача сервисных команд (запуск/остановка ресурсов, узлов и т.д.), обмен информацией о полноте состава кластера (quorum) и т.д. На этом уровне работает Corosync.

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 сам располагает ресурсы на узлах «оптимально» с его точки зрения, но это не всегда может быть оптимально с точки зрения администратора. Липкость ресурса можно задать глобально, т.е. дефолтное значение для всех ресурсов или индивидуально. С помощью правил можно задавать разную липкость ресурса в зависимости от времени суток и дня недели, таким образом можно обеспечить переход ресурса на исходный узел в нерабочее время. Еще один вариант использование правил - перемещение ресурсов по узлам в зависимости от времени.

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

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

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

• priority - приоритет ресурса, учитывается, если узел исчерпал лимит по кол-ву активных ресурсов, по дефолту 0.
• resource-stickiness - липкость ресурса, описывалось выше.
• migration-threshold - сколько отказов должно произойти, чтобы ресурс считал ноду непригодной и мигрировал на другую, по дефолту 0, т.е. отключено.
• failure-timeout - кол-во секунд, по истечении которого можно считать, что отказа не происходило, т.е. потенциально разрешаем ресурсу вернуться на тот узел, на котором он отказал и был перемещен.
• multiple-active - что делать с ресурсом, если он оказался запущен более чем на одном узле. Block - установить опцию unmanaged, т.е. деактивировть, stop_only - остановить на всех узлах или stop_start - остановить на всех узлах и запустить только на одном (дефолтное значение).

По умолчанию кластер не обеспечивает работоспособность ресурсов, т.е. не следит после запуска, жив ли ресурс. Чтобы это происходило, нужно добавлять операцию 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.

Мы прочли немного теории, теперь перейдем к практике.

В этой инструкции мы покажем вам, как настроить кластер высокой доступности Nginx с помощью Pacemaker на ROSA. Чтобы иметь сервер Nginx, который может работать непрерывно без сбоев в течение длительного времени, нам нужно настроить сервер с активными пассивными экземплярами Nginx, если у вас нет имени домена для использования, можно использовать плавающий IP-адрес для доступа к  настройкам.

Настройка кластера в Rosa Сервер

Прописываение хостов

Отредактируйте файл /etc/hosts на все серверах которые будут входить в предполагаемый кластер, с любого терминала в текстовом редакторе, допустим nano nano /etc/hosts Добавьте следующие строки в /etc/hosts: 10.45.4.58    webserver-01 10.45.4.59    webserver-02

Установка Nginx

Устанавливаем nginx командой:  dnf install nginx Добавляем службы в автозагрузку:

systemctl enable nginx

Стартуем сами службы:

systemctl start nginx

Изменение индексной страницы Nginx по умолчанию

После завершения, необходимо внести изменения в индексной странице Nginx по умолчанию на сервере.

Выполните следующую команду на первом сервере

 echo <h1>webserver-01</h1>" > /usr/share/nginx/html/index.html

Выполните следующую команду на втором сервере

 echo "<h1>webserver-02</h1>" > /usr/share/nginx/html/index.html

Установка и настройка Pacemaker и Corosync

Для установки используем команду:

dnf install corosync pacemaker

Добавляем службы в автозагрузку:

systemctl enable pacemaker
systemctl enable corosync
systemctl enable pcsd

Стартуем сами службы:

systemctl start pacemaker
systemctl start corosync

Синхронизация конфигурации

Установка создаст пользователя системы hacluster. Мы также должны запустить PCSD для синхронизации конфигурации

systemctl start pcsd

Создание пароля

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

passwd hacluster

Создание кластера

Затем запустите эту команду ниже

pcs cluster auth webserver-01 webserver-02

На данный момент мы готовы к созданию кластера.

pcs cluster setup --force --name rosacluster webserver-01 webserver-02

rosacluster это имя кластера, в то время как webserver-01 и webserver-02 являются серверы, которые будут частью rosacluster.

systemctl enable pacemaker
systemctl enable corosync
systemctl enable pcsd
reboot

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

pcs status

Отключение STONITH

STONITH или "Shoot The Other Node In The Head" (застрелить другую ноду в голову -- прим.пер.) является реализация ограждения на Pacemaker. Если вы находитесь в производстве, лучше включить STONITH. Поскольку мы не используем устройства ограждения, мы отключаем STONITH.

При выполнении команды pcs status вы увидите предупреждение в выходных данных о том, что никакие устройства STONITH не настроены, и STONITH не отключен:

Предупреждение
no stonith devices and stonith-enabled is not false

Отключите STONITH с помощью следующей команды pcs.

pcs property set stonith-enabled=false

Игнорировать политику кворума

Здесь мы настроим Pacemaker игнорировать кворум:

pcs property set no-quorum-policy=ignore

Проверьте список свойств и убедитесь, что STONITH и политики quorum отключены.

pcs property list

Добавление ресурсов

Плавающий IP является IP-адрес, который может быть мгновенно перенесен с одного сервера на другой в одной и той же сети, он используется для поддержки восстановления после сбоя в кластере высокой доступности. В этой статье, плавающий IP-адрес для Pacemaker высокой доступности будет «10.45.4.60». Сейчас мы собираемся добавить два ресурса, плавающую адрес ресурса IP с именем "v_ip" и новый ресурс для Nginx веб-сервера с именем "webserver".

Добавить новый плавающий IP-адрес «v_ip» с помощью следующей команды.

pcs resource create v_ip ocf:heartbeat:IPaddr2 ip=10.45.4.60 cidr_netmask=24 op monitor interval=20s

Далее, мы можем добавить второй ресурс в кластер. Ресурс агент службы systemd: nginx под названием "nginx", таким образом мы можем добавить любой systemd юнит для отказоустойчивости в Pacemaker, он сам будет отслеживать данные сущности.

pcs resource create nginx systemd:nginx

Убедитесь, что нет ошибок, проверьте ресурсы.

pcs status resources

Если вы видите два ресурса; ‘v_ip’ и ‘nginx’, это означает, что плавающий IP и веб-сервер Nginx были добавлены.

Настройка ограничения

На этом шаге мы скажем серверу сделать так, чтобы оба ресурса, созданные ранее, работали на одном хосте. Мы установим ограничение коллокации для ресурсов со счетом бесконечности.

pcs constraint colocation add nginx v_ip INFINITY

Установка Nginx ресурсов (webserver), чтобы всегда работать на том же хосте, где v_ip активен.

pcs constraint order v_ip then nginx

Чтобы проверить работающие ресурсы на том же хосте, мы можем вызвать:

pcs status

Тест кластера

Перейдите по адресу http://10.45.4.60 на вашем веб-браузере, вы увидите страницу Nginx по умолчанию на webserver-01.

Затем выполните следующую команду, чтобы остановить кластер webserver-01:

pcs cluster stop webserver-01

Теперь, если вы обновите страницу по адресу http:// 10.45.4.60, вы получите страницу Nginx по умолчанию от webserver-02.

Поздравляем, вы успешно создали кластер высокой доступности Nginx с помощью Pacemaker.