| |
| |
| 3.5, pavlinux (ok), 01:56, 05/12/2017 [^] [^^] [^^^] [ответить]
| +6 +/– |
 Да, DNS надо продвигать в массы, а то пойди яблочники до сих пор ipшники руками вбивают.
| | |
| |
| 4.8, Аноним (-), 02:48, 05/12/2017 [^] [^^] [^^^] [ответить]
| +3 +/– |
У них же этот как его, Bonjour. Я всегда подозревал что французы - утонченные извращенцы.
| | |
| |
| 5.13, pavlinux (ok), 03:51, 05/12/2017 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> У них же этот как его, Bonjour. Я всегда подозревал что французы
REQUEST("мусьё, силь ву пле муа ВэКашеку.com")
| | |
|
|
|
|
| 1.4, xm (ok), 00:10, 05/12/2017 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
 > поддерживается только NSEC
В общем, ещё пилить и пилить.
| | |
| 1.9, Sw00p aka Jerom (?), 03:13, 05/12/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
>>Например, при использовании в кластере из 5000 серверов с нагрузкой 18 тысяч DNS-запросов в секунду
это нагрузка ?
| | |
| |
| 2.10, pavlinux (ok), 03:19, 05/12/2017 [^] [^^] [^^^] [ответить]
| –3 +/– |
и не говори, лет 20 назад на Pentium 133/64Мб апач столько отрабатывал.
А эта ...бень - CoreDNS (written in Go), на один dns-запрос потребляет 73 Мб ОЗУ, :рукалицо:
| | |
| |
| |
| 4.12, pavlinux (ok), 03:40, 05/12/2017 [^] [^^] [^^^] [ответить]
| +4 +/– | |
> тот же bind в 2010 40к держать мог )
Сейчас оптимизация - это докупка РАМы, SSD иль сразу ещё одну ноду в кластер.
| | |
| 4.15, пох (?), 05:03, 05/12/2017 [^] [^^] [^^^] [ответить]
| +2 +/– |
Если ты разуешь глазки и посмотришь на графики по собственной ссылке, то они "почему-то" в основном обрываются на восьмой секунде линейного теста (~18k, но реакция уже в этот момент была нестабильной, то есть вряд ли бы он проработал с такой нагрузкой долго). А если долистаешь аж до графика latency, то увидишь прекрасное - bind сперва стал тормозить, а потом вовсе навернулся и перестал отвечать очень близко к восьмой секунде, поэтому дальше и не меряли (cpu кончылся, вах).
Надо сказать, что первым склеил ласты (и вообще с самого начала давал безобразную задержку) всеми любимый powerdns, а до 40 доехал только ripe'овый nsd, причем, судя по очень малому росту задержек и линейному - cpu, он-то мог бы и дальше продолжать.
в качестве оправдания bind'а - тест синтетический, это не kubernetes'овые ноды, которые делают реальные запросы о реальных хостах (и, надо думать, рекурсивные), это тест authoritative зоны с безумным конфигом (не 5000, а Zone-file 550000 delegated domains (includes 100000 IDN name)
- то есть актуально только для root и gtld.
| | |
| |
| 5.17, angra (ok), 06:10, 05/12/2017 [^] [^^] [^^^] [ответить]
| +3 +/– |
 > в качестве оправдания bind'а - тест синтетический
На практике все еще хуже. На большом количестве реальных зон бинду становилось плохо уже на этапе их загрузки. А nsd справляется без проблем.
| | |
| |
| 6.20, пох (?), 09:35, 05/12/2017 [^] [^^] [^^^] [ответить]
| +2 +/– |
>> в качестве оправдания bind'а - тест синтетический
> На практике все еще хуже. На большом количестве реальных зон бинду становилось
> плохо уже на этапе их загрузки. А nsd справляется без проблем.
этап загрузки - банальная линейная обработка. А у nsd она вынесена в отдельный компилирующий код, который точно так же тормозит, но на этапе еще до загрузки. При этом добавляется новая грабля - ты не можешь быть уверен, что db соотвествует текстовому конфигу и вынужден это место тщательно огораживать.
Возможно, опять же, gtld оно и надо. Владельцам кластера из 5000 нод - не знаю, не пробовал. При 1000+ реальных хостов с сотнями authoritative на каждый и еще по мелочи - ничего ужасного с bind не происходит. А перезагружать его все равно нельзя, может лечь прод.
Времена, когда еще можно было отключать dns для перезагрузки, остались в 90х годах вовсе не потому, что он долго запускается.
| | |
| |
| 7.27, xm (ok), 12:55, 05/12/2017 [^] [^^] [^^^] [ответить]
| +/– | |
> что db соотвествует текстовому конфигу
Откровенно говоря, сами файлы зон, в при нормальном раскладе, меняются нечасто. А при изменении не впадлу сделать и nsd-control reload my.domain Домены же добавляются и вовсе редко. Соответственно NSD и принял схему их предзагрузки в RAM и отдачи уже оттуда. И она, как вы верно подметили, прекрасно работает.
| | |
| 7.32, PnDx (ok), 16:59, 05/12/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
 Это у вас что-то с топологией не то. Перезагрузка одной ноды — вполне штатная операция. В особенности, с учётом "протечек" bind в некоторых сценариях.
* Если требуется непрерывная доступность операций записи, может потребоваться мультимастер. Например, тот же bind9 с бэкэндами в ldap. Или тот же pdns, воткнутый во что-нибудь m-m. При заявленном в посте выше профиле, запись вполне себе прокачает что bind что pdns. Ну а чтение всё равно слейвы обслуживают (надеюсь).
| | |
| |
| 8.37, пох (?), 19:34, 05/12/2017 [^] [^^] [^^^] [ответить] | +/– | не для кластеров, лепящих 18 s и да, оно ж еще и регистрироваться в этот dns ле... текст свёрнут, показать | | |
|
|
|
| 5.33, pavlinux (ok), 17:24, 05/12/2017 [^] [^^] [^^^] [ответить]
| +1 +/– | |
5000 нод, кластер! 5000, Карл!
18000/5000 = 3.600 запроса в сек. на одну ноду!!! :)
| | |
| |
| 6.39, пох (?), 19:40, 05/12/2017 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> 5000 нод, кластер! 5000, Карл!
еще один нифига не понял о чем речь
Кластер о котором речь - ни разу не для dns'ов, это dns специально для обслуживания того кластера.
И да, каждый элемет за каким-то хером рожает по 3.5 запроса в секунду (и то, скорее всего, только пока кое-как работает, а когда ляпнется - это ж контейнеры, они всегда ляпаются - то и 33 сгенерит)
"оно так работает".
| | |
|
|
|
| 3.14, angra (ok), 03:54, 05/12/2017 [^] [^^] [^^^] [ответить]
| +5 +/– | |
> и не говори, лет 20 назад на Pentium 133/64Мб апач столько отрабатывал.
Ох, уж эти сказки, ох, уж эти сказочники.
> А эта ...бень - CoreDNS (written in Go), на один dns-запрос потребляет 73 Мб ОЗУ
Если прочитать внимательно, то 73 метра это не на один запрос, а всего. Если предположить, что при 18k rps на каждый запрос уходило в среднем 100ms, то это около 40k памяти на запрос.
| | |
| |
| 4.23, Michael Shigorin (ok), 09:42, 05/12/2017 [^] [^^] [^^^] [ответить]
| +3 +/– |
 > Ох, уж эти сказки, ох, уж эти сказочники.
