Prawidłowy sposób skonfigurowania DNS podstawowego / dodatkowego /… w celu zapewnienia redundancji i redukcji opóźnień?

Myślałem, że DNS podstawowy / pomocniczy do celów redundancji jest prosty. Rozumiem, że powinieneś mieć podstawową i co najmniej jedną dodatkową, i że powinieneś ustawić swoją drugą w geograficznie innej lokalizacji, ale także za innym routerem (patrz na przykład /server/48087 / dlaczego-istnieją-kilka-serwerów-nazw dla mojej domeny )

Obecnie mamy dwa serwery nazw, oba w naszym głównym centrum danych. Niedawno wystąpiły pewne awarie z różnych powodów, które spowodowały usunięcie obu serwerów nazw i pozostawiły nas i naszych klientów bez pracy DNS przez kilka godzin. Poprosiłem mój zespół sysadmin o zakończenie konfiguracji serwera DNS w innym centrum danych i skonfigurowanie go jako dodatkowego serwera nazw.

Jednak nasi administratorzy twierdzą, że to niewiele pomaga, jeśli inne centrum danych nie jest co najmniej tak niezawodne jak główne centrum danych. Twierdzą, że większość klientów nadal nie będzie poprawnie wyszukiwać lub zbyt długo przekroczył limit czasu, gdy główne centrum danych jest wyłączone.

Osobiście jestem przekonany, że nie jesteśmy jedyną firmą z tego rodzaju problemem i że najprawdopodobniej jest to już rozwiązany problem. Nie mogę sobie wyobrazić, że wszystkie te firmy internetowe są dotknięte naszym rodzajem problemu. Nie mogę jednak znaleźć dobrych dokumentów online, które wyjaśniają, co dzieje się w przypadkach awarii (na przykład przekroczenia limitu czasu klienta) i jak obejść je.

Jakich argumentów mogę użyć, aby wykopać dziury w rozumowaniu naszych sysadminów? Jakieś zasoby internetowe, z którymi mogę się zapoznać, aby lepiej zrozumieć problemy, które według nich istnieją?

Kilka dodatkowych uwag po przeczytaniu odpowiedzi:

• jesteśmy na Linuksie
• mamy dodatkowe skomplikowane potrzeby DNS; nasze wpisy DNS są zarządzane przez niektóre niestandardowe oprogramowanie, BIND obecnie slave z implementacji Twisted DNS, a także niektóre widoki w miksie. Jesteśmy jednak w stanie skonfigurować własne serwery DNS w innym centrum danych.
• Mówię o autorytatywnym systemie DNS dla osób z zewnątrz, aby znaleźć nasze serwery, a nie rekurencyjnych serwerach DNS dla naszych lokalnych klientów.

Istnieje naprawdę świetny, aczkolwiek dość techniczny dokument „Najlepsze praktyki”, który może okazać się przydatny podczas walki z twoim sysadminem. http://www.cisco.com/web/about/security/intelligence/dns-bcp.html

Jeśli on / ona nie rozpozna ważności artykułów napisanych przez Cisco, równie dobrze możesz przestać kłócić się z sysadminem - przejść na wyższy poziom zarządzania.

Wiele innych dokumentów „Najlepszych praktyk” zaleca rozdzielenie podstawowego i pomocniczego serwera nazw nie tylko według bloku IP, ale także lokalizacji fizycznej. W rzeczywistości RFC 2182 zaleca, aby wtórne usługi DNS były rozdzielone geograficznie. Dla wielu firm oznacza to wynajem serwera w innym centrum danych lub subskrypcję hostowanego dostawcy DNS, takiego jak ZoneEdit lub UltraDNS .

Jednak nasi administratorzy twierdzą, że to niewiele pomaga, jeśli inne centrum danych nie jest co najmniej tak niezawodne jak główne centrum danych. Twierdzą, że większość klientów nadal nie będzie poprawnie wyszukiwać lub zbyt długo przekroczył limit czasu, gdy główne centrum danych jest wyłączone.

Ach, skupienie jest niezawodne . Wygląda na to, że naciągają cię na twój link na zewnątrz, zamiast konfigurować dodatkowy DNS. Tak samo, skonfiguruj dodatkowy DNS i kontynuuj od tego momentu. Pomoże to w obciążeniu i podeprze rzeczy w mgnieniu oka ... ale zapytaj, dlaczego uważają, że inna lokalizacja nie jest niezawodna .

Osobiście jestem przekonany, że nie jesteśmy jedyną firmą z tego rodzaju problemem i że najprawdopodobniej jest to już rozwiązany problem. Nie mogę sobie wyobrazić, że wszystkie te firmy internetowe są dotknięte naszym rodzajem problemu.

