Я пытаюсь найти максимальный QPS (запрос в секунду) виртуальной машины DNS Resolver.
У нас есть наша инфраструктура, размещенная в Azure, с виртуальной машиной (на основе привязки), выступающей в качестве распознавателя, запрашивающей собственный DNS Azure (168.63.129.16), а также локальный DNS. Я не кэширую никаких запросов в распознавателе, и каждая A-запись имеет TTL 300 секунд.
я использую днперф & resperf для запуска загрузки (только A-записи). Теперь я готовлю резолверы DNS к противостоянию DDOS-атакам со скоростью до 100 000 запросов в секунду. Я сталкиваюсь с такими проблемами, как ограничение скорости запросов между моим преобразователем и собственным преобразователем DNS Azure. В результате этого при увеличении QPS резольвер возвращает SERVFAIL ответы обратно клиенту. Однако мы не увидели ни одного SERVFAIL ответы между распознавателем и локальным DNS.
Максимальное количество запросов в секунду, которое я мог видеть при нацеливании на Azure DNS, составляет около 2100. Я много искал в Интернете, есть ли какое-либо такое ограничение скорости, сделанное Azure, но не смог найти ничего связанного. Почему-то я подозреваю, что виртуальная машина распознавателя попала в узкое место, поскольку 2K QPS очень мало для масштаба инфраструктуры Azure.
Несколько вещей (изменения sysctl ядра), которые я изменил в конце, что немного улучшилось, но не сильно.
Привязать изменения конфигурации ::
рекурсивные клиенты от 1000 -> 30000
Буфер UDP до более высокого значения, чем 26214400 чтобы остановить сбои буфера::
net.core.rmem_max
net.core.rmem_default
Диапазон локальных портов от 32768 61000 к 1024 61000 иметь максимум
порты доступные для DNS::
net.ipv4.ip_local_port_range
разные изменения::
txqueuelen от 1000 -> 20000
uпределы изменено на 100000
net.netfilter.nf_conntrack_max изменено на гораздо более высокое значение
В дополнение к вышесказанному я увеличил размер виртуальной машины с (1 ядро, 2 ГБ ОЗУ) -> (4 ядра, 8 ГБ ОЗУ).После увеличения пропали ошибки пакетов (проверял netstat -s) но не улучшилось SERVFAIL ошибки.
я включил tcpdump чтобы проверить образец SERVFAIL ошибки. В случае сбоев преобразователь пытается отправить запрос в Azure DNS 5 раз (каждый раз через 1 секунду), но ничего не получает от Azure DNS и, следовательно, отправляет SERVFAIL ответ обратно клиенту. Загрузив pcap файл на Wireshark, я вижу, что Azure DNS отправляет ответ обратно на резольвер но резольвер уже отправил SERVFAIL ответ клиенту.
Почему соединение закрывается до получения ответа? Текущий net.netfilter.nf_conntrack_udp_timeout остается нетронутым 30 секунды, но резольвер посылает SERVFAIL через 5 секунд клиенту.
Ниже приведены tcpdump журналы во время ServFail::
чтение из файла dns4.pcap, тип ссылки EN10MB (Ethernet)
10.0.0.10.57710 > 10.0.0.11.домен: [сумма udp в порядке] 1612+ A? SZxvvdyDYy.ns.westeurope.xx.yy.zz.net. (66)
10.0.0.11.44513 > 168.63.129.16.домен: [плохая udp cksum 0xbecd -> 0x8cfd!] 52637+% [1au] A? SZxvvdyDYy.ns.westeurope.xx.yy.zz.net. ар: . OPT UDPsize=4096 DO (77)
10.0.0.11.32378 > 168.63.129.16.домен: [плохая udp cksum 0xbecd -> 0x3950!] 20672+% [1au] A? SZxvvdyDYy.ns.westeurope.xx.yy.zz.net. ар: . OPT UDPsize=512 DO (77)
10.0.0.11.59973 > 168.63.129.16.домен: [плохой udp cksum 0xbecd -> 0xe2e5!] 15199+% [1au] A? SZxvvdyDYy.ns.westeurope.xx.yy.zz.net. ар: . OPT UDPsize=512 DO (77)
10.0.0.11.29976 > 168.63.129.16.домен: [плохая udp cksum 0xbec2 -> 0x051b!] 47104+ A? SZxvvdyDYy.ns.westeurope.xx.yy.zz.net. (66)
10.0.0.11.43442 > 168.63.129.16.домен: [плохая udp cksum 0xbec2 -> 0xe791!] 41199+ A? SZxvvdyDYy.ns.westeurope.xx.yy.zz.net. (66)
10.0.0.11.домен > 10.0.0.10.57710: [плохая udp cksum 0x2a89 -> 0x5e30!] 1612 ServFail q: A? SZxvvdyDYy.ns.westeurope.xx.yy.zz.net. 0/0/0 (66)
Как вы можете видеть из нижней строки ServFail отправляется после 5 попыток.
Если вы зашли так далеко, я должен поблагодарить вас за чтение этого длинного вопроса. Я знаю, что это слишком много вопросов, но я признателен, если у вас есть какие-то подсказки для меня, поскольку я не могу понять, в чем узкое место.
Первоначально опубликовано на суперпользователе здесь