Error unable to get cib

Centos

В дан­ной ста­тье опи­са­на началь­ная уста­нов­ка и настрой­ка паке­та Pacemaker на сер­вер под управ­ле­ни­ем CentOS7

Зада­ча: настро­ить Pacemaker на авто­ма­ти­че­ское пере­клю­че­ние MasterSlave

Уста­нов­ка
Уста­нав­ли­ва­ем паке­ты на каж­дую из нод буду­ще­го кластера.

yum -y install resource-agents pacemaker pcs fence-agents-all psmisc policycoreutils-python corosync

Задать пароль на поль­зо­ва­те­ля, под кото­рым будет рабо­тать сер­вис и выпол­нять­ся синхронизация

Запу­стим служ­бу и доба­вим в автозагрузку

systemctl enable pcsd
systemctl enable corosync
systemctl enable pacemaker

Настрой­ка
Доба­вим име­на хостов в файл /etc/hosts

100.201.203.51 node1
100.201.203.52 node2

Запуск
Откры­ва­ем порты

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

Дан­ную про­це­ду­ру выпол­ня­ем на каж­дом из серверов.

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

#pcs cluster auth node1 node2 -u hacluster

Password:
node2: Authorized
node1: Authorized

pcs cluster setup —force —name CLUSETR node1 node2
Destroying cluster on nodes: node1, node2…
node1: Stopping Cluster (pacemaker)…
node2: Stopping Cluster (pacemaker)…
node2: Successfully destroyed cluster
node1: Successfully destroyed cluster

Sending ‘pacemaker_remote authkey’ to ‘node1’, ‘node2’
node1: successful distribution of the file ‘pacemaker_remote authkey’
node2: successful distribution of the file ‘pacemaker_remote authkey’
Sending cluster config files to the nodes…
node1: Succeeded
node2: Succeeded

Synchronizing pcsd certificates on nodes node1, node2…
node2: Success
node1: Success
Restarting pcsd on the nodes in order to reload the certificates…
node2: Success
node1: Success

Раз­ре­ша­ем авто­за­пуск и запус­ка­ем создан­ный кла­стер pcs cluster enable —all и pcs cluster start —all:

pcs cluster enable —all
node1: Cluster Enabled
node2: Cluster Enabled
pcs cluster start —all
node1: Starting Cluster (corosync)…
node2: Starting Cluster (corosync)…
node2: Starting Cluster (pacemaker)…
node1: Starting Cluster (pacemaker)…

При исполь­зо­ва­нии 2-х нод (как в дан­ном при­ме­ре) отклю­ча­ем stonith (нужен для «доби­ва­ния» сер­ве­ров, кото­рые не смог­ли пол­но­стью завер­шить рабо­чие про­цес­сы) и кво­рум. STONITH (Shoot The Other Node In The Head) или Shoot явля­ет­ся допол­ни­тель­ной защи­той Pacemaker. При выпол­не­нии коман­ды pcs status вы уви­ди­те пре­ду­пре­жде­ние в выход­ных дан­ных о том, что ника­кие устрой­ства STONITH не настро­е­ны, и STONITH не отклю­чен. Если вы исполь­зу­е­те дан­ное реше­ние в про­дак­шене, то луч­ше вклю­чить STONITH . Так как даная систе­ма будет рабо­тать в DMZ , мы отклю­ча­ем STONITH . Нали­чие кво­ру­ма озна­ча­ет, что в кла­сте­ре долж­но быть не менее 3-х узлов. При­чем, необя­за­тель­но все три узла долж­ны быть с СУБД, доста­точ­но на двух узлах иметь Мастер и Репли­ку, а тре­тий узел высту­па­ет в роли «голо­су­ю­ще­го».
Нали­чие устройств фен­син­га на узлах с СУБД. При воз­ник­но­ве­нии сбоя устрой­ства «фен­син­га» изо­ли­ру­ют сбой­нув­ший узел – посы­ла­ют коман­ду на выклю­че­ние пита­ния или пере­за­груз­ку (poweroff или hard-reset). Выпол­ня­ем на обо­их нодах

pcs property set stonith-enabled=false
pcs property set no-quorum-policy=ignore

Если полу­ча­ем ошибку

Error: unable to get cib
Error: unable to get cib

То ско­рее все­го не запу­ще­ны сер­ви­сы pcs cluster enable —all и pcs cluster start —all или не уста­нов­лен пакет fence-agents-all

Что такое кво­рум? Гово­рят, что кла­стер име­ет кво­рум при доста­точ­ном коли­че­стве «живых» узлов кла­сте­ра. Доста­точ­ность коли­че­ства «живых» узлов опре­де­ля­ет­ся по фор­му­ле ниже

где n – коли­че­ство живых узлов, N – общее коли­че­ство узлов в кластере.

Как вид­но из про­стой фор­му­лы, кла­стер с кво­ру­мом – это когда коли­че­ство «живых» узлов, боль­ше поло­ви­ны обще­го коли­че­ства узлов в кла­сте­ре. Как вы, навер­ное, пони­ма­е­те, в кла­сте­ре, состо­я­щем из двух узлов, при сбое на одном из 2-х узлов не будет кво­ру­ма. По умол­ча­нию, если нет кво­ру­ма, Pacemaker оста­нав­ли­ва­ет ресур­сы. Что­бы это­го избе­жать, нуж­но при настрой­ке Pacemaker ука­зать ему, что­бы нали­чие или отсут­ствие кво­ру­ма не учи­ты­ва­лось. Дела­ет­ся это с помо­щью опции no-quorum-policy=ignore.

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

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

, где CLUSTER_IP — назва­ние ресур­са (может быть любым);

ip=100.201.203.50 — вир­ту­аль­ный IP , кото­рый будет назна­чен кластеру;

cidr_netmask=24 — пре­фикс сети (соот­вет­ству­ет мас­ке 255.255.255.0);

op monitor interval=60s — кри­ти­че­ское вре­мя про­стоя, кото­рое будет озна­чать недо­ступ­ность узла

Виды сбо­ев
Сбой по пита­нию на теку­щем масте­ре или на реплике
Сбой пита­ния, когда про­па­да­ет пита­ние и сер­вер выклю­ча­ет­ся. Это может быть как Мастер, так и одна из Реплик.

Сбой про­цес­са
Сбой основ­но­го про­цес­са – систе­ма может завер­шить ава­рий­но про­цесс postgres по раз­ным при­чи­нам, напри­мер, нехват­ка памя­ти, либо недо­ста­точ­ное коли­че­ство фай­ло­вых дескрип­то­ров, либо пре­вы­ше­но мак­си­маль­ное чис­ло откры­тых файлов.

Поте­ря сете­вой связ­но­сти меж­ду каким-либо из узлов и осталь­ны­ми узлами
Это сете­вая недо­ступ­ность како­го-либо узла. Напри­мер, её при­чи­ной может быть выход из строя сете­вой кар­ты, либо пор­та коммутатора.

Сбой про­цес­са Pacemaker/Corosync

Сбой про­цес­са Corosync/pacemaker

Рабо­та в команд­ной стро­ке PCS
Посмот­реть параметры
pcs property list

Посмот­реть состо­я­ние кластера
pcs status

Отклю­чить все ресур­сы кластера
pcs cluster disable —all

Вооб­ще для Pacemaker ресурс — это скрипт, напи­сан­ный на любом язы­ке. Обыч­но эти скрип­ты пишут­ся на bash, но ничто не меша­ет писать их на Perl, Python, C или даже на PHP . Скрипт управ­ля­ет сер­ви­са­ми в опе­ра­ци­он­ной систе­ме. Глав­ное тре­бо­ва­ние к скрип­там — уметь выпол­нять 3 дей­ствия: start, stop, monitor и делить­ся неко­то­рой метаинформацией.
Ресур­сы име­ют мно­же­ство атри­бу­тов, кото­рые хра­нят­ся в кон­фи­гу­ра­ци­он­ном XML-фай­ле Pacemaker’а. Наи­бо­лее инте­рес­ные из них: priority, resource-stickiness, migration-threshold, failure-timeout, multiple-active.
Рас­смот­рим их более подробно.