Nie jesteś jedyną firmą, która prawdopodobnie została przebudowana milion razy w firmach na całym świecie.

Nie mogę jednak znaleźć dobrych dokumentów online, które wyjaśniają, co dzieje się w przypadkach awarii (na przykład przekroczenia limitu czasu klienta) i jak obejść je.

Jakich argumentów mogę użyć, aby wykopać dziury w rozumowaniu naszych sysadminów? Jakieś zasoby internetowe, z którymi mogę się zapoznać, aby lepiej zrozumieć problemy, które według nich istnieją?

• Mówię o autorytatywnym systemie DNS dla osób z zewnątrz, aby znaleźć nasze serwery, a nie rekurencyjnych serwerach DNS dla naszych lokalnych klientów.

Możesz wykonywać różne czynności, w tym konfigurować zewnętrzną usługę DNS, która jest zarejestrowana jako autoryzacja dla Twojej strefy, ale potajemnie czyni (zewnętrzne) autorytatywne serwery wtórnymi do twoich (wewnętrznych) serwerów DNS. Ta konfiguracja jest okropna, zła, pokazuje, że jestem naprawdę złym SysAdminem, a kotek umiera za każdym razem, gdy go polecam. Ale robi dwie rzeczy:

• Dostajesz swoją usługę DNS, która poradzi sobie z obciążeniem, wyświetlając pytania o pojemność własnego (wewnętrznego) DNS-a.
• Dostajesz usługę DNS, która pozostanie aktywna, podczas gdy wewnętrzne serwery DNS mogą być wyłączone, więc nie ma znaczenia, jak niezawodny jest twój link - ważne jest, jak niezawodny jest twój dostawca usług DNS .

Powody, dla których jest to niewłaściwe działanie:

• Będziesz konfigurował tak zwany „ukryty serwer nazw”, ponieważ chociaż pojawi się on w twoich rekordach strefy i możesz zapytać IP o nazwę serwera, nigdy nie zostanie on dotknięty z zewnątrz. Zapytania klientów nigdy do niego nie dotrą.
• Chociaż Twój DNS nadal działałby dobrze (ponieważ twoja usługa hostowana rozwiązałaby problem), nie oznacza to, że wszystkie witryny, które masz, działałyby, gdyby twoje połączenie internetowe było niedostępne, to znaczy rozwiązuje tylko połowę problemu . Wygląda na to, że istnieją inne problemy, którymi obawiają się administratorzy.

Niestety, Linux resolver nie wydaje się mieć bezpośredniego wsparcia dla wykrywania i wykonywania przełączeń awaryjnych dla serwerów DNS. Nadal wysyła żądania do twojego głównego serwera nazw, czeka na skonfigurowany limit czasu, próbuje ponownie itp.

To często oznacza opóźnienie do 30s dla każdego żądania. Bez uprzedniego wypróbowania wtórnego, dopóki pierwotny jest wyłączony.

Chciałem rozwiązać ten problem, ponieważ nasz serwer nazw Amazon EC2 jest nieosiągalny dla wielu naszych pracowników. Powoduje to duże opóźnienia w naszych procesach, aw niektórych przypadkach nawet przestoje, ponieważ polegamy na rozwiązywaniu problemów. Chciałem mieć dobre przełączenie awaryjne na serwery nazw Google / Level3 na wypadek, gdyby Amazon znowu spadł. I wycofaj się JAK NAJSZYBCIEJ, ponieważ wtedy Amazon rozpozna nazwy hostów na adresy lokalne, tam gdzie ma to zastosowanie, rozwiązując je z mniejszym opóźnieniem, na przykład do komunikacji instancji.

Ale bez względu na przypadek użycia, istnieje potrzeba lepszego przełączania awaryjnego. Chciałem to rozwiązać. Chciałem trzymać się z daleka od demonów proxy, usług itp. Ponieważ wprowadziłoby to więcej pojedynczych punktów awarii. Chciałem wykorzystać tak archaiczną i solidną technologię, jak tylko mogłem.

Zdecydowałem się użyć crontab & bash i napisałem nsfailover.sh . Mam nadzieję że to pomoże.

Wygląda na to, że problem polega na tym, że klienci - którym może być każdy, gdziekolwiek - widzą dwa serwery DNS, a jeśli jeden zawiedzie, albo nie przełączają się awaryjnie na serwer pomocniczy, albo upłynęło dużo czasu.

