Настройка pacemaker centos 7

Обновлено: 04.07.2024

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

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

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

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

Настройка

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

Запуск

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

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

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

pcs cluster setup -- force -- name CLUSETR node1 node2 node1 : successful distribution of the file 'pacemaker_remote authkey' node2 : successful distribution of the file 'pacemaker_remote authkey' Synchronizing pcsd certificates on nodes node1 , node2 . . . Restarting pcsd on the nodes in order to reload the certificates . . .

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

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

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

где 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

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

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

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

Вообще для Pacemaker ресурс — это скрипт, написанный на любом языке. Обычно эти скрипты пишутся на bash, но ничто не мешает писать их на Perl, Python, C или даже на PHP. Скрипт управляет сервисами в операционной системе. Главное требование к скриптам — уметь выполнять 3 действия: start, stop, monitor и делиться некоторой метаинформацией.

Атрибут 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, могут быть объединены в группу.

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

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

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

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

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, кото­рая поз­во­ля­ет под­клю­чить­ся и посмот­реть, а так же изме­нить конфигурацию

Добавить в избранное

Главное меню » Операционная система CentOS » Как настроить кластер высокой доступности Nginx с помощью Pacemaker на CentOS 7

(1 оценок, среднее: 4,00 из 5)

1. Предпосылки

Для выполнения этой статьи вам необходимо:

• 2 или более серверов
• Операционная система CentOS 7
• Корневой доступ к каждому из серверов

Отредактируйте файл /etc/hosts на сервере, с любого терминала в текстовом редакторе, допустим nano

Добавьте следующие строки в /etc/hosts:

3. Установка репозитория Epel и Nginx

Дополнительные пакеты для Enterprise Linux в хранилище (Epel) необходимо для того, чтобы установить Nginx. Выполните следующие команды на обоих серверах.

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

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

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

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

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

В этом разделе мы установим стек Pacemaker. Вы должны выполнить этот шаг на обоих серверах.

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

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

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

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

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

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

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

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

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

Включите его при загрузке и запустите его.

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

9. Отключение STONITH

STONITH или Shoot другой узел в голове является реализация ограждения на Pacemaker. Если вы находитесь в производстве, лучше включить STONITH. Поскольку мы не используем устройства ограждения, мы отключаем STONITH.

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

no stonith devices and stonith-enabled is not false

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

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

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

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

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

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

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

Далее, мы можем добавить второй ресурс в кластер. Ресурс агент службы ocf:heartbeat:nginx под названием ‘webserver’.

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

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

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

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

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

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

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

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

Поздравляем, вы успешно создали кластер высокой доступности Nginx с помощью Pacemaker. Если у вас есть очень загруженный веб-сайт, вы можете рассмотреть возможность запуска вашего сайта на Nginx HA. Есть много хорошо известных сайтов, работающих на Nginx HA и они используют Nginx HA, чтобы поставлять их содержание быстро, надежно и безопасно.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

В этой статье мы соберем кластер на дистрибутиве Centos 7 с использованием пакета Pacemaker. Сборка из исходников DRBD описывается в этой статье. Настройка реплицируемого блочного устройства описывается в статье по этой ссылке. Для полноценной работы кластера одного DRBD не достаточно, должен быть механизм мониторинга состояния блочных устройств, процессов, сервисов, состояние работы самой операционной системы, сети […]

В этой статье мы соберем кластер на дистрибутиве Centos 7 с использованием пакета Pacemaker.

Дстрибутив будем использовать CentOS-7-x86_64-Minimal-1908 и DRBD версии 9.

Для полноценной работы кластера одного DRBD не достаточно, должен быть механизм мониторинга состояния блочных устройств, процессов, сервисов, состояние работы самой операционной системы, сети ит.д. Также должен быть механизм репликации диска на другую ноду в случае отказа первой. Также в некоторых случаях используется один общий виртуальный ip адрес на нодах для возможности функционирования кластера как единая система. Этими функциями DRBD не занимается.

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

Вышеописанными задачами занимается Pacemaker – менеджер ресурсов кластера.

Pacemaker состоит из 5 ключевых компонентов:

1. CIB – Cluster Information Base это база данных которая содержит конфигурацию кластера и состояние ресурсов кластера. Сама база данных храниться в файле в формате XML

Отдельно редактировать файл ни в коем случае нельзя, редактирование происходит с помощью самого pacemaker. Иначе вы рискуете остаться без рабочего кастера.

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

3. PEngine – механизм политики. Он рассчитывает идеальное состояние кластера. Если какой либоо механизм дал сбой, PEngine сделает перерасчет механизма работы всего кластера и передаст его в CRMd

4. CRMd – демон управления ресурсами кластера. PEngine выбирает CRMd на какой-то одной ноде. В случае сбоя забочей ноды с CRMd быстро назначается новая нода как главная. Главная CRMd получает инструкции от PEngine и передает их в требуемом порядке или LRMd (демон локального управления) или одноранговым CRMd на других нодах, а те в свою очередь LRMd своего локального процесса.

5. LRMd – демон управления локальными ресурсами который исполняет полученные инструкции от CRMd на локальной машине, а также передает обратно результат их выполнения.

Главный CRMd называется DC (Designated Controller) – назначенный контроллер

Ключевые компоненты из которых состоит Pacemaker

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

Также нужно настроить имя хостовой машины и DNS для общения серверов по имени

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

Исходные параметры первой ноды

Первый интерфейс 192.168.32.20 (доступ в локальную сеть)

Второй интерфейс 10.10.10.1 (интерфейс для общения нод)

Исходные данные второй ноды:

Первый интерфейс 192.168.32.19 (доступ в локальную сеть)

Второй интерфейс 10.10.10.2 (интерфейс для общения нод)

Для изменения имени хоста без перезагрузки сервера воспользуемся утилитой hostnamctl

После указания имени хоста необходимо в файле /etc/hosts прописать Ip адрес и hostname противоположных атс.

На первой ноде добавляем

На второй ноде добавляем

Пример файла /etc/hosts со второй ноды.

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

Результат должен быть как на скриншоте (пример с одной ноды):

пинг со второй ноды.

Перед наxалом установки убедитесь, что отключен SELINUX

Проверка статуса Selinux

Включенный Selinux

Для выключения Selinux необходимо в конфигурационном файле /etc/selinux/config прописать SELINUX=disabled

Отключение Selinux

Далее приступим к установке необходимых пакетов для сборки кластера:

Где pacemaker описан выше, менеджер ресурсов кластера. Он позволяет использовать службы и объекты в рамках одного кластера из двух или более нод.

Resource-agent – этот пакет содержит агенты ресурсов(набор скриптов) кластера (RA), соответствующие спецификации Open Cluster Framework (OCF), используемые для взаимодействия с различными службами в среде высокой доступности, управляемой менеджером ресурсов Pacemaker.

Corosync – информационный уровень. программный продукт, который позволяет создавать единый кластер из нескольких аппаратных или виртуальных серверов. Corosync отслеживает и передает состояние всех участников (нод) в кластере.

Этот продукт позволяет:

Pcs – pacemaker/corosync configuration system. Утилита для управления, настройки и мониторинга кластера. Управляется как через командную строку, так и через веб интерфейс.

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

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

Отключение и остановка фаервола

На следующем этапе запустим на обеих нодах pcs демон:

После установки pcs на обоих нодах будут созданы пользователи «hacluster»

С помощью этих учеток ноды будут «общаться между собой». Зададим для них новые сложные пароли:

создание пароля для учетной записи hacluster

Далее с помощью pcs авторизуемся на обоих нодах:

Авторизация на всех нодах с помощью pcs

На следующем шаге создаем кластер:

Эта команда создаст кластер, автоматически сгенерирует конфигурационный файл corosync.

После успешного создания кластера его необходимо запустить следующей командой:

Запуск кластера.

Как видно из скриншота, запускается corosync и pacemaker.

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

Читайте также:

  
• Wisptis как удалить windows 7
  
• Образы windows 7 для установки с флешки
  
• Не устанавливается defender windows
  
• Курсор как в сталкере windows 10 как установить
  
• Scripteddiagfailure windows 10 что это