Dlaczego przełączanie awaryjne DNS nie jest zalecane?

Z czytania wynika, że ​​przełączanie awaryjne DNS nie jest zalecane tylko dlatego, że DNS nie został do tego przeznaczony. Ale jeśli masz dwa serwery WWW w różnych podsieciach hostujących nadmiarową zawartość, jakie inne metody istnieją, aby zapewnić, że cały ruch zostanie skierowany do serwera na żywo, jeśli jeden serwer ulegnie awarii?

Wydaje mi się, że przełączanie awaryjne DNS jest tutaj jedyną opcją przełączania awaryjnego, ale konsensus nie jest dobrą opcją. Jednak usługi takie jak DNSmadeeasy.com to zapewniają, więc musi być to uzasadnione. Jakieś komentarze?

Przez „przełączanie awaryjne DNS” rozumiem, że masz na myśli Round Robin DNS w połączeniu z pewnym monitorowaniem, tj. Publikowaniem wielu adresów IP dla nazwy hosta DNS i usuwaniem martwego adresu, gdy monitorowanie wykryje, że serwer nie działa. Może to być przydatne w przypadku małych witryn o mniejszym natężeniu ruchu.

Zgodnie z projektem, odpowiadając na żądanie DNS, podajesz również czas wygaśnięcia (TTL) dla udzielonej odpowiedzi. Innymi słowy, mówisz innym serwerom DNS i pamięci podręcznej, że „możesz przechowywać tę odpowiedź i używać jej przez x minut, zanim skontaktujesz się ze mną”. Wady wynikają z tego:

• W przypadku przełączania awaryjnego DNS nieznany procent użytkowników będzie buforował twoje dane DNS, pozostawiając różne ilości TTL. Do czasu wygaśnięcia TTL mogą łączyć się z martwym serwerem. Istnieją szybsze sposoby zakończenia pracy awaryjnej niż to.
• Z tego powodu jesteś skłonny ustawić dość niskie TTL, powiedzmy 5-10 minut. Ale ustawienie go wyżej daje (bardzo małą) korzyść w zakresie wydajności i może pomóc w niezawodnej propagacji DNS, nawet jeśli w sieci występuje krótki błąd. Korzystanie z przełączania awaryjnego opartego na systemie DNS jest zatem sprzeczne z wysokimi wartościami TTL, ale wysokie wartości TTL są częścią DNS i mogą być przydatne.

Bardziej powszechne metody zapewnienia dobrego czasu pracy obejmują:

• Umieszczanie serwerów razem w tej samej sieci LAN.
• Umieść sieć LAN w centrum danych z dostępnymi płaszczyznami zasilania i sieci.
• Użyj modułu równoważenia obciążenia HTTP do rozłożenia obciążenia i przełączenia awaryjnego w przypadku awarii poszczególnych serwerów.
• Uzyskaj poziom redundancji / oczekiwany czas sprawności wymagany dla zapór ogniowych, modułów równoważenia obciążenia i przełączników.
• Przygotuj strategię komunikacji w przypadku awarii pełnego centrum danych oraz sporadycznej awarii przełącznika / serwera bazy danych / innego zasobu, którego nie można łatwo dublować.

Bardzo niewielka mniejszość stron internetowych korzysta z konfiguracji wielu centrów danych, z „równoważeniem geograficznym” między centrami danych.

Tryb failover DNS z pewnością działa świetnie. Używam go od wielu lat do ręcznego przenoszenia ruchu między centrami danych lub automatycznie, gdy systemy monitorowania wykryją awarie, problemy z łącznością lub przeciążone serwery. Kiedy zobaczysz prędkość, z jaką działa, i natężenie ruchu w świecie rzeczywistym, które można łatwo zmienić - nigdy nie będziesz oglądać się za siebie. Używam Zabbix do monitorowania wszystkich moich systemów, a graficzne wykresy pokazujące, co dzieje się podczas przełączania awaryjnego DNS, budzą wszystkie moje wątpliwości. Może istnieć kilku dostawców usług internetowych, którzy ignorują TTL, a niektórzy użytkownicy nadal korzystają ze starych przeglądarek - ale gdy patrzysz na ruch z milionów odsłon stron dziennie w dwóch lokalizacjach centrum danych i dokonujesz zmiany ruchu DNS - reszta ruchu przychodzącego, który ignoruje TTL, jest śmieszna.

