Правильная настройка кэша резолвера NGINX

Понимание работы резолвера NGINX и кэша DNS

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

Директива resolver содержит один или несколько адресов резолверов или поддерживаемых идентификаторов резолверов. Если порт не указан, NGINX использует порт 53; при наличии нескольких указанных серверов запросы обрабатываются по алгоритму Round Robin, как указано в документации. Для надёжной конфигурации начальной загрузки часто целесообразно использовать фиксированные IP-адреса, поскольку их разрешение не зависит от DNS.

По умолчанию NGINX учитывает IPv4- и IPv6-адреса, связанные с именем. Это подходит в том случае, если сеть надежно передает оба семейства протоколов до бэкенда. Такие параметры, как ipv4=off или ipv6=off целенаправленно исключают определённый семейство, но не являются общей оптимизацией кэша. Необходимость их применения определяется доступностью конкретного бэкенда, а не просто наличием записи AAAA.

Резолвер не является ни полноценным рекурсивным DNS-сервером, ни средством автоматического переноса всех настроек из /etc/resolv.conf. NGINX использует явно указанные серверы имен. Для внутренних зон и производственных имен бэкенда следует использовать надежные и должным образом защищенные резолверы, расположенные в собственной сети. Таким образом, ответственность за частные имена и защита от поддельных DNS-ответов остаются в рамках контролируемой инфраструктуры.

Кэш DNS — это не кэш HTTP

Кэш DNS-ответов резолвера хранит сопоставления между именами и DNS-ответами, например, адресами A или AAAA. Его цель — обеспечить возможность повторного доступа к бэкенду без необходимости повторного преобразования каждого имени. Поэтому, если IP-адрес бэкенда изменяется, актуальным является срок действия DNS-ответа, а не содержание ранее доставленного HTTP-ответа.

Отдельно от этого сохраняется proxy_cache HTTP-ответы исходного сервера. В зависимости от конфигурации ключ может включать, например, URI, хост или заголовок; при совпадении клиенту возвращается уже сохраненный ответ. Проблемы в данном случае проявляются в виде устаревших страниц, неверных вариантов или неожиданных попаданий в кэш. Эта функция не определяет, какой IP-адрес NGINX будет использовать при установке нового соединения с бэкендом.

Кэш открытых файлов представляет собой третий уровень: он хранит информацию о файлах и открытые дескрипторы для доступа к локальной файловой системе, но не содержит ни ответов DNS, ни HTTP-контента. Те, кто хочет более подробно изучить это разграничение в контексте статической доставки, найдут соответствующую информацию в статье о Настройка кэша открытых файлов NGINX. Однако он не предоставляет оснований для выбора значения TTL резолвера.

Поэтому очистка, сброс или синхронизация HTTP-кеша не ускоряют обновление DNS. И наоборот, новое разрешение DNS не исправляет некорректно кэшированный HTTP-ответ. В случае обратного прокси-сервера ограничение Кэш DNS Кроме того, он опирается на имена и адреса: он не проверяет работоспособность приложения и не заменяет балансировку нагрузки, повторные попытки или правильное планирование таймаутов для upstream.

Когда NGINX должен повторно выполнять преобразование имен

Имя хоста может быть известно NGINX уже на этапе считывания конфигурации. Иная ситуация складывается в случае переменного адреса назначения, например proxy_pass http://$backend;. NGINX сначала ищет полученное имя в заданных группах Upstream. Если там подходящего имени не найдено, во время выполнения ему потребуется настроенный резолвер для определения адреса назначения.

Сообщение no resolver defined В данном контексте это не указывает на отсутствие HTTP-кеша. Это означает, что NGINX не знает DNS-сервера, необходимого для разрешения доменного имени во время выполнения. resolver может использоваться в контексте http, server или location находится. Одна из ключевых записей в httpБлок - подходит в том случае, если несколько виртуальных хостов используют один и тот же резолвер; более узкая область действия уместна только при действительно отличающихся требованиях.

