Це комплекс демонів, які власне і забезпечують все вищесказане.
Даний комплекс базується чи частково використовує попередні розробки типу Heartbeat чи OpenAIS.
На малюнку зображено архітектуру Pacemaker і ось, якщо говорити коротко, що до неї входить:
1. Не кластерні компоненти (зображені зеленим кольором) - це ресурси та скрипти, що відповідають за їхній старт, зупинку чи моніторинг.
2. Менеджер ресурсів Pacemaker (зображений синім кольором) - "мозок" кластера, проводить обробку подій та процесів (даних, що представили нижчі рівні) та приймає рішення щодо включення/виключення нод із кластеру. Власне Pacemaker розраховує ідеальний стан кластеру шляхом слідування правилам.
3. Інфраструктура низького рівня (зображено червоним), до якої входить Corosync. Corosync забезпечує обмін повідомленнями з Pacemaker щодо стану серверів в кластері (який із серверів працює чи ні і т.д. )
Будемо вважати, що мережа вже налаштована і обидва сервери мають статичні IP. Приклад налаштування мережі для першого серверу pcmk-1:
Для початку опишемо конфігурацію, котру маємо:
Node-1:
Hostname: pcmk-1
IP: 192.168.1.23
Node-2:
Hostname: pcmk-2
IP: 192.168.1.24
На обох серверах встановлено CentOS 6.3 зі стандартним ядром 2.6.32. Нехай на кожному сервері працює Apache і необхідно, щоб у разі падіння одного з серверів відбувався failover, тобто перемикання на працюючий сервер. Як наслідок такий варіант забезпечить максимальну доступність, лише піде деякий час на перемикання нод.
Node-1:
Hostname: pcmk-1
IP: 192.168.1.23
Node-2:
Hostname: pcmk-2
IP: 192.168.1.24
На обох серверах встановлено CentOS 6.3 зі стандартним ядром 2.6.32. Нехай на кожному сервері працює Apache і необхідно, щоб у разі падіння одного з серверів відбувався failover, тобто перемикання на працюючий сервер. Як наслідок такий варіант забезпечить максимальну доступність, лише піде деякий час на перемикання нод.
Переходимо до конфігурації. Редагуємо /etc/hosts (чи свій власний dns, якщо такий є) задля перетворення доменних імен в IP:
# grep pcmk /etc/hosts
192.168.1.23 pcmk-1
192.168.1.24 pcmk-2
# cat /etc/sysconfig/network
NETWORKING=yes
HOSTNAME=pcmk-1
GATEWAY=192.168.1.1
DEVICE=eth0
ONBOOT=yes
BOOTPROTO=static
IPADDR=192.168.1.23
NETMASK=255.255.255.0
Досить важливим є наявність NTP-синхронізації часу на обох серверах. Саме це значно спростить життя у випадку перевірки логів операцій на обох серверах.
Інсталюємо програмне забезпечення для кластера на кожній із нод pcmk-1 та pcmk-2:
# yum install -y pacemaker corosync
Після успішного встановлення переходимо до налаштування Corosync:
# cat /etc/corosync/corosync.conf
compatibility: whitetank
totem {
version: 2
secauth: off
threads: 0
interface {
ringnumber: 0
bindnetaddr: 192.168.1.0
mcastaddr: 239.255.1.1
mcastport: 4000
ttl: 1
}
}
logging {
fileline: off
to_stderr: no
to_logfile: yes
to_syslog: yes
logfile: /var/log/cluster/corosync.log
debug: off
timestamp: on
logger_subsys {
subsys: AMF
debug: off
}
}
amf {
mode: disabled
}
quorum {
provider: corosync_votequorum
expected_votes: 2
}
bindnetaddr - адреса мережі, в якій знаходяться хости.
mcastaddr - мультикаст адреса
quorum - налаштування голосування нод; мінімум нод при яких можливе голосування - 2.
Редагуємо/створюємо файл /etc/corosync/service.d/pcmk:
# cat /etc/corosync/service.d/pcmk
service {
# Load the Pacemaker Cluster Resource Manager
name: pacemaker
ver: 1
}
Він необхідний для сумісної роботи Pacemaker та Сorosync.
Зрозуміло, що конфігураційні файли мають бути ідентичним на обох хостах майбутнього кластеру.
Для управління кластером можна використовувати дві консолі: pcs та crmsh. Надалі піде мова саме про crmsh.
Перевірити версію Pacemaker можна таким чином:
# pacemakerd --features
Pacemaker 1.1.7-6.el6 (Build: 148fccfd5985c5590cc601123c6c16e966b85d14)
Supporting: generated-manpages agent-manpages ascii-docs publican-docs ncurses trace-logging libqb corosync-plugin cman
Для CentOS демон corosync запускається так:
# service corosync start
Для перевірки чи правильно налаштований corosync, виконаємо:
# corosync-cfgtool -s
Printing ring status.
Local node ID 385984704
RING ID 0
id = 192.168.1.23
status = ring 0 active with no faults
Наявність статичного айпі та "no faults" говорять самі за себе. Власне аналогічну перевірку можна провести на другому сервері pcmk-2 кластера.
Нарешті запускаємо менеджер кластера на обох нодах:
# service pacemaker start
Головна програма для моніторингу стану кластера - це crm_mon (crm status).Якщо старт пройшов без помилок можна переглянути статус кластера:
# crm status
============
Last updated: Tue Jan 15 06:18:49 2013
Last change: Mon Jan 14 17:18:53 2013 via crmd on pcmk-2
Stack: openais
Current DC: pcmk-1 - partition with quorum
Version: 1.1.7-6.el6-148fccfd5985c5590cc601123c6c16e966b85d14
2 Nodes configured, unknown expected votes
0 Resources configured.
============
Online: [ pcmk-2 pcmk-1 ]
Конфігураційні файли представляють собою звичайні XML, проте правити їх вручну НЕ МОЖНА, адже вони підлягають версійності; кластер налаштовують за допомогою консолі crmsh або pcs.
Для початку просто переглянемо початковий конфіг:
# crm configure show
node pcmk-1node pcmk-2
property $id="cib-bootstrap-options" \
dc-version="1.1.7-6.el6-148fccfd5985c5590cc601123c6c16e966b85d14" \
cluster-infrastructure="openais"
Зрозуміло, що це тільки тести і сервера не підуть в продакшен, тому ми можемо поки вимкнути STONITH:
# crm configure property stonith-enabled=false
Після цього можна перевірити вірність нашої конфігурації, виконавши команду:
# crm_verify -L
Переходимо до конфігурації ресурсів кластеру. Що таке ресурс на думку Pacemaker? Будь-що, що може бути заскриптовано задля опису його поведінки. Зазвичай скрипти пишуться на bash, але ніщо не заважає вам писати їх на Perl, Python або навіть C. Загалом скрипти повинні відповідати стандарту LSB (Linux Standard Base) або OCF (Open Framework Cluster) - останнє дещо розширює LSB, вимагаючи також передачі параметрів через змінні оточення з особливливою назвою.
Ресурсом може бути:
- IP адреса
- Демон з певною конфігурацією
- Блочний пристрій
- Файлова система
- тощо.
Кожен ресурс представляє собою LSB / OCF скрипт, який повинен обробляти як мінімум три параметри: start, stop, monitor, видаючи коректні коди повернення.
Коротше кажучи, ресурсом являється те, що ви плануєте моніторити. Наприклад, скрипт ocf:heartbeat:apache, в який через crmsh задаються параметри моніторингу (частота моніторингу, адреса конфігураційного файлу тощо ) Apache серверів і буде в результаті ресурсом.
Для початку необхідно описати віртуальну айпі-адресу (VIP), котра буде переміщатись із сервера, що упав, на працюючий сервер.
# crm configure primitive ClusterIP ocf:heartbeat:IPaddr2 \
params ip=192.168.1.30 cidr_netmask=32 \
op monitor interval=25s
Було створено новий ресурс ClusterIP, де ocf — клас скрипта, heartbeat — його провайдер, IPaddr2 — назва скрипта. З айпі та маскою підмережі має бути все зрозуміло.
Перевірити які класи скриптів підтримує Pacemker/Corosync можна таким чином:
# crm ra classes
heartbeat
lsb
ocf / heartbeat pacemaker redhat
stonith
А так - типи агентів, що підтримуються класами:
# crm ra list ocf heartbeat
....
nfsserver nginx oracle oralsnr pgsql pingd portblock postfix proftpd rsyncd scsi2reservation sfex symlink syslog-ng tomcat vmware
Нарешті ми можемо перевірити, конфігурацію кластера з VIP та статус кластера:
# crm configure show
node pcmk-1
node pcmk-2 \
primitive ClusterIP ocf:heartbeat:IPaddr2 \
params ip="192.168.1.30" cidr_netmask="32" \
op monitor interval="25s"
stonith-enabled="false"
# crm_mon -1
Online: [ pcmk-1 pcmk-2 ]
ClusterIP (ocf::heartbeat:IPaddr2): Started pcmk-1
Як бачимо з виводу, ресурс ClusterIP наразі на хості pcmk-1. Перевірити правильність міграції ресурса (айпі адреси) можна шляхом зупинки corosync/pacemaker на першій ноді.
Власне не має сенсу використовувати правила кворуму, якщо в кластері лише два
сервери, тому розумно буде його вимкнути:
# crm configure property no-quorum-policy=ignore
Щоб зменшити ймовірність перебігу айпішника (або ж іншого ресурсу) назад в разі відновлення одного із серверів розумно змінити дефолтне значення параметра resource-stickiness:
Описуємо наступний ресурс WebSite. Для цього будемо використовувати OCF-сценарій, під назвою apache у просторі імен heartbeat.
node pcmk-2 \
primitive ClusterIP ocf:heartbeat:IPaddr2 \
params ip="192.168.1.30" cidr_netmask="32" \
op monitor interval="25s"
property $id="cib-bootstrap-options" \
dc-version="1.1.7-6.el6-148fccfd5985c5590cc601123c6c16e966b85d14" \
cluster-infrastructure="openais" \ stonith-enabled="false"
# crm_mon -1
============
Last updated: Tue Jan 15 18:06:02 2013
Last change: Tue Jan 15 11:33:41 2013 via crmd on pcmk-1
Stack: openais
Current DC: pcmk-1 - partition with quorum
Version: 1.1.7-6.el6-148fccfd5985c5590cc601123c6c16e966b85d14
2 Nodes configured, 1 expected votes
2 Resources configured.
============
Online: [ pcmk-1 pcmk-2 ]
ClusterIP (ocf::heartbeat:IPaddr2): Started pcmk-1
Як бачимо з виводу, ресурс ClusterIP наразі на хості pcmk-1. Перевірити правильність міграції ресурса (айпі адреси) можна шляхом зупинки corosync/pacemaker на першій ноді.
сервери, тому розумно буде його вимкнути:
# crm configure property no-quorum-policy=ignore
Щоб зменшити ймовірність перебігу айпішника (або ж іншого ресурсу) назад в разі відновлення одного із серверів розумно змінити дефолтне значення параметра resource-stickiness:
# crm configure rsc_defaults resource-stickiness=100
Підсумуємо: наразі у нас є віртуальний IP, наявність якого моніториться за допомогою Pacemaker/Corosync і в разі падіння ноди/сервісів VIP "переїде" на іншу ноду. Отже, фінальна конфігурація має виглядати так:
# crm configure show
node pcmk-1
node pcmk-2 \
primitive ClusterIP ocf:heartbeat:IPaddr2 \
params ip="192.168.1.30" cidr_netmask="32" \
op monitor interval="25s"
property $id="cib-bootstrap-options" \
dc-version="1.1.7-6.el6-148fccfd5985c5590cc601123c6c16e966b85d14" \
cluster-infrastructure="openais" \
stonith-enabled="false"
no-quorum-policy="ignore"
rsc_defaults $id="rsc-options" \
resource-stickiness="100"
Надалі спробуємо додати ресурс, що відповідатиме за роботу веб-серверу Apache. Для початку встановимо необхідний софт:
# yum install -y httpd wget
Відредагуємо index.html, котрий показує Apache по замовчуванню:
# cat <<-END >/var/www/html/index.html
<html>
<body>My Test Site - pcmk-1</body>
</html>
END
Для другої ноди все аналогічно, але з назвою хоста pcmk-2. Все це робимо для того, щоб ідентифікувати активну ноду в кластері, просто завантаживши сторінку в браузері.
Редагуємо конфіг веб-сервера /etc/httpd/conf/httpd.conf, цей блок обов'язково має бути присутнім, адже по статусу сторінок Pacemaker перевірятиме роботу сайту і мігруватиме на іншу веб-ноду у разі потреби:
<Location /server-status>
SetHandler server-status
Order deny,allow
Deny from all
Allow from 127.0.0.1
</Location>
Описуємо наступний ресурс WebSite. Для цього будемо використовувати OCF-сценарій, під назвою apache у просторі імен heartbeat.
# crm configure primitive WebSite ocf:heartbeat:apache \
params configfile=/etc/httpd/conf/httpd.conf \
statusurl="http://localhost/server-status" \
op monitor interval=1min
Після налаштування ресурсу, crmsh може видати WARNING на зразок такого:
WARNING: WebSite: default timeout 20s for start is smaller than the advised 40s
WARNING: WebSite: default timeout 20s for stop is smaller than the advised 60s
Тому змінимо дефолтні пераметри виконавши:
# crm configure op_defaults timeout=240s
В результаті ми можемо споглядати такий результат:
# crm configure show
node pcmk-1
node pcmk-2 \
primitive ClusterIP ocf:heartbeat:IPaddr2 \
params ip="192.168.1.30" cidr_netmask="32" \
op monitor interval="25s"primitive WebSite ocf:heartbeat:apache \
params configfile="/etc/httpd/conf/httpd.conf" statusurl="http://localhost/server-status" \
op monitor interval="1min"
property $id="cib-bootstrap-options" \
dc-version="1.1.7-6.el6-148fccfd5985c5590cc601123c6c16e966b85d14" \
cluster-infrastructure="openais" \
stonith-enabled="false" \
no-quorum-policy="ignore"
rsc_defaults $id="rsc-options" \
resource-stickiness="100"
op_defaults $id="op-options" \
timeout="240s"
І такий статус кластера:
# crm_mon -1
============
Last updated: Thu Jan 17 03:52:25 2013
Last change: Thu Jan 17 03:38:48 2013 via crmd on pcmk-1
Stack: openais
Current DC: pcmk-1 - partition with quorum
Version: 1.1.7-6.el6-148fccfd5985c5590cc601123c6c16e966b85d14
2 Nodes configured, 2 expected votes
2 Resources configured.
============
Online: [ pcmk-2 pcmk-1 ]
ClusterIP (ocf::heartbeat:IPaddr2): Started pcmk-2
WebSite (ocf::heartbeat:apache): Started pcmk-1
Вас мабуть має насторожити той факт, що ресурс VIP лишився на одній веб-ноді, а ресурс веб-сервера - на іншій. У такому випадку вебсайт не буде завантажуватись у разі звернення до нього по VIP, що власне нівелює всю суть кластера. Але це не проблема, адже можна указати, щоб ресурси ClusterIP та WebSite переходили парами у разі проблеми:
# crm configure colocation website-with-ip INFINITY: WebSite ClusterIP
Також дуже важливий порядок міграції ресурсів: якщо ж айпі перейде на іншу ноду після запуску Apache - то бажаного результату ми не отримуємо, адже Apache буде доступний лише по наявним IP на момент запуску. Тому, потрібно вказати порядок підняття ресурсів у разі міграції:
# crm configure order apache-after-ip mandatory: ClusterIP WebSite
У разі несиметричності кластера (різне залізо) можна вказати якому із сереверів надавати перевагу у разі міграції ресурсів:
# crm configure location prefer-pcmk-1 WebSite 50: pcmk-1
У разі проведення сервісного обслуговування на сервері чи чогось такого є можливість власноруч перемістити ресурс:
# crm resource move WebSite pcmk-2
У даному випадку спрацює правило colocation, яке ми вказали раніше - тому на pcmk-2 перейде таож і ресурс ClusterIP.
Якщо потрібно зняти правило ручного переведення ноди, варто виконати:
# crm resource unmove WebSite
Надіюсь, що ця стаття була корисною для вас. Буду дуже радий зауваженням чи коментарям.
# crm configure show
node pcmk-1
node pcmk-2 \
primitive ClusterIP ocf:heartbeat:IPaddr2 \
params ip="192.168.1.30" cidr_netmask="32" \
op monitor interval="25s"primitive WebSite ocf:heartbeat:apache \
params configfile="/etc/httpd/conf/httpd.conf" statusurl="http://localhost/server-status" \
op monitor interval="1min"
property $id="cib-bootstrap-options" \
dc-version="1.1.7-6.el6-148fccfd5985c5590cc601123c6c16e966b85d14" \
cluster-infrastructure="openais" \
stonith-enabled="false" \
no-quorum-policy="ignore"
rsc_defaults $id="rsc-options" \
resource-stickiness="100"
op_defaults $id="op-options" \
timeout="240s"
І такий статус кластера:
# crm_mon -1
============
Last updated: Thu Jan 17 03:52:25 2013
Last change: Thu Jan 17 03:38:48 2013 via crmd on pcmk-1
Stack: openais
Current DC: pcmk-1 - partition with quorum
Version: 1.1.7-6.el6-148fccfd5985c5590cc601123c6c16e966b85d14
2 Nodes configured, 2 expected votes
2 Resources configured.
============
Online: [ pcmk-2 pcmk-1 ]
ClusterIP (ocf::heartbeat:IPaddr2): Started pcmk-2
WebSite (ocf::heartbeat:apache): Started pcmk-1
Вас мабуть має насторожити той факт, що ресурс VIP лишився на одній веб-ноді, а ресурс веб-сервера - на іншій. У такому випадку вебсайт не буде завантажуватись у разі звернення до нього по VIP, що власне нівелює всю суть кластера. Але це не проблема, адже можна указати, щоб ресурси ClusterIP та WebSite переходили парами у разі проблеми:
# crm configure colocation website-with-ip INFINITY: WebSite ClusterIP
Також дуже важливий порядок міграції ресурсів: якщо ж айпі перейде на іншу ноду після запуску Apache - то бажаного результату ми не отримуємо, адже Apache буде доступний лише по наявним IP на момент запуску. Тому, потрібно вказати порядок підняття ресурсів у разі міграції:
# crm configure order apache-after-ip mandatory: ClusterIP WebSite
У разі несиметричності кластера (різне залізо) можна вказати якому із сереверів надавати перевагу у разі міграції ресурсів:
# crm configure location prefer-pcmk-1 WebSite 50: pcmk-1
У разі проведення сервісного обслуговування на сервері чи чогось такого є можливість власноруч перемістити ресурс:
# crm resource move WebSite pcmk-2
У даному випадку спрацює правило colocation, яке ми вказали раніше - тому на pcmk-2 перейде таож і ресурс ClusterIP.
Якщо потрібно зняти правило ручного переведення ноди, варто виконати:
# crm resource unmove WebSite
Остаточний статус і конфіг має виглядати таким чином:
# crm_mon -1
============
Last updated: Thu Jan 17 10:18:02 2013
Last change: Thu Jan 17 03:38:48 2013 via crmd on pcmk-1
Stack: openais
Current DC: pcmk-1 - partition with quorum
Version: 1.1.7-6.el6-148fccfd5985c5590cc601123c6c16e966b85d14
2 Nodes configured, 2 expected votes
2 Resources configured.
============
Online: [ pcmk-2 pcmk-1 ]
ClusterIP (ocf::heartbeat:IPaddr2): Started pcmk-2
WebSite (ocf::heartbeat:apache): Started pcmk-2
# crm configure show
node pcmk-1
node pcmk-2 \
attributes standby="off"
primitive ClusterIP ocf:heartbeat:IPaddr2 \
params ip="192.168.1.30" cidr_netmask="32" \
op monitor interval="25s"
primitive WebSite ocf:heartbeat:apache \
params configfile="/etc/httpd/conf/httpd.conf" statusurl="http://localhost/server-status" \
op monitor interval="1min"
location prefer-pcmk-1 WebSite 50: pcmk-1
colocation website-with-ip inf: WebSite ClusterIP
order apache-after-ip inf: ClusterIP WebSite
property $id="cib-bootstrap-options" \
dc-version="1.1.7-6.el6-148fccfd5985c5590cc601123c6c16e966b85d14" \
cluster-infrastructure="openais" \
expected-quorum-votes="2" \
stonith-enabled="false" \
no-quorum-policy="ignore"
rsc_defaults $id="rsc-options" \
resource-stickiness="100"
op_defaults $id="op-options" \
timeout="240s"
Надіюсь, що ця стаття була корисною для вас. Буду дуже радий зауваженням чи коментарям.
Немає коментарів:
Дописати коментар