Описываю ситуацию.
На данный момент есть один мастер ДНС сервер (который находится у нас на площадке), а так же слейв ДНС, который находится у провайдера. Схема в общем-то стандартная.Задача:
Необходимо обеспечить динамическое изменение файла зоны, которую обслуживает ДНС сервер в зависимости от доступности основного и-нет канала.
Т.е. на нашей площадке есть 2 и-нет канала (от двух разных провайдеров) для обеспечения бесперебойной работы веб серверов. В случае если основной канал падает зона ДНС изменяется относительного запасного канала (меняются внешние АйПи адреса серверов, на другого прова).
Но есть проблема. Т.к. мастер ДНС завязан на наш основной канал, при падении канала он не ессно не может отдать новый файл зоны слейв ДНС серверу провайдера.
Вопрос собственно как решить эту проблему без переноса мастер ДНС сервера на другую площадку. Можно-ли указать на слейв ДНС сервере провайдера два мастер сервера (masters { x.x.x.x; y.y.y.y }), которые будут соответствовать нашим двум АйПи адресам разных провайдеров? (Физически сервер ессно будет один и тот же)
Было время я как то тоже замарочился такой проблемой, я не буду говорить что моя схема тру но у меня работает и пока тфу тфу тфу без особых проблем.Ситуация вточ вточ как у вас.
Как делал, с динамическими файлами зон заморачиватся не стал, а запустил два бинда каждый на своем ип, причем в зависемости от текущего основного канала фаерволом все запросы к днс, входящие с резервного перенаправляются на днс основного канала и обратно.
Канал поменялся схема тоже инвертнулась вот и все. Естественно файлы зон у каждого сервера разные :-)Как вариант можно попробовать может подойдет.
Вообщето можно поизвращатся и придумать схему ...
!НО! подход сам по себе бредовый (если не сказать хуже), и таит в себе подводные камни:
предположим что первый канал упал, и сервак (не важно как), стал отдавать
другие адреса - те например www.your_server.ru был 123.123.123.123, а теперь он двруг стал 321.321.321.321. Все вроде бы гут - ДА ШАС!
Взглянем на удаленного пользователя - когда он начинал работать с серваком адрес был 123.123.123.123 - и вдруг он сменился на 321.321.321.321 - дак вот пользователь об этом не узнает ОООЧЕНЬ ДОЛГОЕ ВРЕМЯ, а все потому что у него свой dns (тотже бинд), у которого
есть кешь, который в бинде по дефолту НЕДЕЛЯ!!! В результате пользователь тупо ломится по старому айпи - и у него естественно ничего не работает.
Что будет при регулярнух паднниях канала - не сложно додумать.
О какой доступности и стабильности - тут может идте речь???Если уж очень надо так сделать - то надо пробовать использовать для записей мультиайпи,
те для одной записи несколько айпи - например основной и резервный. Также продублировать в whois инфо для мастер сервером с учетом дублирущих адресом - чтобы мастера были всегда доступны не зависима от того какой канал рабочий - ГЛАВНОЕ ЧТОБЫ ХОТЬ ОДИН РАБОТАЛ!
>!НО! подход сам по себе бредовый (если не сказать хуже)Ну БРЕДОВЫЙ мне кажется слишком, тут как правило диктует ситуация, а они как правело бывают разные.
>предположим что первый канал упал, и сервак (не важно как), стал отдавать
>другие адресаНу ну, как это НЕ ВАЖНО КАК и что это такое ДРУГИЕ АДРЕСА.
Все равно в этом контексте будет отдавать то что нужно.
это так общее замечание...>у которого есть кешь, который в бинде по дефолту НЕДЕЛЯ!!!
Поделись секретом, если у тебя есть в обслуге днс кокой у тебя там кешь
>Что будет при регулярнух паднниях канала - не сложно додумать.
>О какой доступности и стабильности - тут может идте речь???Конечно спасибо за совет и анализ ситуации, но как говорится мы сами с усам и без сопливых скользко :-).
Лично для меня при падении канала основная проблема не в днс а в том как бы можно скорей этот канал поднять.>Если уж очень надо так сделать - то надо пробовать использовать для
>записей мультиайпи, те для одной записи несколько айпи - например основной и резервный.Вот если бы вы до этой светлой идеи раньше дошли бы не пришлось бы так много печатать......
>так же продублировать в whois инфо для мастер сервером с учетом дублирущих адресом
>- чтобы мастера были всегда доступны не зависима от того какой
>канал рабочий - ГЛАВНОЕ ЧТОБЫ ХОТЬ ОДИН РАБОТАЛ!ВОТ ИМЕННО.
Не всегда стоит воспринемать чтото не учтя нюансов.
Плавно так до всего сами дошли :-)Ну а так вообще спасибо за общие рассуждения
Всем спасибо за обсуждение вопроса.
Я вот тут подумал, а что если просто банально прописать у регистратора 3 записи.
Две из них будут отвечать мастер серверу (с разными АйПи), а третья соответственно слейв серверу провайдера. Будет-ли такая схема работать?
по поводу кеша - если крупный сервак то ставить кеш на малый TTL хрено - будет слишком часто чистить базу и часто возобновлять кешь.У меня TTL кеша выставлен на серваках от 1 до 7 дней - в зависимости от объема памяти и загруженности.
Есть у меня серваки который до 1000 рекурсивных запросов паралельно молотят.