Запрос ЦеныЗапрос Цены
Онлайн ЧатОнлайн Чат
Зона КлиентовЗона Клиентов
КонтактыКонтакты
Скрыть
Live Support
Sales department
Technical Support
Достижение высокой степени доступности при помощи свободного программного обеспечения (часть 2)

[Вступление]

Эта статья является продолжением статьи под названием «Достижение высокой степени доступности при помощи свободного программного обеспечения» .Тут мы опишем процесс конфигурации сравнительно сложного кластера с несколькими узлами (больше двух).

[Архитектура кластера]

Описание

Обычно кластер состоит из четырёх узлов. Давайте назовём их:
Узел_A
Узел_B
Узел_C
Узел_D

На этом кластере будут работать несколько служб:
1. Служба HTTP1
VIP со службой Apache.
2. Служба HTTP 2
VIP со службой Nginx
3. Служба HTTP 3
VIP со службой Apache
4. Служба MySQL
Мы только настроим MySQL VIP. Репликация MySQL должна быть настроена вручную и службы MySQL надо запускать вручную.
5. Распределённое Копируемое Блочное Устройство (DRBD)
Для того чтобы не использовать rsync для копирования контента с одного сервера на другой, мы будем использовать DRBD для репликации информации.
6. NNFS сервер и клиент
NFS сервер будет экспортировать DRBD, который будет применяться клиентами NFS для остальных узлов.

Какие службы будут запущены на каждом узле в нормальном состоянии в кластере:
- Узел_А: NFS клиент, сервер MySQL
- Узел_B: Служба HTTP 1, NFS клиент
- Узел_C: DRBD (первичная), NFS сервер, служба HTTP 2, MySQL VIP, MySQL сервер
- Узел_D: DRBD (вторичная), служба HTTP 3

Служба на каждом узле должна перебрасываться только на один другой узел в случае отказа. Какая служба должна перебрасываться на какой узел:
Узел_А:
Ничего.
Узел_B:
Служба HTTP 1 1 -> Узел_A
Узел_C:
DRBD (Первичная) -> Узел_D
NFS Сервер -> Узел_D
Служба HTTP 2 -> Узел_D
MySQL VIP -> Узел_A
Узел_D:
Служба HTTP 3 -> Узел_C

На данный момент читатель задастся вопросом: «Почему эта структура настолько сложная?» Ответ следующий:
1Кластер должен состоять из четырёх различных серверов, причём каждый из них должен обладать различными спецификациями:
Узел_А и Узел_В с RHEL 4, четырьмя ядрами, 8 гигабайтами ОЗУ, RAID1 и маленькими дисками на Узле_В.
Узел_С и Узел_D с RHEL 5, двенадцатью ядрами, 12 гигабайтами ОЗУ, RAID 10 и Узел_С с большими дисками.
2.Таким образом можно показать насколько сложный кластер со множеством различных состояний отказа можно построить при помощи хорошего открытого программного обеспечения. Вот схема кластера:

High Availability diagramm

 

[Настройка кластера]

Выбор программного обеспечения кластера
Pacemaker/Heartbeat 3.0. Mon не будет больше применяться, так как Pacemaker/Heartbeat 3.0 способен следить за ресурсами и выполнять необходимые действия (мигрировать ресурс, перезапускать ресурс и так далее).

Настройка Heartbeat
Для начала, установите Pacemaker 1.x и Heartbeat 3.0 с сайта "http://clusterlabs.org".
Создайте /etc/ha.d/ha.cf со следующим содержимым:

# название кластера 
cluster SuperCluster

# логгирование
debug 0
coredumps true
logfacility daemon
logfile /var/log/ha-log

# узлы
node Node_A Node_B Node_C Node_D

# определение высокой доступности 
bcast eth0 eth1

# общие настройки 
keepalive 1
warntime 20
deadtime 40
udpport 694
baud 19200
crm respawn
auto_failback no
respawn hacluster /usr/lib64/heartbeat/ipfail

# авторизация API 
apiauth cibmon uid=hacluster

# мониторинг
ping 192.168.1.1

# связь с узлами 
ucast eth0 192.168.1.193
ucast eth0 192.168.1.194
ucast eth1 10.10.1.141
ucast eth1 10.10.1.142

Код можно изменить при необходимости. Затем следует запустить Heartbeat.

Настройка ресурсов кластера

