Часть 23: Установка и настройка кластера на Corosync и Pacemaker. - github2wiki/SPBSUT_KURS GitHub Wiki

Для того, чтобы понимать, где применим данный инструмент, сначала стоит познакомиться с понятием HA.

HA - это high availability. Идея ha в автоматической обраьотке отказов узлов кластера. Если один из узлов кластера падает, то необходимые для функционирования кластера службы переносятся на другой узел.

Для настройки Linux HA можно использовать проект Pacemaker.

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

Проект кроме собственно своих демонов, поддерживающих конфиг кластера и указанный выше шелл, также использует сторонние, тот же corosync.

Corosync (Corosync Cluster Engine) — проект с открытым исходным кодом, реализующий систему группового общения для отказоустойчивых кластеров.

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

Установка очень проста. На всех узлах выполняем команду:

sudo yum install -y pacemaker corosync pcs resource-agents

Далее поднимаем pcs. Тоже, на всех узлах

sudo systemctl start pcsd.service
sudo systemctl enable pcsd.service
systemctl status pcsd.service

Откройте порты, необходимые для работы кластера:

sudo firewall-cmd --permanent --add-port=2224/tcp
sudo firewall-cmd --permanent --add-port=3121/tcp
sudo firewall-cmd --permanent --add-port=5403/tcp
sudo firewall-cmd --permanent --add-port=5404/tcp
sudo firewall-cmd --permanent --add-port=5405/tcp
sudo firewall-cmd --permanent --add-port=21064/tcp
sudo firewall-cmd --reload

Создаем пользователя hacluster. На всех узлах.

echo passwd | sudo passwd --stdin hacluster

И, с помощью pcs создаем кластер (на одном из узлов):

sudo pcs cluster auth node01 node02 node03 -u hacluster -p passwd --force
sudo pcs cluster setup --force --name pacemaker1 node0 node1 node2
sudo pcs cluster start --all

Откройте порты, необходимые для работы кластера:

sudo firewall-cmd --permanent --add-port=2224/tcp
sudo firewall-cmd --reload

Узлы

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

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

Ресурсы

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

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

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 этой операции - интервал с каким делать проверку.

STONITH

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

Создание Fencing Device

Для работы со stonith нужно сконфигурировать ipmi. После того, как у вас будет адрес ipmi-интерфейса, логин и пароль, а также порт, к которому нужно подключаться, создайте через pcs fenceing device^

pcs stonith create ipmi-fencing fence_ipmilan \
      pcmk_host_list="pcmk-1 pcmk-2" ipaddr="xxx.xxx.xxx.xxx" login="user" \
      passwd="passwd" op monitor interval=30s

И включите его

pcs property set stonith-enabled=true