Я подключен к 2 разным провайдерам. Через любого из них можно получить доступ к веб-серверу.
Можно ли с помощью ДНС-сервера (BIND) настроить систему резервирования веб-сервера.
Чтобы www.host.com ресолвилось либо в IP первого провайдера, если канал второго провайдера "упал", либо в IP второго провайдера, если первый "упал".
>Я подключен к 2 разным провайдерам. Через любого из них можно получить
>доступ к веб-серверу.
>Можно ли с помощью ДНС-сервера (BIND) настроить систему резервирования веб-сервера.
>Чтобы www.host.com ресолвилось либо в IP первого провайдера, если канал второго провайдера
>"упал", либо в IP второго провайдера, если первый "упал".Я уже тут недавно задавал подобный вопрос. Но мысли свои криво выразил:
http://www.opennet.me/openforum/vsluhforumID8/4427.htmlУ тебя лучше получилось. Может чего нового ответят. :-)
>Я подключен к 2 разным провайдерам. Через любого из них можно получить
>доступ к веб-серверу.
>Можно ли с помощью ДНС-сервера (BIND) настроить систему резервирования веб-сервера.
>Чтобы www.host.com ресолвилось либо в IP первого провайдера, если канал второго провайдера
>"упал", либо в IP второго провайдера, если первый "упал".Для простоты, рассмотрим случай когда есть ваш веб-сервер и каналы двух провайдеров приходят непосредственно к нему.
1.Если вы администрируете primary DNS для домена host.com
2.Если логика "падения" канала реализована на веб-сервереможете попробовать:
- внутри host.com делегировать домен www.host.com , при этом host.com остается где был, а primary DNS домена www.host.com будет на вашем веб-сервере.Таким образом, скрипты или нечто подобное на веб-сервере, модифицируют локальный primary DNS, подставляя для A записи необходимый IP
Плюс, надо хорошо взвесить где разместить secondary для зоны www.host.com (и делать ли его вообще)Недостатки:
- совершенно ни к чему на веб-сервере дополнительный софт (BIND), который надо поддерживать
- проблема решена не полностью, поскольку сложившаяся на сегодняшний день традиция говорит нам что веб-сервер должен откликаться не только на имя www.host.com , но также на host.comЯ дальше не буду распростанятся, но в зависимости от топологии сетей можно попробовать обойти недостатки, используя к примеру механизм DNS Dynamic Update.
P.S. Ну и еще очевидная вещь -- время кеширования (TTL) для www.host.com надо позаботиться сделать очень маленьким.
Дилемма DNShttp://www.ccc.ru/magazine/depot/99_05/read.html?0803.htm
смотри в сторону
nslookup
set type=A
www.google.com.или еще круче www.microsoft.com
на одно имя лепится 2 IP
http://www.webmascon.com/topics/technologies/4c.asp
называется Круговой DNS
для начала - наверно самое простое решение
но это все не будет работать - надо ставить скриптик пингования внешнего канала (и убедиться что пингуется именно по нужному интерфейсу а не в обход) и менять (по результатам) route default. Сервер то один, роут - один. Соответственно его тоже прийдется рулить.
> Таким образом, скрипты или нечто подобное на веб-сервере, модифицируют локальный primary DNS, подставляя для A записи необходимый IP
это вы серьезно ? а как же время refresh ? Скоко его в таком случае для зоны (предвидя падение) выставить ?
Нельзя.
Если один из каналов падает, половина клиентов сервер не увидят (в случае, если имя резолвится в 2 IP).
Если имя резолвится в один IP (скрипты, динамический ДНС), все равно не выйдет. Многие используют кеширующие ДНС. Так что Ваш упавший IP будет находится в кешах по всему миру еще некоторое время после его смены на primary днс-сервере.
>Нельзя.
>Если один из каналов падает, половина клиентов сервер не увидят (в случае,
>если имя резолвится в 2 IP).
>Если имя резолвится в один IP (скрипты, динамический ДНС), все равно не
>выйдет. Многие используют кеширующие ДНС. Так что Ваш упавший IP будет
>находится в кешах по всему миру еще некоторое время после его
>смены на primary днс-сервере."некоторое время" на кеширующих ДНС, можно регулировать с помощью параметра TTL на primary. ИМХО.
>"некоторое время" на кеширующих ДНС, можно регулировать с помощью параметра TTL на
>primary. ИМХО.
Неее - не выйдет. Это время сколько сохранять кеш в случае помирания главного сервера. Ничего этим не добьетесь. По умолчанию - или 12 часов или 2 недели. О секундах и речи не может быть.http://www.dns-master.ru/help/help.html#p8_2
единственное чего наверное можно добиться - траффик ДНС запросов будет превышать трафик веб-сервера.
Идея в другом - отдавать каждый раз другой IP
Что-то мне подсказывает что все-таки прийдется иметь 2 сервера. Одним не обойтись. Или чего-то думать - какой-то изврат роутинга. Типа - роутинг в зависимости от адреса сетевой карты.
>
>>"некоторое время" на кеширующих ДНС, можно регулировать с помощью параметра TTL на
>>primary. ИМХО.
>
>
>Неее - не выйдет. Это время сколько сохранять кеш в случае помирания
>главного сервера. Ничего этим не добьетесь. По умолчанию - или 12
>часов или 2 недели. О секундах и речи не может быть.
>
>
>http://www.dns-master.ru/help/help.html#p8_2
>Странно. По моему здесь все однозначно написано.
8.2. Параметры Default TTL, TTL, Minimum TTL
Временные параметры Default TTL, TTL, Minimum TTL определяют время TTL (Time-to-live - "время жизни"), в течение которого DNS-серверы (кроме вторичных), получившие информацию о записях с любого DNS-сервера, будут ее хранить в своей памяти (кэше) и сообщать ее по запросам других DNS-серверов.
TTL:
определяет "время жизни" для конкретной записи.
Необязательный параметр. Если значение параметра в записи не указано, то "время жизни" определяется параметром Default TTL.Рекомендуемое значение:
86400 (1d);
Диапазон допустимых значений:
от 0 до 2147483647 секунд включительно (2 в степени 31 минус 1.)
Что мешает установить TTL = 60 сек, то есть через 60 сек информация о моем домене в кеше любого ДНС сервера будет считаться устаревшей. То есть будет новый запрос на Праймари ДНС, который будет отдавать только "живой" IP.
> единственное чего наверное можно добиться - траффик ДНС запросов будет превышать
>трафик веб-сервера.
>Это вопрос другого топика.
>Идея в другом - отдавать каждый раз другой IP
>
>Что-то мне подсказывает что все-таки прийдется иметь 2 сервера. Одним не обойтись.
>Или чего-то думать - какой-то изврат роутинга. Типа - роутинг в
>зависимости от адреса сетевой карты.
Нет. У Squidа есть функция "back proxing", точно не помню название, с ее помощью не прийдется думать - какой-то изврат роутинга.