Атри­бут priority — при­о­ри­тет ресур­са, кото­рый учи­ты­ва­ет­ся, если узел исчер­пал лимит по коли­че­ству актив­ных ресур­сов (по умол­ча­нию 0). Если узлы кла­сте­ра не оди­на­ко­вы по про­из­во­ди­тель­но­сти или доступ­но­сти, то мож­но уве­ли­чить при­о­ри­тет одно­го из узлов, что­бы он был актив­ным все­гда, когда работает.

Атри­бут resource-stickiness — лип­кость ресур­са (по умол­ча­нию 0). Лип­кость (stickiness) ука­зы­ва­ет на то, насколь­ко ресурс «хочет» оста­вать­ся там, где он есть сей­час. Напри­мер, после сбоя узла его ресур­сы пере­хо­дят на дру­гие узлы (точ­нее — стар­ту­ют на дру­гих узлах), а после вос­ста­нов­ле­ния рабо­то­спо­соб­но­сти сбой­но­го узла, ресур­сы могут вер­нуть­ся к нему или не вер­нуть­ся, и это пове­де­ние как раз и опи­сы­ва­ет­ся пара­мет­ром липкость.

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

Посколь­ку по умол­ча­нию лип­кость всех ресур­сов 0, то Pacemaker сам рас­по­ла­га­ет ресур­сы на узлах «опти­маль­но» на свое усмотрение.

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

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

Атри­бут migration-threshold — сколь­ко отка­зов долж­но про­изой­ти, что­бы Pacemaker решил, что узел непри­го­ден для дан­но­го ресур­са и пере­нёс (мигри­ро­вал) его на дру­гой узел. По умол­ча­нию так­же этот пара­метр равен 0, т. е. при любом коли­че­стве отка­зов авто­ма­ти­че­ско­го пере­но­са ресур­сов не будет происходить.

Но, с точ­ки зре­ния отка­зо­устой­чи­во­сти, пра­виль­но выста­вить этот пара­метр в 1, что­бы при пер­вом же сбое Pacemaker пере­ме­щал ресурс на дру­гой узел.

Атри­бут failure-timeout — коли­че­ство секунд после сбоя, до исте­че­ния кото­рых Pacemaker счи­та­ет, что отка­за не про­изо­шло, и не пред­при­ни­ма­ет ниче­го, в част­но­сти, не пере­ме­ща­ет ресур­сы. По умол­ча­нию, равен 0.

Атри­бут multiple-active – дает ука­за­ние Pacemaker, что делать с ресур­сом, если он ока­зал­ся запу­щен более чем на одном узле. Может при­ни­мать сле­ду­ю­щие значения:
block — уста­но­вить опцию unmanaged, то есть деактивировать
stop_only — оста­но­вить на всех узлах
stop_start — оста­но­вить на всех узлах и запу­стить толь­ко на одном (зна­че­ние по-умолчанию).

По умол­ча­нию, кла­стер не сле­дит после запус­ка, жив ли ресурс. Что­бы вклю­чить отсле­жи­ва­ние ресур­са, нуж­но при созда­нии ресур­са доба­вить опе­ра­цию monitor, тогда кла­стер будет сле­дить за состо­я­ни­ем ресур­са. Пара­метр interval этой опе­ра­ции – интер­вал, с каким делать проверку.

При воз­ник­но­ве­нии отка­за на основ­ном узле, Pacemaker «пере­ме­ща­ет» ресур­сы на дру­гой узел (на самом деле, Pacemaker оста­нав­ли­ва­ет ресур­сы на сбой­нув­шем узле и запус­ка­ет ресур­сы на дру­гом). Про­цесс «пере­ме­ще­ния» ресур­сов на дру­гой узел про­ис­хо­дит быст­ро и неза­мет­но для конеч­но­го клиента.

Ресур­сы мож­но объ­еди­нять в груп­пы — спис­ки ресур­сов, кото­рые долж­ны запус­кать­ся в опре­де­лен­ном поряд­ке, оста­нав­ли­вать­ся в обрат­ном поряд­ке и испол­нять­ся на одном узле.Все ресур­сы груп­пы запус­ка­ют­ся на одном узле и запус­ка­ют­ся после­до­ва­тель­но, соглас­но поряд­ку в груп­пе. Но нуж­но учи­ты­вать, что при сбое одно­го из ресур­сов груп­пы, вся груп­па пере­ме­стит­ся на дру­гой узел.

При выклю­че­нии како­го-либо ресур­са груп­пы, все после­ду­ю­щие ресур­сы груп­пы тоже выклю­чат­ся. Напри­мер, ресурс PostgreSQL, име­ю­щий тип pgsql, и ресурс Virtual-IP, име­ю­щий тип IPaddr2, могут быть объ­еди­не­ны в группу.

Оста­но­вить все ноды
pcs cluster stop —all

Посмот­реть состо­я­ние ресурсов
pcs status resources

Изме­нить актив­ную ноду
pcs resource move CLUSTER_IP zs-node1

Уда­ле­ние ноды
pcs cluster node remove node_name

Очист­ка счет­чи­ков сбоев
pcs resource cleanup

При­мер созда­ния ресур­са PostgreSQL типа pgsql в кла­сте­ре из трех узлов pgsql01, pgsql02, pgsql03
pcs resource create PostgreSQL pgsql pgctl=»/usr/pgsql-9.6/bin/pg_ctl»
psql=»/usr/pgsql-9.6/bin/psql» pgdata=»/var/lib/pgsql/9.6/data/»
rep_mode=»sync» node_list=» pgsql01 pgsql02 pgsql03″ restore_command=»cp /var/lib/pgsql/9.6/pg_archive/%f %p»
primary_conninfo_opt=»keepalives_idle=60 keepalives_interval=5 keepalives_count=5″ master_ip=»10.3.3.3″ restart_on_promote=’false’

Рабо­та в команд­ном интер­пре­та­то­ре CRM
Дан­ная ути­ли­та име­ет соб­ствен­ный SHELL , в кото­ром доволь­но удоб­но рабо­тать. Из настро­ек дан­но­го интер­пре­та­то­ра мож­но отме­тить назна­че­ние редак­то­ра, в кото­ром вы при­вык­ли рабо­тать, напри­мер nano или mcedit.

crm options editor vim
crm opti edi mcedit
crm conf edit

Посмот­реть конфигурацию
crm configure show

Сохра­не­ние конфигурации
crm configure save _BACKUP_PATH_

Вос­ста­нов­ле­ние конфигурации
crm configure load replace _BACKUP_PATH

Допол­не­ния
Адми­ни­стри­ро­ва­ние через WEB
Каж­дая из нод слу­ша­ет порт 2224, кото­рая поз­во­ля­ет под­клю­чить­ся и посмот­реть, а так же изме­нить конфигурацию

Так же досту­пен и IP кластера.

Уста­нов­ка CRM
[kost@node1

]# crm-bash:
crm: command not found

По умол­ча­нию для CentOS7 отсут­ству­ет пакет CRM , кото­рый поз­во­ля­ет выпол­нять настрой­ку из соб­ствен­но­го SHELL . Дан­ный пакет успеш­но мож­но про­ин­стал­ли­ро­вать из сто­рон­не­го репозитория
cd /etc/yum.repos.d/
wget http://download.opensuse.org/repositories/network:/ha-clustering:/Stable/CentOS_CentOS-7/network:ha-clustering:Stable.repo
yum install crmsh

После чего мож­но вос­поль­зо­вать­ся дан­ной командой

Источник

Knowledge Base

Настройка WindowsUnix систем CISCO MIKROTIK VMWARE

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

В данной статье описана начальная установка и настройка пакета Pacemaker на сервер под управлением CentOS7

