LINUX.ORG.RU
ФорумAdmin

Зеркалирование сервера, как перераспределять трафик между зеркалами?

 , , ,


0

1

Имеется два сервера основной и резервный, они синхронизируются друг с другом посредством rsync. Задача в случае выхода из строя основного сервера перенаправить трафик на резервный, необходимо, чтобы это происходило в кратчайшие сроки и в автоматическом режиме. Собственно как решить поставленную задачу? Лично мне на ум приходит создание над серверами проксирующего фронтенда на nginx, однако это вводит в систему третье звено, и при его отказе система всё-равно выйдет из строя. Так же была идеи использовать что-то вроде DDNS, но вот что, и как именно?!

А не правильнее кластер соорудить?

anonymous
()

Собирайте кластер, правда. ИМХО, рсинк вообще крайне прохладен для таких целей.

l0stparadise ★★★★★
()

Сервера то HTTP? Данные статические и меняются нечасто? Тогда rsync пойдёт в принципе.

А над ними повесь два фронтэнда в кластере, тот же Pacemaker подойдёт отлично. Один будет отдыхать, второй трудиться. Либо сразу оба будут трудиться, если им поднять два айпи адреса и в DNS их оба прописать. Если один падает - второй будет обслуживать оба адреса.

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

А не правильнее кластер соорудить?

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

Сервера то HTTP? Данные статические и меняются нечасто?

Сервера HTTP, с довольно большим трафиком, данные статические, часто добавляются, практически не изменяются.

если им поднять два айпи адреса и в DNS их оба прописать

Это идея! А днс на такое не станет ругаться?

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

ДНСу пофиг, он для этого и сделан. Клиенты будут распределяться по обоим адресам фронтэнда примерно поровну.

Главное тут правильно построить схему кластера. Если нужна действительно катастрофоустойчивость, то нужно брать свою AS и анонсировать по BGP ее из двух разных ДЦ, в каждом ДЦ чтобы были и фронтенды и бэкенды. Иначе никак.

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

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

whitemaster
() автор топика

почитайте о corosync/pacemaker.

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

heartbeat вроде как deprecated уже. Все наработки используются в проекте corosync/pacemaker

ipeacocks ★★★★★
()

Если украинский для вас не проблема http://ipeacocks.blogspot.com/2013/01/linux-ha-pacemaker-corosync.html

Или есть прекрасные маны на англ http://clusterlabs.org/doc/

http://clusterlabs.org/doc/en-US/Pacemaker/1.1-crmsh/pdf/Clusters_from_Scratc...

Лучше всего для тестировки поставить предпоследнюю версию федоры.

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

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

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

та ну почему дополнительного? два сервера на которые сможет просто переходить виртуальный айпи согласно описанным правилам.

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