DNS nie został zaprojektowany do przełączania awaryjnego - ale został zaprojektowany z TTL, które działają niesamowicie na potrzeby przełączania awaryjnego w połączeniu z solidnym systemem monitorowania. Wartości TTL można ustawić bardzo krótko. Efektywnie wykorzystałem TTL 5 sekund w produkcji do błyskawicznych rozwiązań opartych na przełączaniu awaryjnym DNS. Musisz mieć serwery DNS, które są w stanie obsłużyć dodatkowe obciążenie - i nazwane go nie zmniejszy. Jednak powerdns pasuje do rachunku, gdy jest wspierany replikowanymi bazami danych mysql na redundantnych serwerach nazw. Potrzebujesz także solidnego rozproszonego systemu monitorowania, któremu możesz zaufać w przypadku automatycznej integracji trybu failover. Zabbix działa dla mnie - mogę niemal natychmiast zweryfikować awarie z wielu rozproszonych systemów Zabbix - aktualizować rekordy mysql używane przez powerdns w locie - i zapewniać niemal natychmiastowe przełączanie awaryjne podczas awarii i skoków ruchu.

Ale hej - zbudowałem firmę, która świadczy usługi przełączania awaryjnego DNS po latach pracy w dużych firmach. Więc weź moją opinię z odrobiną soli. Jeśli chcesz zobaczyć niektóre wykresy ruchu Zabbix witryn o dużej ilości podczas awarii - aby przekonać się dokładnie, jak działa dobre przełączanie awaryjne DNS - napisz do mnie.

Problem z przełączaniem awaryjnym DNS polega na tym, że w wielu przypadkach jest on zawodny. Niektórzy usługodawcy internetowi zignorują twoje TTL, nie dzieje się to od razu, nawet jeśli szanują twoje TTL, a kiedy twoja strona wróci, może to prowadzić do dziwnych sesji, gdy kończy się pamięć podręczna DNS użytkownika, i kończą do drugiego serwera.

Niestety, jest to właściwie jedyna opcja, chyba że jesteś wystarczająco duży, aby wykonać swój (zewnętrzny) routing.

Powszechnie uważa się, że w przypadku DNS RR, gdy adres IP spada, niektórzy klienci będą nadal używać uszkodzonego adresu IP przez kilka minut. Zostało to stwierdzone w niektórych poprzednich odpowiedziach na to pytanie i jest również zapisane w Wikipedii.

Tak czy siak,

http://crypto.stanford.edu/dns/dns-rebinding.pdf wyjaśnia, że ​​nie jest to prawdą w przypadku większości obecnych przeglądarek HTML. Spróbują następnego adresu IP za kilka sekund.

http://www.tenereillo.com/GSLBPageOfShame.htm wydaje się być jeszcze silniejszy:

Korzystanie z wielu rekordów A nie jest podstępem handlowym ani cechą wymyśloną przez dostawców sprzętu do równoważenia obciążenia. Z tego właśnie powodu protokół DNS został zaprojektowany z obsługą wielu rekordów A. Aplikacje takie jak przeglądarki i serwery proxy oraz serwery poczty korzystają z tej części protokołu DNS.

Być może jakiś ekspert może skomentować i wyjaśnić, dlaczego RR DNS nie jest dobry dla wysokiej dostępności.

Dzięki,

Valentino

PS: przepraszam za zepsuty link, ale jako nowy użytkownik nie mogę wysłać więcej niż 1

Przez wiele lat korzystałem z przełączania awaryjnego RR DNS na produkcyjnej witrynie o średnim natężeniu ruchu, ale o krytycznym znaczeniu dla biznesu (na dwóch obszarach geograficznych).

Działa dobrze, ale nauczyłem się co najmniej trzech subtelności.

1) Przeglądarki przejdą w tryb failover z niedziałającego adresu IP do działającego adresu IP po 30 sekundach (ostatni raz sprawdziłem), jeśli oba są uważane za aktywne w jakimkolwiek buforowanym DNS dostępnym dla twoich klientów. To w zasadzie dobra rzecz.

Niedopuszczalne jest jednak, aby „połowa” użytkowników czekała 30 sekund, więc prawdopodobnie będziesz chciał zaktualizować swoje rekordy TTL tak, aby obejmowały kilka minut, a nie kilka dni lub tygodni, aby w przypadku awarii możesz szybko usunąć wyłączony serwer z twojego DNS. Inni nawiązywali do tego w swoich odpowiedziach.

