LINUX.ORG.RU

архитектура отказоустойчивого решения

 


2

1

всем привет. имеется приложение, которое крутится на серваке ubuntu и общается с удаленным хостом. возник вопрос как организовать такую систему, чтобы было два сервера, мастер и слэйв, при падении приложении на мастере (или при проблеме с самим сервером) чтобы автоматически запускалось приложение(это же) на слэйве? в какую сторону смотреть чтобы был подобный failover? В какую сторону смотреть - а там разберемся сами.

У вас ничего не получится. Закрывайте компанию. Увольняйте сотрудников.

anonymous ()

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

I-Love-Microsoft ★★★★★ ()
Ответ на: комментарий от x905

так то можно, но если сам мастер сервер из строя выйдет? питание например в даун уйдет...

elmir_k ()

Кластер, например pacemaker+corosync

zolden ★★★★★ ()
Ответ на: комментарий от Vsevolod-linuxoid

MOSIX?.. Не, не слышали. Почитал, прикольная штука. Странно что о ней мало кто слышал и новостей не выходит.

I-Love-Microsoft ★★★★★ ()
Ответ на: комментарий от elmir_k

бросайте, стране сварщики нужнее

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

для связи - да, но если речь про VAS, то не все так категорично

elmir_k ()

Самый простой и быстрый наколеночный велосипед - Zookeeper.

xpahos ★★★★★ ()
Ответ на: комментарий от I-Love-Microsoft

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

Потому что это высокая нагрузка а не высокая доступность. Решение другой задачи.

ya-betmen ★★★★★ ()
Ответ на: комментарий от anonymous

главное сделать быстро, а не корректно

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

erlang не подходит, когда нужна максимальное throughput. если вы конечно понимаете о чем я.

есть что-то круче с максимальным throughput для подъема ноды?

anonymous ()

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

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