LINUX.ORG.RU

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

 , , , ,


2

2

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

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

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

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

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

★★★★★

Проверено: Shaman007 ()
Последнее исправление: Shaman007 (всего исправлений: 1)
Ответ на: комментарий от post-factum

Хорошо, а какая нагрузка на балансёр при 11к запросов в секунду (я так понял в пик у вас такая цифра)? По графику не совсем ясно - 30% это от какого количества ядер (и каких?)?

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

Коллега поставил вопрос ребром: так как вы провайдер и раздаёте счастье клиентам по DHCP, то почему бы не поделить весь пулл адресов, скажем, пополам, и раздавать по DHCP разным половинам разные пары DNS-серверов? Когда нагрузка на существующие DNS станет невыносимо большой (например, никогда, в Украине столько людей нет), можно будет ещё раз поделить пополам и тогда уж точно хватит.

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

Я вообще клиентам выдаю два IP-адреса DNSов в рандомном порядке на каждый DHCP-запрос. Получается идеальное разделение нагрузки :)

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

решаем мы не только вопросы балансировки

Странные вы, демон назвали «dnsbalancer» и в теме «демон балансировки UDP-трафика рекурсивного DNS», а теперь оказывается, что балансировка — вообще побочная функция.

А между тем, было бы оно чем-нить вроде «dnsproxy» или «dnsfilter» — «демон фильтрации и сбора статистики UDP-трафика рекурсивного DNS с функцией балансировки», так глядишь, и меньше негатива в отзывах получили бы.

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

Если ты не заметил, меня отзывы здесь вообще не волнуют. Никакие. Если есть что сказать конструктивного — в личку или на гитхаб, лучше пулл-реквестами.

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

Если ты не заметил, меня отзывы здесь вообще не волнуют. Никакие.

А зачем Вы тогда принесли это на мой уютный LOR?

Кстати, Вы лукавите. Если бы отзывы Вас вообще не волновали бы, то вы не пытались бы донести пользу от Вашей поделки до здешней аудитории. А так получается, что Вас не волнуют отрицательные отзывы. Это удобно.

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

то вы не пытались бы донести пользу от Вашей поделки до здешней аудитории

Вот. Про эту самую пользу я и пытаюсь узнать - может оно и мне надо? Но автор никак мне не может объяснить зачем оно в реальной жизни :)

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

Про эту самую пользу я и пытаюсь узнать - может оно и мне надо? Но автор никак мне не может объяснить зачем оно в реальной жизни

Автор слишком обидчив, несмотря на его заявления о том, что здешние отзывы его не волнуют, так что скорее всего он Вам адекватно не ответит. Я попробую...

Дело в том, что некоторые (тоталитарные) режимы пытаются ввести цензуру в интернете, а сей демон, несмотря на его странное название, позволяет фильтровать/обрабатывать запросы на основе неких ACL, что может быть одним из способов достижения цели, в частности для случая с SSL/TLS.

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

Кстати, опущенцы в Северодонецке требовали от Ланета блокировать украинские сайты.

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

Развивай свою мысль дальше на своём уютном ЛОРе, мне жутко интересно, к чему ты придёшь :).

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

Дело в том, что некоторые (тоталитарные) режимы пытаются ввести цензуру в интернете

Это да, но любой DNS-сервер позволяет сделать то же самое без таких костылей. У нас, например, HTTPS-сайты блокируются Unbound-ом - просто заворачиваются в 127.0.0.1 при резолвинге, их там сейчас в списке около 2 тысяч плюс-минус. А не заблокируешь - придёт РосКомПозор, запустит чудо-программулину, увидит что открыто и впилит штраф или ещё что похуже.

В общем, без чудо программулины всё прекрасно делается.

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

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

решаем мы не только вопросы балансировки

Возможно, об этом стоит подробно рассказать в тексте новости.

Впрочем, по «меня отзывы здесь вообще не волнуют. Никакие» я вангую, что разговаривать на эту тему бесполезно чуть менее, чем бесполезен сам dnsbalancer. Удачи в построении деревенских LANов.

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

Новость как бы не о том, как *мы* его используем, если ты не заметил. Хочешь поговорить предметно — милости просим в личку.

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

По графику не совсем ясно - 30% это от какого количества ядер (и каких?)?

да пусть хоть и одного ядра

исходя из того, как я общался с процом и памятью, вот моя прикидка: нормально написанный udp балансер под линуксом под правильной сетевой картой должен балансить 40Гбит/с при менее чем 100% загрузке одного ядра или 50% двух ядер

если тут пакет 100 байт, то значит 400Mpps при 100% и 120_М_pps при 30% одного ядра

правда остальные 3 ядра (или сколько там ядер на одной с ядром паре каналов ddr3) будут весьма ограничены в доступе к памяти, т.е. че-то типа майнинга биткойнов смогут, а полноценно работать — нет