2) Jeśli jeden z twoich serwerów nazw (lub jeden z twoich dwóch obszarów geograficznych całkowicie) ulegnie awarii, co służy Twojej domenie typu round-robin, a jeśli podstawowy z nich ulegnie awarii, niejasno przypominam sobie, że możesz napotkać inne problemy, próbując je usunąć spadł serwer nazw z DNS, jeśli nie ustawiłeś również TTL / wygasania SOA dla serwera nazw na wystarczająco niską wartość. Mogłem pomylić tutaj szczegóły techniczne, ale istnieje więcej niż jedno ustawienie TTL, które musisz zrobić, aby naprawdę bronić się przed pojedynczymi punktami awarii.

3) Jeśli publikujesz sieciowe interfejsy API, usługi REST itp., Zwykle nie są one wywoływane przez przeglądarki, a zatem moim zdaniem przełączanie awaryjne DNS zaczyna wykazywać prawdziwe wady. Być może dlatego niektórzy mówią, jak to określasz, „nie jest to zalecane”. Oto dlaczego tak mówię. Po pierwsze, aplikacje korzystające z tych adresów URL zazwyczaj nie są przeglądarkami, więc brakuje im 30-sekundowych właściwości / logiki przełączania awaryjnego typowych przeglądarek. Po drugie, to, czy wywoływany jest drugi wpis DNS, czy nawet DNS jest ponownie odpytywany, zależy w dużej mierze od szczegółów programowania niskopoziomowego bibliotek sieciowych w językach programowania używanych przez tych klientów API / REST, a także dokładnie, jak są wywoływani przez aplikacja klienta API / REST. (Pod pokrywą, czy biblioteka wywołuje get_addr, a kiedy? Jeśli gniazda zawieszają się lub zamykają, czy aplikacja ponownie otwiera nowe gniazda? Czy istnieje jakaś logika przekroczenia limitu czasu? Itd. Itp.)

Jest tani, dobrze przetestowany i „przeważnie działa”. Tak jak w przypadku większości rzeczy, przebieg może się różnić.

Istnieje grupa ludzi, którzy używają nas (Dyn) do przełączania awaryjnego. Jest to ten sam powód, dla którego strony mogą albo zrobić stronę statusu, gdy mają przestoje (pomyśl o takich rzeczach jak Whale Fail Twittera) ... lub po prostu przekierować ruch w oparciu o TTL. Niektórzy mogą myśleć, że DNS Failover to getto ... ale poważnie zaprojektowaliśmy naszą sieć z przełączaniem awaryjnym od samego początku ... aby działała równie dobrze jak sprzęt. Nie jestem pewien, jak DME to robi, ale mamy 3 z 17 naszych najbliższych anycastowanych punktów Po, które monitorują twój serwer z najbliższej lokalizacji. Kiedy wykryje, że z dwóch z trzech nie działa, po prostu przekierowujemy ruch do drugiego adresu IP. Jedyny czas przestoju dotyczy tych, których wymagano przez pozostałą część tego przedziału czasu TTL.

Niektórzy ludzie lubią korzystać z obu serwerów jednocześnie ... iw takim przypadku mogą zrobić coś takiego jak równoważenie obciążenia za pomocą okrągłego robina ... lub równoważenie obciążenia na podstawie położenia geograficznego. Dla tych, którzy faktycznie dbają o wydajność ... nasz menedżer ruchu w czasie rzeczywistym będzie monitorował każdy serwer ... a jeśli jest wolniejszy ... przekieruj ruch na najszybszy na podstawie adresów IP, które łączysz w nazwach hostów. Znowu ... działa to w oparciu o wartości wprowadzone w naszym interfejsie użytkownika / interfejsie API / portalu.

Chyba mam na myśli… celowo zaprojektowaliśmy przełączanie awaryjne dns. Chociaż DNS nie był przeznaczony do przełączania awaryjnego, gdy został pierwotnie utworzony ... nasza sieć DNS została zaprojektowana do wdrożenia od samego początku. Zwykle może być tak samo skuteczny jak sprzęt .. bez amortyzacji lub kosztów sprzętu. Mam nadzieję, że to nie sprawia, że ​​czuję się winny, że podłączę Dyn ... jest wiele innych firm, które to robią ... Mówię tylko z perspektywy naszego zespołu. Mam nadzieję że to pomoże...