Из уважения: две запятые из трёх были лишние, берегитесь сезонной малвари псевдограмотности.
| | |
|
|
| 2.16, пох (?), 05:07, 05/12/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
>>>Например, при использовании в кластере из 5000 серверов с нагрузкой 18 тысяч DNS-запросов в секунду
> это нагрузка ?
какого размера у тебя кластер? Дай угадаю - никакого.
Да, это нагрузка.
(правда, непонятно, откуда берущаяся и что они все забыли в dns - вероятно, очередной синтетический тест)
| | |
| |
| |
| 4.21, пох (?), 09:37, 05/12/2017 [^] [^^] [^^^] [ответить]
| +/– |
>>непонятно, откуда берущаяся
> Service discovery через DNS
18/s ? Хрена себе, оно так работает?
| | |
|
| 3.25, Анонин (?), 10:42, 05/12/2017 [^] [^^] [^^^] [ответить]
| +/– |
Такая нагрузка возникает из-за того, что записи имеет TTL 0 - обычная практика для service discovery.
В итоге как только система оркестрации замечает, что контейнер не проходит health check проверку, дается команда DNS серверу исключить dns запись (тип AAA) об этом контейнере.
| | |
| |
| 4.29, пох (?), 13:32, 05/12/2017 [^] [^^] [^^^] [ответить]
| +1 +/– | |
ну то есть в кластере из 5000 nodes (заметим, не серверов, а контейнеров всего-то навсего - читай 5000 процессов не считая мелких сервисных) 18 раз в секунду какой-нибудь да оказывается дохлым? ;-)
Не то чтобы я особенно удивлен...
| | |
| |
| 5.30, Sw00p aka Jerom (?), 14:31, 05/12/2017 [^] [^^] [^^^] [ответить]
| +/– |
Учитывая особенности днс нейм серверов, кешей и ттл лучше уж сравнивать рекурсоры и количество клиентов за ними.
| | |
| |
| 6.36, пох (?), 19:29, 05/12/2017 [^] [^^] [^^^] [ответить]
| +/– |
дружище, ты разговариваешь с воображаемым другом. Уже третий коммент не в тему.
Ты явно нихрена не понял, о чем вообще речь.
| | |
| |
| 7.42, Sw00p aka Jerom (?), 00:06, 06/12/2017 [^] [^^] [^^^] [ответить]
| +/– |
речь в коментах как минимум идёт о производительностисего поделия в качестве днс нейм сервера и его производительности. Если речь идёт о кластере и хер пойми каком кластере и нафига там днс то возникает ещё куча других вопросов. Сервис дискавери на базе днс в кластере ? вы чё серьёзно ?
| | |
|
|
| 5.31, Анонин (?), 16:42, 05/12/2017 [^] [^^] [^^^] [ответить]
| +/– |
ну вообщем, да)
Но во первых у dns спрашивают не конкретный контейнер, а AAA запись сервиса в которой ip:port контейнера + адреса меняются по правилам round-robin, вероятность попасть на выпавший контейнер минимальна.
Вот если у Вас 5001 )))
| | |
|
|
| 3.26, Sw00p aka Jerom (?), 12:11, 05/12/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
Dns-у кластер не нужен.
У меня 4 ноды, и почти 1к зон. Нагрузка в среднем 500qps на ноду, в пиках до 5к qps регистрировал.
| | |
|
|
| 1.35, Синтоловая Базука (?), 19:22, 05/12/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Чем это может быть полезно для домохозяйки, использующей Acrylic DNS как кеширующий DNS и как замену hosts с поддержкой масок, под офтопик?
| | |
| |
| 2.40, пох (?), 19:42, 05/12/2017 [^] [^^] [^^^] [ответить]
| +/– |
> Чем это может быть полезно для домохозяйки, использующей Acrylic DNS как кеширующий
> DNS и как замену hosts с поддержкой масок, под офтопик?
под офтопиком прекрасный собственный dns, домохозяйке ничего другого не требуется.
Он в 2016-м году даже view научился. (правда, это, наверное, последнее что от него нужно)
| | |
| |
| 3.41, Синтоловая Базука (?), 19:49, 05/12/2017 [^] [^^] [^^^] [ответить]
| +/– |
А оно умеет сразу несколько днс опрашивать? А маски поддерживает? Про семерочку вопрос, не про серверную ось.
| | |
|
|
|
