From: Andrey Markelov <amarkelov@yandex.ru.>
Newsgroups: email
Date: Mon, 21 Dec 2008 17:02:14 +0000 (UTC)
Subject: Построение HA-кластера с использованием RHCS и GFS в RHEL 5
Цель поста - продемонстрировать создание тестовой конфигурации кластера высокой доступности
с использованием Red Hat Cluster Suite и кластерной файловой системы Global File System.
При создании HA-кластера используем следующее ПО/технологии. Все они являются полностью
открытыми и для них доступен исходный код:
- Red Hat Enterprise Linux Advanced Platform 5.1
- Red Hat Cluster Suite (в том числе web-интерфейс Conga, qdiskd и clvmd);
- Global File System;
- udev.
Вместо RHEL можно использовать CentOS, Scientific Linux и другие подобные.
Для создания демо-стенда использовались два физических сервера с внешним дисковым массивом,
подключенным через FC, и одна управляющая станция, на которой была установлена web-консоль
luci (проект Conga). Данная конфигурация избыточна, и все эти шаги можно повторить с
использованием одного физического сервера, предоставляющего доступ к разделу по iSCSI двум
виртуальным машинам, которые работают на том же сервере. В этом случае luci также можно
было бы запускать на хост-системе или, в зависимости от числа доступных ресурсов, на
сервере "поднять" третью виртуальную машину. Использование физических серверов критично в
случае, если вы в качестве серверного ресурса планируете запускать виртуальные машины - HA
+ "живая миграция" (т.е. примерно то, что обеспечивает VMWareHA, и чего ждем в Windows
Server 2008 R2). В этом случае рекомендую помимо официальной документации Red Hat
ознакомиться со статьей в Red Hat Magazine и workaround на тему живой миграции
виртуальных машин, описанном в блоге Андрея Мартынова.
Важно. Хотя, по информации, приведенной в этом посте, можно повторить все шаги и по
аналогии настроить свой кластер, но информации будет явно не достаточно для понимания всех
деталей работы, команд и планирования развертывания кластера. Для дальнейшего изучения
материала рекомендую обратиться к официальной документации Red Hat, свободно доступной на
сайте Red Hat как в виде PDF, так и HTML. Пост в блоге не заменяет чтения сотен страниц
документации. Также нужно заметить, что решение задействовать GFS и использование кластера
именно из двух узлов не является необходимым/оптимальным решением для рассмотренной задачи
(отказоустойчивый web-сервер). Решение продиктовано желанием продемонстрировать
использование большего числа технологий (GFS и кворумный диск). Более того, использование
web-сервера как кластерной службы выбрано исключительно для демонстрации и из-за простоты
базовой настройки. Для достижения результата в каждом конкретном шаге также, как правило,
возможно воспользоваться разными инструментами: system-config-cluster, Conga или командная
строка.
Создаем кластер, используя web-интерфейс (проект Conga)
Наиболее простой способ создать кластер - использовать Conga. Также стоит использовать
данный интерфейс, когда мы хотим управлять из одной точки несколькими кластерами. Для того
чтобы избежать некоторых "шероховатостей" в дальнейшем, убедимся, что на всех кластерах в
/etc/hosts имя узла не присутствует в одной строчке с localhost, как это прописывает по
умолчанию Anaconda. Кроме того, для независимости кластера от работы службы DNS лучше всего
также прописать в hosts все остальные узлы и машину, где будет установлена luci. Кроме
того, предполагается, что всем машинам доступны группы Cluster и Cluster Storage через RHN,
Satellite или локальный репозиторий.
[root@server1 ~]# service luci restart
Shutting down luci: [ OK ]
Starting luci: [ OK ]
Point your web browser to https://server1.example.com:8084 to access luci
А на обоих узлах кластера агента, который работает в паре c luci:
[root@node1 ~]# yum -y install ricci
[root@node1 ~]# service ricci restart; chkconfig ricci on
Теперь можно как нам и предложили зайти в web-интерфейс server1.example.com:8084. Со
вкладки Clucter выбираем создание нового кластера:
После нажатия кнопки Submit узлы кластера скачивают и устанавливают соответствующие пакеты.
По окончании процесса мы должны увидеть такую картину:
Настраиваем постоянные имена для разделов на дисковом массиве
Данный шаг необходим в ряде случаев, например, когда мы не можем гарантировать, что после
перезагрузки каждый раздел будет иметь то же имя, что и перед прошлым циклом перезагрузки
(iSCSI), или, например, в случае различного числа дисков на узлах кластера, когда один и
тот же LUN будет выглядеть на узлах по-разному:
[root@node1 ~]# fdisk -l
...
Disk /dev/sdc: 72.8 GB, 72837857280 bytes
255 heads, 63 sectors/track, 8855 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdc1 1 13 104391 83 Linux
...
[root@node2 ~]# fdisk -l
...
Disk /dev/sdd: 72.8 GB, 72837857280 bytes
255 heads, 63 sectors/track, 8855 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdd1 1 13 104391 83 Linux
...
В первом случае наш рабочий LUN на массиве - это sdc, а во втором - sdd. Данную проблему
можно решить при помощи правила udev. В качестве альтернативы при использовании LVM и ext3
можно было бы воспользоваться UUID или метками ФС. Однако, правило udev более универсально.
Получим идентификатор нашего рабочего диска:
[root@node1 ~]# ls -l /dev/my*
lrwxrwxrwx 1 root root 3 Dec 2 12:54 /dev/mydata -> sdc
lrwxrwxrwx 1 root root 4 Dec 2 12:54 /dev/mydata1 -> sdc1
[root@node2 ~]# ls -l /dev/my*
lrwxrwxrwx 1 root root 3 Aug 1 13:58 /dev/mydata -> sdd
lrwxrwxrwx 1 root root 4 Aug 1 13:58 /dev/mydata1 -> sdd1
Еще один вариант - это воспользоваться стандартно создаваемыми симлинками в /dev/disk/by-id/
Fencing
В Red Hat Cluster Suite поддерживается большое число агентов, в том числе для ряда ИБП APC,
что радует - HP iLO и IBM Blade Center, виртуальных машин Xen, коммутаторов McData,
Brocade. Однако, например, Cisco MDS, насколько я знаю, "родными" средствами "гасить"
нельзя. В luci настройка fencing производится на вкладке Cluster в свойствах кластера и
пункте меню Shared Fence Devices. Снимки с экрана пропустим :)
Добавляем кворумный диск
Получившийся кластер состоит из двух узлов. Чтобы разрешить проблему разделения кластера на
две независимые части, когда каждый из узлов думает что он единственный уцелевший и
продолжает изменять данные на диске, добавим кворумный диск. Просмотрим состояние нашего
кластера. Два узла, флаг специального двух-узлового режима и ни одного сервиса:
[root@node1 ~]# clustat
Member Status: Quorate
Member Name ID Status
------ ---- ---- ------
node2.example.com 1 Online
node1.example.com 2 Online, Local
[root@node1 ~]# cman_tool status
Version: 6.0.1
Config Version: 1
Cluster Name: cluster0
Cluster Id: 26776
Cluster Member: Yes
Cluster Generation: 140
Membership state: Cluster-Member
Nodes: 2
Expected votes: 1
Total votes: 2
Quorum: 1
Active subsystems: 8
Flags: 2node
Ports Bound: 0 11 177
Node name: node1.example.com
Node ID: 2
Multicast addresses: 239.192.104.1
Node addresses: 192.168.50.140
В качестве кластерного диска используем первый раздел на общем диске:
mkqdisk v0.5.1
Writing new quorum disk label 'myqdisk' to /dev/mydata1.
WARNING: About to destroy all data on /dev/mydata1; proceed [N/y] ? y
Initializing status block for node 1...
...
Теперь необходимо вручную на одном из узлов убрать флаг, говорящий о том, что кластер в
особой двухнодовой конфигурации (luci ставит этот флаг автоматом), и увеличить число
голосов на один. Кроме того, необходимо увеличить версию конфигурационного файла:
Даем команду узлам кластера обновить конфигурацию:
[root@node1 ~]# ccs_tool update /etc/cluster/cluster.conf
Config file updated from version 2 to 3
Update complete.
Стартуем сервис qdiskd, который уже привнесен нам на узлы пакетом cman:
[root@node2 ~]# chkconfig qdiskd on; service qdiskd start
Starting the Quorum Disk Daemon: [ OK ]
Теперь в luci добавляем кворумный раздел. В качестве проверки будем пинговать шлюз по
умолчанию:
За объяснением параметров идем к документации. В итоге в clustat мы получаем следующую
картину:
[root@node1 ~]# clustat
Member Status: Quorate
Member Name ID Status
------ ---- ---- ------
node2.example.com 1 Online
node1.example.com 2 Online, Local
/dev/mydata1 0 Online, Quorum Disk
Раздел GFS
Если в двух словах, то про сетевые файловые системы, в том числе и GFS, Андрей Меганов
писал в блоге. А дальше, традиционно, читаем документацию.
К настоящему моменту Conga уже должна была установить все необходимые пакеты. Для гарантии
того, что тип блокировок LVM2 сменен с stand-alone на cluster-wide, отдадим команду:
[root@node2 ~]# lvmconf --enable-cluster
После чего (пере)запустим clvmd. Далее создадим на общем диске раздел под GFS:
[root@node1 ~]# fdisk /dev/mydata
На обоих узлах перечитаем таблицу разделов:
[root@node1 ~]# partprobe
[root@node1 ~]# fdisk -l
Disk /dev/sdc: 72.8 GB, 72837857280 bytes
255 heads, 63 sectors/track, 8855 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdc1 * 1 13 104391 83 Linux
/dev/sdc2 14 6093 48837600 8e Linux LVM
На новом разделе создадим логический том, который, благодаря clvmd, будет доступен на всех
узлах кластера:
[root@node1 ~]# pvcreate /dev/mydata2
Physical volume "/dev/mydata2" successfully created
[root@node1 ~]# vgcreate vgcluster /dev/mydata2
Volume group "vgcluster" successfully created
В случае, если последняя команда отработает с ошибкой, workaround:
[root@node2 ~]# service clvmd stop
Stopping clvm: [ OK ]
[root@node2 ~]# rm /etc/lvm/cache/.cache
rm: remove regular file `/etc/lvm/cache/.cache'? y
[root@node2 ~]# pvscan
connect() failed on local socket: Connection refused
WARNING: Falling back to local file-based locking.
Volume Groups with the clustered attribute will be inaccessible.
PV /dev/mydata2 VG vgcluster lvm2 [46.57 GB / 0 free]
PV /dev/sdb1 VG VolGroup00 lvm2 [149.03 GB / 0 free]
PV /dev/sda2 VG VolGroup00 lvm2 [74.41 GB / 0 free]
Total: 3 [270.01 GB] / in use: 3 [270.01 GB] / in no VG: 0 [0 ]
[root@node2 ~]# vgscan
connect() failed on local socket: Connection refused
WARNING: Falling back to local file-based locking.
Volume Groups with the clustered attribute will be inaccessible.
Reading all physical volumes. This may take a while...
Skipping clustered volume group vgcluster
Found volume group "VolGroup00" using metadata type lvm2
[root@node2 ~]# lvscan
connect() failed on local socket: Connection refused
WARNING: Falling back to local file-based locking.
Volume Groups with the clustered attribute will be inaccessible.
Skipping clustered volume group vgcluster
ACTIVE '/dev/VolGroup00/LogVol00' [221.50 GB] inherit
ACTIVE '/dev/VolGroup00/LogVol01' [1.94 GB] inherit
[root@node1 ~]# service clvmd start
Starting clvmd: [ OK ]
Activating VGs: 1 logical volume(s) in volume group "vgcluster" now active
2 logical volume(s) in volume group "VolGroup00" now active
[ OK ]
Создаем файловую систему (один лишний журнал "про запас"):
[root@node1 ~]# mount /dev/vgcluster/gfsvol /var/www/html
[root@node1 ~]# mount
/dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/sda1 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
none on /sys/kernel/config type configfs (rw)
/dev/mapper/vgcluster-gfsvol on /var/www/html type gfs
(rw,hostdata=jid=0:id=131074:first=1)
Информация о файловой системе:
[root@node1 ~]# gfs_tool df /var/www/html
/var/lib/xen/images:
SB lock proto = "lock_dlm"
SB lock table = "cluster0:share"
SB ondisk format = 1309
SB multihost format = 1401
Block size = 4096
Journals = 3
Resource Groups = 186
Mounted lock proto = "lock_dlm"
Mounted lock table = "cluster0:share"
Mounted host data = "jid=0:id=131074:first=1"
Journal number = 0
Lock module flags = 0
Local flocks = FALSE
Local caching = FALSE
Oopses OK = FALSE
Type Total Used Free use%
-------------------------
inodes 5 5 0 100%
metadata 5 5 0 100%
data 12109426 0 12109426 0%
Создание кластерного ресурса
Остался последний шаг - создаем службу, которая будет хранить, и, если необходимо, изменять
данные на GFS. С httpd пример не очень хороший, зато делается просто. На всех узлах:
[root@node2 ~]# yum -y install httpd
На одном из узлов:
[root@node2 ~]# vi /var/www/html/index.html
Теперь в web-интерфейсе:
Проверяем:
[root@server1 ~]# elinks -dump http://192.168.50.146
My web Service!
И с любого из узлов:
[root@node1 ~]# clustat
Member Status: Quorate
Member Name ID Status
------ ---- ---- ------
node2.example.com 1 Online
node1.example.com 2 Online, Local
/dev/mydata1 0 Online, Quorum Disk
Service Name Owner (Last) State
------- ---- ----- ------ -----
service:webservice node2.example.com started
Теперь можно через web-интерфейс или из командной строки поперекидывать сервис с узла на
узел, сымитировать падение узла, добавить скрипт, который будет каким-то образом менять
данные, или добавить более интересный сервис в созданный HA-кластер.
910 Прочтений • [Построение HA-кластера с использованием RHCS и GFS в RHEL 5 (cluster linux redhat)] [08.05.2012] [Комментариев: 0]
Vova
