LINUX.ORG.RU
ФорумAdmin

HA кластер - как сейчас с софтом?

 , , ,


0

3

В близкой перспективе понадобится поднять небольшой кластер (3 ноды, причем скорее всего одна будет чисто кворумной), на который нужно будет упихать кучку серисов (MySQL/PostgreSQL БД, веб, радиус и т.п., + скорее всего минимум одна VM с виндой).

Нагрузка планируется не особо большая. SAN/NAS хранилище не планируется.

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

Весьма желательно простое добавление виртуалок/контейнеров.

Собссно вопрос: стоит ли смотреть на что-то типа openstack/proxmox, или готовиться сразу выпиливать лобзиком нужное в pacemaker?

★★★★★
Ответ на: комментарий от axelroot

Для этого и нужен фенсинг. Активная нода после вынимания кабельков будет мгновенно убита и никакого сплитбрейна.

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

Дык проще уже 3 сервера - третий сугубо для кворума. Ну чтобы не рубить друг друга, и не словить сплит брэйн при нежданчике типа отключения свича/сетевого кабеля.

NiTr0 ★★★★★
() автор топика
Ответ на: комментарий от Vlad-76

Ну можно на тех же нодах крутить мускул нативно. Можно ессно и мастер-мастер (и я даже знаю примеры такого в продакшне), хотя ИМХО мастер-слэйв предсказуемее. Насчет постгри - пока в сомнениях, как лучше.

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

Оно-то понятно что будет O_DIRECT. С мускулом ловил несколько раз странные его падения (вплоть до порчи некоторых баз) при нештатном отключении. Маловероятно, но все же. С репликой как-то спокойнее жить - при смерти одной БД вторая копия будет живой. data=journal насколько сильно будет производительность сажать?

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

Для этого и делают 3 ноды. Пропал кворум на одной - все свалилось в рид-онли. При возврате связи - если это был ребут свича, ресурсы поднимаются на той ноде что была мастером. Если это было отключение ноды от сети - нода становится слэйвом и в теории должна самостоятельно засинкаться с мастером.

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

Реплика, конечно, безопаснее, тут вопросов нет. Если есть возможность использовать её - нужно использовать. data=journal не особо сильно снижает производительность, но я не замерял.

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

Ок, понял, значит буду скрещивать ужа с ежом, pacemaker для мускул/постгрес кластера + proxmox для витруалок/контейнеров с прочими сервисами, похоже - самый адекватный вариант по удобству и надежности.

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

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

кстати по теме и про системы управления. Очень занятно для мелких кластеров смотрелся LCMC, но два года назад эта шарманка любила конфиг портить. Оно сейчас как, никто не тыкал?

upcFrost ★★★★★
()
Последнее исправление: upcFrost (всего исправлений: 1)
Ответ на: комментарий от NiTr0

Я не очень силён во всём в этом, но я думаю, что в качестве третей железки может выступать тогда, надёжный неттоп какой-нибудь. Пусть он да, заправляет твоими двумя машинками. Если выйдет из строя одна из них - переподнимет на другом. Я уж не думаю, что ты будешь проксировать весь трафик через кворум машинку. :)

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

Да что-то подобное и будет. Заправлять он никем не будет, будет для кворума. Ну и IPMI карточку какую-нить в него, для фенсинга/stonith.

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

Если реализуешь, опиши подробности, кастани, интересно посмотреть на рез-т. :) Но всё же, я бы ориентировался на что-то одно. Если у тебя в требованиях полная виртуализация, то я бы всё виртуализовал. Чтобы было надёжно и без приключений в случае чего. То есть и mysql, тоже наверно бы виртуализовал.

DALDON ★★★★★
()
Последнее исправление: DALDON (всего исправлений: 1)
Ответ на: комментарий от DALDON

Ну как раз приключений огрести с виртуализацией мускула можно намного больше, чем без оной. И с постгрей, думается, ситуация похожая. Полузаписанный ib_logfile или ibdata на момент краша/потери связи - и как минимум мускул не поднялся, как максимум - похерились какие-то данные. Хотя возможно полное журналирование ФС и поможет, но на 100% не уверен.

+ мускул - немного непредсказуемая субстанция; у меня на относительно нагруженном кластере с активной записью мастер один раз сам по себе издох, попортив что-то в БД, и без ручного вмешательства по хорошему стартовать отказывался (железо 100% ни при чем).

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

Ты рассуждаешь, здраво. Я у себя пошёл немного по другому пути. Я согласовал с руководством, допустимое время простоя, согласовал допустимый интервал потери данных. - И сделал ноды с zfs, и перекидываю с ноды на ноду снепшоты просто. А на самой zfs, у меня бежит kvm.

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

Лишний раз убеждаюсь, что использовать DRBD можно тому кто знает и понимает все тонкости технологии и в состоянии ее настроить.

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

Стек из пары свичей принципиально ничего не меняет. При отказе мастера в стеке будет перерыв в связи на ХХ секунд в любом случае. И что могло развалиться - развалится. А ставить какого-то динозаврика-калорифер типа 4500/6500 - оверкилл ИМХО.

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

Кластер с одним свитчем - оригинально.

А в чём проблема? Я чего-то не понимаю?

Две ноды - уже кластер. В оп три ноды. Прекрасно поместятся в один свитч.

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

Не могу не согласиться с тобой, петюня. Тот кто не вчитывается в документацию должен страдать.

anonymous
()
Ответ на: комментарий от EvgGad_303

Единая точка отказа, если ты ещё не понял.

Затраты на отказоустойчивость определяются стоимостью простоя. Не похоже, что у ТС полное дублирование всего будет оправдано.

Ivan_qrt ★★★★★
()
13 февраля 2016 г.
Ответ на: комментарий от stave

Xenserver 6.5 уже умеет в контейнеры

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