Unikanie przekroczenia limitu czasu DNS w przypadku awarii serwera DNS

17

Mamy małe centrum danych z około setką hostów wskazujące na 3 wewnętrzne serwery dns (powiązanie 9). Nasz problem pojawia się, gdy jeden z wewnętrznych serwerów dns staje się niedostępny. W tym momencie wszyscy klienci wskazujący ten serwer zaczynają działać bardzo wolno.

Problemem wydaje się być to, że podstawowy program do rozwiązywania problemów z linuksem tak naprawdę nie ma pojęcia „przełączania awaryjnego” na inny serwer dns. Możesz dostosować limit czasu i liczbę ponownych prób, z których korzysta, (i ustawić rotację, aby działał na liście), ale bez względu na to, jakie ustawienia korzystasz z naszych usług, działają znacznie wolniej, jeśli podstawowy serwer dns stanie się niedostępny. W tej chwili jest to dla nas jedno z największych źródeł zakłóceń usług.

Moją idealną odpowiedzią byłoby coś w stylu „RTFM: tweak /etc/resolv.conf like this ...”, ale jeśli jest to opcja, nie widziałem tego.

Zastanawiałem się, jak inni poradzili sobie z tym problemem?

Widzę 3 możliwe typy rozwiązań:

  • Użyj linux-ha / Pacemaker i przełączania awaryjnego ips (więc VIP dns IP VIP jest „zawsze” dostępny). Niestety, nie mamy dobrej infrastruktury do szermierki, a bez szermierki stymulator serca nie działa zbyt dobrze (z mojego doświadczenia Pacemaker zmniejsza dostępność bez szermierki).

  • Uruchom lokalny serwer dns na każdym węźle i niech resolv.conf wskazuje na localhost. To by działało, ale dałoby nam znacznie więcej usług do monitorowania i zarządzania.

  • Uruchom lokalną pamięć podręczną na każdym węźle. Wydaje się, że ludzie uważają nscd za „zepsuty”, ale dnrd wydaje się mieć odpowiedni zestaw funkcji: oznacza, że ​​serwery dns są w górę lub w dół i nie będą używać serwerów „down”.

Wydaje się, że rzutowanie dowolne działa tylko na poziomie routingu IP i zależy od aktualizacji tras z powodu awarii serwera. Wydawało się, że wielokrotne przesyłanie byłoby idealną odpowiedzią, ale bind nie obsługuje emisji ani wysyłania wielokrotnego, a dokumenty, które mogłem znaleźć, wydają się sugerować, że dns multiemisji jest bardziej ukierunkowany na wykrywanie usług i automatyczną konfigurację niż na zwykłe rozwiązywanie dns .

Czy brakuje mi oczywistego rozwiązania?

Neil Katin
źródło
2
Sugeruję, że oprócz znalezienia rozwiązania, o które prosisz (w czym nie mogę ci pomóc), powinieneś pracować nad prawdziwym problemem root i naprawić problemy z niezawodnością serwera DNS.
John Gardeniers,
Główny problem polega na tym: dlaczego te serwery DNS tak często się psują, abyś się tym przejmował? Rozważ zreplikowanie swojego DNS za pomocą specjalistycznych usług, takich jak BuddyNS . Twoje opóźnienia znacznie spadną, a czas przestoju nie sprawi, że będziesz się martwić o poprawki /etc/resolv.conf.
michele

Odpowiedzi:

15

Kilka opcji. Oba będą rozkładać obciążenie DNS na twoje serwery DNS.

  • Spróbuj użyć options rotatew resolv.conf. Zminimalizuje to wpływ awarii głównego serwera. Jeśli jeden z pozostałych serwerów nie działa, spowoduje to spowolnienie działań.
  • Użyj innej kolejności serwera nazw dla różnych klientów. Umożliwi to niektórym klientom normalne działanie, jeśli podstawowy serwer DNS nie działa. To rozkłada wpływ nieczynnego serwera DNS na cały.

Te opcje można łączyć z options timeout:1 attempts:5. Zwiększ liczbę prób, jeśli skrócisz limit czasu, aby móc obsługiwać wolne serwery zewnętrzne.

W zależności od konfiguracji routera możesz skonfigurować serwery DNS, aby przejmowały adres IP głównego serwera DNS, gdy jest on wyłączony. Można to połączyć z powyższymi technikami.

UWAGA: Działam przez lata bez nieplanowanych przestojów DNS. Jak zauważyli inni, będę pracował nad rozwiązaniem problemów powodujących awarię serwerów DNS. Powyższe kroki pomagają również w przypadku źle skonfigurowanych serwerów DNS z określeniem nieosiągalnych serwerów nazw.

BillThor
źródło
4

Sprawdź „man resolv.conf”. Możesz dodać opcję limitu czasu do resolv.conf. Domyślnie jest to 5, ale dodanie następującego do resolv.conf powinno sprowadzić go do 1 sekundy:

Limit czasu opcji: 1

Niall Donegan
źródło
Po przeczytaniu drugiego akapitu wypróbowałem powyższe na Centos i Debian VPS. Po obniżeniu podstawowych dns, resolver działał dokładnie tak, jak oczekiwano. Uruchamiając tcpdump, widziałem nawet resolver próbujący pierwszego serwera, a następnie próbujący następnego. Jakie widzisz zachowanie?
Niall Donegan
1
Istnieją dwa duże przypadki użycia do rozwiązania: procesy krótkotrwałe (takie jak narzędzia wiersza poleceń) i procesy długowieczne, a ta sama konfiguracja resolvera musi działać dla obu. W przypadku ustawienia krótkotrwałego (pojedynczego wyszukiwania) krótki limit czasu szybko zakończy się niepowodzeniem. Ale jeśli szukasz adresu zewnętrznego, który nie zostanie rozwiązany w tym czasie: otrzymasz nazwę, której nie znaleziono, ponieważ resolver porzuci to zapytanie, jeśli nie wróci w ciągu sekundy. (poza pokojem; więcej w następnym komentarzu)
Neil Katin
Procesy długoterminowe będą ponawiać każde wyszukiwanie, limit czasu, a następnie przechodzić na następny serwer. Ale nie wydaje się buforować „martwości” serwera.
Neil Katin
3

