LINUX.ORG.RU

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

 , , , ,


2

2

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

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

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

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

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

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

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

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

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

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

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

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

MumiyTroll ★★ ()

Круто. А есть бечмарки в сравнении с nginx ? :)

joy4eg ★★★★★ ()
Ответ на: комментарий от 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 у него сдох.

dimss ★★★★★ ()

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

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

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

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

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

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

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

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

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

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

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

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

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

blind_oracle ★★★★★ ()

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

anonymous ()

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

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

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

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

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

когда запрос или ответ в UDP не помещается и DNS переключается на TCP?

меня тоже интересует данный вопрос.

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

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

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

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

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

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

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

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

То есть IPv6 и DNSSec у вас в пролёте?

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

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

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

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

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

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

post-factum ★★★★★ ()

Вот поэтому люди и не пользуются провайдерским DNS :)

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

Заббиксовые графики с тобой категорически не согласны.

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

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

anonymous ()

Где TODO, Roadmap? Я бы поучаствовал.

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

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

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

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

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

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

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

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

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

Нам изначально нужно было решить несколько задач, в т. ч. балансировку и фильтрацию.

post-factum ★★★★★ ()
Ответ на: комментарий от 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 ★★★★★ ()
Ответ на: комментарий от post-factum

Зачем резервировать балансировщики через VRRP если можно через него же зарезервировать сами DNS сервера?

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

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

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