Prawidłowa konfiguracja pamięci podręcznej resolwera NGINX

Zrozumieć działanie modulu NGINX Resolver i pamięci podręcznej DNS

Serwer proxy odwrotny potrzebuje najpierw adresu IP dla serwera zaplecza o nazwie hosta. Ten Moduł rozpoznawania NGINX w tym celu wysyła zapytanie do serwerów nazw określonych w konfiguracji. Otrzymana odpowiedź DNS jest buforowana, dzięki czemu NGINX nie musi ponownie rozpoznawać nazwy dla każdego zapytania w okresie jej ważności. Ta pamięć podręczna dotyczy wyłącznie rozpoznawania nazw prowadzących do systemu docelowego.

Dyrektywa resolver zawiera jeden lub więcej adresów resolverów lub obsługiwanych identyfikatorów resolverów. Jeśli nie podano innego portu, NGINX używa portu 53; w przypadku wpisania kilku serwerów zapytania są kierowane zgodnie z dokumentacją metodą round-robin. W celu zapewnienia niezawodnej konfiguracji bootstrapowej często stosuje się stałe adresy IP, ponieważ ich rozpoznawanie nie zależy od samego systemu DNS.

Domyślnie NGINX uwzględnia adresy IPv4 i IPv6 danej nazwy. Jest to odpowiednie rozwiązanie, jeśli sieć niezawodnie przekazuje obie rodziny protokołów do serwera zaplecza. Parametry takie jak ipv4=off lub ipv6=off wykluczają konkretną rodzinę, ale nie stanowią ogólnej optymalizacji pamięci podręcznej. O tym, czy są one konieczne, decyduje dostępność konkretnego serwera zaplecza, a nie sam fakt istnienia rekordu AAAA.

Resolver nie jest ani pełnoprawnym rekurencyjnym serwerem DNS, ani nie powoduje automatycznego przejęcia wszystkich ustawień z /etc/resolv.conf. NGINX korzysta z wyraźnie określonych serwerów nazw. W przypadku stref wewnętrznych i nazw produkcyjnych serwerów zaplecza powinny to być godne zaufania i odpowiednio zabezpieczone serwery rozpoznające nazwy w własnej sieci. Dzięki temu odpowiedzialność za nazwy prywatne oraz ochrona przed sfałszowanymi odpowiedziami DNS pozostają w ramach infrastruktury, nad którą można sprawować kontrolę.

Pamięć podręczna DNS nie jest pamięcią podręczną HTTP

Pamięć podręczna odpowiedzi DNS resolwera przechowuje powiązania między nazwami a odpowiedziami DNS, takimi jak adresy typu A lub AAAA. Jej celem jest umożliwienie ponownego połączenia się z serwerem zaplecza bez konieczności powtarzania każdego procesu rozpoznawania nazwy. W przypadku zmiany adresu IP serwera zaplecza istotna jest zatem ważność odpowiedzi DNS – a nie treść wcześniej dostarczonej odpowiedzi HTTP.

Oddzielnie zapisuje proxy_cache Odpowiedzi HTTP z serwera nadrzędnego. W zależności od konfiguracji klucz może obejmować na przykład adres URI, nazwę hosta lub nagłówek; trafienie powoduje dostarczenie klientowi już zapisanej odpowiedzi. Problemy w tym zakresie objawiają się w postaci nieaktualnych stron, błędnych wariantów lub nieoczekiwanych trafień w pamięci podręcznej. Funkcja ta nie decyduje o tym, który adres IP zostanie użyty przez NGINX podczas nawiązywania nowego połączenia z serwerem zaplecza.

