High Availability
Для построения решений с High Availability (иначе — отказоустойчивых кластеров) в Сизифе / Бранче? 4.0 в настоящее время есть:
- drbd — эдакий raid1 over ethernet, а точнее средство автоматического зеркалирования разделов жесткого диска на двух компьютерах, обеспечивающие доступ к файлам на чтение и запись только с одного компьютера
- heartbeat — менеджер кластера, предоставляющий средства коммуникации между узлами кластера (в том числе механизм оповещения об отключении/включении узла) и управления ресурсами кластера
Кроме того, для упрощения конфигурации удобно использовать какую-либо систему виртуализации, например Open VZ?.
Как постоить отказоустойчивый кластер, написано здесь:
Однако 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'ом.
HAD уже в Сизифе и в Бранче 4.0
по результатам тестирования HAD оказался не так уж хорош. Но в результате я созрел сформулировать, что же мне все-таки нужно — Cluster Manager. Реализация была начата, но затем отложена как обычно из-за недостатка времени. Впрочем, есть есть и другие желающие:
http://lists.altlinux.org/pipermail/community/2007-December/401931.html http://www.radlinux.org/connexion/roadmap