Oprogramowanie do grupowania, takie jak bicie serca lub rozrusznik serca / corosync, jest tutaj Twoim przyjacielem. Jako przykład skonfigurowaliśmy rozrusznik serca / corosync w następujący sposób:

  • Sparuj każdy serwer z innym
  • Na parę mają 2 dips vips, zwykle po jednym na każdym
  • W przypadku wiązania lub awarii serwera VIP przechodzi na inny serwer w ciągu milisekund

Godziny produkcji to 24x7, ale jesteśmy przekonani, że każdy serwer powinien mieć możliwość awarii bez wpływu na klientów. opcja obracania jest jedynie obejściem, nie zrobiłbym tego.

Dennis Kaarsemaker
źródło
3

Uruchom lokalny serwer dns na każdym węźle i niech resolv.conf wskazuje na localhost. To by działało, ale dałoby nam znacznie więcej usług do monitorowania i zarządzania.

FWIW, jest to jedyne wykonalne rozwiązanie tego problemu. Musisz ograniczyć serwer do nasłuchiwania tylko na localhost, ale całkowicie wyeliminował on użytkowników zauważających awarie DNS w naszym środowisku.

Ciekawym efektem ubocznym jest to, że jeśli z jakiegoś powodu serwer localhost ulegnie awarii, standardowe biblioteki tłumaczące wydają się obsługiwać przełączenie awaryjne na następny serwer znacznie szybciej niż w standardowym przypadku.

Robimy to od około 3 lat i nie widziałem żadnego problemu, który mógłby być związany z awarią / awarią serwera dns działającego na localhost.

Fred the Magic Wonder Dog
źródło
2

Jeśli serwer nazw przestaje działać w celu konserwacji, normalną procedurą jest skrócenie limitów czasu w SOA dla tej domeny z wyprzedzeniem, tak że gdy konserwacja się pojawi, zmienia się (np. Usuwa rekordy NS przed konserwacją i odkłada je z powrotem po konserwacji ) rozprzestrzeniają się szybko. Zauważ, że jest to podejście po stronie serwera - zmiana resolverów jest podejściem po stronie klienta i ... chyba że możesz porozmawiać z każdym z klientów i poprosić ich o dokonanie tej regulacji na ich komputerze ... może nie być właściwe podejście. Wydaje mi się, że powiedziałeś tylko stu klientów w centrum danych korzystających z wewnętrznych serwerów DNS, ale czy naprawdę chcesz zmienić konfigurację na stu klientach, kiedy możesz po prostu zmienić strefę?

Powiem ci, które wartości SOA należy dostosować, ale przeglądałem internet, by znaleźć dokładne informacje, gdy natknąłem się na to pytanie.

Brenda J. Butler
źródło
3
Ta odpowiedź dotyczy wyłącznie autorytatywnego systemu DNS. Pytanie dotyczyło rekurencyjnych wyszukiwań DNS wykonywanych przez oprogramowanie klienckie.
Andrew B,
1

Być może możesz ustawić swoje serwery DNS za moduł równoważenia obciążenia? Najwyraźniej LVS może zrównoważyć UDP. Oczywiście spraw, aby Twój LB był wysoce dostępny, aby nie był to pojedynczy punkt awarii.

rxvt
źródło
0

Wiem, że może to zabrzmieć banalnie, ale co powiesz na zbudowanie bardziej stabilnej i odpornej infrastruktury DNS jako stałego rozwiązania problemu.

joeqwerty
źródło
Mamy dość odporną infrastrukcję dns. Ale 2 lub 3 razy w roku mamy awarię, ponieważ serwer dns ulega awarii (lub jest restartowany, ma aktualizację systemu operacyjnego lub cokolwiek innego).
Neil Katin
1
Cóż ... restarty i aktualizacje powinny być zaplanowane na godziny nieprodukcyjne. Co do reszty, wydaje się, że robisz całkiem spory interes z czegoś, co zdarza się kilka razy w roku. Czy dodatkowa infrastruktura, czas, pieniądze i koszty ogólne zarządzania są tego warte w przypadku problemu, który pojawia się tak pozornie rzadko?
joeqwerty
8
Co się stanie, gdy twoje godziny produkcji będą 24x7? DNS powinien zawieść na drugim / trzecim / x serwerze ORAZ buforować awarię drugiego serwera przez pewien okres. Domyślny 5-sekundowy limit czasu wystarcza do obniżenia poziomu usług w zależności od obciążenia.
Ryaner
0

Bardziej zorientowanym na sieć rozwiązaniem byłoby użycie dwóch serwerów DNS o tym samym (dedykowanym) adresie IP i routingiem Anycast . (Do tej pory nie zauważyłem tej odpowiedzi w tym wątku, ale tutaj się jej używa).

Dopóki oba są włączone, używany jest najbliższy serwer. Jeśli jeden z nich spadnie, ruch dla tego adresu IP będzie kierowany do drugiego węzła, dopóki nie pojawi się ponownie. Ma to szczególne znaczenie, jeśli masz dwie lub więcej lokalizacji lub centrów danych.

Axel Beckert
źródło