Pamięć podręczna otwartych plików (Open-File-Cache) stanowi trzeci poziom: przechowuje informacje o plikach i otwarte deskryptory na potrzeby lokalnego dostępu do systemu plików, ale nie zawiera ani odpowiedzi DNS, ani treści HTTP. Osoby pragnące zgłębić tę klasyfikację w kontekście dostarczania treści statycznych znajdą więcej informacji w artykule poświęconym Konfiguracja pamięci podręcznej otwartych plików NGINX. Nie dostarcza on jednak żadnych podstaw do podjęcia decyzji dotyczącej wyboru wartości TTL resolwera.

Opróżnienie, wyczyszczenie lub zsynchronizowanie pamięci podręcznej HTTP nie przyspiesza zatem zmiany DNS. Z drugiej strony nowe rozpoznanie DNS nie naprawia błędnie zapisanej w pamięci podręcznej odpowiedzi HTTP. W przypadku serwera proxy odwrotnego ogranicza to Pamięć podręczna DNS opiera się ponadto na nazwach i adresach: nie sprawdza on ani poprawności działania aplikacji, ani nie zastępuje równoważenia obciążenia, ponownych prób połączenia ani prawidłowego planowania limitów czasu dla połączeń z serwerami nadrzędnymi.

Kiedy NGINX musi ponownie przeprowadzić rozpoznawanie nazw

Nazwa hosta może być znana serwerowi NGINX już podczas wczytywania konfiguracji. Inaczej wygląda sytuacja w przypadku zmiennego celu, na przykład proxy_pass http://$backend;. NGINX najpierw wyszukuje uzyskany nazwę w zdefiniowanych grupach upstream. Jeśli nie znajdzie tam pasującej nazwy, potrzebuje w czasie działania skonfigurowanego modułu rozpoznającego nazwy, aby ustalić adres docelowy.

Komunikat no resolver defined W tym kontekście nie wskazuje to na brak pamięci podręcznej HTTP. Oznacza to, że serwer NGINX nie zna żadnego serwera DNS, który mógłby przeprowadzić niezbędne rozpoznanie adresu w czasie wykonywania. resolver może w kontekście http, server lub location znajdują się. Kluczowy wpis w http-Blok ten sprawdza się, gdy kilka wirtualnych hostów korzysta z tego samego modulu rozdzielającego; węższy zakres ma sens tylko wtedy, gdy wymagania faktycznie się różnią.

Od tej dostępnej od dawna rozdzielczości czasu wykonania należy oddzielić dynamiczną aktualizację klasycznej grupy upstream. Konfiguracja modułów rozdzielających bezpośrednio w upstream-blok oraz server hostname resolve Zgodnie z dokumentacją są one dostępne w wersji open source NGINX od wersji 1.27.3. Starszych instalacji open source nie należy traktować tak, jakby automatycznie obsługiwały ten wzorzec; w przeszłości niektóre z tych funkcji były zarezerwowane wyłącznie dla NGINX Plus.

Przed zaplanowaniem dynamicznych strumieni upstream należy sprawdzić informacje o zainstalowanej wersji i kompilacji. Poniższe polecenie wyświetla wersję NGINX, wersję kompilatora oraz parametry konfiguracyjne użyte podczas kompilacji.

nginx -V

W przypadku wdrożeń o krytycznym znaczeniu należy porównać wyświetlany stan z dokumentacją konkretnego pakietu oraz jego dostawcy. Decydujące znaczenie ma to, czy dana instalacja dokumentuje i udostępnia wymaganą funkcję. Dopiero wtedy można dynamiczny upstream rozwiązanie architektoniczne o wysokiej niezawodności.

Celowe ustawienie TTL i valid

Pamięć podręczna resolwera NGINX, o ile nie określono inaczej, opiera się na DNS-TTL w odpowiedzi od zapytanego serwera nazw. Jeśli operator autorytatywnego serwera DNS zmieni adres IP serwera zaplecza, NGINX wykorzystuje dotychczasową odpowiedź aż do upływu jej czasu życia (TTL). Dopiero gdy ponownie konieczne będzie rozpoznanie nazwy, NGINX ponownie wysyła zapytanie do serwera rozpoznającego nazwy. Dzięki temu okres ważności można kontrolować w miejscu, gdzie dane dotyczące nazw są aktualizowane.