Zgadzam się, że główny i dodatkowy serwer DNS powinny znajdować się w różnych obiektach jako najlepsza praktyka, ale nie wiem, jak to rozwiązałoby ten konkretny problem.

Jeśli klient będzie nalegał na zapytanie o konkretny adres IP, zignorowanie adresu IP wtórnego (lub poświęcenie mu czasu), po prostu musisz znaleźć rozwiązanie, które utrzyma ten adres IP w działaniu, nawet jeśli główny serwer jest wyłączony.

Niektóre kierunki do eksploracji to moduł równoważenia obciążenia, który może przekierowywać ruch dla jednego adresu IP do wielu serwerów w różnych centrach danych; lub może routing anycast.

Dopóki każde z twoich centrów danych znajduje się w różnych obwodach (najlepiej z różnymi dostawcami znajdującymi się daleko w chmurze), możesz skonfigurować całkiem niezawodny DNS za pomocą tylko dwóch centrów danych. Musisz tylko upewnić się, że Twój rejestrator zapełni odpowiednie rekordy kleju na dużych serwerach na niebie.

Nasza konfiguracja to:

• 2 fizyczne centra danych (osobne obwody, dostawcy usług internetowych i dostawcy usług)
• 2 fizyczne serwery zapytań w klastrze za SLB w każdym obiekcie
• 2 urządzenia równoważące obciążenie do obsługi określonych rekordów, w których chcemy zarządzać równowagą między dwoma modułami danych
• ukryty wzorzec dostępny wewnętrznie dla obu klastrów serwerów (bardzo mocno wierzę w ukryte konfiguracje wzorca dla bezpieczeństwa)

Ta konfiguracja jest na tyle skuteczna, że ​​daje nam około 5 9 przestojów w ciągu ostatnich 6 lub 7 lat, nawet przy sporadycznym przestoju serwera na aktualizacje itp. Jeśli chcesz wydać kilka dodatkowych dolarów, możesz spojrzeć na outsourcing hosting strefy z kimś takim jak ultradns ...

Jeśli chodzi o konwersację obciążenia wspomnianą przez KPWINC, jest to w 100% poprawne. Jeśli twoje najmniejsze centrum danych nie jest w stanie obsłużyć 100% obciążenia, prawdopodobnie i tak zostaniesz zwolniony, ponieważ Twoje awarie wystąpią, gdy najmniej tego chcesz =)

Biorę maksymalne obciążenie ze wszystkich routerów brzegowych, dodam je wszystkie razem, a następnie dzielę przez 0,65 ... to minimalna przepustowość, którą musimy mieć w każdym centrum danych. Wprowadziłem tę zasadę około 5 lat temu, a niektóre dokumenty, które ją uzasadniłem, zebrałem od CCO i Internetu i nigdy nas nie zawiodła. Należy jednak sprawdzać te statystyki co najmniej raz na kwartał. Nasz ruch wzrósł prawie 3-krotnie między listopadem a lutym ubiegłego roku i nie byłem na to przygotowany. Ta jasna strona polega na tym, że sytuacja pozwoliła mi wygenerować bardzo wyraźne twarde dane, które mówią, że przy 72% obciążeniu naszego obwodu WAN, zaczynamy upuszczać pakiety. Nigdy nie wymagano ode mnie dodatkowego uzasadnienia dla większej przepustowości.

Po przeczytaniu opisu uświadomiłem sobie, że nie jest jasne, czy masz na myśli autorytatywny DNS dla osób z zewnątrz, aby znaleźć twoje serwery, czy rekurencyjne serwery DNS dla lokalnych klientów. Zachowanie tych dwóch osób jest bardzo różne.

W przypadku autorytatywnych serwerów DNS „klientami” będą inne serwery DNS z pamięcią podręczną i dużą inteligencją. Będą mieli tendencję do wypróbowania wielu serwerów jednocześnie, jeśli pierwszy będzie w ogóle wolny i będą preferować ten, który daje im szybsze odpowiedzi. W takim przypadku przestój jednego centrum danych miałby bardzo niewielki wpływ na wydajność.

W przypadku rekurencyjnych serwerów DNS klienci to lokalni klienci, którzy prawdopodobnie mają serwery DNS wymienione w DHCP. Za każdym razem będą próbować swoich serwerów w podanej kolejności, z boleśnie długim (kilka sekund) limitem czasu przed przejściem z pierwszego serwera na drugi.

