Как понять использование процессора на DNS-сервере?

На Serverfault мы обычно сообщаем вам, что не можем помочь с планированием вашей мощности. На это есть веская причина: мы не знаем особенностей вашей среды, и ответы о том, как ее измерить, практически одинаковы. К сожалению, измерение емкости DNS - это плохо изученная тема, и большинство администраторов полагают, что высокая загрузка ЦП означает, что пора подумать о добавлении емкости. Это действительно очень плохая идея, и масштабирование до DNS DDoS неизбежно приведет к зависанию ваших сетевых устройств. (или того хуже, люди, обращающиеся в ваш юридический отдел)

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

В дополнение к отслеживанию системной статистики по умолчанию, предоставляемой вашим инструментом мониторинга SNMP (которая должна включать загрузку ЦП, пропускную способность интерфейса и счетчики пакетов, дисковый ввод-вывод и т. Д.), Я рекомендую добавить следующие OID:

• UDP-MIB
  • Ошибки очереди приема: udpInErrors (настоятельно рекомендуется красный цвет)
  • Счетчики дейтаграмм UDP: udpInDatagrams, udpOutDatagrams
  • (по желанию) Неожиданные датаграммы: udpNoPorts
• TCP-MIB
  • Счетчики сегментов TCP: tcpInSegs, tcpOutSegs

Интерпретация графиков

Эти графики можно разделить на две категории: метрики, указывающие на проблему, и метрики, которые помогают ее диагностировать.

Индикаторы

• Высокая загрузка ЦП - это плохо. Это само собой разумеющееся, но когда это случается, вам нужно искать другие метрики, чтобы сопоставить их. Если высокая загрузка ЦП соответствует всплеску использования исходящей сети (пропускной способности или количества пакетов), велика вероятность того, что вас используют в DDoS-атаке. Подробная информация о том, как интерпретировать характер атаки, содержится в следующем разделе.
• udpInErrors - ваш главный признак проблемы с мощностью. Этот счетчик увеличивается каждый раз, когда ядро ​​отбрасывает дейтаграмму UDP, поскольку приложение недостаточно быстро обрабатывает трафик. Это означает, что ваш DNS-сервис перегружен и не может справиться с входящим трафиком.
  • Большинство руководств по производительности сети сообщают вам, что увеличение размера очереди приема - неправильное решение: обычно они верны. Попробуйте найти причину, объясняющую Зачем сервер перегружен из-за просмотра других графиков или анализа журналов.
  • Если ваша компания использует почтовые серверы, использующие таблицы DNSBL, имейте в виду, что атаки на снегоступах может вызвать кратковременные всплески законный Трафик DNS, который может исчерпать пространство в ваших очередях приема. Это один из случаев, когда может быть целесообразно увеличить размер очереди приема вашего сокета (так как это известное временное состояние), но обычно лучше использовать больше оборудования для решения проблемы, чтобы снизить задержку.

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

Диагностика

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

• На загруженном рекурсивном сервере исходящая пропускная способность должна оставаться в районе вдвое больше вашего ввода. Это связано с тем, что ответы обычно намного больше, чем связанные запросы. Постоянные всплески, которые значительно превышают этот уровень, указывают на то, что ваш сервер участвует в усиление атаки. Вы, скорее всего, работаете открытый преобразователь.
• Входящие пакеты должны быть примерно равны исходящим пакетам даже на рекурсивном DNS-сервере. Хотя время от времени возникает необходимость в повторной передаче запроса из-за тайм-аута, это происходит не так часто, чтобы вызвать значительный перекос графика. Значительное увеличение количества исходящих пакетов указывает на проблему в сети или на то, что ваш кластер используется для атаки на авторитетные серверы имен. Это не обязательно означает, что вы работаете с открытым преобразователем: другие DNS-серверы могут пересылать вам запросы, которые нельзя кэшировать.
• Может показаться излишним, что я предлагаю построить графики ввода-вывода UDP + TCP в дополнение к графикам для каждого интерфейса, но эти графики не привязаны к интерфейсам и также дают вам представление о характере текущей атаки, если у вас есть достаточный опыт работы с ваше программное обеспечение сервера имен.

Примечание: udpNoPorts не действительно метрика емкости, но она полезна для выявления попыток отравления кеша. Этот счетчик увеличивается каждый раз, когда UDP-пакет обнаруживается на неожиданном порте, и их постоянная стена во время нормальной работы может указывать на то, что кто-то пытается подделать ответ. (либо это, либо один из ваших слушателей не работает: снова включите foo '!)

С DNS-серверами (на самом деле, с любым типом серверов) иногда вам нужно просматривать и анализировать запросы, которые к ним поступают, на случай, если неправильная конфигурация (возможно, в другом месте) увеличивает объем запросов (см. DNS-серверы Windows неоднократно запрашивают записи в зоне при получении ответа SERVFAIL). Посмотрите на пропорции запросов и ответов, а затем попробуйте найти компаратор для проверки нормальности.