Inną opcją byłoby skonfigurowanie serwera nazw 1 w lokalizacji A i serwera nazw 2 w lokalizacji B, ale skonfigurowanie każdego z nich, aby wszystkie rekordy A dotyczące ruchu NS1 wskazywały na adresy IP dla lokalizacji A, a na NS2 wszystkie rekordy A wskazywały na adresy IP dla lokalizacja B. Następnie ustaw swoje TTL na bardzo niską liczbę i upewnij się, że rekord domeny u rejestratora został skonfigurowany dla NS1 i NS2. W ten sposób automatycznie załaduje saldo i przejdzie w tryb failover w przypadku awarii jednego serwera lub jednego łącza do lokalizacji.

Zastosowałem to podejście w nieco inny sposób. Mam jedną lokalizację z dwoma dostawcami usług internetowych i używam tej metody do kierowania ruchem przez każde łącze. Teraz może to wymagać nieco więcej konserwacji, niż jesteś w stanie zrobić ... ale udało mi się stworzyć proste oprogramowanie, które automatycznie pobiera rekordy NS1, aktualizuje adresy IP rekordów dla wybranych stref i przesuwa te strefy do NS2.

Alternatywą jest oparty na BGP system przełączania awaryjnego. Konfiguracja nie jest prosta, ale powinna być kuloodporna. Skonfiguruj witrynę A w jednej lokalizacji, witrynę B w drugiej, wszystkie z lokalnymi adresami IP, a następnie uzyskaj przenośne IP klasy C lub inny blok adresów IP i skonfiguruj przekierowanie z przenośnych adresów IP na lokalne adresy IP.

Istnieją pułapki, ale jest to lepsze niż rozwiązania oparte na DNS, jeśli potrzebujesz tego poziomu kontroli.

Jedną z opcji przełączania awaryjnego wielu centrów danych jest szkolenie użytkowników. Reklamujemy naszym klientom, że udostępniamy wiele serwerów w wielu miastach oraz w naszych e-mailach rejestracyjnych i zawierają one linki bezpośrednio do każdego „serwera”, aby użytkownicy wiedzieli, jeśli jeden serwer nie działa, mogą użyć łącza do drugiego serwera.

To całkowicie omija problem przełączania awaryjnego DNS, po prostu utrzymując wiele nazw domen. Użytkownicy, którzy wejdą na www.firma.com lub company.com i zalogują się, zostaną przekierowani na server1.company.com lub server2.company.com i będą mieli do wyboru jedną z tych zakładek, jeśli zauważą, że uzyskują lepszą wydajność przy użyciu jednego lub drugiego . W przypadku awarii użytkownicy są szkoleni, aby przejść do drugiego serwera.

Używam równoważenia witryn i przełączania awaryjnego w oparciu o DNS przez ostatnie dziesięć lat i są pewne problemy, ale można je złagodzić. BGP, chociaż pod pewnymi względami lepszy, nie jest rozwiązaniem w 100% o zwiększonej złożoności, prawdopodobnie dodatkowych kosztach sprzętu, czasach konwergencji itp.

Przekonałem się, że łączenie lokalnego (opartego na LAN) równoważenia obciążenia, GSLB i hostingu stref w chmurze działa całkiem dobrze, aby zamknąć niektóre problemy normalnie związane z równoważeniem obciążenia DNS.

Wszystkie te odpowiedzi mają pewną ważność, ale myślę, że to naprawdę zależy od tego, co robisz i jaki masz budżet. Tutaj w CloudfloorDNS duży procent naszej działalności to DNS, który oferuje nie tylko szybki DNS, ale także niskie opcje TTL i przełączanie awaryjne DNS. Nie bylibyśmy w biznesie, gdyby to nie działało i działało dobrze.

Jeśli jesteś międzynarodową korporacją z nieograniczonym budżetem czasu pracy, tak, sprzętowe usługi równoważenia obciążenia GSLB i centra danych poziomu 1 są świetne, ale Twój DNS nadal musi być szybki i solidny. Jak wielu z was wie, DNS jest krytycznym aspektem każdej infrastruktury, poza samą nazwą domeny, jest usługą na najniższym poziomie, na której jeździ każda inna część twojej obecności online. Począwszy od solidnego rejestratora domen, DNS jest tak samo ważny, jak niedopuszczenie do wygaśnięcia domeny. DNS przestaje działać, oznacza to, że cały aspekt online Twojej organizacji również nie działa!

