LINUX.ORG.RU

dnsbalancer — демон балансировки UDP-трафика рекурсивного DNS

 , , , ,


2

2

Компания Ланет Нетворк сделала общедоступным код демона для балансировки UDP-трафика рекурсивного DNS — dnsbalancer. Демон используется для распределения клиентских DNS-запросов между многочисленными рекурсивными DNS-серверами с целью балансировки нагрузки и повышения отказоустойчивости кластера рекурсивного DNS.

Возможности dnsbalancer'а:

  • поддержка IPv4 и IPv6;
  • поддержка множества фронтендов и бекендов одновременно;
  • слежение за доступностью бекендов, игнорирование недоступных бекендов;
  • работа в многопоточном режиме;
  • поддержка правил обработки DNS-запросов с использованием регулярных выражений и выполнением различных действий над клиентскими запросами;
  • ведение статистики по фронтендам, бекендам, типам запросов и задержкам ответов.

Демон способен обрабатывать десятки тысяч запросов в секунду на виртуальной машине с несколькими ядрами. Код демона работает только под управлением ядра Linux версии 3.9 и выше.

>>> Исходный код

★★★★★

Проверено: Shaman007 ()
Последнее исправление: Shaman007 (всего исправлений: 1)

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

https://en.wikipedia.org/wiki/Equal-cost_multi-path_routing :

  • поддержка IPv4 и IPv6;
  • поддержка множества фронтендов и бекендов одновременно;
  • слежение за доступностью бекендов, игнорирование недоступных бекендов;
  • работа в многопоточном режиме;

Тем более если это интернет-провайдер и динамическая маршрутизация там уже используется в полный рост.

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

  • поддержка правил обработки DNS-запросов с использованием регулярных выражений и выполнением различных действий над клиентскими запросами;
  • ведение статистики по фронтендам, бекендам, типам запросов и задержкам ответов.

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

MumiyTroll ★★★
()
Ответ на: комментарий от joy4eg

Не-а. В nginx запилили поддержку UDP уже после того, как мы своё поделие внедрили в продакшн. А сейчас руки не доходят, но и правда, самому интересно. Может, как-то сделаю.

post-factum ★★★★★
() автор топика

Зачем оно??...

Один инстанс Unbound жуёт на 6 ядрах более 600kpps(!) при правильной настройке, сами юзаем. А они 10kpps балансируют.. странные люди.

blind_oracle ★★★★★
()
Последнее исправление: blind_oracle (всего исправлений: 1)
Ответ на: комментарий от DELIRIUM

Там тоже есть UDP балансер, и его тоже можно использовать для балансировки UDP трафика (в т.ч. DNS).

joy4eg ★★★★★
()
Последнее исправление: joy4eg (всего исправлений: 1)
Ответ на: комментарий от joy4eg

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

cvv ★★★★★
()

Обычно такое делается при помощи Anycast. Нескольким серверам назначается общий IP-адрес, анонсируемый в сеть при помощи протокола динамической маршрутизации, например, OSPF. Естественным путем получается и распределение нагрузки, и выбор ближайшего сервера, и надежность. Единственное, за чем нужно следить админам - чтобы по данному адресу оставалось не менее одного работоспособного сервера, и ни один сервер не анонсировал себя, если демон DNS у него сдох.

Deleted
()

А код, видимо, на Си написан. Кто-то может объяснить, где у этого демона тесты? Или у Си-программистов ничего тестировать не принято? Как-то страшно должно быть такое прям в открытый мир выставлять лицом

ostin ★★★★★
()
Ответ на: комментарий от Deleted

Это делается гораздо проще - обычным VRRP с плавающим виртуальным адресом (или несколькими). И не надо заморачиваться с анонсами.

Anycast это скорее не отказоустойчивость, а выбор наиболее близкого хоста (пусть и в попугаях BGP).

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

Это делается гораздо проще - обычным VRRP

При обычном VRRP нет защиты от отказа того рутера, который обслуживает оба сервера.

Deleted
()
Ответ на: комментарий от blind_oracle

Но с другой стороны приятно узнать что еще остались люди которые в состоянии хоть чтото написать.

cvv ★★★★★
()
Ответ на: комментарий от Deleted

Всмысле? Что значит «обычном»? Шлюз должен быть отказоустойчивым - как это реализовано (VSS, VRRP/HSRP/GLBP или ещё как) - не важно.

Затем сам сервис через VRRP (keepalived), либо какой-нибудь Pacemaker делается отказоустойчивым.

В итоге не имеем единой точки отказа.

blind_oracle ★★★★★
()

Это для тех, кто не осилил anycast? А как оно работает, когда запрос или ответ в UDP не помещается и DNS переключается на TCP? Бессмысленный код.

anonymous
()
Ответ на: комментарий от Harald

средствами Iptables эту же задачу нельзя было решить?

Во, я тоже хотел про это спросить!

vasya_pupkin ★★★★★
()
Ответ на: комментарий от Harald

Нет. Эта задача не решается ни iptables, ни этим вот поделием.

anonymous
()
Ответ на: комментарий от blind_oracle

