- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Особо не вникал, но может кто-то знает и поправит.
1. В буржуйнете видел сайт (уже не помню где) который предлагал услугу под названием похожим на backup DNS.
Из описания понял, что суть этой услуги в том, что они следят за состоянием вашего сайта/сервера, и в случае его падения их DNS-сервера перенаправляют пользователей на указанную вами страницу (или ваше зеркало).
Тогда вспомнил о кешах DNS и закрыл страницу, но может в этом есть смысл?
2. Есть ли стандарт при котором при неответе первого адреса из списка "IN A" запрос должен отправляться на второй и последующие? Тогда это тоже должно помочь.
Есть ли стандарт при котором при неответе первого адреса из списка "IN A" запрос должен отправляться на второй и последующие? Тогда это тоже должно помочь.
Элементарно, Ватсон. :)
В файле зоны пишем где-то так:
google.com. A 72.14.207.99
google.com. A 64.233.187.99
google.com. A 64.233.167.99
...
При DNS-запросе получаем ответ:
[root@power]#host google.com
google.com has address 72.14.207.99
google.com has address 64.233.187.99
google.com has address 64.233.167.99
Здесь еще:
Впервые "тасовать" адреса (Shuffle Addresses) предложил Брайн Бичер, но его идея требовала введения дополнительных записей описания ресурсов, поэтому прошло решение Маршала Розе, которое, собственно, и называется Round Robin код.
Round Robin код разрабатывался для кластеров, на которых функционировали серверы доменных имен. Именно это обстоятельство позволяло не заботится о реальной нагрузке на хост, т.к. ее (нагрузку) учитывала кластерная архитектура вычислительной установки и соответствующая операционная среда.
Следует заметить, что современные resolver-ы позволяют игнорировать при соответствующей настройке упорядочивание записей в отклике сервера и опираться на топологию сети, т.е. обращаться к наиболее предпочтительному с их точки зрения IP-адресу. Таким resolver-ом является, например, resolver операционной системы Windows2000.
И обратите внимание на директивы rrset-order, sortlist и topology в конфиге BIND.
Элементарно, Ватсон. :)
В файле зоны пишем где-то так:
google.com. A 72.14.207.99
google.com. A 64.233.187.99
google.com. A 64.233.167.99
...
При DNS-запросе получаем ответ:
[root@power]#host google.com
google.com has address 72.14.207.99
google.com has address 64.233.187.99
google.com has address 64.233.167.99
Ну, это немного не то.
Это балансировка нагрузки, если все сервера работают. В принципе, тоже должно помочь при выпадении одного из них.
Я имел в виду реакцию на стороне клиента, если у него есть список IP то он ведь не перебирает все по порядку, пока хоть кто-то не ответит. Обычно берут первый адрес и всё, даже в настройках резолвера можно отрубить возврат нескольких IP для имени.
Такого клиента можно написать, но есть ли это в стандартах - если не ответил первый IP то пытаться соединиться со вторым?
По идее ведь для этого и придумали возможность прописать несколько "IN A".
Для почты (MX-записей) это работает, а для IP-адресов?
Я имел в виду реакцию на стороне клиента
Даже при наличии такого резольвера, в данной ситуации это никак не поможет - всем посетителям его не поставишь. :)
Сейчас малость поэкспериментирую в резольвером XP и напишу, что вышло.
UPD:
Сделал в локальной сети (использую bind8) такую зону. Вставил десяток неотвечающих и среди них один реальный IP. Все сервисы винды сразу нашли рабочий и пошли только к нему. :)
Даже при наличии такого резольвера, в данной ситуации это никак не поможет - всем посетителям его не поставишь. :)
Сейчас малость поэкспериментирую в резольвером XP и напишу, что вышло.
UPD:
Сделал в локальной сети (использую bind8) такую зону. Вставил десяток неотвечающих и среди них один реальный IP. Все сервисы винды сразу нашли рабочий и пошли только к нему. :)
Неплохо. :)
В таком случае это один из вариантов ответа на вопрос ТС: прописать в ДНС IP-адреса своих серверов в разных ДЦ, винда найдёт работающий.
Т.е. Вы хотите сказать что всего лишь нужно в ДНС дать вторую А-запись с ИП сервака в другом ДЦ на котором тупо будет лежать дубль? И в случае не ответа ИП в первой А-записи клиент получит второй ИП?
(я бы сам проэксперементировал, но нет возможности вырубить сервак)
Т.е. Вы хотите сказать что всего лишь нужно в ДНС дать вторую А-запись с ИП сервака в другом ДЦ на котором тупо будет лежать дубль? И в случае не ответа ИП в первой А-записи клиент получит второй ИП?
(я бы сам проэксперементировал, но нет возможности вырубить сервак)
Не 100%.
Поскольку этот способ опирается на логику клиента, тут нет гарантии.
У меня на линуксе стоит запрет возврата нескольких IP для одного адреса: если не включить, такое не пройдёт.
На виндузах, похоже, проходит.
И в случае не ответа ИП в первой А-записи клиент получит второй ИП?
Если просто прописать, то клиенты будут бегать на оба сервера равномерно.
Если хотите, чтобы на второй ходили только при отказе первого, используйте sortlist в конфиге бинда..
Если просто прописать, то клиенты будут бегать на оба сервера равномерно.
Если хотите, чтобы на второй ходили только при отказе первого, используйте sortlist в конфиге бинда..
В целом всё верно.
Однако отмечу, что такое возможно по большому счёту только в случае статического контента. В случае если выдаётся динамика, да ещё и из базы, то сколько с днсами не играйся, ничего путного не выйдет =)
Стоимость решения с бэкапным каналом от другого прова в ДЦ и свою автономку
вполне сопоставимо со стоимостью сервера в другом дц и его размещением.
Зачем городить всю эту игру с днс?
Однако отмечу, что такое возможно по большому счёту только в случае статического контента. В случае если выдаётся динамика, да ещё и из базы, то сколько с днсами не играйся, ничего путного не выйдет =)
А датасервер в третьем. :) Или по технологии master - slave. Остается только угадать, кто первым ляжет. :D