Parametr valid całkowicie zastępuje ten czas TTL skonfigurowanym okresem. Nie ogranicza więc czasu TTL w DNS tylko od góry, ani nie definiuje regularnego odświeżania jako uzupełnienia czasu TTL. Wartość valid=30s może skrócić dłuższy czas TTL adresu DNS, ale również wydłużyć celowo ustawiony krótki czas TTL. Musi to być zgodne z planem przeniesienia i wdrożenia zaplecza.

Jeśli strefa jest rzetelnie utrzymywana, konfiguracja bez nadpisywania stanowi logiczny punkt wyjścia. Adres podany w przykładzie został wybrany zgodnie z sieciami opisanymi w dokumentacji i nie wolno go stosować jako resolvera produkcyjnego. Zamiast tego należy wpisać adres dostępnego i wiarygodnego resolvera DNS z własnej sieci.

resolver 192.0.2.53;
resolver_timeout 5s;

Zastąpienie może być uzasadnione, jeśli nie ma możliwości wpływania na czas TTL DNS i istnieje udokumentowana wytyczna operacyjna. Wówczas to odstępstwo wyraźnie wskazuje, jak długo NGINX przechowuje odpowiedzi. Nie jest to ogólna optymalizacja wydajności: krótsze czasy mogą powodować większą liczbę zapytań DNS, natomiast dłuższe czasy mogą opóźniać przejście na nowe adresy backendowe.

resolver 192.0.2.53 valid=30s;
resolver_timeout 5s;

W związku z tym rozstrzygnięcie nie opiera się na konkretnej liczbie sekund, lecz na pytaniu, kto kontroluje dane DNS i jak szybko musi nastąpić zmiana serwera zaplecza. prawidłowy stanowi celową zmianę tej konfiguracji. Nie nadaje się on jako uniwersalne rozwiązanie służące do przyspieszenia działania serwera proxy odwrotnego lub ukrycia problemów z DNS.

Prawidłowe rozpoznawanie zmiennych w `proxy_pass`

Zawiera proxy_pass zmienną, NGINX musi przetworzyć wynikową nazwę hosta w czasie wykonywania. Najpierw NGINX szuka odpowiedniej grupy upstream; jeśli jej nie znajdzie, potrzebuje skonfigurowanego modulu rozpoznającego nazwę. Jeśli go brakuje, pojawia się typowy komunikat no resolver defined Nie jest to wskazówka dotycząca pamięci podręcznej HTTP, lecz brakującej konfiguracji DNS dla tej ścieżki wykonania.

Poniższy przykład w wyraźny sposób ilustruje działanie mechanizmu rozwiązywania w czasie wykonywania. Moduł rozwiązywania znajduje się w http-kontekst i w związku z tym ma zastosowanie do wielu wirtualnych hostów, o ile nie zostanie nadpisany przez bardziej szczegółowe ustawienie. Używany adres dokumentacji należy zastąpić wewnętrznym resolverem danego środowiska.

