Добавлено: 28/12/03 в 03:48

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

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

в принципе были кой какие идеи, но может кто нить знает 100% работающие варианты.

Добавлено: 28/12/03 в 04:52

round robin dns

A load balancing technique in which balance power is placed in the DNS server instead of a strictly dedicated machine as other load techniques do.
Round robin works on a rotating basis in that one server IP address is handed out, then moves to the back of the list; the next server IP address is handed out, and then it moves to the end of the list; and so on, depending on the number of servers being used. This works in a looping fashion.

Round robin DNS is usually used for balancing the load of geographically distributed Web servers. For example, a company has one domain name and three identical home pages residing on three servers with three different IP addresses. When one user accesses the home page it will be sent to the first IP address. The second user who accesses the home page will be sent to the next IP address, and the third user will be sent to the third IP address. In each case, once the IP address is given out, it goes to the end of the list. The fourth user, therefore, will be sent to the first IP address, and so forth.

Although very easy to implement, round robin DNS has important drawbacks, such as those inherited from the DNS hierarchy itself and TTL times, which causes undesired address caching to be very difficult to manage. Moreover, its simplicity makes that remote servers that go unpredictably down inconsistent in the DNS tables. However, this technique, together with other load balancing and clustering methods, can produce good solutions for some situations.

Добавлено: 28/12/03 в 05:00

login.icq.com по такому принципу работает. Что не запросишь - каждый раз натыкаешься на ссылку на саб-домен, в следствии чего разные IP попадаются.

Вот только не знаю, как это реализуется.

Добавлено: 28/12/03 в 05:05

там скорее всего более дорого реализовано через cisco local director

Добавлено: 28/12/03 в 07:20

RFC 1794

Добавлено: 28/12/03 в 15:01

глюк.

Последний раз редактировалось: bog (28/12/03 в 15:04), всего редактировалось 1 раз

Добавлено: 28/12/03 в 15:03

про такой вариант мне говорили, но мне надо не распределение трафа,а чисто работу. + я не понял что будет если этот днс сервер завалить.

У меня была идея поставить на каждый сервак неймсервер.
прописать в хуиз домене эти неймсерверы. И если один неймсервер (и следовательно и сервер) не работает,
то по идее будет же обращение к другому НС и следовательно будет выдаваться ИП другого сервера.

Правильно я понимаю как днс работает ?

Добавлено: 28/12/03 в 16:07

Ну да. Дык так и есть в общем-то. При регистрации домена указываешь НСы, на которых он зарегистрен. При дауне одного из них, запрашивается альтернатива. Лично у меня в панельке можно указать до 10 (вроде) НСов.
Ну а с зеркалированием возможно ты прав. Каждое зеркало имеет НС, который прописан в хуисе. Теоретически должно работать Не знаю только, как застраховаться от падения хуиса

А ты не к ядерной войне готовишься случаем?

Добавлено: 28/12/03 в 16:10

Кстати имеет место кэш НС-ов. Т.е. эти НСы, в которых ты пишешь свои хосты, их записи кэшируются провайдерскими НС-ами тех пользователей, которые у тебя лазят. По этому при такой резкой смене ай-пишников, это может не сработать в стандартной конфигурации НСа. Поле "Expires" надо выставить как можно меньше. Но тогда возрастет нагрузка на сам NS.

Добавлено: 28/12/03 в 16:29

Продвигали систему SmardDNS (Из наших аналог делал Security). Позволяет распределять нагрузку между серверами.. Решает эти проблемы в лет.

Добавлено: 28/12/03 в 20:46

У каждого уважающего себя хостера несколько Name-серверов.
Кроме того есть халявные сервисы которые хостят домены.
Всех прописать и баста.

Добавлено: 29/12/03 в 00:55

ок, завтра бум пробовать ченить сделать. а то один сервак два раза за неделю уже падал

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

т.е. вначале то что прописано в поле ns1, потом 2 и т.д.
или этот порядок от чего то другого может зависеть.

Добавлено: 29/12/03 в 07:46

Вся эта демагогия хороша,НО,ныче провайдеры,дабы экономить DNS траффик,считывают данные как правило с ns1,а ns2...хх игнорят уроды,поэтому прописывание домена на разных серверах и сетках почему-то последнее время не имеет никакого значеня.

Случай из практики :
Многие клиенты viva-host , пишут свои DNS-ы как ns1.xtraff.com и ns2.xtraff.com ,зоны на них обновляются одновременно и все в соотв с RFC ,НО,как только падает ns1.xtraff.com (счас уже сделали хитрее(залатали таким образом багу),просто ИП,поднимаем резервно на другом сервере),домены становятся недоступны,хотя с вторичным DNS все в порядке и он работал.
--------
Вобщем резюме,устойчивость определяется тем,что неймсерверы находятся на ненагруженном сервере,в хорошей сети,а вот на случай падения,чтобы вызвать другой IP(на примере login.icq.com) используется djbdns ,который это умеет.,с этим нет и не было проблемм,но падение ns1 ,как правило все равно в 80% оборачивается недоступностью домена....причем для многих,разъясню,что IP адрес ns1 ,внешние провы будут запрашивать не по записи в файле зоны,а по адресу,указанному у регистратора,и прописанного в root серверах.

Добавлено: 30/12/03 в 11:45

У меня длительное время сотни доменов висели на нс2 - и никаких проблем небыло.. Причем говорить об об очередности я бы тоже не стал - слейв тянет инфу с прайма да, но внешние запросы могут в первую очередь с слейва потянуть - было такое тоже - меняешь на прайме, слейв не обновил - и у многих и многих инфа не обновляеца. Гдето у трети сеток:)

Добавлено: 03/01/04 в 17:30

вообщем если решения не найдете то стучитесь буду делать