LINUX.ORG.RU
ФорумAdmin

Что хочу — не знаю, а что знаю — не хочу (подробности внутри)

 , , ,


0

4

Я не сисадмин, естественно. Но могу прикинуть в какую сторону копать. И, на 99% уверен, что то, что я хочу — уже есть.

Bот подробности:

Должно быть N равноправных между собой, полных копий бекенд-серваков (статика, апликуха, бд).
Где каждый такой узел может работать самостоятельно, типа P2P.
Время рассинхронизации (отличий в статике, апп, бд) узлов должно быть не более 5 секунд.
При выпадении одного из узлов, естественно, остальные должны автоматически переконфижицца(?) на оставшуюся группу.

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

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

Ок, распишу свои размышления...

Припустим для файлов апликухи (ну и статики тоже, хер с ним) можно повесить на крон каждые 5 сек скрипта который будет тупо делать гит пулл.

Но что делать с БД? Делать один из узлов актуальным (и единственным) «мастером» (тогда остальные смогут реже синковать БД до актуального состояния). Тогда, каждый узел должен общаться с остальными и чекать их доступность. И если «мастер»-узел ё****** упал, то, кто-то из узлов становится новоиспеченным «мастером». А старый «мастер» после того как восстанет, увидит что он уже не «мастер» и переконфижицца. Но тут возникает проблема состояния гонки, т.к. нужно как-то распределить порядок(приоритет?) желания стать «мастером» среди других.

deep-purple ★★★★★ ()
Последнее исправление: deep-purple (всего исправлений: 2)

Если узлов неизвестное количество будет работать, но известны адреса всех узлов, тот ту какой-нибудь балансер и round-robin должно подойти.

Так-то подписался.

Radjah ★★★★★ ()

Ну що, мужики, кто подписался — предлагайте варианты как распределить порядок(приоритет?) желания стать «мастером» среди других БД.

deep-purple ★★★★★ ()
Ответ на: комментарий от NoobeR

На оставшихся в живых она и так «одинаковая» — они же равноправны, и ни один не является мастером.

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

inb4: почти не в теме.

Тот же MySQL умеет в кластер же. Тыкать в балансер, а там они сами разберутся.

На счет статики надо какой-нибудь аналог btsync держать на каждой ноде, чтобы они по DHT друг дружку пинали на скачивание свежака и удаление просраченных файлов. Только наверное надо какую-то систему версий вносить, чтобы балансер знал у кого самая свежая копия данных. ИМХО синхронизация статики в 5 секунд лага не влезет.

Ну это всё на мой обывательский взгляд. :)

Radjah ★★★★★ ()

Как-то так: http://habrahabr.ru/post/248837/

Необязательно строить кластер с виртуализацией, можно ограничиться распределённой файловой системой. Всё зависит от средств, выделенных на задачу.

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

Нафиг, нафиг этот ваш drbd. Он как сплит словит - потом еще 5 минут руками на место все прикручиваешь. Да и дуал-мастер у него только на пару хостов идет, и то коряво. Проще glusterfs. Что делать с базой - вопрос философский, на основе фс ее шарить не надо, а то можно лок или коллизию словить.

Переключать сервисы если это вообще надо по тому же heartbeat с агрессивным поллингом, коросинх пока имхо не готов. Можно еще поднимать добро на контейнерах чтоб в случае чего добавлять/удалять их по надобности.

По поводу баланса - можешь через dns балансить (может зафейлить когда шлет на дохлый серв а днс-кеш не обновлен), либо можешь вынести балансер отдельно скажем на виртуалки и поднимать в нужном количестве (имхо лучший вариант). Или настроить pcmk так чтоб на одной из нод поднимался балансер, а дальше аналогом дднс, но это легко обломать днс-кешем.

И еще - можно решить вопрос сетями. Создать 2 сети - сервис-виртуалка и реальное физическое расположение. Днс смотрит на сервисы, их адрес один и тот же. Нужен сервак который будет хранить таблицу привязки сервиса к локации (типа локального днс без кеша). Дальше l3-роутингом все решается. В случае жопы виртуалка просто поднимается в другой локации с сохранением адреса сервиса. Такие решения для цодов есть. Имхо лучший вариант. Гугли VL2 data center

upcFrost ★★★★★ ()
Последнее исправление: upcFrost (всего исправлений: 4)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.