Задача: настроить Pacemaker на автоматическое переключение MasterSlave

Дано:

Решение:

Установка

Устанавливаем пакеты на каждую из нод будущего кластера.

Задать пароль на пользователя, под которым будет работать сервис и выполняться синхронизация

Запустим службу и добавим в автозагрузку

Настройка

Добавим имена хостов в файл /etc/hosts

Запуск

Данную процедуру выполняем на каждом из серверов.

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

Разрешаем автозапуск и запускаем созданный кластер pcs cluster enable –all и pcs cluster start –all:

При использовании 2-х нод (как в данном примере) отключаем stonith (нужен для «добивания» серверов, которые не смогли полностью завершить рабочие процессы) и кворум. STONITH (Shoot The Other Node In The Head) или Shoot является дополнительной защитой Pacemaker. При выполнении команды pcs status вы увидите предупреждение в выходных данных о том, что никакие устройства STONITH не настроены, и STONITH не отключен. Если вы используете данное решение в продакшене, то лучше включить STONITH. Так как даная система будет работать в DMZ, мы отключаем STONITH. Наличие кворума означает, что в кластере должно быть не менее 3-х узлов. Причем, необязательно все три узла должны быть с СУБД, достаточно на двух узлах иметь Мастер и Реплику, а третий узел выступает в роли «голосующего».
Наличие устройств фенсинга на узлах с СУБД. При возникновении сбоя устройства «фенсинга» изолируют сбойнувший узел – посылают команду на выключение питания или перезагрузку (poweroff или hard-reset). Выполняем на обоих нодах

Если получаем ошибку

То скорее всего не запущены сервисы pcs cluster enable –all и pcs cluster start –all или не установлен пакет fence-agents-all

Что такое кворум? Говорят, что кластер имеет кворум при достаточном количестве «живых» узлов кластера. Достаточность количества «живых» узлов определяется по формуле ниже

где n – количество живых узлов, N – общее количество узлов в кластере.

Как видно из простой формулы, кластер с кворумом – это когда количество «живых» узлов, больше половины общего количества узлов в кластере. Как вы, наверное, понимаете, в кластере, состоящем из двух узлов, при сбое на одном из 2-х узлов не будет кворума. По умолчанию, если нет кворума, Pacemaker останавливает ресурсы. Чтобы этого избежать, нужно при настройке Pacemaker указать ему, чтобы наличие или отсутствие кворума не учитывалось. Делается это с помощью опции no-quorum-policy=ignore.

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

,где CLUSTER_IP — название ресурса (может быть любым);

ip=100.201.203.50 — виртуальный IP, который будет назначен кластеру;

cidr_netmask=24 — префикс сети (соответствует маске 255.255.255.0);

op monitor interval=60s — критическое время простоя, которое будет означать недоступность узла

Виды сбоев

Сбой по питанию на текущем мастере или на реплике

Сбой питания, когда пропадает питание и сервер выключается. Это может быть как Мастер, так и одна из Реплик.

Сбой процесса

Сбой основного процесса – система может завершить аварийно процесс postgres по разным причинам, например, нехватка памяти, либо недостаточное количество файловых дескрипторов, либо превышено максимальное число открытых файлов.

Потеря сетевой связности между каким-либо из узлов и остальными узлами

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

Сбой процесса Pacemaker/Corosync

Сбой процесса Corosync/pacemaker

Работа в командной строке PCS

Посмотреть параметры

Посмотреть состояние кластера

Отключить все ресурсы кластера

Ресурсы имеют множество атрибутов, которые хранятся в конфигурационном XML-файле Pacemaker’а. Наиболее интересные из них: priority, resource-stickiness, migration-threshold, failure-timeout, multiple-active.
Рассмотрим их более подробно.

Атрибут priority — приоритет ресурса, который учитывается, если узел исчерпал лимит по количеству активных ресурсов (по умолчанию 0). Если узлы кластера не одинаковы по производительности или доступности, то можно увеличить приоритет одного из узлов, чтобы он был активным всегда, когда работает.

Атрибут resource-stickiness — липкость ресурса (по умолчанию 0). Липкость (stickiness) указывает на то, насколько ресурс «хочет» оставаться там, где он есть сейчас. Например, после сбоя узла его ресурсы переходят на другие узлы (точнее — стартуют на других узлах), а после восстановления работоспособности сбойного узла, ресурсы могут вернуться к нему или не вернуться, и это поведение как раз и описывается параметром липкость.

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

Поскольку по умолчанию липкость всех ресурсов 0, то Pacemaker сам располагает ресурсы на узлах «оптимально» на свое усмотрение.

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

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

Атрибут migration-threshold — сколько отказов должно произойти, чтобы Pacemaker решил, что узел непригоден для данного ресурса и перенёс (мигрировал) его на другой узел. По умолчанию также этот параметр равен 0, т. е. при любом количестве отказов автоматического переноса ресурсов не будет происходить.

Но, с точки зрения отказоустойчивости, правильно выставить этот параметр в 1, чтобы при первом же сбое Pacemaker перемещал ресурс на другой узел.

Атрибут failure-timeout — количество секунд после сбоя, до истечения которых Pacemaker считает, что отказа не произошло, и не предпринимает ничего, в частности, не перемещает ресурсы. По умолчанию, равен 0.

Атрибут multiple-active – дает указание Pacemaker, что делать с ресурсом, если он оказался запущен более чем на одном узле. Может принимать следующие значения:
block — установить опцию unmanaged, то есть деактивировать
stop_only — остановить на всех узлах
stop_start — остановить на всех узлах и запустить только на одном (значение по-умолчанию).

По умолчанию, кластер не следит после запуска, жив ли ресурс. Чтобы включить отслеживание ресурса, нужно при создании ресурса добавить операцию monitor, тогда кластер будет следить за состоянием ресурса. Параметр interval этой операции – интервал, с каким делать проверку.

При возникновении отказа на основном узле, Pacemaker «перемещает» ресурсы на другой узел (на самом деле, Pacemaker останавливает ресурсы на сбойнувшем узле и запускает ресурсы на другом). Процесс «перемещения» ресурсов на другой узел происходит быстро и незаметно для конечного клиента.

Ресурсы можно объединять в группы — списки ресурсов, которые должны запускаться в определенном порядке, останавливаться в обратном порядке и исполняться на одном узле.Все ресурсы группы запускаются на одном узле и запускаются последовательно, согласно порядку в группе. Но нужно учитывать, что при сбое одного из ресурсов группы, вся группа переместится на другой узел.

При выключении какого-либо ресурса группы, все последующие ресурсы группы тоже выключатся. Например, ресурс PostgreSQL, имеющий тип pgsql, и ресурс Virtual-IP, имеющий тип IPaddr2, могут быть объединены в группу.

Источник

В дан­ной ста­тье опи­са­на началь­ная уста­нов­ка и настрой­ка паке­та Pacemaker на сер­вер под управ­ле­ни­ем CentOS7

Зада­ча: настро­ить Pacemaker на авто­ма­ти­че­ское пере­клю­че­ние MasterSlave

Дано:

node1 CentOS7

node2 CentOS7

Реше­ние:

Уста­нов­ка
Уста­нав­ли­ва­ем паке­ты на каж­дую из нод буду­ще­го кластера.

yum -y install resource-agents pacemaker pcs fence-agents-all psmisc policycoreutils-python corosync

Задать пароль на поль­зо­ва­те­ля, под кото­рым будет рабо­тать сер­вис и выпол­нять­ся синхронизация

passwd hacluster

Запу­стим служ­бу и доба­вим в автозагрузку

systemctl enable pcsd
systemctl enable corosync
systemctl enable pacemaker

Настрой­ка
Доба­вим име­на хостов в файл /etc/hosts

100.201.203.51 node1
100.201.203.52 node2

Запуск
Откры­ва­ем порты

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

Дан­ную про­це­ду­ру выпол­ня­ем на каж­дом из серверов.

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

