Обзор Pacemaker (перепечатка)

[Marley]

Pacemaker
Проект сайта: clusterlabs.org


Вводные статьи:
http://habrahabr.ru/blogs/sysadm/107837/
http://olemskoi.ru/node/6108


Статьи для углубленного изучения:

Cluster from Scratch развернутый пример установки и настройки с краткими пояснениями;
Pacemaker Explained полное, исчерпывающее описание всех настроек с примерами;
CRM command line interface описание шелла crm;


Pacemaker

Clusters from Scratch (OpenAIS)

[Marley]

Pacemaker набор утилит от ClusterLabs для управления распределением ресурсов вычислительного кластера.

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

Если говорить кратко, Pacemaker работает по принципу Heartbeat, только расширяет его функциональность до высоких высот. Во-первых, Pacemaker может управлять более чем двумя узлами кластера, во-вторых, мониторить состояние ресурсов, в-третьих, позволяет ресурсы клонировать. И еще много-много чего другого.

Согласно официальной документации, Pacemaker это менеджер ресурсов кластера со следующими основными фичами:

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

Pacemaker представляет из себя конгломерат из пакетов Pacemaker, Corosyc, OpenAIS, Heartbeat. Pacemaker использует транспорт сообщений Corosync/OpenAIS либо Heartbeat для взаимодействия между узлами кластера. При этом действующий транспорт в кластере может быть только одного типа: либо Corosync/OpenAIS, либо Heartbeat.


Не смотря на то, что предпочтительным транспортом является Corosync, пакет Heartbeat так же должен быть установлен, поскольку он включает в себя достаточно большое количество OCF скриптов для управления ресурсами кластера.

За работу Pacemaker в CentOS отвечают два LSB-скрипта:

/etc/init.d/corosync
/etc/init.d/openais

За конфигурацию Pacemaker на отдельной ноде отвечают файлы:

/etc/corosync/corosync.conf - конфигурация corosync
/etc/corosync/authkey - авторизационный ключ для работы в кластере
/etc/corosync/service.d/pcmk - файл для связки corosync и pacemaker

Конфигурация кластера представляет из себя единый внутренний файл, изменения в который можно вносить на любой ноде с помощью утилиты crm. Изменения распространяются по другим нодам в качестве diffов автоматически.

За конфигурацию кластера отвечает единая консольная утилита crm.
Мониторинг состояния кластера: crm status мгновенный слепок состояния, crm_mon реалтайм мониторинг из консоли.

[Marley]

Основные понятия

Узлы (ноды,nodes) кластера

Узел (нода,node) кластера представляет из себя машину с установленным Pacemaker и включенным в состав кластера.

Управление нодами кластера осуществляется через команду crm node:

crm node standby node1 - переключить node1 в режим простоя
crm node online node1 - переключить node1 в рабочий режим
crm node fence node1 - убить (выключить) при помощи STONITH node1
crm node help - справка по операциям с узлами

Узлы, предназначенные для выполнения одинаковых ресурсов должны иметь одинаковую конфигурацию софта, который используется ресурсами. То есть, если ресурс res1 ocf:heartbeat:apache предполагается запускать на узлах node1,node2,node3 и он использует определенный нестандартный модуль mod_rpaf, то все три узла должны иметь установленный apache и mod_rpaf одинаковых версий. Это исключает ситуацию, когда ресурс при перемещении между узлами может запуститься на одном ушле и не может на другом.

Ресурсы

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

Ресурс может представлять из себя:

• IP адрес
• Демон с определенной конфигурацией
• Блочное устройство
• Файловую систему
• etc

Каждый ресурс представляет из себя LSB/OCF скрипт, который должен обрабатывать минимум три параметра: start,stop,monitor, выдавая корректные коды возврата.

Управление ресурсами осуществляется через команду crm resource:

• crm resource stop resource1 - остановить ресурс resource1
• crm resource start resource1 - запустить ресурс resource1
• crm resource move resource1 node2 - принудительно переместить ресурс resource1 на node2
• crm resource cleanup resource1 - удалить счетчики сбоев ресурса resource1 со всех узлов
• crm resource cleanup resource1 node2 - удалить счетчики сбоев ресурса resource1 с узла node2
• crm resource help - справка по доступным действиям

Создание ресурсов осуществляется через crm configure primitive .

Создание ресурса веб сервера apache из скрипта OCF apache осуществляется командой:

crm configure primitive sites-httpd ocf:heartbeat:apache params \
configfile="/cluster/conf/httpd-sites/conf/httpd.conf" httpd="/usr/sbin/httpd" port="85" \
statusurl="http://127.0.0.1:85/server-status" testregex="Apache" op monitor interval="30s"

