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

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

Наркоманы

разве что ИТшники. Остальные будут жрать что дают.

NDA :).

Бро, ты на Ланет работаешь?

Вопросы не сильно по теме можно слать в личку.

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

К делу не относится, и решаем мы не только вопросы балансировки.

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

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

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

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

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

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

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

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

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

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

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

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

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

Не резолвлятся домены. Скайп продолжает работу, а браузинг не работает. После смены ДНС всё нормализуется. Хотя, конечно, может просто ґлюк роутера.

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

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

Было бы, конечно, хорошо получить детали в личку.

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

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

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

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

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

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

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

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

На беглый взгляд годно. Оно сокет-активацию имени systemd поддерживает?

Нет, но идея хорошая. Возьмём на заметку.

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

В дереве исходников есть спеки для rpm, ими и опакечиваем. Можно будет попробовать через obs собрать бинарники.

как? целых 11kpps на 30% проца? я прям со стула чуть не упал

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

может на php? но нет, php работает быстрее... может на javascript? но он тоже шустрее...

неужели оно написано на встроенном языке системы 1С ?!!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На CRIU смотрели?

Конечно, но насколько оно юзабельно с тем ядром, которое в CentOS 7?

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

да это прям прикладной фашизм. тем более, что у большинства доменов типа гугла и прочих самых популярных монстров ответ в UDP не помещается.

я тоже не поняла особого смысла. у меня даже bind на виртуальном сервере в «два ядра два гига» жевал не менее 5K уникальных запросов в секунду. включая tcp. но это ваще был дохляцкий сервер с фиговой сеткой в жопе мира. unbound на порядки шустрее. а если ещё на нормальном сервере...

ваще, практика показала, что 11 миллионов юзеров создают среднюю нагрузку около 10000 запросов в секунду. если они не занимаются амплификацией или прочим злостным вредительством. балансировщик нагрузки нужен разве что в случае какого-то совершенно дикого наплыва юзеров или активных DNS-атак.

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

11 миллионов юзеров создают среднюю нагрузку около 10000 запросов в секунду

Интересно, конечно, откуда такое число взялось. Наша практика даёт около 20k в ЧНН с количеством абонов где-то в 100 раз меньшим.

мир большой. я дорабатывала и поддерживала софтину DNS-фильтрации для компании, которая её предоставляет в РФ и по всему миру.

на самом деле, поток довольно разнородный. абоненты тоже разнородны. причём на сервера лезут не только зарегистрированные юзеры, но и все, кто ни попадя (сервер их не отшивает, просто обслуживает по дефолту без фильтрации). среди запросов можно выделить кучу заспуфленных липовых запросов, явных атак. некоторые юзеры могут запускать пауков, которые фигачат по тыще запросов в секунду. но в среднем обычный рядовой юзер создаёт не так много нагрузки на DNS, потому что есть кеширование браузерами и прочие опосредованные кэши. прикинь, с какой скоростью юзер должен шастать по сети, чтобы создавать (в среднем!) трафик пусть даже 1 запрос в пять секунд, учитывая то, что ночью юзер спит, и в среднем он шастает по одним и тем же сайтам, которые у него закешированы в браузере чуть ли не навечно.

у провайдеров в DNS часто обнаруживается бардак, который плодится от «вирусных» запросов, создаваемых троянами (такое часто заметно в виндузяцких рассадниках). причём трафик иногда дополнительно умножается внутренними роутерами, которые неверно настроены (они мультиплицируют запросы). кроме того, по DNS протоколу иногда ходят непонятные пакеты, которые, как я думаю, содержат внутри протокол другого уровня и не являются DNS-запросами. это какой-то хитрожопый хак с обходом блокировки протоколов, видимо. есть также масса оборванных, неверно сформированных пакетов, которые ядро отсекает на подлёте. я думаю, их также генерят либо трояны, либо неверно настроенные железяки.

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

Ну, у нас всё-таки не всё так плохо ;). Атаки вычисляются проактивным мониторингом, дополнительно есть возможность посмотреть, чё происходит, по конкретным балансерам и абонам. Открытые резолверы у абонов по умолчанию закрыты для мира. ANY-запросы тоже закрыты. И т.д., и т.п.

Флуд, кстати, хорошо видно на графиках. Когда он начинается, есть ступенька. Так что или все флудят потихоньку и не выделяются, или всё, что есть, — в основном нормальные запросы.

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

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

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

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

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

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

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

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

разве что ИТшники. Остальные будут жрать что дают.

Не всегда есть выбор и у IT.

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

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