#pcs cluster auth node1 node2 -u hacluster

Password:
node2: Authorized
node1: Authorized

Созда­ем кластер

pcs cluster setup —force —name CLUSETR node1 node2
Destroying cluster on nodes: node1, node2…
node1: Stopping Cluster (pacemaker)…
node2: Stopping Cluster (pacemaker)…
node2: Successfully destroyed cluster
node1: Successfully destroyed cluster

Sending ‘pacemaker_remote authkey’ to ‘node1’, ‘node2’
node1: successful distribution of the file ‘pacemaker_remote authkey’
node2: successful distribution of the file ‘pacemaker_remote authkey’
Sending cluster config files to the nodes…
node1: Succeeded
node2: Succeeded

Synchronizing pcsd certificates on nodes node1, node2…
node2: Success
node1: Success
Restarting pcsd on the nodes in order to reload the certificates…
node2: Success
node1: Success

Раз­ре­ша­ем авто­за­пуск и запус­ка­ем создан­ный кла­стер pcs cluster enable —all и pcs cluster start —all:

pcs cluster enable —all
node1: Cluster Enabled
node2: Cluster Enabled
pcs cluster start —all
node1: Starting Cluster (corosync)…
node2: Starting Cluster (corosync)…
node2: Starting Cluster (pacemaker)…
node1: Starting Cluster (pacemaker)…

При исполь­зо­ва­нии 2-х нод (как в дан­ном при­ме­ре) отклю­ча­ем stonith (нужен для «доби­ва­ния» сер­ве­ров, кото­рые не смог­ли пол­но­стью завер­шить рабо­чие про­цес­сы) и кво­рум. STONITH (Shoot The Other Node In The Head) или Shoot явля­ет­ся допол­ни­тель­ной защи­той Pacemaker. При выпол­не­нии коман­ды pcs status вы уви­ди­те пре­ду­пре­жде­ние в выход­ных дан­ных о том, что ника­кие устрой­ства STONITH не настро­е­ны, и STONITH не отклю­чен. Если вы исполь­зу­е­те дан­ное реше­ние в про­дак­шене, то луч­ше вклю­чить STONITH. Так как даная систе­ма будет рабо­тать в DMZ, мы отклю­ча­ем STONITH. Нали­чие кво­ру­ма озна­ча­ет, что в кла­сте­ре долж­но быть не менее 3-х узлов. При­чем, необя­за­тель­но все три узла долж­ны быть с СУБД, доста­точ­но на двух узлах иметь Мастер и Репли­ку, а тре­тий узел высту­па­ет в роли «голо­су­ю­ще­го».
Нали­чие устройств фен­син­га на узлах с СУБД. При воз­ник­но­ве­нии сбоя устрой­ства «фен­син­га» изо­ли­ру­ют сбой­нув­ший узел – посы­ла­ют коман­ду на выклю­че­ние пита­ния или пере­за­груз­ку (poweroff или hard-reset). Выпол­ня­ем на обо­их нодах

pcs property set stonith-enabled=false
pcs property set no-quorum-policy=ignore

Если полу­ча­ем ошибку

Error: unable to get cib
Error: unable to get cib

То ско­рее все­го не запу­ще­ны сер­ви­сы pcs cluster enable —all и pcs cluster start —all или не уста­нов­лен пакет fence-agents-all

Что такое кво­рум? Гово­рят, что кла­стер име­ет кво­рум при доста­точ­ном коли­че­стве «живых» узлов кла­сте­ра. Доста­точ­ность коли­че­ства «живых» узлов опре­де­ля­ет­ся по фор­му­ле ниже

n > N/2

где n – коли­че­ство живых узлов, N – общее коли­че­ство узлов в кластере.

Как вид­но из про­стой фор­му­лы, кла­стер с кво­ру­мом – это когда коли­че­ство «живых» узлов, боль­ше поло­ви­ны обще­го коли­че­ства узлов в кла­сте­ре. Как вы, навер­ное, пони­ма­е­те, в кла­сте­ре, состо­я­щем из двух узлов, при сбое на одном из 2-х узлов не будет кво­ру­ма. По умол­ча­нию, если нет кво­ру­ма, Pacemaker оста­нав­ли­ва­ет ресур­сы. Что­бы это­го избе­жать, нуж­но при настрой­ке Pacemaker ука­зать ему, что­бы нали­чие или отсут­ствие кво­ру­ма не учи­ты­ва­лось. Дела­ет­ся это с помо­щью опции no-quorum-policy=ignore.

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

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

,где CLUSTER_IP — назва­ние ресур­са (может быть любым);

ip=100.201.203.50 — вир­ту­аль­ный IP, кото­рый будет назна­чен кластеру;

cidr_netmask=24 — пре­фикс сети (соот­вет­ству­ет мас­ке 255.255.255.0);

op monitor interval=60s — кри­ти­че­ское вре­мя про­стоя, кото­рое будет озна­чать недо­ступ­ность узла

Виды сбо­ев
Сбой по пита­нию на теку­щем масте­ре или на реплике
Сбой пита­ния, когда про­па­да­ет пита­ние и сер­вер выклю­ча­ет­ся. Это может быть как Мастер, так и одна из Реплик.

Сбой про­цес­са
Сбой основ­но­го про­цес­са – систе­ма может завер­шить ава­рий­но про­цесс postgres по раз­ным при­чи­нам, напри­мер, нехват­ка памя­ти, либо недо­ста­точ­ное коли­че­ство фай­ло­вых дескрип­то­ров, либо пре­вы­ше­но мак­си­маль­ное чис­ло откры­тых файлов.

Поте­ря сете­вой связ­но­сти меж­ду каким-либо из узлов и осталь­ны­ми узлами
Это сете­вая недо­ступ­ность како­го-либо узла. Напри­мер, её при­чи­ной может быть выход из строя сете­вой кар­ты, либо пор­та коммутатора.

Сбой про­цес­са Pacemaker/Corosync

Сбой про­цес­са Corosync/pacemaker

Рабо­та в команд­ной стро­ке PCS
Посмот­реть параметры
pcs property list

Посмот­реть состо­я­ние кластера
pcs status

Отклю­чить все ресур­сы кластера
pcs cluster disable —all

Вооб­ще для Pacemaker ресурс — это скрипт, напи­сан­ный на любом язы­ке. Обыч­но эти скрип­ты пишут­ся на bash, но ничто не меша­ет писать их на Perl, Python, C или даже на PHP. Скрипт управ­ля­ет сер­ви­са­ми в опе­ра­ци­он­ной систе­ме. Глав­ное тре­бо­ва­ние к скрип­там — уметь выпол­нять 3 дей­ствия: start, stop, monitor и делить­ся неко­то­рой метаинформацией.
Ресур­сы име­ют мно­же­ство атри­бу­тов, кото­рые хра­нят­ся в кон­фи­гу­ра­ци­он­ном XML-фай­ле Pacemaker’а. Наи­бо­лее инте­рес­ные из них: priority, resource-stickiness, migration-threshold, failure-timeout, multiple-active.
Рас­смот­рим их более подробно.

Атри­бут priority — при­о­ри­тет ресур­са, кото­рый учи­ты­ва­ет­ся, если узел исчер­пал лимит по коли­че­ству актив­ных ресур­сов (по умол­ча­нию 0). Если узлы кла­сте­ра не оди­на­ко­вы по про­из­во­ди­тель­но­сти или доступ­но­сти, то мож­но уве­ли­чить при­о­ри­тет одно­го из узлов, что­бы он был актив­ным все­гда, когда работает.

Атри­бут resource-stickiness — лип­кость ресур­са (по умол­ча­нию 0). Лип­кость (stickiness) ука­зы­ва­ет на то, насколь­ко ресурс «хочет» оста­вать­ся там, где он есть сей­час. Напри­мер, после сбоя узла его ресур­сы пере­хо­дят на дру­гие узлы (точ­нее — стар­ту­ют на дру­гих узлах), а после вос­ста­нов­ле­ния рабо­то­спо­соб­но­сти сбой­но­го узла, ресур­сы могут вер­нуть­ся к нему или не вер­нуть­ся, и это пове­де­ние как раз и опи­сы­ва­ет­ся пара­мет­ром липкость.

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

