HA кластер
Часть 1: Heartbeat
Кластер - это прежде всего система повышенной готовности (high
availability - HA), построеная с учетом того, что она продолжает
работать безотказно, даже если какая-то ее часть выходит из строя.
Heartbeat - продукт проекта Linux-HA, позволяющий реализовать механизм
безотказной работы отдельных частей кластера. Первый, кому необходим
этот механизм в кластере - это распределитель нагрузки (load balancer,
или director).
Допустим, у нас есть два сервера (loadb1, loadb2), которые выделены
для того, чтобы стать распределителями нагрузки в будущем кластере. Но
прежде чем устанавливать на них программное обеспечение для управление
кластером, необходимо настроить и оттестировать механим безотказной
работы - когда какой-либо из серверов (loadb1 или loadb2) выходит из
строя, второй, благодаря heartbeat, заменяет его. В данном случае
условием того, что сервер вышел из строя будет считаться, что он не
отвечает на broadcast запросы, т.е. проблемы в сетевом интерфейсе.
Сервера loadb1 и loadb2 будут эмулировать ip-адрес кластера -
195.46.64.21, т.е. он будет "поднят" на сетевом интерфейсе как
дополнительный (alias).
Настройка heartbeat в Debian 4.0 (Etch)
1. Установить пакет heartbeat-2 и все зависимости, которые он за собой
тянет.
apt-get install heartbeat-2
В конце установки сервис heartbeat не сможет запуститься, потому как
не созданы основные конфигурационные файлы - ha.cf, authkeys,
haresources.
ha.cf - основной конфигурационный файл, содержащий массу различных
параметров того, как будет осуществляться heartbeat-механизм. За
основу можно взять файл, идущий в пакете (расположен в
/usr/share/doc/heartbeat-2). Перед использованием достаточно
установить 3 параметра (директивы):
bcast eth0
node loadb1
node loadb2
Указав таким образом использовать heartbeat-механизм через eth0
интерфейсы на основе broadcast-запросов. Имена loadb1, loadb2 должны
быть hostname-именами серверов, команда uname -a должна возвращать
такие же значения.
authkeys - файл для взаимной аутентификации серверов loadb1 и loadb2.
Можно использовать sha, md5, но чтобы не расходовать ресурсы
достаточно использовать crc. После создания файл, необходимо
установить права доступа к нему только для root
# cat > authkeys
auth 1
1 crc
[Ctrl+C]
# chmod 600 authkeys
haresources - файл, описывающий ресурсы, контролируемые серверами
loadb1 и loadb2. Ресурсы представляют собой обычные стоп/старт
скрипты, похожие чем-то на сценарии из/etc/init.d. В директории
/etc/ha.d/resource.d можно посмотреть доступные (уже готовые к
использованию) сценарии. В данном примере будет использован ресурс
IPaddr для активации дополнительного ip-адреса на интерфейсе eth0.
loadb1 IPaddr::195.46.64.21/24/eth0
Данные конфигурационные файлы должны быть помещены на обоих серверах в
директорию /etc/ha.d и должны быть идентичны. После того, как все
подготовлено, запустить heartbeat-сервис на обоих серверах:
# /etc/init.d/heartbeat start
Starting High-Availability services:
2007/06/28_10:14:21 INFO: IPaddr Resource is stopped
Done.
Спустя пару секунд на сервере loadb1 будет поднят дополнительный
ip-адрес - 195.46.64.21.
loadb1# ifconfig
eth0 Link encap:Ethernet HWaddr 00:60:08:04:09:0D
inet addr:195.46.64.15 Bcast:195.46.64.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1119456 errors:0 dropped:0 overruns:0 frame:0
TX packets:96462 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:79824340 (76.1 MiB) TX bytes:18991729 (18.1 MiB)
Interrupt:10 Base address:0xe000
eth0:0 Link encap:Ethernet HWaddr 00:60:08:04:09:0D
inet addr:195.46.64.21 Bcast:195.46.64.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:10 Base address:0xe000
Если что-то случается с loadb1 (можно сэмулировать аварию, отправив
его на перезагрузку), loadb2 поднимает данный ip-адрес на своем eth0
интерфейсе и принимает на себя основную роль.
loadb2# ifconfig
eth0 Link encap:Ethernet HWaddr 00:10:5A:BF:2B:8C
inet addr:195.46.64.16 Bcast:195.46.64.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1256304 errors:0 dropped:0 overruns:0 frame:0
TX packets:93726 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:99944699 (95.3 MiB) TX bytes:19336953 (18.4 MiB)
Interrupt:9 Base address:0xec00
eth0:0 Link encap:Ethernet HWaddr 00:10:5A:BF:2B:8C
inet addr:195.46.64.21 Bcast:195.46.64.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:9 Base address:0xec00
В /var/log/messages можно проследить происходящее - всё очень подробно
и понятно.
Ссылки:
1. Программное обеспечение повышенной готовности промежуточного
уровня в Linux, часть 1: Heartbeat и Web-сервер Apache
http://www.ibm.com/developerworks/ru/linux/library/l-halinux/
2. How To Set Up A Loadbalanced High-Availability Apache Cluster
http://howtoforge.com/high_availability_loadbalanced_apache_cluster
3. The High Availability Linux Project
http://www.linux-ha.org/
Часть 2: Storage
Для функционирования кластерной системы, необходимо наличие единой
дисковой подсистемы, доступной для всех серверов (node), работающих
внутри кластера.
С дисковой подсистемой (storage) можно общаться на уровне:
- сервиса (примеры - NFS-директория, примонтированная на всех нодах, DNBD)
- блочного устройства, доступного всем нодам (SAN)
Самым простым решением является использование сетевой файловой системы
NFS. В данном случае все проблемы по обслуживанию блокировок при
совместной работе с данными NFS-служба берет на себя. Статья [1]
прекрасно описывает пример создания storage на основе NFS. Я
попробовал на Debian 4.0 - все отлично работает. Но присутствие уровня
сервиса накладывает некоторый отрицательный отпечаток на
производительность.
Более низкий уровень общения с дисковой системой - уровень обычного
блочного устройства (block device). В этом случае Вы имете в системе
дополнительный диск (/dev/sdb, /dev/hdb), с которым работаете как с
обычным жестким диском, но есть несколько "но":
* если данный диск доступен нескольким нодам в режиме записи (RW),
Вы должны обеспечить на нем функционирование кластерной файловой
системы, которая позволит работать одновременно с одними и теми же
данными с разных нодов.
* Вам придется раскошелиться на приобретение SAN (на основе Fibre
Channel или более дешевого - iSCSI. Точных цен я не знаю, но
это недешевая покупка :)
Перед написанием этих строк я попробовал две кластерные файловые
системы - GFS и OCFS2. Если сравнивать "на глаз" производительность,
то можно сказать, что обе файловые системы работают более менее
одинакого быстро. Но GFS по сравнению с OCFS на первых порах более
сложен в запуске, так как требует установки и настройки Red Hat
Cluster Suite. Данный Suite включает в себя все необходимые "примочки"
для работы кластера, начиная от heartbeat'а, поддержки множества
сетевых служб, заканчивая фенсингом кластерной файловой системы
(fencing). Информации по GFS доступно достаточно, чего не скажешь
об OCSF. Обе данные кластерные файловые системы опробованы на CentOS
5, все работает стабильно без каких-либо оговорок, лог действий скоро
выложу.
Ссылки:
1. Setting Up A Highly Available NFS Server
http://howtoforge.com/high_availability_nfs_drbd_heartbeat
2. Distributed filesystem for Debian clusters? (discussion)
http://www.debian-administration.org/articles/348
3. DRBD/NFS: Linux HA
http://linux-ha.org/DRBD/NFS