Unikanie przekroczenia limitu czasu DNS w przypadku awarii serwera DNS

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?

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.

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

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.

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.

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.

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.

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

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.