Посколь­ку по умол­ча­нию лип­кость всех ресур­сов 0, то Pacemaker сам рас­по­ла­га­ет ресур­сы на узлах «опти­маль­но» на свое усмотрение.

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

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

Атри­бут migration-threshold — сколь­ко отка­зов долж­но про­изой­ти, что­бы Pacemaker решил, что узел непри­го­ден для дан­но­го ресур­са и пере­нёс (мигри­ро­вал) его на дру­гой узел. По умол­ча­нию так­же этот пара­метр равен 0, т. е. при любом коли­че­стве отка­зов авто­ма­ти­че­ско­го пере­но­са ресур­сов не будет происходить.

Но, с точ­ки зре­ния отка­зо­устой­чи­во­сти, пра­виль­но выста­вить этот пара­метр в 1, что­бы при пер­вом же сбое Pacemaker пере­ме­щал ресурс на дру­гой узел.

Атри­бут failure-timeout — коли­че­ство секунд после сбоя, до исте­че­ния кото­рых Pacemaker счи­та­ет, что отка­за не про­изо­шло, и не пред­при­ни­ма­ет ниче­го, в част­но­сти, не пере­ме­ща­ет ресур­сы. По умол­ча­нию, равен 0.

Атри­бут multiple-active – дает ука­за­ние Pacemaker, что делать с ресур­сом, если он ока­зал­ся запу­щен более чем на одном узле. Может при­ни­мать сле­ду­ю­щие значения:
block — уста­но­вить опцию unmanaged, то есть деактивировать
stop_only — оста­но­вить на всех узлах
stop_start — оста­но­вить на всех узлах и запу­стить толь­ко на одном (зна­че­ние по-умолчанию).

По умол­ча­нию, кла­стер не сле­дит после запус­ка, жив ли ресурс. Что­бы вклю­чить отсле­жи­ва­ние ресур­са, нуж­но при созда­нии ресур­са доба­вить опе­ра­цию monitor, тогда кла­стер будет сле­дить за состо­я­ни­ем ресур­са. Пара­метр interval этой опе­ра­ции – интер­вал, с каким делать проверку.

При воз­ник­но­ве­нии отка­за на основ­ном узле, Pacemaker «пере­ме­ща­ет» ресур­сы на дру­гой узел (на самом деле, Pacemaker оста­нав­ли­ва­ет ресур­сы на сбой­нув­шем узле и запус­ка­ет ресур­сы на дру­гом). Про­цесс «пере­ме­ще­ния» ресур­сов на дру­гой узел про­ис­хо­дит быст­ро и неза­мет­но для конеч­но­го клиента.

Ресур­сы мож­но объ­еди­нять в груп­пы — спис­ки ресур­сов, кото­рые долж­ны запус­кать­ся в опре­де­лен­ном поряд­ке, оста­нав­ли­вать­ся в обрат­ном поряд­ке и испол­нять­ся на одном узле.Все ресур­сы груп­пы запус­ка­ют­ся на одном узле и запус­ка­ют­ся после­до­ва­тель­но, соглас­но поряд­ку в груп­пе. Но нуж­но учи­ты­вать, что при сбое одно­го из ресур­сов груп­пы, вся груп­па пере­ме­стит­ся на дру­гой узел.

При выклю­че­нии како­го-либо ресур­са груп­пы, все после­ду­ю­щие ресур­сы груп­пы тоже выклю­чат­ся. Напри­мер, ресурс PostgreSQL, име­ю­щий тип pgsql, и ресурс Virtual-IP, име­ю­щий тип IPaddr2, могут быть объ­еди­не­ны в группу.

Оста­но­вить все ноды
pcs cluster stop —all

Посмот­реть состо­я­ние ресурсов
pcs status resources

Изме­нить актив­ную ноду
pcs resource move CLUSTER_IP zs-node1

Уда­ле­ние ноды
pcs cluster node remove node_name

Очист­ка счет­чи­ков сбоев
pcs resource cleanup

При­мер созда­ния ресур­са PostgreSQL типа pgsql в кла­сте­ре из трех узлов pgsql01, pgsql02, pgsql03
pcs resource create PostgreSQL pgsql pgctl=»/usr/pgsql-9.6/bin/pg_ctl»
psql=»/usr/pgsql-9.6/bin/psql» pgdata=»/var/lib/pgsql/9.6/data/»
rep_mode=»sync» node_list=» pgsql01 pgsql02 pgsql03″ restore_command=»cp /var/lib/pgsql/9.6/pg_archive/%f %p»
primary_conninfo_opt=»keepalives_idle=60 keepalives_interval=5 keepalives_count=5″ master_ip=»10.3.3.3″ restart_on_promote=’false’

Рабо­та в команд­ном интер­пре­та­то­ре CRM
Дан­ная ути­ли­та име­ет соб­ствен­ный SHELL, в кото­ром доволь­но удоб­но рабо­тать. Из настро­ек дан­но­го интер­пре­та­то­ра мож­но отме­тить назна­че­ние редак­то­ра, в кото­ром вы при­вык­ли рабо­тать, напри­мер nano или mcedit.

crm options editor vim
crm opti edi mcedit
crm conf edit

Посмот­реть конфигурацию
crm configure show

Сохра­не­ние конфигурации
crm configure save _BACKUP_PATH_

Вос­ста­нов­ле­ние конфигурации
crm configure load replace _BACKUP_PATH

Допол­не­ния
Адми­ни­стри­ро­ва­ние через WEB
Каж­дая из нод слу­ша­ет порт 2224, кото­рая поз­во­ля­ет под­клю­чить­ся и посмот­реть, а так же изме­нить конфигурацию

Напри­мер https://100.201.203.54:2224

Так же досту­пен и IP кластера.

Уста­нов­ка CRM
[kost@node1 ~]# crm-bash:
crm: command not found

По умол­ча­нию для CentOS7 отсут­ству­ет пакет CRM, кото­рый поз­во­ля­ет выпол­нять настрой­ку из соб­ствен­но­го SHELL. Дан­ный пакет успеш­но мож­но про­ин­стал­ли­ро­вать из сто­рон­не­го репозитория
cd /etc/yum.repos.d/
wget http://download.opensuse.org/repositories/network:/ha-clustering:/Stable/CentOS_CentOS-7/network:ha-clustering:Stable.repo
yum install crmsh

После чего мож­но вос­поль­зо­вать­ся дан­ной командой

When configuring a cluster, you want tot keep managing the server as simple as possible. Theoretically, the results given by any node in the cluster should be equal as you want the cluster to be transparent to the end-user. Part of doing this, is having the same data available on every node of the cluster when it’s active. One way to do this, is using a central file-share, for example over NFS but this also has disadvantages. Another way is to have a distributed file system that stays on the nodes itself. DRBD is one of them. This post explains how to integrate DRBD in a cluster with Corosync and Pacemaker.

DRBD stands for Distributed Replicated Block Device and the name already explains what it is. DRBD presents a layer on top of a normal block device and is responsible for keeping it synchronized over multiple nodes. Simplified, you can compare DRBD with a RAID1-array over multiple devices in different nodes instead of over multiple devices on the same node.

In this post, I will continue with the setup which was created earlier in Building a high-available failover cluster with Pacemaker, Corosync & PCS. So if you’re looking for the basic configuration of a cluster, have a look here. I assume, for this post, that you got a working cluster with Corosync and Pacemaker.

The goal of these actions is to have the data for the Apache webserver synchronized over both nodes. In the example, the configured webserver was presenting the local data which we even used to identify the nodes.

