Как разместить сайт сразу на двух серверах?

myhand, в сравнении с более-менее типичными значениями. Реальная ситуация - Auth NS на VDS, TTL 120, нагруженный проект.

Можно и поболее - 120 далеко не 10 минут, о которых писали выше.

Какая роль у этого проекта? WEB-сервер + DNS "сбоку припека"? Что конкретно там может создавать нагрузку? По сравнению с GET/POST HTTP запросами, DNS - это копейки.

Унесите NS на нормальный DNS-хостинг. Раз знаний не хватает - доверьте тому, кто умеет.

А вот с этого места можно поподробнее? Основная задача у меня это обеспечение работы сайта 24/7 без перерывов больше 10-15 минут (операторы сидят и делают на сайте заказы, стоит очередь и т.д. :-)). Доступ к сайту - вся россия, снг и европа. У нас как показала практика DNS до большинства пользователей расходится за 1-2 часа, но есть и такие, которые ждут до 12-18 часов. Очень хотелось бы решить эту проблему.

И еще - размещение dns сервера на внешней площадке это очень хорошая штука, но тогда встает вопрос - можно ли как то сделать резервный dns в другом датаценте? Тут как я понимаю не должно же быть трудностей?

Думаете я буду рекламировать какого-то конкретного провайдера? Да нет - не буду. Любой крупный хостер решает подобные задачи для своих клиентов.

Вы о чем? Кеширующие DNS плюют на настройки TTL записей что-ли? Бывает такое, конечно. Но это уже не техническая проблема, если люди не следуют стандартам.

Если Вы о изменении NS-записей (домен делегируется на другие ns-сервера) - это занимает до 72 часов по стандарту. Чтобы это не вызывало проблем для работы сайтов и т.п. - просто размещайте при переносе зону в точности так, как она была на старом сервере (за исключением NS-записей).

Что значит "резервный dns"? В dns некоторым образом встроено резервирование. Сколько захотите slave-серверов разместить - столько и делайте.

120 - это секунды. 120 сек. == 2 мин. И в описанном примере этот Auth NS, обслуживавший около 20 доменов, жил на довольно дохлом VDS. Создавать нагрузку могут как запросы, особенно рекурсивные, так и плохая конфигурация самого сервера имён - вне зависимости от того, что там за демон работает. А что до знаний - так это не мой проект и VDS был.

Эту проблему не всегда можно решить только на Вашей стороне. Процесс ресолва - многоступенчатый процесс и всякие кэши (локальные в браузерах, локальные в ресолверах, у провайдеров) очень много значат для него. Кстати, а что, Вы так часто меняете записи в DNS?

И можно и нужно. Есть специальные услуги под названием "DNS-хостинг". Но нужно учитывать географию расположения Ваших secondary и не допускать того, что какие-то из них будут находиться на одном канале за одним маршрутизатором, как это есть к примеру у ресолверов широко и недальновидно используемого OpenDNS.

Это время можно сократить ценой увеличения продолжительности переноса домена.

Я в курсе. 2 минуты и 10-15 есть разница?

Унести их на нормальный провайдеровский сервер. Поддержка зоны стоит копейки.

Какие еще рекурсивные запросы на auth dns? То, что плохая конфигурация - это и ежу понятно.

"Все эти кеши" должны руководствоваться тем, что в TTL для домена указано, для отдельных записей в том числе.

Это каким образом?

Есть конечно. С чем Вы спорите? Что слишком малый TTL может быть источником повышенной нагрузки на сервер? Или с тем, что некоторые хостинги просто не возьмут зону, если на master малые TTL?

Если один и тот же сервис используется и как Auth NS и как ресолвер для каких-то внутренних нужд. Это тоже часто бывает. Понятно, что это плохо со многих позиций, но многие так делают, поскольку считают, что "ну а вот же DNS-сервер под рукой".

Когда я вижу слово "должны" применительно к сфере IT, я ему не верю. Крайне рекомендую проверять и проверять, т.к. примеров некорректной работы кэширующих ресолверов, причём у довольно крупных провайдеров, масса.

Грамотным планированием и проведением процедуры переезда в первую очередь. Если переезд запланированный, то весьма поможет предварительное уменьшение до разумной величины TTL SOA и NS RR.

Всё зависит от бюджета.

/ru/forum/443282

в идеальном случае делать геокластер как у гугла

kpv добавил 21.04.2010 в 18:11

Резервируйте эту точку в двух местах. И отказ этой точки не значит "всё пропало, кричи караул", просто в этот момент пропадает мониторинг активных серверов и караул будет только в случае двойного отказа - этой точки управления и текущей локации прописанной в DNS.

Это именно Самый Дешёвый Вариант: серия DNS серверов, на которые проделегирован домен, которыми можно управлять из одной точки, с которой мониторится состояние разных локаций серверов.

p.s. Каждая следующая девятка в аптайме сервиса стоит раза в два дороже предыдущей

Да, именно с этим. Проблемы (вполне решаемые подходящим масштабированием сервиса) это вызовет только для масштабного dns-хостинга, а не для пары доменов.

Никаких проблем. Если, конечно, все безопасно устроено. В частности, рекурсивные запросы кому попало снаружи не позволено делать.

Например?

А как еще действовать в отношение клиентского ПО, если оно стандартам не следует? Это проблемы пользователей. Вы не можете запретить клиентскому ПО кешировать зону вплоть до бесконечно долго, игнорируя TTL записей. Просто те, кто делает подобное игнорируя стандарты - вполне ССЗБ.

Это - да. К сожалению, не все парковщики DNS такое позволяют. Так что предпочтительнее вариант смены критичных IN A записей (TTL которых мал) предварительно и затем - делегирование на новые NS-сервера (ежели их надо сменить, и тут уже неважно как долго это длится).

Означает именно "караул", если точка входа - это именно availability monitor+redirector:

Если же это просто availability monitor, то время реакции на падение одного из мониторящихся серверов увеличивается и в течение этого времени [часть] пользователей будет видеть connection refused/timed out.

ППКС.

Я Вам привёл практический пример и подтвердил его несколькими тезисами. Если не верите - это Ваше право.

Верно. Только вот при повальном распространении dynamic IP на клиентах и VDS/VPS как хостинговых решений о безопасности DNS-серверов (сервисов) не всегда думают или считают это менее важной задачей.

dmitrov.ru

Не очень понял, что Вы этим хотели сказать. Против какого именно клиентского ПО нужно действовать таким замысловатым образом?

Вы уже несколько раз употребляете термин "DNS-парковщики". Кто это?