Доброе время суток!
Как то слышал что bind умеет проверять доступность хоста перед тем как срезолвить доменное имя. Задача сводится к тому что бы реализовать некий failover средствами DNS. Подскажите действительно есть такая возможность у bind или это был чей то бред?
> Доброе время суток!
> Как то слышал что bind умеет проверять доступность хоста перед тем как
> срезолвить доменное имя. Задача сводится к тому что бы реализовать некий
> failover средствами DNS. Подскажите действительно есть такая возможность у bind или
> это был чей то бред?Каким образом можно проверить доступность хоста ДО ТОГО как его отрезолвить?
чей то бред
возможно путаешь с безотказным DNS
> возможно путаешь с безотказным DNSДля безотказности вроде как есть секондари.
>> возможно путаешь с безотказным DNS
> Для безотказности вроде как есть секондари.я имел в виду смену dns-зоны при выходе из строя основного сервера
> я имел в виду смену dns-зоны при выходе из строя основного сервераХм, если вас не затруднит, можно ссылку на почитать что это такое?
> Хм, если вас не затруднит, можно ссылку на почитать что это такое?к сожалению сам не помню где читал , но сводилось,вроде, все к тому, что берутся 2 сервера поднимаются 2 днс сервиса на каждом и соединяются между собой виртуальным адресом на который вешаются эти самые сервисы (или даже делается высокодоступный кластер), честно говоря на момент прочтения посчитал это какой-то ерундой и более подробно не вдавался в подробности. Так смысл как я понял был в том что если первый выходил из строя его заменял второй, естественно со своей зоной и.т.д
> возможно путаешь с безотказным DNSЧеловек вероятно собирается делать балансировку через ДНС с контролем загруженности серверов. То есть отдавать юзеру тот сервер что менее загружен, а не раунд-робин.
штука называется lbnamed
Задача следующая: есть 2-3 сервера 10.0.0.2, 10.0.0.3, 10.0.0.4
Доменное имя server.local у которого в А записаны данные адреса. Сервера находятся географически удаленно друг от друга и полностью реплицируют свои сервисы. Они мало нагружены и актуальность данных не сильно критична. Если информация различается на 5-10 минут ни чего страшного. Самое важное гарантированно предоставить пользователю рабочий сервис. Те если мало ли по каким то причинам один из серверов из пула стал недоступен (канал связи упал, сетевуха накрылась и тд) не резолвить его адрес и не отдавать его пользователю.
> Задача следующая: есть 2-3 сервера 10.0.0.2, 10.0.0.3, 10.0.0.4
> Доменное имя server.local у которого в А записаны данные адреса. Сервера находятся
> географически удаленно друг от друга и полностью реплицируют свои сервисы. Они
> мало нагружены и актуальность данных не сильно критична. Если информация различается
> на 5-10 минут ни чего страшного. Самое важное гарантированно предоставить пользователю
> рабочий сервис. Те если мало ли по каким то причинам один
> из серверов из пула стал недоступен (канал связи упал, сетевуха накрылась
> и тд) не резолвить его адрес и не отдавать его пользователю.Для этого у клиента есть список dns-серверов, если первый недоступен перейдет на следующий...
..
>> из серверов из пула стал недоступен (канал связи упал, сетевуха накрылась
>> и тд) не резолвить его адрес и не отдавать его пользователю.
> Для этого у клиента есть список dns-серверов, если первый недоступен
> перейдет на следующий...Да нет, скорее всего тут речь о поддержке healthcheck'ов - те если целевой хост сдох, то убирать его из выдачи dns сервера. Такая функциональность есть у многих сервисов - типа route53. но можно и самому сделать - через динамические зоны.
> Да нет, скорее всего тут речь о поддержке healthcheck'ов - те
> если целевой хост сдох, то убирать его из выдачи dns сервера.
> Такая функциональность есть у многих сервисов - типа route53. но можно
> и самому сделать - через динамические зоны.route53 отлично подходит под конкретную задачу. Только надо что то локальное. Но идея понятна.