Не следует путать это давно доступное разрешение времени выполнения с динамической актуализацией классической группы «upstream». Настройка резолвера непосредственно в upstream-блок, а также server hostname resolve Согласно документации, в NGINX с открытым исходным кодом эти функции доступны начиная с версии 1.27.3. Не следует считать, что более старые версии с открытым исходным кодом автоматически поддерживают этот шаблон; исторически соответствующие функции частично были доступны только в NGINX Plus.

Перед планированием динамических входящих потоков необходимо проверить установленную версию и информацию о сборке. Следующая команда выводит версию NGINX, версию компилятора и параметры configure, использованные при сборке.

nginx -V

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

Назначить TTL и valid вручную

Кэш резолвера NGINX, если не указано иное, ориентируется на DNS-TTL в ответе запрашиваемого сервера имен. Если оператор авторитетного DNS изменяет IP-адрес бэкенда, NGINX продолжает использовать прежний ответ до истечения его TTL. Только когда впоследствии вновь потребуется разрешение имени, NGINX повторно запрашивает резолвер. Таким образом, срок действия можно контролировать там, где ведется учет данных об именах.

Параметр valid полностью заменяет этот TTL на заданный период времени. Таким образом, он не только ограничивает максимальное значение TTL в DNS, но и не определяет регулярное обновление в дополнение к TTL. Значение valid=30s может сократить длительный TTL DNS, но также и продлить намеренно короткий TTL. Это должно соответствовать плану переноса и развертывания бэкенда.

Если зона надежно обслуживается, то конфигурация без переопределения является обоснованной отправной точкой. Адрес, приведённый в примере, выбран в соответствии с сетями, указанными в документации, и не должен использоваться в качестве рабочего резолвера. Вместо этого введите адрес доступного и надёжного DNS-резолвера из вашей собственной сети.

resolver 192.0.2.53;
resolver_timeout 5s;

Переопределение может быть целесообразно, если на значение TTL DNS невозможно повлиять и существует задокументированное рабочее правило. В этом случае отклонение явно показывает, как долго NGINX хранит ответы. Это не является общей оптимизацией производительности: более короткие временные интервалы могут вызвать большее количество DNS-запросов, а более длительные — задержать переход на новые адреса бэкенда.

resolver 192.0.2.53 valid=30s;
resolver_timeout 5s;

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

Правильное разрешение переменных в proxy_pass

Содержит proxy_pass если это переменная, NGINX должен обработать полученное имя хоста во время выполнения. Сначала NGINX ищет подходящую группу Upstream; если таковой не найдено, для обработки имени требуется настроенный резолвер. Если его нет, выводится типичное сообщение no resolver defined Это не указывает на HTTP-кеш, а свидетельствует об отсутствии настроек DNS для данного пути выполнения.

В приведенном ниже примере намеренно продемонстрировано разрешение во время выполнения. Резолвер находится в http-контекст и, следовательно, применяется к нескольким виртуальным хостам, если его не переопределяет более конкретная настройка. Используемый адрес документации необходимо заменить на адрес, определяемый внутренним резолвером соответствующей среды.

http {
    resolver 192.0.2.53;
    resolver_timeout 5s;

    server {
        listen 80;

        location / {
            set $backend api.internal.example;
            proxy_pass http://$backend;
        }
    }
}

Директива resolver_timeout не влияет на продолжительность кэширования. Этот параметр ограничивает время, в течение которого NGINX ожидает разрешения имени; стандартное значение, указанное в документации, составляет 30 секунд. Выбор этого параметра относится к остальным параметрам, связанным с допустимым количеством ошибок: слишком высокое значение может затянуть обработку неудачного запроса до получения ответа об ошибке, а слишком низкое значение приводит к излишним ошибкам разрешения при временном снижении производительности внутренних резолверов.

Для отдельного, четко очерченного местоположения резолвер может в location-блок. Если нескольким локациям или серверам требуется одно и то же разрешение, необходимо использовать общий диапазон в server- или http-Блок требует меньшего объема технического обслуживания. NGINX допускает использование этой директивы во всех трёх контекстах; область действия должна отражать фактическую структуру работы, а не просто устранять одно конкретное сообщение об ошибке на короткий срок.

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

