В далеком 2007 году, когда Ukrnames был еще маленьким и делал первые шаги, большую часть работы выполняли программисты. Они и разрабатывали систему управления доменами, и тестировали ее, и администрировали сервера, где все это добро работало.
А там где домены, там DNS. А какой самый простой способ сделать DNS-сервер? Поставить вездесущий BIND. Да BIND непростой, а с DLZ патчем, чтобы с MySQL дружил.
Шли годы, система работала, мощности серверов росли. А как водится, пока работает – не трогай. Так бы это все и продолжалось, если бы нагрузка не начала упираться в очередной 8-ми ядерный сервер.
В этот момент пришлось принять волевое решение и построить новую систему DNS-серверов, вместо того чтобы в очередной раз апгрейдить железо для ненасытного BIND+DLZ.
И тут закончилась сказка, и начались суровые будни администратора.
Необходимо обслуживать услугу, которую бесплатно предоставляет Ukrnames для доменов, а именно «Управляемый DNS».
На данный момент эта услуга используется для более ста тысяч доменов. Домены разнообразные, с разной посещаемостью, соответственно нагрузка не зависит от количества доменов.
Услуга обслуживается 3-мя DNS-серверами, с конфигурацией Xeon X3430, 8Gb DDR3, 2x500Gb SATA RAID1. На серверах используется BIND+DLZ patch в связке с MySQL. БД работает как Slave активного на данный момент сервера-хранилища доменных зон.
Из существующего многообразия были выбраны PowerDNS с MySQL и NSD (работа на файлах).
Было решено сделать соревнование для старичка BIND и этих двух самозванцев.
На первый взгляд самый логичный выбор это взять DNS сервер, который из коробки умеет работать с БД MySQL и привязать его к существующей базе.
Практически же оказалось, что с существующей БД и с тем, что требует PowerDNS обнаружилось несколько довольно неприятных различий.
В итоге для реализации, нужно было либо менять структуру БД, а это потянет за собой изменения в коде всей системы. Либо строить костыли, а именно процедуры или view.
Для соревнования был выбран второй вариант, т.к. основную систему трогать было нельзя.
Судя по Wikipedia, NSD успешно работает на 3-х корневых серверах.
Особенностью NSD является то, что он компилирует все зоны в свой внутренний формат БД, после чего загружает его целиком в ОЗУ.
На сайте разработчика есть инструмент для расчета потребления ОЗУ. В нашем случае получилось приблизительно 367 Mb, что было более чем приемлемым результатом.
Была написана утилита, которая в 50 потоков отправляла запросы к DNS-серверу. Домены выбирались случайно из существующей БД, тип записей также случайно менялся.
Для PowerDNS была написана view, которая выдавала данные в нужном формате. В процессе тестирования она была 3 раза переписана для оптимизации.
Для NSD была написана, на моем любимом Google Go, утилита-конвертер, которая делала выборку по всей БД и собирала базу во внутренний формат NSD.
В обоих случаях использовались логические фильтры, чтобы преобразовывать все несоответствия с RFC в удобоваримый вид.
Также была произведена чистка базы от многолетнего мусора. Без идиоматических выражений не обошлось. Никогда бы не подумал, что ТАКОЕ можно записывать в DNS. Там были и URL в CNAME записях, и email-ы с паролями в MX. Видимо изначально программисты тоже верили в пользователей, и не делали нормальных фильтров для записей.
По очереди был проведен тест для каждого участника. Длительность теста 10 минут. Раз в минуту сохраняется среднее время ответа за прошлую минуту и текущая нагрузка на процессор в процентах. Тестирование проводили на машине с такой же конфигурацией, как и боевые DNS-сервера.
PowerDNS был настроен на самостоятельную генерацию SOA, чтобы снизить количество запросов к MySQL, также был включен кеш записей на 1 минуту.
NSD работал в 4 потока, в стандартной конфигурации.
BIND+DLZ показал себя как обычно, огромное время ответа, космические нагрузки.
PowerDNS показал хорошую производительность, также как и BIND давая приблизительно 50 на 50 нагрузки основным демоном и MySQL. И он был бы лидером, если бы в тесте не было NSD…
Время отклика:
Нагрузка на ЦП:
Тест с NSD повторялся 3-жды, т.к. было стойкое ощущение, что что-то не так, и такого не может быть.
Собственно итог напрашивается сам собой.
Логика в MySQL – слабое место. Подобные данные лучше обрабатывать уже на получателе и делать как можно меньше запросов.
Для DNS вполне нормально, если данные обновляются не чаще получаса. Утилита-конвертер отрабатывает за 7 секунд и позволяет обеспечить ежеминутное обновление.
На серверах у нас теперь работает NSD и мы не скоро задумаемся об апгрейде железа, разве что для замены дисков на более свежие.
А там где домены, там DNS. А какой самый простой способ сделать DNS-сервер? Поставить вездесущий BIND. Да BIND непростой, а с DLZ патчем, чтобы с MySQL дружил.
Шли годы, система работала, мощности серверов росли. А как водится, пока работает – не трогай. Так бы это все и продолжалось, если бы нагрузка не начала упираться в очередной 8-ми ядерный сервер.
В этот момент пришлось принять волевое решение и построить новую систему DNS-серверов, вместо того чтобы в очередной раз апгрейдить железо для ненасытного BIND+DLZ.
И тут закончилась сказка, и начались суровые будни администратора.
Что мы имеем?
Необходимо обслуживать услугу, которую бесплатно предоставляет Ukrnames для доменов, а именно «Управляемый DNS».
На данный момент эта услуга используется для более ста тысяч доменов. Домены разнообразные, с разной посещаемостью, соответственно нагрузка не зависит от количества доменов.
Услуга обслуживается 3-мя DNS-серверами, с конфигурацией Xeon X3430, 8Gb DDR3, 2x500Gb SATA RAID1. На серверах используется BIND+DLZ patch в связке с MySQL. БД работает как Slave активного на данный момент сервера-хранилища доменных зон.
Ищем проблемы на свою… голову
- Высокая нагрузка, используется 100% серверных мощностей. Половина приходится на MySQL, вторая половина на BIND.
- DLZ патч уже морально устарел и не развивается. Бесконечно переделывать патч под новые версии BIND не лучший подход.
- При использовании других решений возникает проблема старой БД, которая наполнялась изначально без особых проверок. Много мусора, много записей, которые не соответствуют RFC. Их банально не примет ни один вменяемый DNS.
Расчехляем бубен
Из существующего многообразия были выбраны PowerDNS с MySQL и NSD (работа на файлах).
Было решено сделать соревнование для старичка BIND и этих двух самозванцев.
Смотрим PowerDNS
На первый взгляд самый логичный выбор это взять DNS сервер, который из коробки умеет работать с БД MySQL и привязать его к существующей базе.
Практически же оказалось, что с существующей БД и с тем, что требует PowerDNS обнаружилось несколько довольно неприятных различий.
В итоге для реализации, нужно было либо менять структуру БД, а это потянет за собой изменения в коде всей системы. Либо строить костыли, а именно процедуры или view.
Для соревнования был выбран второй вариант, т.к. основную систему трогать было нельзя.
Щупаем NSD
Судя по Wikipedia, NSD успешно работает на 3-х корневых серверах.
Особенностью NSD является то, что он компилирует все зоны в свой внутренний формат БД, после чего загружает его целиком в ОЗУ.
На сайте разработчика есть инструмент для расчета потребления ОЗУ. В нашем случае получилось приблизительно 367 Mb, что было более чем приемлемым результатом.
Заряжаем бубен
Была написана утилита, которая в 50 потоков отправляла запросы к DNS-серверу. Домены выбирались случайно из существующей БД, тип записей также случайно менялся.
Для PowerDNS была написана view, которая выдавала данные в нужном формате. В процессе тестирования она была 3 раза переписана для оптимизации.
Для NSD была написана, на моем любимом Google Go, утилита-конвертер, которая делала выборку по всей БД и собирала базу во внутренний формат NSD.
В обоих случаях использовались логические фильтры, чтобы преобразовывать все несоответствия с RFC в удобоваримый вид.
Также была произведена чистка базы от многолетнего мусора. Без идиоматических выражений не обошлось. Никогда бы не подумал, что ТАКОЕ можно записывать в DNS. Там были и URL в CNAME записях, и email-ы с паролями в MX. Видимо изначально программисты тоже верили в пользователей, и не делали нормальных фильтров для записей.
Танцуем
По очереди был проведен тест для каждого участника. Длительность теста 10 минут. Раз в минуту сохраняется среднее время ответа за прошлую минуту и текущая нагрузка на процессор в процентах. Тестирование проводили на машине с такой же конфигурацией, как и боевые DNS-сервера.
PowerDNS был настроен на самостоятельную генерацию SOA, чтобы снизить количество запросов к MySQL, также был включен кеш записей на 1 минуту.
NSD работал в 4 потока, в стандартной конфигурации.
Результаты
BIND+DLZ показал себя как обычно, огромное время ответа, космические нагрузки.
PowerDNS показал хорошую производительность, также как и BIND давая приблизительно 50 на 50 нагрузки основным демоном и MySQL. И он был бы лидером, если бы в тесте не было NSD…
Время отклика:
Нагрузка на ЦП:
Тест с NSD повторялся 3-жды, т.к. было стойкое ощущение, что что-то не так, и такого не может быть.
Итог
Собственно итог напрашивается сам собой.
Логика в MySQL – слабое место. Подобные данные лучше обрабатывать уже на получателе и делать как можно меньше запросов.
Для DNS вполне нормально, если данные обновляются не чаще получаса. Утилита-конвертер отрабатывает за 7 секунд и позволяет обеспечить ежеминутное обновление.
На серверах у нас теперь работает NSD и мы не скоро задумаемся об апгрейде железа, разве что для замены дисков на более свежие.