Since RHEL 7, Red Hat doesn’t officially support DRBD anymore. Support for DRBD is still available via an external partner. This also means that CentOS, one of the RHEL derivatives doesn’t have the DRBD packages available. Fortunately, ELRepo still provides what we need to get going with DRBD.

Installing DRBD

More info about ELRepo can be found here: http://elrepo.org/tiki/drbd83-utils.

The first step in adding DRBD to the existing cluster is to configure the nodes to use the ELRepo-repository:

[jensd@node01 ~]$ sudo rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
[jensd@node01 ~]$ sudo yum install http://www.elrepo.org/elrepo-release-7.0-2.el7.elrepo.noarch.rpm
...
Complete !

[jensd@node02 ~]$ sudo rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
[jensd@node02 ~]$ sudo yum install http://www.elrepo.org/elrepo-release-7.0-2.el7.elrepo.noarch.rpm
...
Complete !

After adding the repository, we can install drbd as before:

[jensd@node01 ~]$ sudo yum install drbd84-utils kmod-drbd84
...
Complete !

[jensd@node02 ~]$ sudo yum install drbd84-utils kmod-drbd84
...
Complete !

Create a (logical) volume for DRBD

DRBD provides a way to distribute a block device over multiple nodes. In order to do so, we need a block device to distribute (sound logical, doesn’t it). The block device can be any available device, it doesn’t need to be a logical volume but can be a pure physical partition too. For this post, I’ll add a new logical volume on both nodes to use as my distributed block device. The size of the devices needs to be equal on all nodes.

First I’ll check if I still have some free space in my volume group to create the logical volume:

[jensd@node01 ~]$ sudo vgdisplay vg_drbd|grep Free
Free PE / Size 255 / 1020.00 MiB

[jensd@node02 ~]$ sudo vgdisplay vg_drbd|grep Free
Free PE / Size 255 / 1020.00 MiB

After checking what is available, I’ll create a new logical volume, named lv_drbd0 in that volume group:

[jensd@node01 ~]$ sudo lvcreate -n lv_drbd0 -l +100%FREE vg_drbd
Logical volume "lv_drbd0" created

[jensd@node02 ~]$ sudo lvcreate -n lv_drbd0 -l +100%FREE vg_drbd
Logical volume "lv_drbd0" created

After these steps, both nodes contain a logical volume called lv_drbd0 that are equal in size (1GB).

Configuring DRBD for Single-primary mode

Now that we have a block device to share, we’ll configure DRBD to do so. Our DRBD setup will be in single-primary mode. This means that only one of the nodes can be the primary. This means that the data is only manipulated from one point at a time. For other configurations, you will need non-standard file systems. The goal of my setup is to use a standard file system like EXT3, EXT4 or XFS.

Before we will start configure DRBD, we’ll have to open two TCP-ports on our firewall in order for the nodes to communicate with eachother. DRBD uses, by default, port 7788 and 7799.

[jensd@node01 ~]$ sudo iptables -I INPUT -p tcp -m state --state NEW -m tcp --dport 7788 -j ACCEPT
[jensd@node01 ~]$ sudo iptables -I INPUT -p tcp -m state --state NEW -m tcp --dport 7799 -j ACCEPT
[jensd@node01 ~]$ sudo service iptables save

[jensd@node02 ~]$ sudo iptables -I INPUT -p tcp -m state --state NEW -m tcp --dport 7788 -j ACCEPT
[jensd@node02 ~]$ sudo iptables -I INPUT -p tcp -m state --state NEW -m tcp --dport 7799 -j ACCEPT
[jensd@node01 ~]$ sudo service iptables save

The next step is to create the DRBD configuration files. These files need to be completely equal on all nodes in the cluster.

File /etc/drbd.d/global_common.conf (on node01 and node02):

global {
        usage-count yes;
}
common {
        net {
                protocol C;
        }
}

File /etc/drbd.d/drbd0.res (on node01 and node02):

resource drbd0 {
        disk /dev/vg_drbd/lv_drbd0;
        device /dev/drbd0;
        meta-disk internal;
        on node01 {
                address 192.168.202.101:7789;
        }
        on node02 {
                address 192.168.202.102:7789;
        }
}

Now that we have the configuration in place, it’s time to initialize our data:

[jensd@node01 ~]$ sudo drbdadm create-md drbd0
initializing activity log
NOT initializing bitmap
Writing meta data...
New drbd meta data block successfully created.
success

At this point, we’re ready to start DRBD on both nodes and bring the drbd0 resource up. After bringing the resource up, let’s check the status:

[jensd@node01 ~]$ sudo drbdadm up drbd0
[jensd@node01 ~]$ cat /proc/drbd
version: 8.4.5 (api:1/proto:86-101)
GIT-hash: 1d360bde0e095d495786eaeb2a1ac76888e4db96 build by mockbuild@, 2014-08-17 22:54:26
 0: cs:WFConnection ro:Secondary/Unknown ds:Inconsistent/DUnknown C r----s
	ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:1048508

[jensd@node02 ~]$ sudo drbdadm up drbd0
[jensd@node02 ~]$ cat /proc/drbd
version: 8.4.5 (api:1/proto:86-101)
GIT-hash: 1d360bde0e095d495786eaeb2a1ac76888e4db96 build by mockbuild@, 2014-08-17 22:54:26
 0: cs:Connected ro:Secondary/Secondary ds:Inconsistent/Inconsistent C r-----
	ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:1048508

As you can see in the contents of /proc/drbd, DRBD marks this resource as inconsistent. This is because we didn’t tell DRBD who is the primary node. In the above output you can see that both nodes are thinging that they are the secondary node. All configuration files are identical on both nodes so at this point, they’re considered equal.

Let’s configure node01 as the primary and check the status again:

[jensd@node01 ~]$ sudo drbdadm primary --force drbd0
[jensd@node01 ~]$ cat /proc/drbd
version: 8.4.5 (api:1/proto:86-101)
GIT-hash: 1d360bde0e095d495786eaeb2a1ac76888e4db96 build by mockbuild@, 2014-08-17 22:54:26
 0: cs:SyncSource ro:Primary/Secondary ds:UpToDate/Inconsistent C r-----
    ns:175896 nr:0 dw:0 dr:175896 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:868516
        [==>.................] sync'ed: 16.9% (868516/1044412)K
        finish: 0:01:38 speed: 8,792 (8,792) K/sec

