High Availability

Для построения решений с High Availability (иначе – отказоустойчивых кластеров) в Сизифе / Бранче? 4.0 в настоящее время есть:

• • drbd – эдакий raid1 over ethernet, а точнее средство автоматического зеркалирования разделов жесткого диска на двух компьютерах, обеспечивающие доступ к файлам на чтение и запись только с одного компьютера
  • heartbeat – менеджер кластера, предоставляющий средства коммуникации между узлами кластера (в том числе механизм оповещения об отключении/включении узла) и управления ресурсами кластера

Кроме того, для упрощения конфигурации удобно использовать какую-либо систему виртуализации, например Open VZ?.

Как постоить отказоустойчивый кластер, написано здесь:

• • http://www.av5.com/journals-magazines-online/1/19/121
  • http://www.av5.com/journals-magazines-online/1/20/736

Однако heartbeat слишком крив, монстрообразен и имеет кучу лишних зависимостей (т.к. включает в себя слишком много того, что мне, например, не нужно). Поэтому я начал его перепиливать, но закончить не смог. Пишу об этом здесь, чтобы помочь тем, кому heartbeat потребуется и кто сможет довести эту работу до конца.

Первое, что я сделал – вместо нескольких бинарных пакетов собрал один, а затем с помощью ldd и тыка стал выкидывать лишнее ;) Для моей конфигурации, описанной в приведенных выше ссылках, оказалось достаточно:

# find /usr/lib/heartbeat/
/usr/lib/heartbeat/
/usr/lib/heartbeat/ocf-shellfuncs
/usr/lib/heartbeat/heartbeat
/usr/lib/heartbeat/req_resource
/usr/lib/heartbeat/plugins
/usr/lib/heartbeat/plugins/InterfaceMgr
/usr/lib/heartbeat/plugins/InterfaceMgr/generic.so
/usr/lib/heartbeat/plugins/HBcompress
/usr/lib/heartbeat/plugins/HBcompress/bz2.so
/usr/lib/heartbeat/plugins/HBcompress/zlib.so
/usr/lib/heartbeat/plugins/HBauth
/usr/lib/heartbeat/plugins/HBauth/crc.so
/usr/lib/heartbeat/plugins/HBauth/md5.so
/usr/lib/heartbeat/plugins/HBauth/sha1.so
/usr/lib/heartbeat/plugins/HBcomm
/usr/lib/heartbeat/plugins/HBcomm/serial.so
/usr/lib/heartbeat/plugins/HBcomm/mcast.so
/usr/lib/heartbeat/plugins/HBcomm/ping_group.so
/usr/lib/heartbeat/plugins/HBcomm/ucast.so
/usr/lib/heartbeat/plugins/HBcomm/bcast.so
/usr/lib/heartbeat/plugins/HBcomm/ping.so
/usr/lib/heartbeat/ResourceManager
/usr/lib/heartbeat/mach_down

# find /etc/ha.d
/etc/ha.d
/etc/ha.d/shellfuncs
/etc/ha.d/resource.d
/etc/ha.d/resource.d/Filesystem
/etc/ha.d/resource.d/drbddisk
/etc/ha.d/resource.d/hto-mapfuncs
/etc/ha.d/rc.d
/etc/ha.d/rc.d/ip-request-resp
/etc/ha.d/rc.d/ip-request
/etc/ha.d/rc.d/status
/etc/ha.d/rc.d/ask_resources
/etc/ha.d/rc.d/hb_takeover

+ /etc/ha.d/ocf/resource.d, перенесенный из /usr/lib/ocf (и замена пути в скриптах)

+ ldd /usr/lib/heartbeat/heartbeat ;)

Инитскрипт там тоже можно значительно упростить, убрав, как минимум, использование ha_logd.

Вот это все (не считая ресурсов) я планировал упаковать в пакет heartbeat, под каждый необходимый мне ресурс я планировал держать отдельный пакет вида linux-ha-resource-[name] или linux-ha-resource-ocf-[name]. ha_logd и ha_logger я планировал выносить в отдельный пакет и писать для первого отдельный инитскрипт. Еще один пакет – это heartbeat-crm, куда я планировал положить все, необходимое для того, чтобы описать свою конфигурацию в стиле 2.x. Еще отдельно нужно было бы упаковать heartbeat-management и haclient. Разумеется, все это косметика, но на большее я и не претендовал. Бороться с warnings – это в случае heartbeat вообще борьба с мельницами :( Не зря lakostis@ включил unresolved=relaxed ...

По ходу борьбы с heartbeat выяснилось, что у него есть более простые альтернативы (все Active / Standby?, хотя сам heartbeat поддерживает и Active / Active?-конфигурации):

• • http://linuxha.net – слакварьный ужас ;)
  • http://www.bolthole.com/freeha/ – выглядит более вменяемо
  • jhad- форк предыдущего от «Инфосистемы Джет», используется в production на solaris 9/10

Последний выглядит наиболее перспективным, к страничке прикреплен оригинальный архив jhad и первая попытка его опакетить. Инитскрипт там надо переписывать по аналогии c postgresql (т.к. jhad не успевает остановиться за время, выделяемое stop_daemon), вместо скриптов, которые запускают/останавливают сервисы, там просто заглушки, реальные скрипты нужно писать по аналогии с соляркиными.

По вопросам работы jhad обращаться к Sergey Pinaev <dfo at antex.ru>, хотя мне тоже желательно рассказать о результатах ;)

Важный, как мне кажется, фрагмент из переписки с Сергеем:

>>Вопрос по логике работы: как я понял (в основном из английской
>> документации), starthasrv не будет вызван до тех пор, пока не запустятся 
>> хотя бы 2 узла, при этом starthasrv будет запущен на том узле, где 
>> значение uname окажется меньше ;) Затем уже один из узлов может умереть 
>> (тот, который RUNNING, например, тогда соседний STANDBY станет RUNNING), 
>> и все время, пока узел остается единственным, на него даже дышать 
>> нельзя, поскольку если он остановится, то повторно уже не стартует. Да, 
>> остановка единственного узла – это очень плохо (это совершенно нештатная 
>> ситуация), но невозможность запуска после остановки еще хуже. Очень 
>> напоминает кластер My SQL, кстати. 
>> >> Судя по ответу: 
>> >>> Если узел один – послать SIGUSR1. 
>>> Если несколько и какой-то из них RUNNING – пойти на него и перевести 
>>> в STANDBY. 
>> >> >> это уже не так? Кстати, каким образом единственный узел может оказаться 
>> в STANDBY? 
> > >вроде бы как не так =) 
>будет вызван, если had запущен с ключом -m (force main mode). 
> >может оказаться в STANDBY если ты его в него переведешь принудительно SIGHUP'ом. 

UPDATED:

HAD уже в Сизифе и в Бранче 4.0

UPDATED2:

по результатам тестирования HAD оказался не так уж хорош. Но в результате я созрел сформулировать, что же мне все-таки нужно - Cluster Manager. Реализация была начата, но затем отложена как обычно из-за недостатка времени. Впрочем, есть есть и другие желающие:

http://lists.altlinux.org/pipermail/community/2007-December/401931.html http://www.radlinux.org/connexion/roadmap