Служба HTTP 1
Ресурсы: HTTP VIP и служба HTTP (Apache). Оба ресурса будут мониторизироваться на предмет отказа и перезапущены в случае необходимости. Apache будет мониторизироваться при помощи проверки страницы «/server-status» через VIP.<

primitive VIP_192.168.1.10 ocf:heartbeat:IPaddr \
         params ip="192.168.1.10" nic="eth0" cidr_netmask="255.255.255.0" \
         op monitor interval="5s" timeout="20s" start-delay="1s" 
primitive http_1_apache ocf:heartbeat:apache \ 
         params port="80" statusurl="192.168.1.10/server-status" 
         configfile="/etc/httpd/conf/httpd.conf" \ 
         op monitor interval="15" timeout="20" on-fail="restart" start-delay="15" 

Служба HTTP 2
Ресурсы: HTTP VIP и служба HTTP (Nginx).
Оба ресурса будут мониторизироваться на предмет отказа и будут перезапущены в случае необходимости. Nginx будет мониторизироваться скриптом LSB, так как на данный момент скрипта мониторинга для Nginx не существует.

primitive VIP_192.168.1.11 ocf:heartbeat:IPaddr \
	params ip="192.168.1.11" nic="eth0" cidr_netmask="255.255.255.0" \
	op monitor interval="5s" timeout="20s" start-delay="1s"
primitive http_2_nginx nginx lsb:nginx \
	op monitor interval="5" timeout="15" on-fail="restart" start-delay="15"
	

Служба HTTP 3
Ресурсы: HTTP VIP и служба HTTP (Apache). Оба ресурса будут мониторизироваться на предмет отказа и перезапущены в случае необходимости. Apache будет мониторизироваться при помощи проверки страницы «/server-status» через VIP.

primitive VIP_192.168.1.13 ocf:heartbeat:IPaddr \
	params ip="192.168.1.13" nic="eth0" cidr_netmask="255.255.255.0" \
	op monitor interval="5s" timeout="20s" start-delay="1s"
primitive http_2_apache ocf:heartbeat:apache \
	params port="80" statusurl="192.168.1.13/server-status"
	configfile="/etc/httpd/conf/httpd.conf" \
	op monitor interval="15" timeout="20" on-fail="restart" start-delay="15"

Служба MySQL
Ресурсы: MySQL VIP.

primitive VIP_10.1.1.11 ocf:heartbeat:IPaddr \
	params ip="10.1.1.11" nic="eth1" cidr_netmask="255.255.255.0" \
	op monitor interval="5s" timeout="20s" start-delay="1s"

DRBD Storage
Ресурсы: процесс DRBD и DRBD виртуальный диск.
Оба ресурса будут мониторизироваться на предмет отказа и перезапущены в случае необходимости.

primitive drbd_ps heartbeat:drbddisk \
	params 1="data" \
	op monitor interval="20" timeout="40" on-fail="restart" start-delay="10"
primitive fs_var_www ocf:heartbeat:Filesystem \
	params device="/dev/drbd0" directory="/var/www" fstype="ext3" options="noatime"
	statusfile_prefix=".fs_nfs_server_ha" \
	op monitor interval="20" timeout="60" on-fail="restart" start-delay="10"

NFS сервер
Ресурсы: NFS VIP, служба NFS сервер и служба NFS Lock. Все ресурсы будут мониторизироваться на предмет отказа и перезапущены в случае необходимости.

primitive VIP_10.1.1.10 ocf:heartbeat:IPaddr \
	params ip="10.1.1.10" nic="eth1" cidr_netmask="255.255.255.0" \
	op monitor interval="5s" timeout="20s" start-delay="1s"
primitive nfs lsb:nfs \
	op monitor interval="10" timeout="15" on-fail="restart" start-delay="15"
primitive nfslock lsb:nfslock \
	op monitor interval="5" timeout="15" on-fail="restart" start-delay="15"

Клиент NFS
Ресурсы: служба NFS Lock и диск файловой системы. Оба ресурса будут мониторизироваться на предмет отказа и перезапущены в случае необходимости.

primitive nfslock_client lsb:nfslock \
	op monitor interval="5" timeout="15" on-fail="restart" start-delay="15"
primitive fs_var_www_nfs_client ocf:heartbeat:fs_nfs_client \
	params server="10.10.1.143" server_directory="/var/www" directory="/var/www" statusfile_prefix=".fs_nfs_client_ha" options="rw,soft,async,noatime,proto=udp" \
	op monitor interval="30" timeout="60" on-fail="restart" start-delay="10"
	OCF_CHECK_LEVEL="20" \
	meta target-role="Started" is-managed="true"