Где

sites-httpd имя ресурса
ocf:heartbeat:apache расположение скрипта ресурса. ocf тип скрипта (ocf или lsb), heartbeat набор скриптов heartbeat, apache имя скрипта. OCF скрипты располагаются в /usr/lib/ocf.
configfile, httpd, port, statusurl, testregex набор параметров OCF скрипта. Их имена, семантика и использование индивидуальны для каждого скрипта.
op monitor interval=»30s» применять к скрипту операцию monitor каждые 30 секунд. В случае если скрипт ocf::apache monitor вернул статус отличный от нуля, осуществляется попытка потушить ресурс и поднять его снова. При определенном количестве сбоев осуществляется решение о перемещении ресурса на другой узел.

Апач очевидно необходимо повесить на определенный IP адрес. По этому необходимо создать ресурс IP адреса:

crm configure primitive sites-ip-ext ocf:heartbeat:IPaddr2 \
params ip="192.168.0.31" cidr_netmask="32" \
op monitor interval="30s"


Однако очевидно что IP адрес и апач должны стартовать последовательно и на одном узле. Для определения таких связей используются Группы ресурсов


Группы ресурсов

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

Например, ресурсы веб-сервера Apache (sites-httpd) и IP адрес для него (sites-ip-ext). Это два ресурса. Очевидно, что Apache не поднимется, если в системе нет определенного для него IP адреса. По этому мы создаем группу sites:

crm configure group sites sites-ip-ext sites-httpd

Теперь в кластере имеется группа под названием sites, включающая в себя два ресурса. К группе можно обращаться как к отдельному ресурсу: перемещать, устанавливать связи и свойства.
Вес связи

Для установки предпочтений связей используется вес связей от -INFINITY до +INFINITY. Установка с весом -INFINITY или +INFINITY является жесткой. Вес +/- INFINITY не может оспариваться другими условиями. Вес в целочисленном представлении может.
location

Директивой location можно определить предпочтительный запуск определенного ресурса/группы на определенном узле.

Установка предпочтения запуска ресурса httpd с весом 50 на node1 и весом 100 на node2:

crm configure location httpd-prefer-node1 httpd rule 50: node1
crm configure location httpd-prefer-node2 httpd rule 100: node2

Установка жесткого запуска ресурса httpd сугубо на node1 (ахтунг! при сбое ресурса его миграция на другие ноды будет весьма затруднена!):

crm configure location httpd-prefer-node1 httpd rule INFINITY: node1

Ресурс httpd не должен вообще никогда запускаться на node2:

crm configure location httpd-prefer-node1 httpd rule -INFINITY: node2

colocation

Директивой colocation можно определить предпочтительный запуск определенных ресурсов/групп вместе на одном узле.

Запускать ресурсы WebSite ClusterIP только на одном узле

crm configure colocation website-with-ip INFINITY: WebSite ClusterIP

Никогда не запускать ресурсы nginx и apache на одном узле

crm configure colocation nginx-not-apache -INFINITY: nginx apache

[Marley]

Установка

Нужно убедиться что:

• IP и hostname ноды взаимно отвечают друг другу в DNS на A и PTR запросы.
• Настроена ssh авторизация по публичному ключу между узлами кластера.
• SELinux выключен
• Временная зона на всех нодах одинакова и время синхронизировано

Подключаем репозиторий ClusterLabs и устанавливаем софт:

cd /etc/yum.repos.d
wget http://www.clusterlabs.org/rpm/epel-5/clusterlabs.repo
yum install pacemaker corosync openais

Содержимое файла /etc/corosync/corosync.conf:

# Please read the corosync.conf.5 manual page
compatibility: whitetank
 
totem {
        version: 2
        secauth: off
        threads: 0
        interface {
                ringnumber: 0
                bindnetaddr: 192.168.0.0
                mcastaddr: 239.192.1.1
                mcastport: 4000
#               broadcast yes
        }
}
 
logging {
        fileline: off
        to_stderr: no
        to_logfile: yes
        to_syslog: yes
        syslog_facility: local2
        logfile: /var/log/corosync.log
        debug: off
        timestamp: on
        logger_subsys {
                subsys: AMF
                debug: off
        }
}
 
amf {
        mode: disabled
}

Где:

bindnetaddr Сеть класса С для внутренних коммуникаций, это не IP адрес ноды, это сеть /24, в котором он находится
mcastaddr, mcastport адрес и порт для мультикастовых сообщений

Файл /etc/corosync/authkey суть случайная последовательность байт длинной около 128 байт, должен быть одинаковый для всех нод кластера. Следовательно, для первой ноды кластера мы его создаем