Jeśli główne centrum danych nie działa, nikt i tak nie będzie w stanie uzyskać dostępu do tych serwerów, ale często błędy z nich są bardziej zrozumiałe niż błędy z nieosiągalnych serwerów DNS. „nie można skontaktować się z serwerem” lub „przekroczono limit czasu połączenia” zamiast „nie można znaleźć serwera” lub „nie ma takiego serwera”. Na przykład większość serwerów SMTP będzie umieszczać pocztę w kolejce przez tydzień, jeśli zobaczy serwer w DNS, ale po prostu nie będzie w stanie go uzyskać; jeśli w ogóle nie mogą go znaleźć w DNS, mogą natychmiast odmówić nawet próby dostarczenia go do Twojej domeny.

Wtórne DNS oddzielone geograficznie i od sieci jest dobrą rzeczą. Być może będziesz mógł handlować wtórnym DNS z przyjazną firmą, a jest wielu dostawców DNS, za które możesz zapłacić za to. Niektórzy rejestratorzy mają również drugorzędny DNS jako usługę.

Tomasz,

Po przeczytaniu aktualizacji poprawiłem swój post (poprzedni post zawiera odniesienie do oprogramowania Windows).

Wydaje mi się, że twój sysadmin (s) mówi ci, że twoja dodatkowa lokalizacja nie ma niezbędnego sprzętu do obsługi PEŁNEGO OBCIĄŻENIA?

Brzmi tak, jakby powiedział: „Hej kolego, jeśli nasza podstawowa lokalizacja (w tym podstawowy DNS) ulegnie awarii, wówczas DNS jest NAJMNIEJ naszym zmartwieniem, ponieważ jeśli COLO1 nie działa, COLO2 i tak nie wytrzyma obciążenia”.

Jeśli tak jest, sugerowałbym, abyś spojrzał na swoją infrastrukturę i spróbował wymyślić lepszy projekt. Łatwiej to powiedzieć niż zrobić, zwłaszcza teraz, gdy mieszkasz w środowisku produkcyjnym.

Poza tym, w idealnym świecie, COLO1 i COLO2 byłyby w stanie stać samodzielnie i poradzić sobie z ładunkiem.

Kiedy to już było na miejscu ... DNS to tak naprawdę nic więcej jak posiadanie wystarczającej liczby serwerów DNS z wystarczająco szybkim odświeżaniem, a jeśli jedna strona zawiedzie, możesz przepisać swój DNS, aby wskazywał na serwery, które działają.

Zastosowałem tę metodę w środowiskach od małych do rozsądnych rozmiarów i działa ona świetnie. Przełączanie awaryjne zajmuje zwykle mniej niż 10 minut.

Musisz tylko upewnić się, że twoje serwery DNS są w stanie poradzić sobie z dodatkowym obciążeniem krótkim TTL (czasem życia).

Mam nadzieję że to pomoże.

Twoi administratorzy są (w większości) źli.

Serwery rekurencyjne, które odpytują Twoje wiarygodne serwery, zauważą bardzo szybko, jeśli którakolwiek strona nie będzie odpowiadać.

Tak, istnieje szansa, że ​​klienci mogą doświadczyć bardzo niewielkich opóźnień w rozpoznawaniu DNS w przypadku awarii, ale będą to tylko sekunda lub dwie, a gdy własne serwery DNS klienta dowiedzą się, że jeden z serwerów jest wyłączony, użyją pozostałe serwery wolą serwer uszkodzony.

Jeśli to konieczne (aby uspokoić administratorów systemu), nadal uruchom dwa serwery w głównym centrum danych, ale umieść co najmniej jeden na zewnątrz.

Pomocniczy serwer dns nigdy nie boli, w zależności od tego, gdzie jest hostowany, da ci mniej więcej funkcjonalność.

Jeśli Twój główny host ulegnie awarii, może go przejąć drugi, bez względu na to, czy siedzi obok niego, czy w zdalnej lokalizacji. Jeśli jednak połączenie z centrum danych zawiedzie, nadal możesz otrzymywać odpowiedzi DNS z serwera w innym centrum danych, ale i tak nie będziesz mógł uzyskać dostępu do serwerów. Użytkownicy końcowi nie będą więc mogli bezpośrednio korzystać z dodatkowego DNS w zdalnej lokalizacji.

Różni klienci reagują w inny sposób na niedostępność serwerów DNS, więc istnieje pewna prawda, że ​​klienci przekraczają limit czasu, ale nie wszyscy.

Wtórny serwer DNS w zdalnym centrum danych nadal będzie jednak w stanie rozpoznać adres IP serwera, do którego chcesz dotrzeć, abyś mógł debugować routing i zobaczyć, kiedy pojawi się ponownie. A jeśli poprawnie skonfigurowałeś dodatkowe serwery MX, nie stracisz nawet żadnej poczty.