http {
    resolver 192.0.2.53;
    resolver_timeout 5s;

    server {
        listen 80;

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

Dyrektywa resolver_timeout Nie wpływa na czas trwania pamięci podręcznej. Ogranicza czas, przez jaki NGINX czeka na rozpoznanie nazwy; udokumentowana wartość domyślna wynosi 30 sekund. Wybór tej wartości należy do pozostałych parametrów związanych z tolerancją błędów: zbyt wysoka wartość może opóźnić nieudane żądanie aż do otrzymania odpowiedzi o błędzie, natomiast zbyt niska wartość powoduje niepotrzebne błędy rozpoznawania w przypadku sporadycznie wolno działających wewnętrznych serwerów rozpoznawania nazw.

W przypadku pojedynczej, jasno określonej lokalizacji moduł Resolver może w location-Block. Jeśli kilka lokalizacji lub serwerów wymaga tej samej rozdzielczości, należy zdefiniować wspólny zakres w server- lub http-Blok wymaga mniej konserwacji. NGINX zezwala na stosowanie tej dyrektywy we wszystkich trzech kontekstach; jej zakres powinien odzwierciedlać rzeczywistą strukturę operacyjną, a nie tylko tymczasowo eliminować pojedynczy komunikat o błędzie.

Nawet w przypadku celów zmiennych limit czasu DNS i połączenie z serwerem zaplecza pozostają odrębnymi kategoriami błędów. Pomyślne rozpoznanie nazwy nie oznacza ani tego, że port docelowy jest dostępny, ani tego, że aplikacja odpowiada. Z drugiej strony wydłużenie limitu czasu połączenia z serwerem zaplecza nie rozwiązuje problemu niedostępnego adresu serwera rozpoznającego nazwy.

Konfiguracja dynamicznych źródeł za pomocą polecenia `resolve`

W przypadku określonej grupy backendów dynamiczny upstream może być bardziej czytelny niż zmienna wartość docelowa w każdej lokalizacji. Ten wzorzec oddziela definicję elementów backendowych od routingu: proxy_pass odnosi się do grupy, podczas gdy nazwa hosta w sieci nadrzędnej może być aktualizowana za pośrednictwem DNS. Jest to szczególnie przydatne, gdy kilka tras prowadzi do tej samej aplikacji.

Parametr resolve dla jednego server-Ta opcja istnieje historycznie od wersji NGINX 1.5.12. Jednak zgodnie z dokumentacją w wersji open source NGINX jest ona dostępna dopiero od wersji 1.27.3; wcześniej funkcja ta była ograniczona do wersji komercyjnych. Również konfiguracja resolwera bezpośrednio w upstream-Blok jest udokumentowany dla wersji Open Source od 1.27.3.

Die Strefa pamięci współdzielonej Nie jest to ani limit czasu pamięci podręcznej, ani ścieżka danych DNS. Zapewnia ona w ramach NGINX wspólną pamięć, której potrzebują dynamicznie zmieniające się konfiguracje upstream. Jeśli podczas rozpoznawania DNS serwer NGINX wykryje inne adresy dla danej nazwy, grupę upstreamową można dostosować na podstawie tego wewnętrznie zarządzanego stanu bez konieczności ponownego uruchamiania.

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;
        }
    }
}

Tak jak we wszystkich przykładach, 192.0.2.53 tylko dla jednego adresu dokumentacyjnego. W praktyce zarejestrowany resolver musi niezawodnie rozpoznawać nazwy wewnętrzne, być dostępny z sieci NGINX oraz być uznawany za godny zaufania. Przed wdrożeniem należy również sprawdzić rzeczywisty zakres funkcji zainstalowanego pakietu, zamiast opierać konfigurację wyłącznie na aktualnym przykładzie.

Usługa dostępna wyłącznie za pośrednictwem protokołu IPv4 może uzasadniać wprowadzenie ukierunkowanego ograniczenia: resolver 192.0.2.53 ipv6=off; uniemożliwia wysyłanie zapytań AAAA oraz wybór adresu IPv6 dla tego kontekstu resolvera. Jest to jednak decyzja dotycząca architektury sieciowej. Jeśli dual stack działa poprawnie, nie należy wyłączać IPv6 wyłącznie z przyzwyczajenia; domyślnie NGINX obsługuje obie rodziny adresów IP.

Dokładne sprawdzenie konfiguracji i wdrożenie

Przed wprowadzeniem zmian sprawdź najpierw, w których miejscach dyrektywy resolwera faktycznie mają zastosowanie. W tym celu przejrzyj aktywną konfigurację, w tym dołączone pliki, i ustal, czy resolwer obejmuje całość http-kontekst, przeznaczony wyłącznie dla jednego wirtualnego hosta lub jedynie dla pojedynczej ścieżki. Zbyt wąski zakres może spowodować, że inna zmienna ścieżka proxy nie znajdzie resolvera; z kolei zbyt szeroki zakres utrudnia późniejsze przypisanie zmian.