И всё это ради того, чтобы DNS не падал? Anycast делает всё то же самое, только проще, быстрее, надёжнее и на уже имеющейся инфраструктуре.

inb4: рекурсивные и авторитативные DNS-серверы на всех континентах кроме Южной Америки. ~2000 r/s/s в среднем. Anycast. Брат жив.

anonymous
()
Ответ на: комментарий от Harald

Нет, iptables не умеет DPI в том смысле, в котором он нам нужен.

post-factum ★★★★★
() автор топика
Ответ на: комментарий от post-factum

Печально. Небось ещё и пользователей за NATом держите и отдельные деньги за «белый айпи-адрес» берёте?

anonymous
()
Ответ на: комментарий от post-factum

Стало быть доброе начало в вас есть! Ну что же, не стоит себя сдерживать, вперёд к массовым деплоям IPv6 и отказу от наколенных решений по DNS-балансировке ;)

anonymous
()
Ответ на: комментарий от anonymous

Можешь сравнить. С того времени, как мы внедрили своё, это поделие так и не научилось много потоков и больше 2^16 одновременных запросов. Хотя да, это более фичастый и перспективный конкурент, но когда-то потом, а не сейчас.

post-factum ★★★★★
() автор топика
Ответ на: комментарий от post-factum

Конечно, если запретить весь трафик на udp/53 tcp/53 во внешний мир ;)

anonymous
()
Ответ на: комментарий от Deleted

Пока в планах две вещи — хранение конфига в мускуле с релоадом на лету и оптимизация ACL, т.к. я уверен, что он будет тормозить, если правил будет много.

post-factum ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Что городить? Пару строк в конфиге VRRP? А для эникаста нужно роутинговые демоны пущать на каждом сервере чтобы анонсы отваливались вместе с сервером.

Пока эникаст-анонсы перестроятся у тебя отвалится по таймауту куча запросов, VRRPv3 же сработает за доли секунды.

Ещё раз - эникаст это, в основном, способ сократить количество хопов до сервера, а уже во вторую - отказоустойчивость. Никто не мешает юзать и то и то.

blind_oracle ★★★★★
()
Ответ на: комментарий от post-factum

Вы так и не рассказали - какую задачу решает этот софт? Фильтрация запросов (ACL)? Другого применения я пока не вижу, ибо всё остальное решается уже имеющимся софтом.

blind_oracle ★★★★★
()
Ответ на: комментарий от post-factum

Таки зачем балансировать если с любым адекватным потоком справится практически любой DNS-рекурсор? Не пойму вот никак.

blind_oracle ★★★★★
()
Ответ на: комментарий от MumiyTroll

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

Великий фильтр неугодных по DNS, это же очевидно.

no-dashi ★★★★★
()
Ответ на: комментарий от blind_oracle

VRRP это протокол для резервирования конечного шлюза. И кому он будет резервировать и балансировать DNS? Машрутизатору в своем сегменте?

А по поводу роутинг демонов на серверах это вообще о чем? Машрутизатор может за сервер проанонсировать его anycast.

CNick
()
Ответ на: комментарий от blind_oracle

Вы так и не сказали: как вы собираетесь с помощью vrrp решать задачу балансировки нагрузки?

anonymous
()

Из-за нестабильности ланетовского DNS, я накостылил баш-скриптец, который проверяет доступность интернета, и если есть проблемы, переключает из ланетовского DNS на DNS от Google/OpenDNS

zhouck
()
Ответ на: комментарий от CNick

VRRP это протокол для резервирования конечного шлюза.

К шлюзу он имеет отношение постольку-поскольку. Это универсальный протокол резервирования IP-адресов. man keepalived etc. У меня два DNS-сервера сейчас крест-накрест зарезервированы через keepalived/VRRPv3, на каждом приличная нагрузка по ~12k запросов в секунду. Любой из них могу отключить для обслуживания и клиенты ничего не заметят - IP переедет ко второму за ~0.2сек.

А по поводу роутинг демонов на серверах это вообще о чем? Машрутизатор может за сервер проанонсировать его anycast.

Про то что маршрутизатор не знает жив ли сервер. Либо нужно городить какие-то хартбиты/health check и убирать анонс когда сервер дохнет, либо анонсировать с самих серверов чтобы анонс отваливался когда истечёт dead time в роутинговом протоколе.

blind_oracle ★★★★★
()
Ответ на: комментарий от post-factum

А отказоустойчивость вашего балансировщика кто будет обеспечивать? Получается его тоже резервировать надо, иначе будет SPOF. Проще резервировать сразу DNS-сервера через виртуальные IP-адреса чем дополнительно городить ещё один слой, который тоже надо резервировать.

blind_oracle ★★★★★
()
Ответ на: комментарий от anonymous

Зачем её решать в контексте DNS? Я уже выше писал, что Unbound в одно рыло покроет *любые реальные* требования по производительности.

Для справки - у Google Public DNS (8.8...) по статистике за 2012 год было около 850к запросов в секунду, это лишь чуть больше чем может всего один unbound (>600к)

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

Персонал провайдеров очень любят кодить ибо тупо админить им скучно. В 99% случаев изобретают велосипеды, на за то свои!

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.