Настройка динамических источников с помощью resolve

Для заданной группы бэкендов динамический апстрим может быть более понятным, чем переменная целевая величина в каждом блоке Location. Данный шаблон отделяет определение членов бэкенда от маршрутизации: proxy_pass указывает на группу, тогда как имя хоста в верхнем уровне может обновляться через DNS. Это особенно удобно, когда несколько маршрутов ведут к одному и тому же приложению.

Параметр resolve для одного server-Эта настройка исторически существует начиная с версии NGINX 1.5.12. Однако, согласно документации, в открытой версии NGINX она доступна только начиная с версии 1.27.3; ранее эта функция была доступна только в коммерческой версии. Также настройка резолвера непосредственно в upstream-Блок описан в документации по Open Source, начиная с версии 1.27.3.

Die Зона общей памяти При этом речь не идет ни о таймауте кэша, ни о пути данных DNS. Она предоставляет общее хранилище внутри NGINX, необходимое для динамически изменяющихся конфигураций upstream. Если при разрешении DNS NGINX обнаруживает другие адреса для данного имени, группу upstream можно настроить на основе этого внутренне управляемого состояния без перезапуска.

http {
    resolver 192.0.2.53;
    resolver_timeout 5s;

    upstream application_pool {
        zone application_pool 64k;
        server app.internal.example resolve;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://application_pool;
        }
    }
}

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

Служба, доступ к которой возможен исключительно через IPv4, может служить основанием для целенаправленного ограничения: resolver 192.0.2.53 ipv6=off; блокирует запросы AAAA и выбор IPv6-адреса для данного контекста резолвера. Однако это решение зависит от архитектуры сети. При исправной работе двойного стека IPv6 не следует отключать только из привычки; по умолчанию NGINX разрешает оба семейства IP-адресов.

Тщательная проверка конфигурации и ее внедрение

Перед внесением изменений сначала проверь, в каких местах директивы резолвера действительно применяются. Для этого найди активную конфигурацию, включая подключенные файлы, и выясни, действует ли резолвер для всего http-контекст, предназначенный только для одного виртуального хоста или лишь для одного конкретного пути. Слишком узкая область действия может привести к тому, что другой переменный путь прокси не найдет резолвер; с другой стороны, слишком широкая область действия затрудняет последующее сопоставление изменений.

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

nginx -t
nginx -s reload

Выполняй перезагрузку только после успешной проверки. nginx -s reload заставляет NGINX запустить новые рабочие процессы с новой конфигурацией и упорядоченно завершить старые рабочие процессы. В зависимости от установленного пакета и операционной системы перезагрузку может инициировать предусмотренный в них диспетчер служб. Для этого используйте описанный в документации порядок работы установки, а не копируйте команды из посторонней среды.

Затем запланируйте техническую проверку в предусмотренном окне для внесения изменений. Сравните ожидаемое значение TTL DNS со временем, с которого должен начать использоваться новый адрес бэкенда, и проверьте доступность службы через фактически разрешённое семейство IP-адресов. Кроме того, задокументируйте адрес резолвера, выбранный диапазон и возможное valid-Override. Это позволяет в случае сбоя определить, что стало его причиной: DNS, маршрутизация или приложение.

Систематическое выявление типичных неисправностей резолвера

Начните поиск ошибок с целевого выражения в proxy_pass. Если он содержит переменную, NGINX должен разрешить содержащееся в ней имя хоста во время выполнения, если оно не входит в какую-либо определённую группу Upstream. Сообщение no resolver defined поэтому в первую очередь указывает на отсутствие или невидимость в контексте, имеющем значение, Настройка резолвера . Добавьте надежный сервер имен в соответствующий контекст, вместо того чтобы поспешно заменять имя хоста фиксированным IP-адресом.