Po każdej zmianie następuje Sprawdzanie składni. Odczytuje konfigurację i próbuje również otworzyć pliki, do których są odwołania. Pozwala to wykryć błędy ortograficzne, nieprawidłowe dyrektywy oraz problemy w plikach dołączanych jeszcze przed ponownym załadowaniem. Sprawdzenie to nie potwierdza jednak, że wprowadzony serwer DNS jest dostępny, rozpoznaje oczekiwaną nazwę ani że backend znajdujący się pod rozpoznanym adresem akceptuje połączenia.

nginx -t
nginx -s reload

Przeprowadź ponowne ładowanie dopiero po pomyślnym zakończeniu sprawdzania. nginx -s reload powoduje, że NGINX uruchamia nowe procesy robocze z nową konfiguracją i w kontrolowany sposób zamyka stare procesy robocze. W zależności od zainstalowanego pakietu i systemu operacyjnego operację przeładowania może zamiast tego zainicjować menedżer usług przewidziany w danym środowisku. W tym celu należy skorzystać z udokumentowanej procedury operacyjnej instalacji, zamiast stosować polecenia z obcego środowiska.

Następnie zaplanuj test funkcjonalny w wyznaczonym oknie czasowym na wprowadzenie zmian. Porównaj oczekiwany czas życia DNS (TTL) z momentem, od którego ma być używany nowy adres zaplecza, i sprawdź dostępność usługi za pośrednictwem faktycznie dozwolonej rodziny adresów IP. Udokumentuj również adres resolvera, wybrany zakres oraz ewentualne valid-Override. Dzięki temu w razie awarii można ustalić, czy przyczyną jest usterka serwera DNS, routingu czy aplikacji.

Systematyczne zawężanie zakresu typowych błędów resolvera

Rozpocznij diagnostykę od wyrażenia docelowego w proxy_pass. Jeśli zawiera zmienną, NGINX musi rozpoznać zawartą w niej nazwę hosta w czasie wykonywania, o ile nie należy ona do zdefiniowanej grupy upstream. Komunikat no resolver defined w związku z tym zwraca najpierw uwagę na brak lub niewidoczność w danym kontekście Konfiguracja modułów Resolver . Dodaj zaufany serwer nazw w odpowiednim kontekście, zamiast pochopnie zastępować nazwę hosta stałym adresem IP.

Jeśli skonfigurowano resolver, w następnym kroku sprawdź jego adres, ścieżkę sieciową oraz zakres odpowiedzialności za daną strefę. Publiczny resolver nie może znać nazw wewnętrznych; z kolei niedostępny resolver powoduje przekroczenie limitu czasu rozpoznawania. Sprawdź również, czy dyrektywa ta nie jest nadpisywana przez bardziej szczegółowe ustawienie. NGINX korzysta wyłącznie z wyraźnie wskazanych serwerów nazw, a nie automatycznie ze wszystkich ustawień z pliku /etc/resolv.conf.

Jeśli po zmianie adresu DNS stary adres docelowy pozostaje aktywny, sprawdź czas życia odpowiedzi (TTL) oraz ustawienie valid. Długie nadpisanie zastępuje czas życia (TTL) odpowiedzi DNS i może odpowiednio opóźnić wprowadzenie zmiany. Dopuszczalna korekta nie polega na ustaleniu jak najkrótszego czasu trwania, lecz na wartości dostosowanej do okna zmian i wydajności infrastruktury DNS; często pominięcie valid lepsze rozwiązanie.

