Awaria DNS ma jedną szczególną cechę: wygląda jak awaria wszystkiego innego. Poczta nie działa, strony się nie ładują, logowanie do domeny trwa minuty, monitoring zgłasza niedostępność setek usług, które działają bez zarzutu. Diagnoza trwa długo, bo objawy wskazują na sieć, serwery i aplikacje jednocześnie, a przyczyną jest jedna usługa, o której nikt nie pomyślał.
Gdzie ukrywają się pojedyncze punkty awarii
Jeden resolver. W konfiguracji DHCP i na serwerach wpisane są dwa adresy, ale drugi to ten sam serwer pod innym adresem, serwer wyłączony rok temu albo kontroler domeny stojący na tym samym hoście wirtualizacji, co pierwszy. Redundancja istnieje na papierze.
Resolver zależny od tego, co obsługuje. Węzły klastra kontenerowego skonfigurowane tak, by używać DNS działającego w tym klastrze. Awaria sieci klastra odbiera węzłom możliwość rozwiązania nazwy rejestru obrazów, z którego potrzebują pobrać obraz, by się naprawić.
Forwardery do jednego dostawcy. Oba wewnętrzne resolvery przekazują zapytania zewnętrzne do dwóch adresów tego samego operatora. Awaria operatora oznacza brak internetu po nazwach, mimo działającego łącza zapasowego.
Zbyt długi lub zbyt krótki czas życia rekordów. Długi TTL utrudnia przełączenie usługi na inny adres. Krótki TTL zamienia każdy problem z resolverem w natychmiastową awarię, bo pamięć podręczna klientów nie osłania niczego.
Monitoring procesu, nie usługi. Sprawdzenie „proces DNS działa” przechodzi, gdy proces działa, ale odpowiada po dziesięć sekund lub zwraca błędy. Użytkownicy mają awarię, monitoring ma zielono.
Projekt, który wytrzymuje awarię
Dwa resolvery na niezależnych hostach wirtualizacji, w osobnych segmentach sieci, jeśli architektura na to pozwala. W środowisku Active Directory są to zwykle dwa kontrolery domeny z rolą DNS, pod warunkiem, że nie dzielą hosta, macierzy ani zasilania.
Każdy klient, także serwery i węzły klastra, zna oba adresy. Kolejność ma znaczenie: część klientów pyta pierwszy resolver do skutku, część przełącza się po jednym nieudanym zapytaniu. Warto rozdzielić: połowa klientów z resolverem A jako pierwszym, połowa z B.
Węzły klastra i infrastruktura używają resolverów niezależnych od klastra. DNS wewnątrz klastra obsługuje wyłącznie nazwy usług klastra i przekazuje resztę do resolverów zewnętrznych.
Każdy resolver ma co najmniej dwa forwardery od różnych dostawców: operatora oraz publiczny serwer, albo dwa publiczne od różnych organizacji.
Przekierowania warunkowe i strefy pomocnicze są udokumentowane w jednym miejscu, z uzasadnieniem. Przekierowanie dodane pięć lat temu do partnera, który już nie istnieje, jest opóźnieniem przy każdym zapytaniu o tę domenę.
Monitoring, który widzi awarię
Dla każdego resolvera osobno: czas odpowiedzi na zapytanie o nazwę wewnętrzną i zewnętrzną, odsetek odpowiedzi z błędem, liczba zapytań na sekundę. Alert na czas odpowiedzi powyżej progu przez kilka minut, nie na stan procesu. Dodatkowo test z perspektywy klienta: zapytanie z segmentu użytkowników do adresu, który dostają z DHCP.
Test
Wyłączenie jednego resolvera na godzinę w godzinach pracy, po uprzedzeniu zespołu. Jeśli ktokolwiek zauważy, projekt nie jest redundantny: albo klienci nie mają drugiego adresu, albo drugi resolver nie działa, albo przełączenie trwa dłużej niż cierpliwość użytkowników. Powtarzane co pół roku, po każdej większej zmianie w sieci.
Podsumowanie
DNS jest usługą, od której zależy każda inna, i jednocześnie tą, którą najrzadziej się projektuje. Dwa niezależne resolvery, dwa forwardery od różnych dostawców, klienci znający oba adresy, klaster niezależny od własnego DNS i monitoring czasu odpowiedzi zamiast stanu procesu. Test przez wyłączenie potwierdza, że to działa, a nie tylko wygląda na działające.