Есть домен domain.com с адрессом 1.1.1.1Возможно ли настроить bind таким образом, что-бы при недоступности
первого сервера, domain.com резолвился в 2.2.2.2 (запасной сервер),
а по поднятию основного резолв возвращался на 1.1.1.1 ?Как организовать такую схему? Какой конфиг бинда должен быть на основном сервере,
какой на резервном? Что должно быть прописано у регистратора?
> Есть домен domain.com с адрессом 1.1.1.1
> Возможно ли настроить bind таким образом, что-бы при недоступности
> первого сервера, domain.com резолвился в 2.2.2.2 (запасной сервер),
> а по поднятию основного резолв возвращался на 1.1.1.1 ?проверям доступность сервера - если недоступен:
меняем файл зоны 1.1.1.1->2.2.2.2, serial++, rndc reload domain.com
при возобновлении аналогично, колько айпЫ наоборот
> Как организовать такую схему? Какой конфиг бинда должен быть на основном сервере,ммм бинд не умеет проверять доступность http
> какой на резервном? Что должно быть прописано у регистратора?тоже что и обычно
>> Есть домен domain.com с адрессом 1.1.1.1
>> Возможно ли настроить bind таким образом, что-бы при недоступности
>> первого сервера, domain.com резолвился в 2.2.2.2 (запасной сервер),
>> а по поднятию основного резолв возвращался на 1.1.1.1 ?
> проверям доступность сервера - если недоступен:
> меняем файл зоны 1.1.1.1->2.2.2.2, serial++, rndc reload domain.com
> при возобновлении аналогично, колько айпЫ наоборотА как я заменю файл зоны, если сервер недоступен? Предпологается что
bind запущен на основном сервере.
Напрашивается вывод что нужно ставить bind и на запасном сервере, и на нем производить вышеуказанные действия
отказоустойчивостью это можно назвать, разве что в пределах маленькой локальной сети ;)
>>> Есть домен domain.com с адрессом 1.1.1.1
>>> Возможно ли настроить bind таким образом, что-бы при недоступности
>>> первого сервера, domain.com резолвился в 2.2.2.2 (запасной сервер),
>>> а по поднятию основного резолв возвращался на 1.1.1.1 ?
>> проверям доступность сервера - если недоступен:
>> меняем файл зоны 1.1.1.1->2.2.2.2, serial++, rndc reload domain.com
>> при возобновлении аналогично, колько айпЫ наоборот
> А как я заменю файл зоны, если сервер недоступен? Предпологается что
> bind запущен на основном сервере.Смешно...
И так... есть домен domain.com с адрессом 1.1.1.1
Есть днс-сервер обслуживающий этот домен, причем он поднят на том же 1.1.1.1Но уважаемый...:) ведь запись о том, что домен domain.com обслуживается ДНС-сервером с адресом 1.1.1.1 прописана не на вашем сервере, а у регистратора.
Вы можете, указать (обязаны указать при регистрации) что у вас есть секондари, который вы соответственно разместите на 2.2.2.2Соответственно... если неработоспособность вашего сайта однозначно связывается с неработоспособностью ДНС-сервера НА ЭТОМ ЖЕ компьютере, то на секондари, для вашего домена можно просто указать адрес 2.2.2.2
> Есть домен domain.com с адрессом 1.1.1.1
> Возможно ли настроить bind таким образом, что-бы при недоступности
> первого сервера, domain.com резолвился в 2.2.2.2 (запасной сервер),
> а по поднятию основного резолв возвращался на 1.1.1.1 ?В зоне прописываете 2 своих ns. На запасном втором после тестирования подменяете зону и блокируете ответы, на нем же проверяете доступность 1-го, и если он лег - разрешаете отвечать...
>> Есть домен domain.com с адрессом 1.1.1.1
>> Возможно ли настроить bind таким образом, что-бы при недоступности
>> первого сервера, domain.com резолвился в 2.2.2.2 (запасной сервер),
>> а по поднятию основного резолв возвращался на 1.1.1.1 ?
> В зоне прописываете 2 своих ns. На запасном втором после тестирования
> подменяете зону и блокируете ответы, на нем же проверяете доступность 1-го,
> и если он лег - разрешаете отвечать...и получаете большооооой таймаут при резовинге в половине случаев
> Как организовать такую схему? Какой конфиг бинда должен быть на основном сервере,Знаю, что это не ответ на ваш вопрос, но будет порядком лучше использовать DNS-rr + (carp/vrrp), если это возможно.
>> Как организовать такую схему? Какой конфиг бинда должен быть на основном сервере,
> Знаю, что это не ответ на ваш вопрос, но будет порядком лучше > использовать DNS-rr + (carp/vrrp), если это возможно.а чем лучше? какие плюсы?
>>> Как организовать такую схему? Какой конфиг бинда должен быть на основном сервере,
>> Знаю, что это не ответ на ваш вопрос, но будет порядком лучше > использовать DNS-rr + (carp/vrrp), если это возможно.
> а чем лучше? какие плюсы?Ну, DNS-rr нужен лишь для распределения нагрузки, а carp/vrrp - для отказоустойчивости. carp/vrrp лучше тем, что работают мгновенно, и никакие кеш-ы на DNS-серверах или на стороне клиента не помешают failover-у. Более того, не надо изобретать велосипед, всё уже давно сделано, если идти таким путём ;)
Я даже конкретно могу сказать что использовать - carp или vrrp. Во FreeBSD лучше сделана реализация carp, а в linux лучше сделана реализация vrrp (на базе keepalived). Думаю, каждый кто пробывал ucarp, осознал какое это бажное убожество :)
А на ttl все забили что ли? :D
> А на ttl все забили что ли? :DНе забивал, просто:
1.) Очень не рекомендую делать 1-секундный TTL.
2.) Зачем изобретать велосипед с какими-то левыми скриптами, если есть хорошие стандартны и их реализации для обеспечения failover-а?
3.) Даже 1-секундный TTL может не помочь в силу того, как, наверника, работают браузеры. Отресолвили один раз, и далее работают с IP-адресом не проверяя его актуальность.И если уж на то пошло, то не рекомендую в таком случае использовать bind. Есть полно легковесных DNS-серверов с backend-ом в mysql. Всё таки работать с MySQL проще, чем с файлами в такой ситуации, например, серийник двигается вперёд автоматически ;). Меньше возможностей, чтобы накостылявить.
Я как раз и говорил, что существует понятие ttl и делать проверку доступности сервера и потом переключать что то не имеет смысла.> И если уж на то пошло, то не рекомендую в таком случае использовать bind. Есть полно легковесных DNS-серверов с backend-ом в mysql. Всё таки работать с MySQL проще, чем с файлами в такой ситуации, например, серийник двигается вперёд автоматически ;). Меньше возможностей, чтобы накостылявить
не вижу никакой взаимосвязи! Т.е. по твоему хранение записей в MySQL эффективней, чем в текстовом файле?
> Я как раз и говорил, что существует понятие ttl и делать проверку
> доступности сервера и потом переключать что то не имеет смысла.То что существует понятие "TTL", лично я, как думаю и остальные, и сами знаем (и, я, надеюсь, вы сейчас про DNS TTL, а не про IP TTL, иначе вообще какой-то бред получается). Однако объясните, пожалуйста, какую схему предлагаете Вы. Вы предлагаете разместить по bind-у на обоих серверах, проделегировать зону на них и занизить TTL? Тут всё хорошо, кроме всяких браузеров (если это веб-сервер), которые предётся перезапускать, чтобы они заного отресолвили и начали работать с новым адресом.. ну и прочих подобных неприятностей. Да и не хорошо, когда на двух NS-ах одной зоны разная информация.
Тем более в данной ситуации никак нельзя отказаться от балансировки нагрузки, если не переключать зону. Если у автора не предпоалагается, что сервера могут работать параллельно, то это не подходит.
Ествественно, если не получится воспользоваться {vr,ca}rp, то такая схема подходит. Собственно, если бы автор сказал, что объединить {vr,ca}rp-ом не удастся, была бы предложена какая-нибудь похожая схема.
> не вижу никакой взаимосвязи! Т.е. по твоему хранение записей в MySQL эффективней,
> чем в текстовом файле?Я написал "проще" и "меньше возможностей, чтобы на костылявить", но я не говорил "эффективнее". И поясню на всякий случай, что речь была про системы, где какие-то скрипты _автоматически_ правят зону по каким-то событиям. А почему проще? Например, когда изменяешь зону, нужно сдвигать серийник, а когда начинаешь делать подобные парсеры для файла - это серьёзный источник багов. Допустим, закончилось место на диске, тогда файл затрётся при первом же автоматическом передёргивании. Другими словами, нет, я не считаю, что это "эффективнее", я считаю, как я это изначально и написал, что это "проще".
как в схеме с отказоустойчивостью будет задействован "carp/vrrp" , где он будет расположен, где будут располагаться днс сервера?
> как в схеме с отказоустойчивостью будет задействован "carp/vrrp" , где он будет
> расположен, где будут располагаться днс сервера?Вы расскажите для начала что имеется и что требуется. IP-адреса эти гуляют из одного vlan-е или как вообще это всё у вас устроено? И какому именно сервису вы хотите прикрутить failover?
>> как в схеме с отказоустойчивостью будет задействован "carp/vrrp" , где он будет
>> расположен, где будут располагаться днс сервера?
> Вы расскажите для начала что имеется и что требуется. IP-адреса эти гуляют
> из одного vlan-е или как вообще это всё у вас устроено?
> И какому именно сервису вы хотите прикрутить failover?Имеется сервер, на нем 40 виртуальных доменов (apache virtual hosts).
Каждый из доменов прописан у своего регистратора, который ссылается на днс этого же сервера. На сервере стоит bind, обслуживает все домены. Есть второй сервер, он расположен в сети другого провайдера, на него с помощью rsync каждый час копируется все с первого. Трафиком он не нагружен, дежурит так сказать в stand-by режиме. Нужно чтобы при падении основного сервера (пропал канал к провайдеру, сгорело оборудование, упал апач и т.п.) весь трафик направлялся на резервный. Как только сервер оживает, весь траффик возвращался на него, а запасной переходил в режим ожидания.
>[оверквотинг удален]
>> И какому именно сервису вы хотите прикрутить failover?
> Имеется сервер, на нем 40 виртуальных доменов (apache virtual hosts).
> Каждый из доменов прописан у своего регистратора, который ссылается на днс этого
> же сервера. На сервере стоит bind, обслуживает все домены. Есть второй
> сервер, он расположен в сети другого провайдера, на него с помощью
> rsync каждый час копируется все с первого. Трафиком он не нагружен,
> дежурит так сказать в stand-by режиме. Нужно чтобы при падении основного
> сервера (пропал канал к провайдеру, сгорело оборудование, упал апач и т.п.)
> весь трафик направлялся на резервный. Как только сервер оживает, весь траффик
> возвращался на него, а запасной переходил в режим ожидания.Я, помнится, делал отказоустойчивый web-кластер с распределением нагрузки. Делалось это на связке DNS-rr+keepalived+drbd+ocfs2+rsync+mysql-replication+(php-sessions -> memcached+mysql). Вся связь между нодами осуществлялась по ipsec. Самым слабым местом был ocfs2, несколько тормозная FS. В остальном абсолютно рабочая схема.
Однако, если вы хотите делать по-вашему. Я так понял, эти сервера не имеют прямой связи друг с другом (в обход сети Интернет)? И что тоже важно, BGP, я так понимаю, тоже не доступен, так? Если "да и да", то, Вам, действительно стоит занизить TTL почти до нуля, проделегировать зону на оба сервера и выбрать один из _костыльных_ путей:
1.) Сделать скрипты, которые по событиям правят зону, переключая IP-адрес (самый терпимый, на мой взгляд, вариант). В этом случае вместо bind советую использовать какой-нибудь DNS с backend-ом в MySQL;
2.) Сделать на каждом из серверов так, чтобы bind указывал на себя, но тогда вы должны обеспечивать корректность работы "кластера" при параллельном использовании. К сожалению, эксперимент показывает, что клиенты опрашивают NS-сервера выбирая случайный, а не первый по их порядку;Ещё возможен вариант, что у вас есть третий хост в надёжном месте, который направляет запросы на рабочий сервер.
> Есть домен domain.com с адрессом 1.1.1.1
> Возможно ли настроить bind таким образом, что-бы при недоступности
> первого сервера, domain.com резолвился в 2.2.2.2 (запасной сервер),
> а по поднятию основного резолв возвращался на 1.1.1.1 ?
> Как организовать такую схему? Какой конфиг бинда должен быть на основном сервере,
> какой на резервном? Что должно быть прописано у регистратора?не стоит делать обеспечение отказоустойчивости сервисов средствами, не предназначенными для этого.
Выясните основные причины возможных отказов (каналы, железо, идиотизм персонала) и применяйте соответствующие методы (бгп, карп, кластеры, повышение квалификации)
>> Есть домен domain.com с адрессом 1.1.1.1
>> Возможно ли настроить bind таким образом, что-бы при недоступности
>> первого сервера, domain.com резолвился в 2.2.2.2 (запасной сервер),
>> а по поднятию основного резолв возвращался на 1.1.1.1 ?
>> Как организовать такую схему? Какой конфиг бинда должен быть на основном сервере,
>> какой на резервном? Что должно быть прописано у регистратора?
> не стоит делать обеспечение отказоустойчивости сервисов средствами, не предназначенными
> для этого.
> Выясните основные причины возможных отказов (каналы, железо, идиотизм персонала) и применяйте
> соответствующие методы (бгп, карп, кластеры, повышение квалификации)Если я правильно понял ситуацию, то ни BGP, ни carp не доступен в данной ситуации. А повышать квалификацию своего ISP или электриков - очень проблематично :)