LINUX.ORG.RU

создание кластера. выбор технологий


0

1

Нужно собрать кластер из двух серверов, так что один будет рабочим, а второй горячим резервом. Из ресурсов на кластере будет крутится общий внешний ip, cервер MySQL и asterisk. Узлы соеденены в локалку через управляемый свитч. Еще понадобится общая файловая система, организованная как некий сетевой аналог зеркального рейда.

Пока остановился на связке pacemaker + heartbeat + glusterfs Конфигурация для астериска, его логи и записи разговоров пишется на сетевую ФС. С MySQL пока решил сделать связку master - slave, но не нравится, что будет разная конфигурация на разных узлах, хотелось бы, чтобы софт был настроен идентично. Может быть стоит просто вынести файлы БД (все мои таблицы в isam) на сетевую ФС. Pacemaker следит за целостностью кластера и поднимает ресурсы на резервном узле, в случае падения основного. heartbeat - транспорт. Вроде как рекомендуют corosync, но никаких внятных его преемуществ мне нагуглить не удалось.

★★

Могу ошибаться, но по-моему удобнее будет развернуть локальное облако, например на openstack, и на нем уже настраивать нужные сервисы.

wisp ★★ ()

зачем вам поднимать такого монстра как pacemaker ради двухузлового кластера.. подойдет heartbeat. А Mysql как master-master, в отличии от slave-master, достаточно просто перевезти ip.

apmucm ()

А если увести Mysql и Asterisk в виртуальные машины, поставив их на LVM+DRBD. Машины будут идентичные на двух серверах. Ломается один сервер, достаточно запустит машину. Ну или предчувствуя поломки в живую мигрировать машины на здоровый сервер, а потом потушить сбойный. Ну или pacemaker использовать для автоматизации с обязательным stonitsh по serial порту.

petav ★★★★★ ()
Ответ на: комментарий от apmucm

зачем вам поднимать такого монстра как pacemaker ради двухузлового кластера

Автоматизация, будь она неладна, да и не такой уж он и монстр как про него пишут, я тут к нему пригляделся. Конфиг в xml, это конечно минус, но руками его править не надо, все через админскую консольку делается, даже подсказки по табу выводит. Требования к решению такие - оно должно быть теражирумым, а заменить вылетевший узел, должен способен низкоквалифицированный персонал.

А Mysql как master-master,

Я тут master-slave только с пятой попытки осилил поднять, плюс еще не понятно как реализовать замену узла, но замена это в перспективе, чисто теоретически я рассуждаю так, в случае падения мастера, резервный mysql сам становится мастером, а в момент, когда в кластер вводится узел на замену, то на нем каким-то волшебным скриптом MySQL заливает копию базы в себя и настраивается слейвом. Вот только скрипт этот еще не написан.

Yur4eg ★★ ()
Ответ на: комментарий от petav

А если увести Mysql и Asterisk в виртуальные машины, поставив их на LVM+DRBD

Сие попахивает оверхедом еще и производительность просядет. Сам я c DRBD не сталкивался, но про него написано много гадостей, вроде как работает пока не сломается.

Yur4eg ★★ ()
Ответ на: комментарий от Yur4eg

Сие попахивает оверхедом

Да

еще производительность просядет

Это легко учесть

Сам я c DRBD не сталкивался, но про него написано много гадостей, вроде как работает пока не сломается.

ХЗ УМВР

petav ★★★★★ ()
Ответ на: комментарий от Yur4eg

плюс еще не понятно как реализовать замену узла, но замена это в перспективе, чисто теоретически я рассуждаю так, в случае падения мастера, резервный mysql сам становится мастером

вот для этого и нужен master-master, чтобы оставалось перевезти только ip с помощью pacemaker

apmucm ()

А вариант с лоадбалансером (opensips, kamailio) в виртулке, который балансирует на две ноды, чем не подходит?

anton_jugatsu ★★★★ ()
Ответ на: комментарий от anton_jugatsu

А вариант с лоадбалансером

Во первых надо в рубаться в его работу, что требует время. Во вторых это не не решает вопрос с мускулем.

Yur4eg ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.