Настройка групп ресурсов
Группы ресурсов являются альтернативой ограничениям коллокации ресурсов с возможностью управления ресурсами. Для того чтобы снизить сложность конфигурации, некоторые ресурсы будут перегруппированы.
Оба ресурса VIP_192.168.1.10 и http_1 должны располагаться на одном узле. Из них будет создана одна группа.

group gr_http_1_apache VIP_192.168.1.10 http_1_apache \
        meta ordered="true" collocated="true"
	

Оба ресурса VIP_192.168.1.11 и http_2_nginx должны быть на одном узле, и мы создадим из них одну группу.


group gr_http_2_nginx VIP_192.168.1.11 http_2_nginx \
        meta ordered="true" collocated="true"
	

Оба ресурса VIP_192.168.1.13 и http_3_apache должны быть на одном узле, и мы создадим из них одну группу.


group gr_http_3_apache VIP_192.168.1.13 http_3_apache \
        meta ordered="true" collocated="true"
	

Ресурсы процесса DRBD, диска DRBD, NFS VIP, NFS сервера и NFS Lock должны быть на одном узле, и мы создадим из них одну группу.


group gr_storage_server VIP_10.1.1.10 drbd_pp fs_var_www nfslock nfs \
	meta ordered="true" collocated="true"

Оба ресурса NFS Lock и FS mount должны быть на одном узле, и мы создадим из них одну группу.


group gr_storage_client fs_var_www_nfs_client nfslock_client \
	meta ordered="true" collocated="true"

Настройка зависимостей ресурсов
NFS/DRBD клиент зависим от NFS DRBD сервера.


order ord_storage inf: gr_storage_server gr_storage_client

Все HTTP службы зависят от NFS/DRBD сервера и клиентов.


	order ord_www inf: gr_storage_server ( gr_http_1_apache gr_http_2_nginx gr_http_3_apache )
	order ord_www2 inf: gr_storage_client ( gr_http_1_apache gr_http_2_nginx gr_http_3_apache )

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

Служба HTTP 1
По умолчанию эта группа ресурсов должна быть на Узле_В. В случае отказа, её необходимо переместить на Узел_А.

location loc_gr_http_1_apache_default gr_http_1_apache 100: #uname eq Node_B
location loc_gr_http_1_apache_failover gr_http_1_apache 50: #uname eq Node_A

Служба HTTP 2
По умолчанию эта группа ресурсов должна быть на Узле_С. В случае отказа, её необходимо переместить на Узел_D.

location loc_gr_http_2_nginx_default gr_http_2_nginx 100: #uname eq Node_C
location loc_gr_http_2_nginx_failover gr_http_2_nginx 50: #uname eq Node_D

Служба HTTP 3
По умолчанию эта группа ресурсов должна быть на Узле_D. В случае отказа, её необходимо переместить на Узел_С.

location loc_gr_http_3_apache_default gr_http_3_apache 100: #uname eq Node_D
location loc_gr_http_3_apache_failover gr_http_1_apache 50: #uname eq Node_C

Служба MySQL
По умолчанию эта группа ресурсов должна быть на Узле_C. В случае отказа, её необходимо переместить на Узел_А.

location loc_gr_http_3_apache_default gr_http_3_apache 100: #uname eq Node_D
location loc_gr_http_3_apache_failover gr_http_1_apache 50: #uname eq Node_C

DRBD/NFS Сервер

location loc_gr_storage_server_default gr_storage_server 100: #uname eq Node_C
location loc_gr_storage_server_failover gr_storage_server 50: #uname eq Node_D

Настройка коллокации ресурсов
Группы ресурсов gr_storage_server и gr_storage_client не могут быть на одном узле.

colocation colo_gr_storage -inf: gr_storage_client gr_storage_server

Настройка клонирования ресурсов
Группа ресурсов gr_storage_client должна выполняться на трёх узлах.

clone clone_gr_storage_client gr_storage_client \
	meta globally-unique=false clone-max=3 clone-node-max=1

[Заключение]

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

[Документация]

Pacemaker/Heartbeat: http://www.clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Pacemaker_Explained/
DRBD: http://www.drbd.org/users-guide

Запросить цену
Заполните форму и мы свяжемся с Вами в ближайшее время
Вход для клиентов
Система запросов и другие полезные сервисы для наших клиентов
Свяжитесь с нами
Мы с удовольствием ответим на все ваши вопросы