dd if=/dev/urandom of=/etc/corosync/authkey bs=1 count=128
chmod 600 /etc/corosync/authkey

А для остальных нод кластера мы его просто копируем.

Файл для связки corosync & pacemaker /etc/corosync/service.d/pcmk:

service {
# Load the Pacemaker Cluster Resource Manager
name: pacemaker
ver: 0
}
END

Стартуем:

/etc/init.d/openais start
/etc/init.d/corosync start
chkconfig opeais on
chkconfig corosync on

Убедиться что кластер стартовал можно командой crm status.

[Marley]

Настраиваем сетевые интерфейсы

# vi /etc/sysconfig/network

Указать соответствующий HOSTNAME

HOSTNAME={node1.localdomain | node2.localdomain | node3.localdomain | node4.localdomain}

NETWORKING=yes
NETWORKING_IPV6=no
HOSTNAME=<HOSTNAME>
GATEWAY=192.168.1.1

# vi /etc/resolv.conf

search localdomain 
nameserver 192.168.1.1
options attempts: 2
options timeout: 1

===============================================


node1.localdomain

(public)
# vi /etc/sysconfig/network-scripts/ifcfg-eth0

DEVICE=eth0
ONBOOT=yes
BOOTPROTO=static
IPADDR=192.168.1.11
NETMASK=255.255.255.0

(private)
# vi /etc/sysconfig/network-scripts/ifcfg-eth1

DEVICE=eth1
ONBOOT=yes
BOOTPROTO=static
IPADDR=192.168.2.11
NETMASK=255.255.255.0

# service network restart

===============================================


node2.localdomain

(public)
# vi /etc/sysconfig/network-scripts/ifcfg-eth0

DEVICE=eth0
ONBOOT=yes
BOOTPROTO=static
IPADDR=192.168.1.12
NETMASK=255.255.255.0

(private)
# vi /etc/sysconfig/network-scripts/ifcfg-eth1

DEVICE=eth1
ONBOOT=yes
BOOTPROTO=static
IPADDR=192.168.2.12
NETMASK=255.255.255.0

# service network restart



===============================================


node3.localdomain

(public)
# vi /etc/sysconfig/network-scripts/ifcfg-eth0

DEVICE=eth0
ONBOOT=yes
BOOTPROTO=static
IPADDR=192.168.1.13
NETMASK=255.255.255.0

(private)
# vi /etc/sysconfig/network-scripts/ifcfg-eth1

DEVICE=eth1
ONBOOT=yes
BOOTPROTO=static
IPADDR=192.168.2.13
NETMASK=255.255.255.0

# service network restart



===============================================


node4.localdomain

(public)
# vi /etc/sysconfig/network-scripts/ifcfg-eth0

DEVICE=eth0
ONBOOT=yes
BOOTPROTO=static
IPADDR=192.168.1.14
NETMASK=255.255.255.0

(private)
# vi /etc/sysconfig/network-scripts/ifcfg-eth1

DEVICE=eth1
ONBOOT=yes
BOOTPROTO=static
IPADDR=192.168.2.14
NETMASK=255.255.255.0

# service network restart

[Marley]

Создаю файл hosts на первой ноде

# vi /etc/hosts

## Localdomain and Localhost (hosts file, DNS)

127.0.0.1 localhost.localdomain localhost


## eth0 Public Network (hosts file, DNS)

192.168.1.11 node1.localdomain node1
192.168.1.12 node2.localdomain node2
192.168.1.13 node3.localdomain node3
192.168.1.14 node4.localdomain node4


## eth1 Interconnect Private Network  (hosts file, DNS)


192.168.2.11 node1-interconnect
192.168.2.12 node2-interconnect
192.168.2.13 node3-interconnect
192.168.2.14 node4-interconnect

-----------------------------------------------
scp /etc/hosts node2:/etc/hosts
scp /etc/hosts node3:/etc/hosts
scp /etc/hosts node4:/etc/hosts

[Marley]

// Уменьшили время для выбора ядра пользователем.
# vi /etc/grub.conf
timeout=1


# vi /etc/selinux/config
SELINUX=disabled

[Marley]

Настраиваем secure shell (ssh) на 4 узлах

1) Создаем на серверах каталоги
[[email protected] ~]# mkdir /root/.ssh/
[[email protected] ~]# ssh node2 mkdir /root/.ssh/
[[email protected] ~]# ssh node3 mkdir /root/.ssh/
[[email protected] ~]# ssh node4 mkdir /root/.ssh/

2) Генерируем 2 ключа, приватный и публичный. Ключи создаются в каталоге /root/.ssh/

