Комментарии 3
Мне кажется, что вы переизобрели en.wikipedia.org/wiki/Round-robin_DNS
Ну если быть точнее — я взял его за основу и убрал основные недостатки:
1. Время ответа: вместо обращения к библиотеке nss_files, чтения /etc/hosts, потом обращения к nss_dns, чтения /etc/resolv.conf и потом обращения к DNS serveram по списку (и обработки ответов, таймаутов, если кто-то из DNS упал) делается обращение к библиотеке nss_xxx которая отдаёт уже готовый ответ из shared memory, что, по идее, значительно быстрее.
2. При внесении изменений в DNS они вступят в силу на slave-dns серверах самое раннее через секунду (из-за TTL). Репликация зоны между DNS серверами — тоже не самое быстрое действие.
3. Нет необходимости в настройке Failover-DNS'a.
4. Если первый в списке resolv.conf DNS помер — второй будет использован только после таймаута (мин. 1 сек), и так далее по списку. При списке в 3 сервера это всё может залипнуть аж на 3 секунды.
5. Если одна из нод хочет сказать «притормозите, мне и так плохо» — через DNS это весьма нетривиальная задачка.
Всё это вместе делает использование обычного round-robin DNS'a для, например, обращения к mysql порядка 5 000 раз в секунду мягко говоря пороховой бочкой. Не дай бог первый в списке DNS тормознёт на несколько секунд…
Далее:
5. Общаться с УДАЛЁННЫМ bind'ом через rndc, менять зону скриптами и перезапускать dns-server с каждой ноды, так чтоб все это сразу подхватили — имхо куда сложнее чем тупо писать в файл (named-socket) команду типа 'delete host somename' или 'add host somename ip priority'
7. Настраивать всю это конструкцие со slave-dns на каждой ноде и возможностью быстро менять состояние зоны с каждой ноды — то ещё удовольствие.
Ну а в остальном — да, согласен, довольно близко.
1. Время ответа: вместо обращения к библиотеке nss_files, чтения /etc/hosts, потом обращения к nss_dns, чтения /etc/resolv.conf и потом обращения к DNS serveram по списку (и обработки ответов, таймаутов, если кто-то из DNS упал) делается обращение к библиотеке nss_xxx которая отдаёт уже готовый ответ из shared memory, что, по идее, значительно быстрее.
2. При внесении изменений в DNS они вступят в силу на slave-dns серверах самое раннее через секунду (из-за TTL). Репликация зоны между DNS серверами — тоже не самое быстрое действие.
3. Нет необходимости в настройке Failover-DNS'a.
4. Если первый в списке resolv.conf DNS помер — второй будет использован только после таймаута (мин. 1 сек), и так далее по списку. При списке в 3 сервера это всё может залипнуть аж на 3 секунды.
5. Если одна из нод хочет сказать «притормозите, мне и так плохо» — через DNS это весьма нетривиальная задачка.
Всё это вместе делает использование обычного round-robin DNS'a для, например, обращения к mysql порядка 5 000 раз в секунду мягко говоря пороховой бочкой. Не дай бог первый в списке DNS тормознёт на несколько секунд…
Далее:
5. Общаться с УДАЛЁННЫМ bind'ом через rndc, менять зону скриптами и перезапускать dns-server с каждой ноды, так чтоб все это сразу подхватили — имхо куда сложнее чем тупо писать в файл (named-socket) команду типа 'delete host somename' или 'add host somename ip priority'
7. Настраивать всю это конструкцие со slave-dns на каждой ноде и возможностью быстро менять состояние зоны с каждой ноды — то ещё удовольствие.
Ну а в остальном — да, согласен, довольно близко.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Концепт простого Load-balancer'a / Failover'a IP сервисов