As you can see in the above output now, the data is synced from node01 (which we set as the primary node) to node02 (which is now the secondary node. The volume which we used (lv_drbd0) was empty but since DRBD is not looking at the contents (blocks) it still needs to synchronize the blocks on the volume.

After a while, the synchronization finished and the resource is considered UpToDate:

[jensd@node01 ~]$ cat /proc/drbd
version: 8.4.5 (api:1/proto:86-101)
GIT-hash: 1d360bde0e095d495786eaeb2a1ac76888e4db96 build by mockbuild@, 2014-08-17 22:54:26
 0: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r-----
    ns:1044412 nr:0 dw:0 dr:1044412 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0

To be sure, we can check this in another way. Here you can also clearly see who’s the primary and who’s the secondary:

[jensd@node01 ~]$ sudo drbd-overview
 0:drbd0/0  Connected Primary/Secondary UpToDate/UpToDate

[jensd@node02 ~]$ sudo drbd-overview
 0:drbd0/0  Connected Secondary/Primary UpToDate/UpToDate

 Create a file system on the DRBD resource

Now that the resource is synced over both nodes, we can start creating the actual file system for the block device. For DRBD, the contents of the file system isn’t important, DRBD only cares that the “blocks” are equal on both sides. This will also happen with the file system which we create:

[jensd@node01 ~]$ sudo mkfs.xfs /dev/drbd0
meta-data=/dev/drbd0             isize=256    agcount=4, agsize=65276 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=0
data     =                       bsize=4096   blocks=261103, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=0
log      =internal log           bsize=4096   blocks=853, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

After creating a filesystem on the DRBD resource, we can start putting data on the FS:

[jensd@node01 ~]$ sudo mount /dev/drbd0 /mnt
[jensd@node01 ~]$ sudo mkdir /mnt/test
[jensd@node01 ~]$ sudo touch /mnt/f1
[jensd@node01 ~]$ sudo touch /mnt/f2

Test the failover

To do a (clean) manual failover, we can simply switch the primary and secondary nodes and check if the data got replicated to the second node and back:

[jensd@node01 ~]$ mount|grep /dev/drbd0
/dev/drbd0 on /mnt type xfs (rw,relatime,seclabel,attr2,inode64,noquota)
[jensd@node01 ~]$ ls -al /mnt/
total 4
drwxr-xr-x. 3 root root 35 Nov 21 12:26 .
dr-xr-xr-x. 17 root root 4096 Nov 21 10:05 ..
-rw-r--r--. 1 root root 0 Nov 21 12:26 f1
-rw-r--r--. 1 root root 0 Nov 21 12:26 f2
drwxr-xr-x. 2 root root 6 Nov 21 12:26 test
[jensd@node01 ~]$ sudo umount /mnt
[jensd@node01 ~]$ sudo drbdadm secondary drbd0
[jensd@node01 ~]$ sudo drbd-overview
0:drbd0/0 Connected Secondary/Secondary UpToDate/UpToDate

[jensd@node02 ~]$ sudo drbdadm primary drbd0
[jensd@node02 ~]$ sudo mount /dev/drbd0 /mnt
[jensd@node02 ~]$ sudo mount /dev/drbd0 /mnt
[jensd@node02 ~]$ ls -al /mnt/
total 4
drwxr-xr-x.  3 root root   35 Nov 21 12:26 .
dr-xr-xr-x. 17 root root 4096 Nov 21 10:04 ..
-rw-r--r--.  1 root root    0 Nov 21 12:26 f1
-rw-r--r--.  1 root root    0 Nov 21 12:26 f2
drwxr-xr-x.  2 root root    6 Nov 21 12:26 test
[jensd@node02 ~]$ sudo drbd-overview
 0:drbd0/0  Connected Primary/Secondary UpToDate/UpToDate /mnt xfs 1017M 33M 985M 4%

In case you try to mount the resource on a node which is considered secondary, you should a message similar to this:

[jensd@node01 ~]$ sudo mount /dev/drbd0 /mnt
mount: /dev/drbd0 is write-protected, mounting read-only
mount: mount /dev/drbd0 on /mnt failed: Wrong medium type

Add the DRBD resource to our previously configured Pacemaker/Corosync cluster

In my previous post, I created a cluster with Apache to serve webpages in a high available setup. both nodes had to have an identical set of webpages in order to server the exact same content regardless of which node was the active one. Now we’ll add the DRBD-resource to the cluster and move the data for the website to the resource.

To configure DRBD on our cluster, we’ll first edit the configuration as we want it to be and then push it to the actual, running configuration. To accomplish this, we can create a new CIB (Cluster Information Base). Basically it’s a file that contains the complete cluster configuration.

[jensd@node01 ~]$ sudo pcs cluster cib add_drbd
[jensd@node01 ~]$ ls -al add_drbd
-rw-rw-r--. 1 jensd jensd 6968 Nov 21 12:40 add_drbd

If you would look at the contents of the file, you would find the complete, currently active, configuration in there.

Now, let’s add the changes to the cib-file to include our DRBD resource:

[jensd@node01 ~]$ sudo pcs -f add_drbd resource create webserver_data ocf:linbit:drbd drbd_resource=drbd0 op monitor interval=60s
[jensd@node01 ~]$ sudo pcs -f add_drbd resource master webserver_data_sync webserver_data master-max=1 master-node-max=1 clone-max=2 clone-node-max=1 notify=true

We can query the CIB as we would do with the normal active configuration:

[jensd@node01 ~]$ sudo pcs -f add_drbd resource show
 virtual_ip (ocf::heartbeat:IPaddr2): Started
 webserver (ocf::heartbeat:apache): Started
 Master/Slave Set: webserver_data_sync [webserver_data]
 Stopped: [ node01 node02 ]

When the configuration is as want it to be, we can activate it by pushing it to the cluster:

[jensd@node01 ~]$ sudo pcs cluster cib-push add_drbd
CIB updated

When looking at the status of our cluster now, we see that something clearly went wrong:

[jensd@node01 ~]$ sudo pcs status
Cluster name: cluster_web
Last updated: Fri Nov 21 13:18:07 2014
Last change: Fri Nov 21 13:17:55 2014 via cibadmin on node01
Stack: corosync
Current DC: node01 (1) - partition with quorum
Version: 1.1.10-32.el7_0.1-368c726
2 Nodes configured
4 Resources configured

Online: [ node01 node02 ]
Full list of resources:

 virtual_ip     (ocf::heartbeat:IPaddr2):       Started node01
 webserver      (ocf::heartbeat:apache):        Started node01
 Master/Slave Set: webserver_data_sync [webserver_data]
     webserver_data     (ocf::linbit:drbd):     FAILED node01 (unmanaged)
     webserver_data     (ocf::linbit:drbd):     FAILED node02 (unmanaged)

Failed actions:
    webserver_data_stop_0 on node01 'not installed' (5): call=22, status=complete, last-rc-change='Fri Nov 21 13:17:56 2014', queued=51ms, exec=0ms
    webserver_data_stop_0 on node02 'not installed' (5): call=18, status=complete, last-rc-change='Fri Nov 21 13:17:56 2014', queued=43ms, exec=0ms

After a little investigation, it seems that the permissions on file /var/lib/pacemaker/cores do not allow write from DRBD. It found this by looking at /var/log/audit/audit.log:

type=AVC msg=audit(1416572808.128:620): avc: denied { dac_read_search } for pid=27616 comm="drbdadm-84" capability=2 scontext=system_u:system_r:drbd_t:s0 tcontext=system_u:system_r:drbd_t:s0 tclass=capability
type=SYSCALL msg=audit(1416572808.128:620): arch=c000003e syscall=2 success=no exit=-13 a0=4256d7 a1=80000 a2=666e6f632e6462 a3=7fffe11d3590 items=1 ppid=27613 pid=27616 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="drbdadm-84" exe="/usr/lib/drbd/drbdadm-84" subj=system_u:system_r:drbd_t:s0 key=(null)
type=CWD msg=audit(1416572808.128:620): cwd="/var/lib/pacemaker/cores"

The message saying that dac_read_search is denied means that the user doesn’t have access to the file but tries to elevate it’s permissions to get it.

We’ll change the permissions to world writable (not secure) to fix this on both nodes:

[jensd@node01 ~]$ sudo ls -al /var/lib/pacemaker/cores
total 0
drwxr-x---. 2 hacluster haclient 6 Sep 30 14:40 .
drwxr-x---. 6 hacluster haclient 57 Nov 21 10:33 ..
[jensd@node01 ~]$ sudo chmod 777 /var/lib/pacemaker/cores

[jensd@node02 ~]$ sudo chmod 777 /var/lib/pacemaker/cores

After restarting the cluster, it’s still not working and now we can stil see very similar messages in the audit.log:

type=AVC msg=audit(1416573839.047:692): avc: denied { read } for pid=30198 comm="drbdadm-84" name="cores" dev="dm-2" ino=16918999 scontext=system_u:system_r:drbd_t:s0 tcontext=system_u:object_r:cluster_var_lib_t:s0 tclass=dir
type=SYSCALL msg=audit(1416573839.047:692): arch=c000003e syscall=2 success=no exit=-13 a0=4256d7 a1=80000 a2=666e6f632e6462 a3=7fffa43960a0 items=1 ppid=30197 pid=30198 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="drbdadm-84" exe="/usr/lib/drbd/drbdadm-84" subj=system_u:system_r:drbd_t:s0 key=(null)
type=CWD msg=audit(1416573839.047:692): cwd="/var/lib/pacemaker/cores"

The difference is that DRBD does have access to the file now but SELinux is trying to prevent access. To see which SELinux boolean we need to enable, if there is one to allow access:

[jensd@node01 ~]$ sudo tail -200 /var/log/audit/audit.log|grep AVC|tail -1|audit2allow -m drbd_0
module drbd_0 1.0;
require {
        type cluster_var_lib_t;
        type drbd_t;
        class dir read;
}
#============= drbd_t ==============
#!!!! This avc can be allowed using the boolean 'daemons_enable_cluster_mode'
allow drbd_t cluster_var_lib_t:dir read;

As the output of audit2allow states, we can set daemons_enable_cluster_mode to enabled on both nodes to fix this:

[jensd@node01 ~]$ sudo setsebool daemons_enable_cluster_mode=1

[jensd@node02 ~]$ sudo setsebool daemons_enable_cluster_mode=1

When restarting the cluster, things should look a little better. Unfortunately, there is still a problem which doesn’t allow us to stop the cluster. Again SELinux is not allow us to take this action. Which is clear when looking at /var/log/audit/audit.log:

type=AVC msg=audit(1416575077.693:1532): avc:  denied  { sys_admin } for  pid=40528 comm="drbdsetup-84" capability=21  scontext=system_u:system_r:drbd_t:s0 tcontext=system_u:system_r:drbd_t:s0 tclass=capability

We can allow this action by creating a new SELinux module and to load it:

[jensd@node01 ~]$ sudo tail -100 /var/log/audit/audit.log|grep AVC|tail -1|audit2allow -M drbd_1
******************** IMPORTANT ***********************
To make this policy package active, execute:
semodule -i drbd_1.pp
[jensd@node01 ~]$ cat drbd_1.te
module drbd_1 1.0;
require {
        type drbd_t;
        class capability sys_admin;
}
#============= drbd_t ==============
allow drbd_t self:capability sys_admin;
[jensd@node01 ~]$ sudo semodule -i drbd_1.pp

We’ll copy the module to node02 and load it there too:

[jensd@node02 ~]$ scp node01:/home/jensd/drbd_1.pp ~
jensd@node01's password:
drbd_1.pp
[jensd@node02 ~]$ sudo semodule -i drbd_1.pp

Now we can stop and start the cluster again and the output of the status command looks better:

[jensd@node01 ~]$ sudo pcs status
Cluster name: cluster_web
Last updated: Fri Nov 21 14:24:28 2014
Last change: Fri Nov 21 14:01:04 2014 via cibadmin on node01
Stack: corosync
Current DC: node01 (1) - partition with quorum
Version: 1.1.10-32.el7_0.1-368c726
2 Nodes configured
4 Resources configured

Online: [ node01 node02 ]

Full list of resources:
 virtual_ip     (ocf::heartbeat:IPaddr2):       Started node01
 webserver      (ocf::heartbeat:apache):        Started node01
 Master/Slave Set: webserver_data_sync [webserver_data]
     Masters: [ node02 ]
     Slaves: [ node01 ]

The above output shows that the resource is successfully added and is started but since our master was still node02, this isn’t really how we want it. The master should be the node that is owning the virtual IP and is running the webserver.

First, we’ll create a filesystem resource on the cluster, using a new cib-file:

[jensd@node01 ~]$ sudo pcs cluster cib add_fs
[jensd@node01 ~]$ sudo pcs -f add_fs resource create webserver_fs Filesystem device="/dev/drbd0" directory="/var/www/html" fstype="xfs"

Then we’ll create some constraints for the added resource:
The filesystem of the webserver should be made available on the master:

[jensd@node01 ~]$ sudo pcs -f add_fs constraint colocation add webserver_fs webserver_data_sync INFINITY with-rsc-role=Master

DRBD should first be started and then the file system should be made available:

[jensd@node01 ~]$ sudo pcs -f add_fs constraint order promote webserver_data_sync then start webserver_fs
Adding webserver_data_sync webserver_fs (kind: Mandatory) (Options: first-action=promote then-action=start)

Apache and the file system should be running on the same node

[jensd@node01 ~]$ sudo pcs -f add_fs constraint colocation add webserver webserver_fs INFINITY

The file system needs to be made available before Apache is started:

[jensd@node01 ~]$ sudo pcs -f add_fs constraint order webserver_fs then webserver
Adding webserver_fs webserver (kind: Mandatory) (Options: first-action=start then-action=start)

Next step is to acutally apply the changes which we made in the cib-file on the actual running configuration:

[jensd@node01 ~]$ sudo pcs cluster cib-push add_fs
CIB updated

Normally, the actions should be performed immediately but I had to stop and start the cluster in order to get things working but this should be the result:

[jensd@node01 ~]$ sudo pcs status
Cluster name: cluster_web
Last updated: Fri Nov 21 15:05:22 2014
Last change: Fri Nov 21 15:05:13 2014 via cibadmin on node01
Stack: corosync
Current DC: node01 (1) - partition with quorum
Version: 1.1.10-32.el7_0.1-368c726
2 Nodes configured
5 Resources configured

Online: [ node01 node02 ]

Full list of resources:

 virtual_ip     (ocf::heartbeat:IPaddr2):       Started node01
 webserver      (ocf::heartbeat:apache):        Started node01
 Master/Slave Set: webserver_data_sync [webserver_data]
     Masters: [ node01 ]
     Slaves: [ node02 ]
 webserver_fs   (ocf::heartbeat:Filesystem):    Started node01

As the output shows, the DRBD master has become node01 and all resources were started on that node. Our constraints made sure that before the webserver was started, the virtual IP was available and that the DRBD-resource was mounted and available.

To be sure that the DRBD configuration went fine, we can check if our filesystem-resource did it’s work:

[jensd@node01 ~]$ mount|grep drbd0
/dev/drbd0 on /var/www/html type xfs (rw,relatime,seclabel,attr2,inode64,noquota)
[jensd@node01 ~]$ ls -al /var/www/html/
total 0
drwxr-xr-x. 3 root root 35 Nov 21 15:07 .
drwxr-xr-x. 4 root root 31 Nov 21 10:33 ..
-rw-r--r--. 1 root root  0 Nov 21 12:26 f1
-rw-r--r--. 1 root root  0 Nov 21 12:26 f2
drwxr-xr-x. 2 root root  6 Nov 21 12:26 test

Finally, we can add data for our website to the mount: Let’s start with creating an index.html on our DRBD file system:

[jensd@node02 ~]$ sudo vi /var/www/html/index.html
[jensd@node02 ~]$ cat /var/www/html/index.html
<html>
 <h1>DRBD</h1>
</html>

When stopping node01, everything should switch to node02 including the data which we just modified on node01:

[jensd@node01 ~]$ sudo pcs cluster stop
Stopping Cluster…

[jensd@node02 ~]$ sudo pcs status
Cluster name: cluster_web
Last updated: Fri Nov 21 15:12:27 2014
Last change: Fri Nov 21 15:05:13 2014 via cibadmin on node01
Stack: corosync
Current DC: node02 (2) - partition with quorum
Version: 1.1.10-32.el7_0.1-368c726
2 Nodes configured
5 Resources configured

Online: [ node02 ]
OFFLINE: [ node01 ]

Full list of resources:

 virtual_ip     (ocf::heartbeat:IPaddr2):       Started node02
 webserver      (ocf::heartbeat:apache):        Started node02
 Master/Slave Set: webserver_data_sync [webserver_data]
     Masters: [ node02 ]
     Stopped: [ node01 ]
 webserver_fs   (ocf::heartbeat:Filesystem):    Started node02

When checking the website, we get the modified webpage:

[jensd@node02 ~]$ curl http://192.168.202.100
<html>
 <h1>DRBD</h1>
</html>

The above example was made for a webserver but can be used for various other services too. Unfortunately DRBD isn’t really supported as it should on RHEL or CentOS (at least not for free) so we need to perform some additional steps in order to get things working.