Если резолвер настроен, далее необходимо проверить его адрес, сетевой путь и полномочия в отношении используемой зоны. Публичный резолвер не может знать внутренних имен; недоступный резолвер, в свою очередь, приводит к таймаутам при разрешении имен. Кроме того, проверьте, не переопределяется ли эта директива более конкретной настройкой. NGINX использует только явно указанные серверы имен, а не автоматически все настройки из /etc/resolv.conf.

Если после смены DNS старый целевой адрес остаётся активным, проверьте TTL ответа и наличие установленного valid. Длительный переопределитель заменяет TTL ответа DNS и может соответственно задержать применение изменения. Допустимое значение TTL — это не максимально короткий срок в общем случае, а значение, соответствующее окну изменений и нагрузочной способности инфраструктуры DNS; часто опущение valid более чистый вариант.

Если после успешного разрешения адреса по-прежнему возникают проблемы с подключением, отсоедини DNS от бэкенд-соединения. Проверь, имеются ли ответы A и AAAA, а также действительно ли цель маршрутизируется по IPv6 и доступна. ipv6=off подходит только для архитектурных сценариев, в которых подтверждено использование исключительно IPv4. Таймаут DNS влияет на разрешение имен; в то же время ошибка подключения к уже известному IP-адресу указывает на проблемы с маршрутизацией, брандмауэром, портом или приложением.

Кроме того, для динамических потоков входящего трафика необходимо указать номер версии, зону общей памяти и resolve совместимы. Документированная поддержка открытого исходного кода действует начиная с версии NGINX 1.27.3; более старые версии не следует рассматривать как равноценные. status_zone Кроме того, статистика резолверов на основе API не является универсальным решением для мониторинга NGINX Open Source, поскольку указанные функции относятся к коммерческому сегменту.

Выбрать стратегию работы резолвера

Правильная стратегия начинается не с установки фиксированного значения кэша, а с учета суверенитета DNS и частоты изменений. Если ваша команда может поддерживать авторитетную зону, а значения TTL в ней реалистично отражают окно развертывания, то Разрешение с управлением по TTL без valid как правило, является наиболее понятной отправной точкой. В этом случае DNS остается основным источником информации о том, как долго используется тот или иной ответ.

Сознательно установленный valid это вариант, который можно рассмотреть, если вы не можете влиять на TTL и можете обосновать иное время хранения в кэше с точки зрения эксплуатации. При этом определите, какие последствия сбоя являются приемлемыми: более длительное значение снижает количество возможных DNS-запросов, но после переезда может указывать на адрес, который больше не соответствует действительности. Оно не является ни верхним пределом для DNS-TTL, ни универсальным регулятором производительности.

Выберите шаблон NGINX в соответствии со структурой маршрутизации. Переменная proxy_pass подходит в тех случаях, когда адрес назначения определяется во время выполнения для каждого запроса или конфигурации; для этого требуется резолвер в соответствующей области видимости. Для именованной группы бэкендов с изменением адресов на основе DNS необходимо использовать апстрим с zone и resolve если, конечно, версия NGINX Open Source 1.27.3 или более поздняя действительно доступна.

Только после этого ты определяешь Таймауты и семейства IP-адресов. Тайм-аут резолвера должен соответствовать тайм-аутам клиента и вышестоящего сервера, чтобы отсутствие ответа DNS не приводило к неоправданной задержке. IPv4 или IPv6 следует включать только в соответствии с архитектурой сети. Используйте исключительно защищённые резолверы, способные надёжно отвечать на запросы к внутренним зонам.

Разрешение DNS и Upstream-Keepalive решают разные задачи. Резолвер определяет, какой адрес бэкенда может использовать NGINX; Keepalive сохраняет уже установленные, неактивные соединения с бэкендом для повторного использования. Поэтому изменение в механизме повторного использования соединений не заменяет ни планирование TTL, ни проверку резолвером. Для расчёта параметров этого уровня соединений см. статью о NGINX: Keepalive на стороне исходного сервера Стратегия резолвера.