Podczas korzystania z przełączania awaryjnego DNS inne krytyczne aspekty to monitorowanie serwera (zawsze wiele lokalizacji geograficznych do sprawdzenia i zawsze wiele (co najmniej 3) powinno sprawdzać, aby uniknąć fałszywych alarmów) i prawidłowe zarządzanie rekordami DNS wykrywane jest niepowodzenie. Niski poziom TTL i niektóre opcje przełączania awaryjnego mogą sprawić, że proces ten będzie przebiegał bezproblemowo, a jeśli jesteś administratorem sys, przebije się do przebudzenia w środku nocy.

Ogólnie rzecz biorąc, tryb failover DNS naprawdę działa i może być bardzo przystępny cenowo. W większości przypadków od nas lub większości zarządzanych dostawców DNS otrzymasz Anycast DNS wraz z monitorowaniem serwera i przełączaniem awaryjnym za ułamek kosztów opcji sprzętowych.

Tak więc prawdziwa odpowiedź brzmi: tak, działa, ale czy jest przeznaczona dla wszystkich i każdego budżetu? Może nie, ale dopóki go nie wypróbujesz i nie wykonasz testów, ciężko go zignorować, jeśli jesteś małym lub średnim biznesem z ograniczonym budżetem na IT, który chce jak najlepszego czasu pracy bez przestojów.

„i dlaczego ryzykujesz używanie go w większości środowisk produkcyjnych (chociaż jest to lepsze niż nic)”.

W rzeczywistości „lepiej niż nic” lepiej wyraża się jako „jedyna opcja”, gdy obecność jest zróżnicowana geograficznie. Sprzętowe moduły równoważące obciążenia doskonale nadają się do pojedynczego punktu obecności, ale pojedynczy punkt obecności jest również pojedynczym punktem awarii.

Istnieje wiele witryn z dużymi dolarami, które z dobrym skutkiem wykorzystują manipulacje ruchem oparte na DNS. Są to typy witryn, które co godzinę wiedzą, czy sprzedaż jest wyłączona. Wydaje się, że są oni ostatnimi, którzy są gotowi „zaryzykować użycie go w większości środowisk produkcyjnych”. Rzeczywiście dokładnie sprawdzili swoje opcje, wybrali technologię i dobrze za nią zapłacili. Jeśli uznają, że coś jest lepsze, odejdą w mgnieniu oka. Fakt, że nadal decydują się na pozostanie, mówi wiele o rzeczywistym użyciu.

Przełączanie awaryjne oparte na usłudze Dns wiąże się z pewnym opóźnieniem. Nie da się tego obejść. Ale nadal jest to jedyne realne podejście do zarządzania przełączaniem awaryjnym w scenariuszu z wieloma popami. Jako jedyna opcja jest czymś więcej niż „lepszym niż niczym”.

Dzisiaj dobre globalne moduły równoważące obciążenie, które działają przy użyciu tej techniki i działają całkiem dobrze. Sprawdź na przykład Azure Traffic Manager https://azure.microsoft.com/en-us/services/traffic-manager/

Jeśli chcesz dowiedzieć się więcej, przeczytaj uwagi dotyczące aplikacji pod adresem

http://edgedirector.com

Obejmują one: przełączanie awaryjne, globalne równoważenie obciążenia oraz szereg powiązanych kwestii.

Jeśli architektura zaplecza na to pozwala, lepszą opcją jest globalne równoważenie obciążenia z opcją przełączania awaryjnego. W ten sposób wszystkie serwery i przepustowość są w grze tak dużo, jak to możliwe. Zamiast wstawiania dodatkowego dostępnego serwera w przypadku awarii, ta konfiguracja wycofuje uszkodzony serwer z usługi do czasu jego odzyskania.

Krótka odpowiedź: działa, ale musisz zrozumieć ograniczenia.

Uważam, że pomysł przełączania awaryjnego był przeznaczony do tworzenia klastrów, ale ponieważ może on również działać w trybie solo, nadal umożliwia pracę w trybie jeden do jednego.

Polecam A albo wybranie centrum danych, które jest wieloadresowe na swoim własnym AS lub B, hostowanie serwerów nazw w chmurze publicznej. Jest NAPRAWDĘ mało prawdopodobne, aby upadł EC2, HP lub IBM. Tylko myśl. Podczas gdy DNS działa jako poprawka, w tym przypadku jest to po prostu naprawa złego projektu w fundamencie sieci.

Inną opcją, w zależności od środowiska, jest użycie kombinacji z IPSLA, PBR i FHRP w celu spełnienia potrzeb związanych z redundancją.