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

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

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

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

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

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

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

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

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

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

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

Сделай lacp

Сделай lacp

Ты у мамы сетевик?). И чем ему поможет агрегация?

lacp это не только агрегация

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

lacp это не только агрегация

lacp - это l2. А ТС хочет l7.

Ради интереса, а что же это еще?

Как минимум это отказоустойчивость физического канала

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

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

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

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

Оч смешно. Четыре звезды и такие советы.

Что не так?

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

Что не так?

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

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

Уели :)

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

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

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

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

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