W przypadku problemów z połączeniem po pomyślnym rozwiązaniu odłącz DNS od połączenia z backendem. Sprawdź, czy dostępne są odpowiedzi A i AAAA oraz czy adres docelowy jest faktycznie routowany i dostępny przez IPv6. ipv6=off nadaje się wyłącznie do przypadków architektury, w których wykazano, że działa wyłącznie w oparciu o protokół IPv4. Limit czasu DNS ma wpływ na rozpoznawanie nazw; natomiast błąd połączenia z już znanym adresem IP wskazuje na problem z routingiem, zaporą sieciową, portem lub aplikacją.

W przypadku dynamicznych strumieni upstream należy ponadto podać numer wersji, strefę pamięci współdzielonej oraz resolve są ze sobą zgodne. Udokumentowana obsługa oprogramowania open source w tym zakresie dotyczy wersji NGINX 1.27.3 i nowszych; starszych instalacji nie należy traktować jako równoważnych. status_zone Ponadto statystyki resolvera oparte na API nie stanowią ogólnego rozwiązania do monitorowania serwera NGINX Open Source, ponieważ wymienione funkcje dotyczą zastosowań komercyjnych.

Wybór strategii resolerów do pracy

Odpowiednia strategia nie zaczyna się od ustalenia ogólnej wartości pamięci podręcznej, lecz od kontroli nad DNS i częstotliwości zmian. Jeśli twój zespół jest w stanie zarządzać strefą autorytatywną, a jej wartości TTL realistycznie odzwierciedlają okno wdrożeniowe, to Rozdzielczość sterowana sygnałem TTL bez valid zazwyczaj jest to najbardziej zrozumiały punkt wyjścia. DNS pozostaje wówczas głównym źródłem informacji o tym, jak długo odpowiedź jest wykorzystywana.

Celowo umieszczony valid Można to rozważyć, jeśli nie masz wpływu na wartość TTL i jesteś w stanie uzasadnić operacyjnie inny czas przechowywania w pamięci podręcznej. Należy przy tym określić, jakie skutki awarii są akceptowalne: dłuższa wartość zmniejsza liczbę potencjalnych zapytań DNS, ale po przeniesieniu serwisu może wskazywać na adres, który już nie jest aktualny. Nie stanowi ona ani górnej granicy dla TTL DNS, ani ogólnego przełącznika wydajności.

Wybierz następnie szablon NGINX na podstawie struktury routingu. Zmienny proxy_pass nadaje się, gdy adres docelowy jest określany w czasie wykonywania dla każdego żądania lub konfiguracji; w tym celu wymagany jest resolver w odpowiednim zakresie. W przypadku nazywanej grupy backendów z zmianami adresów opartymi na DNS, upstream z zone oraz resolve Oczywiście, o ile wersja NGINX Open Source 1.27.3 lub nowsza jest rzeczywiście dostępna.

Dopiero potem decydujesz Limity czasu i rodziny adresów IP. Limit czasu resolwera musi być dostosowany do limitów czasu klienta i serwera nadrzędnego, aby brak odpowiedzi DNS nie powodował nieproporcjonalnie długich opóźnień. Protokół IPv4 lub IPv6 należy włączyć wyłącznie zgodnie z architekturą sieci. Należy korzystać wyłącznie z zabezpieczonych resolverów, które są w stanie niezawodnie odpowiadać na zapytania dotyczące stref wewnętrznych.

Rozpoznawanie DNS i funkcja Upstream Keepalive pełnią różne zadania. Moduł rozpoznawania decyduje, z którego adresu serwera zaplecza może korzystać NGINX; funkcja Keepalive utrzymuje już nawiązane, nieaktywne połączenia z serwerami zaplecza w celu ich ponownego wykorzystania. Zmiana dotycząca ponownego wykorzystania połączeń nie zastępuje zatem ani planowania TTL, ani sprawdzania przez moduł rozpoznający. W celu doboru parametrów tej warstwy połączeń artykuł dotyczący NGINX – funkcja Keepalive w upstreemie strategia resolwera.