LINUX.ORG.RU
Форум — Admin  

Автоматическое переключение на резервный канал для WEB сервера. (DNS)

 


0

1

Subj?
Как настроить DNS сервер (BIND 9), что бы при недоступности основного канала, все клиенты начинали подключаться к резервному?
Тут 2 проблемы
1. Если добавить две А записи, то каналы будут чередоваться, что мне не надо, тк он может попасть на неработающий канал.
2. Кэш DNS у клиента. Если я буду менять настройки ДНС сервера, то они сразу не заработают из-за кэширования на клиенте и на других хопах.
А переключение должно происходить прозрачно для клиента.

★

Это не решается биндом. DNS как сервис никогда нигде не работает мгновенно. У клиентов всегда есть кэш.

Для балансировки на коленке можно использовать haproxy или nginx, которая/ый висит в стабильном месте с нормальным каналом и перенаправляет трафик на рабочий в данный момент IP.

Ну и если подойти к вопросу взвешенно, то не надо держать веб сервис для клиентов там, где есть возможность падения канала ( в помещении вашей фирмы, я полагаю)

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

В том то и дело. Что сеть закрытая. И вариант расположения в другом месте - не подходит.

mnk ★
() автор топика

Никак. Используй пару балансеров, если нужно дешево и сердито - carp.

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

В том то и дело. Что сеть закрытая.

Если сеть закрытая, то зачем клиенты смотрят веб снаружи?

Все равно: прендуем виртуалку где угодно, ставим на нее haproxy, в ней делаем балансировку, А запись на айпи haproxy. При это ваши сервисы остаются у вас в «закрытой» сети.

constin ★★★★
()

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

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

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

К тому же, он сам написал, сеть то у него закрытая. Либо я не правильно понял его кейс.

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

Чтобы получить отказоустойчивость вместе с агрегацией нужна фабрика, которой в обычных условиях СМБ почти ни у кого нет. Такая фабрика стоит будь здоров и не очень тривиальна в настройке. Поэтому чаще получается или отказоустойчивость, но работает 1 аплинк, или агрегация, но к одному коммутатору (что естественно никакая не отказоустойчивость).

В итоге по факту проще поднять такие вещи на л7, чем вникать в сетевые вещи.

stave ★★★★★
()

Сделай ttl dns-записи в несколько секунд. Тогда кеш будет протухать почти мгновенно.

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

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

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

Что не так?

Первый ответ первая строка. Клиенты тоже кэшируют. И плевать на ttl.
Есть сервера которые тоже плюют на ttl, не то что бы их много, но все-таки попадаются.

З.ы. 5 звезд, и не знает что значат звезды на лоре.

Уели :)

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

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

Это нарушение RFC, и нормальные кеширующие DNS так не делают.

Можно еще вспомнить, что кто-то может в hosts прописать ойпи, и тогда балансировка ТСа не сработает. А потом еще что-нибудь, и в итоге прийти к выводу, что балансировка/failover через dns - не самая лучшая идея.

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

Это нарушение RFC, и нормальные кеширующие DNS так не делают.

Нарушение, не нарушение, но по факту такие есть. И ведь не скажу что я так уж часто меняю записи dns, но иногда при смене всплывают такие.

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