Манипуляции с ДНС

Valenok

Новичок
Манипуляции с ДНС

Есть два веб сервера
Ip1: 132.123.123.123
Ip2: 789.789.789.789
и 1 домен: www.xxx.ru

Задача следующая:
Сервер 123 иногда падает.
Нужно чтоб в этом случае все запросы к домену xxx.ru
отправлялись к серверу 789.

Что для этого нужно сделать ?
(Apache 2.2.11, Ubuntu 9.04 на обоих)

На сколько я понимаю достаточно просто прописать name сервера в виде
ns1 - 123.123.123.123
ns2 - 789.789.789.789
для домена.

Проверить к сожалению на практике в ближайшее время не имею возможности.
Обращаюсь за теоритической помощью.


Задача вторая
ping google.com = 15 ms
ping google.com моегод друга из австралии тоже 15 мс

Вопрос: как происходит это перенаправления к локальным серверам гугла ?
 

MiksIr

miksir@home:~$
Теоретически - да, два NS-а на разных серверах. Каждый NS отдает A для домена на себя.

> Вопрос: как происходит это перенаправления к локальным серверам гугла ?

DNS сервер по IP адресу клиента определяет ближайший к нему и выдает этот IP.
 

Активист

Активист
Команда форума
MiksIr
> Теоретически - да, два NS-а на разных серверах. Каждый NS
> отдает A для домена на себя.

Вы ошибаетесь. Получив IP с NS'са - DNS клиента (провайдера) закешит результат. Нет гарантии, что после 10 секунд от первого обращения хоть с одного клиента провайдера твой сервер, он не упадет. Можно, конечно, ограничение на кеш в 10 секунд поставить. На фронте кроме нигса ничего быть не должно.

Но как временная затыка - будет работать, конечно, если снизить время кеширования.

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

Политику резервирующих серверов не очень любят руководители, ибо, экономическая целесообразность их использования появляется только в случае полной остановки работы серверов, во всех остальных случаях - нааффига они нам??!
 

MiksIr

miksir@home:~$
Активист
стопудов

Есть разные задачи, разные решения. DNS баланисровка позваляет обеспечить бюджетное решение при серверах в разных ДЦ. Иных решений я не знаю (без покупки адресов, автономки, да еще уговорить оба дц все это хозяйство поддерживать). Имеет свои минусы, но вполне рабочее решение.

Если сервера в одном дц, то да - carp или heartbeat.
 

fender

Новичок
Автор оригинала: MiksIr
Теоретически - да, два NS-а на разных серверах. Каждый NS отдает A для домена на себя.
Такая схема, когда каждый NS выдает для 1 зоны несколько A-записей, абсолютна не нужна и нестандартна - оба сервера должны быть master.
Для примитивного циклического перебора адресов для одного домена достаточно просто иметь несколько А-записей. Тогда резолверы ОС будут выбирать при каждом запросе следующий по порядку ip.
Пример того же гугла:

$ host -t A google.com
google.com has address 74.125.45.100
google.com has address 74.125.67.100
google.com has address 74.125.127.100

$ ping google.com
...(74.125.45.100) 56(84) bytes of data.

$ ping google.com
...(74.125.127.100) 56(84) bytes of data.

$ ping google.com
...(74.125.67.100) 56(84) bytes of data.
 

MiksIr

miksir@home:~$
Абсолютизм - это диагноз, а мы живем в реальном мире. Проделайте такой же эксперимент под виндой - и тогда можно будет продолжить разговор о плюсах и минусах такого решения.
 

fender

Новичок
Я не утверждаю, что это решает проблему топикстартера. Что мой вариант, что ваш практически равнозначны.
Просто ваше решение очень нестандартное, а то что написал я - общепринято. Как-то так.
 

MiksIr

miksir@home:~$
Не равнозначны. Ресолвер поддерживает выбор рабочего NS-а, а вот механизмов выбора рабочего A - нет. Т.е. если один сервер лежит, то ресолвер сможет достучаться до рабочего сервера, а вот какой IP он выберет, когда получит их две штуки - рабочий или нет, вероятность 50% =) Если будет выбран нерабочий сервер - он уйдет клиенту, закешируется у него (в локальном DNS кеше или хотя бы в браузерном кеше), и минут на 15-30 шанса у клиента достучаться до рабочего сервера не будет.
Тех, кто работал с этим сервером в момент падения - уже ничто не спасет, а вот новых клиентов - вполне можно направить на рабочий сервер.
Так что это, конечно, костыль, но рабочий, используется (не я его придумал)... все остальные варианты - дороги (и, кстати, тоже не обеспечивают мгновенного перебрасывания клиентов из одного ДЦ в другой)
Классический dns round-robin хорош, только когда сервера рядом и в случае падения одного - второй заберет его IP.
 

MiksIr

miksir@home:~$
Кто о чем, а Активист о своем =) Как вы этим кластером организуете резервирование ДЦ? Вариант, что у вас свои каналы до всех ДЦ, и связность с миром сами обеспечиваете - отбросим как утопию =)
Кстати, помнится, агава пыталась предлагать такую услугу в свое время - резервирование серверов в нескольких _своих_ ДЦ... не знаю, чем эти попытки закончились.
 

Активист

Активист
Команда форума
MiksIr
В где написано, что ДЦ разные?

-~{}~ 28.07.09 08:46:

MiksIr
Есть же общая практика. Зачем эти танцы с DNS и бубном...
 

MiksIr

miksir@home:~$
Но нигде не сказано, что они и в одном ДЦ =) А два сервера в одном ДЦ рядышком - это частный случай, так что исходим из общего. На самом деле такой вопрос очень часто встает в лоу-бюджетных вариантах, когда хочется зарезервировать не только сервера, но и ДЦ и каналы - если проблемы с ДЦ не часты (но, кстати, почему-то чаще, чем проблемы с серверами), то проблемы с каналами - еще более часты =) Решения типа CDN, когда DNS определяет куда клиенту ближе, да еще и мониторит состояние сервисов... оно, конечно, правильное, но далеко не бюджетное =) Товарищи из немамбы не дадут соврать =)
 
Сверху