// На все вопросы отвечаю Enter
[[email protected] ~]# ssh-keygen -t dsa

// Результат 2 ключа
[[email protected] ~]# ls /root/.ssh/
id_dsa id_dsa.pub known_hosts

[[email protected] ~]# cat /root/.ssh/id_dsa.pub >>/root/.ssh/authorized_keys

// Теперь мы должны скопировать на второй сервер публичный ключ

[[email protected] .ssh]# scp /root/.ssh/authorized_keys node2:/root/.ssh/

====================

[[email protected] /]# ssh node2

Повторяем данные операции, но уже на другом сервере

Генерируем ключи
[[email protected] ~]# ssh-keygen -t dsa
[[email protected] ~]# cat /root/.ssh/id_dsa.pub >>/root/.ssh/authorized_keys
[email protected] ~]# scp /root/.ssh/authorized_keys node3:/root/.ssh/

====================

[[email protected] ~]# ssh node3
[[email protected] ~]# ssh-keygen -t dsa
[[email protected] ~]# cat /root/.ssh/id_dsa.pub >>/root/.ssh/authorized_keys
[[email protected] ~]# scp /root/.ssh/authorized_keys node4:/root/.ssh/

====================

[[email protected] ~]# ssh node4
[[email protected] ~]# ssh-keygen -t dsa
[[email protected] ~]# cat /root/.ssh/id_dsa.pub >>/root/.ssh/authorized_keys

[[email protected] ~]# scp /root/.ssh/authorized_keys node1:/root/.ssh/
[[email protected] ~]# scp /root/.ssh/authorized_keys node2:/root/.ssh/
[[email protected] ~]# scp /root/.ssh/authorized_keys node3:/root/.ssh/


=====================

[[email protected] ~]# ssh node1

// Стартуем на первом сервере
[[email protected] ~]# exec /usr/bin/ssh-agent $SHELL
[[email protected] ~]# ssh-add

[Marley]

// создаем фал с описанием параметров подключения к репозиторию
# vi /etc/yum.repos.d/centosRepo.repo

[Centos5_extras_PublicRepo]
name=Centos Linux $releasever - $basearch - latest
baseurl=http://mirror.centos.org/centos/5.6/extras/x86_64/
gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5
gpgcheck=1
enabled=1

# vi /etc/yum.repos.d/oracleLinuxRepo.repo

[OEL55_PublicRepo]
name=Enterprise Linux $releasever - $basearch - latest
baseurl=http://public-yum.oracle.com/repo/OracleLinux/OL5/6/base/x86_64/
gpgkey=http://public-yum.oracle.com/RPM-GPG-KEY-oracle-el5
gpgcheck=1
enabled=1

// Для проверки правильности созданного файла, воспользуйтесь командой
# yum list



scp /etc/yum.repos.d/centosRepo.repo node2:/etc/yum.repos.d/centosRepo.repo
scp /etc/yum.repos.d/centosRepo.repo node3:/etc/yum.repos.d/centosRepo.repo
scp /etc/yum.repos.d/centosRepo.repo node4:/etc/yum.repos.d/centosRepo.repo



scp /etc/yum.repos.d/oracleLinuxRepo.repo node2:/etc/yum.repos.d/oracleLinuxRepo.repo
scp /etc/yum.repos.d/oracleLinuxRepo.repo node3:/etc/yum.repos.d/oracleLinuxRepo.repo
scp /etc/yum.repos.d/oracleLinuxRepo.repo node4:/etc/yum.repos.d/oracleLinuxRepo.repo



Устанавливаем дополнительные пакеты (на всех узлах):

[[email protected] ~]#

yum install -y \
mc \
screen \
vsftpd \
xinetd \
net-snmp \
sysstat

[Marley]

Настраиваем планировщик заданий

На всех виртуальных машинах.
Сервера ru.pool.ntp.org выбраны в качестве примера

crontab -e

# Set the date and time via NTP
*/15 * * * * /usr/sbin/ntpdate 0.ru.pool.ntp.org 1.ru.pool.ntp.org 2.ru.pool.ntp.org 3.ru.pool.ntp.org   > /var/log/time.log

Внесите изменения в файл параметров ntpd.

vi /etc/sysconfig/ntpd

замените

# Drop root to id 'ntp:ntp' by default.
OPTIONS="-u ntp:ntp -p /var/run/ntpd.pid"

на

# Drop root to id 'ntp:ntp' by default.
# OPTIONS="-u ntp:ntp -p /var/run/ntpd.pid"
OPTIONS="-x -u ntp:ntp -p /var/run/ntpd.pid"

service ntpd restart