disclaimer: под сетевые карты ничего не писал, только работа с памятью; предполагаю: если уж сетевая карта дает 40Гбит/с наружу, то и с оперативкой она обменивается не менее, чем с той же скоростью (естественно, не отдельными пакетами, а целыми их пачками через dma)

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

исходя из того, как я общался с процом и памятью, вот моя прикидка: нормально написанный udp балансер под линуксом под правильной сетевой картой должен балансить 40Гбит/с при менее чем 100% загрузке одного ядра или 50% двух ядер

Всё сильно зависит от сетевого стека (особенно от карт и их дров - как они обрабатывают прерывания так далее) - на деле твои цифры очень далеки от реальности. Реальный предел где-то в районе нескольких mpps.

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

глядя на слова «на виртуальной машине» я задумался о том, что именно это может тебя тормозить, но решил дождаться более полной информации от тебя

а зачем, собственно, виртуальная машина, если действительно она тормозит процесс более чем в 1000 раз?

virtio как работает? попакетно или же умеет передавать сразу, скажем, 1МБ из 10К пакетов?

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

Всё сильно зависит от сетевого стека (особенно от карт и их дров - как они обрабатывают прерывания так далее) - на деле твои цифры очень далеки от реальности. Реальный предел где-то в районе нескольких mpps.

от карты понятно зависит — pcie v_какая? и x_сколько?

а на самом деле, предположу, что 400Мpps никому не требуются

если же требуются, то мне это даже и интересно

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

Всё сильно зависит от сетевого стека

тут надо обходиться вообще без него

получаем кусок сырой памяти из сетевой карты, пробегаем по нему, выплевываем его обратно в карту (в эту же или в другую) (емнип, в линуксе для этого сисколл есть)

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

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

Кстати, когда это дело было на lxc, а не kvm, загрузка CPU была в несколько раз меньшей.

а зачем, собственно, виртуальная машина, если действительно она тормозит процесс более чем в 1000 раз?

Потому что удобно деплоить и админить, и ресурсов хватает.

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

Кстати, когда это дело было на lxc, а не kvm, загрузка CPU была в несколько раз меньшей.

не исключено, что повысив время отклика до разумных значений (ну даже 10мс) можно существенно уменьшить нагрузку

Потому что удобно деплоить и админить, и ресурсов хватает.

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

но сходу не скажу, будет ли в неймспейсах все что нужно от eth#

bottom line: даже и здесь совершенно необходимо было (бы) обсудить это с админами, которые в курсе

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

повысив время отклика

Забавно, но нам не интересно.

есть неймспейсы

Live migration нужно, поэтому мы не используем контейнеры.

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

А теперь всё то же самое, только для KVM с virtio, т.к. графики оттуда.

если все настроено правильно, то моя прикидка на 1 ядро (а точнее, на 2 канала ддр3): 400Mpps/количество_копирований_памяти_от_интерфейса_до_проги

что касается времени отклика: у проги менее 1 мс, а че там с virtio — не в курсе

еще может ты какие тяжелые хэши считаешь для балансинга? или ACL-ки у тебя такие большие, что в кэши проца не влезают?

update: это все при условии, что копирования делаются по-человечески, т.е. не засирая кэши проца; как там на самом деле в kvm — не знаю

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

ACL маленькие, а хеши считаю, да. Раньше считал CRC64, сейчас там xxHash, по загрузке CPU, кстати, между ними разницы особой нет.

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

Сейчас, кстати, при 15 kpps нагрузка около 9%. Наверное, я ещё и неудачный момент для скриншота выбрал :).

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

если хэш считается с целью «на какой сервер кинуть пакет», то попробуй экспериментально супершустрый хэш типа количество_единиц_в_битовой_строке % количество_серверов

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

Нет, там домены коллизий на хешах для типа убыстрения lookup'а при однозначной идентификации пакета. xxHash сам по себе достаточно быстрый.

Если интересно, могу при случае на виртуалке gprof'ом отпрофилировать.

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

Не подскажу - у меня ubuntu+lxc, так что самому интересно :)

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

на деле твои цифры очень далеки от реальности.

я в курсе, и это потому, что

Всё сильно зависит от сетевого стека

мне интересно, насколько сетевой стек линукса неэффективен (для этой задачи), поэтому повторю просьбу: посмотри что за карты выдают «в районе нескольких mpps»

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

поэтому повторю просьбу: посмотри что за карты выдают «в районе нескольких mpps»

Где посмотреть? В хрустальном шаре? Да практически любые современные 10/40гбитки с очередями по ядрам.

Тот же Intel XL710 выдает ~20mpps на 10Гбит на пакетах по 64 байта или ~40mpps на 40Гбит на пакетах по 128 байт.

Но это именно карта - когда оно пройдет через проц\память\обратно в карту (если роутинг), то упадет как раз до <<10mpps.

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

Где посмотреть? В хрустальном шаре?

ок, пока что меня вполне устроит точность хрустального шара; пойду осмыслять твои цифры

www_linux_org_ru ★★★★★
()
Последнее исправление: www_linux_org_ru (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.