Dlaczego przełączanie awaryjne DNS nie jest zalecane?

170

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?

Lin
źródło
2
Spójrz tutaj , aby uzyskać zaktualizowany dyskusji na ten temat. Przełączanie awaryjne jest teraz wykonywane automatycznie przez nowoczesne przeglądarki.
GetFree

Odpowiedzi:

94

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.

Jesper Mortensen
źródło
39
Myślę, że szczególnie próbuje zarządzać przełączaniem awaryjnym między dwoma różnymi centrami danych (zwróć uwagę na komentarze dotyczące różnych podsieci), więc umieszczenie serwerów razem / użycie równoważenia obciążenia / dodatkowej redundancji nie pomoże mu (oprócz redundantnych centrów danych. Ale ty wciąż muszę powiedzieć internetowi, żeby poszedł do tego, który wciąż działa).
Cian
10
Dodaj anycast do konfiguracji wielu centrów danych, aby stała się odporna na awarie centrów danych.
petrus
1
Wpis wikipedia na anycast ( en.wikipedia.org/wiki/Anycast ) omawia to w odniesieniu do odporności serwera root DNS.
dunxd
4
Ataki DDoS są tak powszechne, że całe centra danych można przenieść w tryb offline (zdarzyło się Linode London i ich innym centrom danych w grudniu 2015 r.). Dlatego korzystanie z tego samego dostawcy w tym samym centrum danych nie jest zalecane. Dlatego też wiele centrów danych z różnymi dostawcami byłoby dobrą strategią, która przywraca nas do trybu failover DNS, chyba że istnieje lepsza alternatywa.
Laurence Cope
2
Czy nie jest konieczne przełączanie awaryjne, ponieważ musisz utrzymywać witrynę w działaniu, gdy urządzenie jest wyłączone / uszkodzone? Jaki będzie pożytek z przełączania awaryjnego, gdy będzie w tej samej sieci, współużytkując te same urządzenia, np. Routery?
user2128576
47

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.

Scott McDonald
źródło
Odpowiedź Ciana serverfault.com/a/60562/87017 bezpośrednio zaprzecza twojej ..... więc kto ma rację?
Pacerier
1
Z mojego doświadczenia wynika, że ​​krótkie TTL NIE DZIAŁAJĄ w Internecie. Być może korzystasz z serwerów DNS, które szanują RFC, ale istnieje wiele serwerów, które tego nie robią. Proszę nie zakładać, że jest to argument przeciwko Round Robin DNS - patrz także odpowiedź vmiazzo poniżej - Uruchomiłem zajęte strony przy użyciu RR DNS i przetestowałem - działa. Jedyne problemy, jakie napotkałem, były z niektórymi klientami opartymi na Javie (nie przeglądarkami), które nawet nie próbowały połączyć się ponownie w przypadku awarii, nie mówiąc już o cyklicznym wyświetlaniu listy hostów na RST
symcbean
9
Założę się, że ludzie, którzy twierdzą, że awaryjne monitorowanie DNS jest świetne, a ludzie, którzy twierdzą, że jest do bani, mają podobne doświadczenia, ale mają inne oczekiwania. Przełączanie awaryjne DNS NIE jest płynne, ale NIE pozwala na znaczne przestoje. Jeśli potrzebujesz całkowicie płynnego dostępu (nigdy nie stracisz ani jednego żądania, nawet podczas awarii serwera), prawdopodobnie potrzebujesz znacznie bardziej wyrafinowanej - i kosztownej - architektury. Nie jest to wymagane w wielu aplikacjach.
Tom Wilson,
32

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.

Cian
źródło
1
+1 powolny i zawodny
Chris S,
Zobacz także serverfault.com/q/315199/87017
Pacerier
19

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

Valentino Miazzo
źródło
1
Wiele rekordów A jest zaprojektowanych, ale do równoważenia obciążenia, a nie do przełączania awaryjnego. Klienci będą buforować wyniki i kontynuować korzystanie z pełnej puli (w tym zepsutego adresu IP) przez kilka minut po zmianie rekordu.
Cian
7
Czy to, co jest zapisane na crypto.stanford.edu/dns/dns-rebinding.pdf rozdział 3.1, jest fałszywe? << Internet Explorer 7 przypina powiązania DNS przez 30 minut.1 Niestety, jeśli domena atakującego ma wiele rekordów A, a bieżący serwer stanie się niedostępny, przeglądarka spróbuje użyć innego adresu IP w ciągu jednej sekundy. >>
Valentino Miazzo
2
Przeniosłem tutaj moje pytanie tutaj serverfault.com/questions/69870/…
Valentino Miazzo
12

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ć.

GregW
źródło
biblioteka, która nie próbuje ponawiać innych RR dla adresu, jest uszkodzona. wskaż programistom strony podręcznika dla getaddrinfo () itp.
Jasen
Równie ważne jest to, że przeglądarek takich jak Chrome i Firefox nie honorować TTLS, lecz uczynić z nich co najmniej 1 minutę, nawet jeśli podasz kilka sekund ( Firefox referencyjnych , referencyjne Chrome i następne ). Myślę, że to źle, ponieważ buforowanie przez czas dłuższy niż TTL jest niezgodne ze specyfikacją.
nh2
9

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...

Ryan
źródło
Co rozumiesz przez „może być tak samo skuteczny jak sprzęt”? Jakiego rodzaju sprzęt obsługuje routing DNS?
mpen
@ Ryan, co masz na myśli mówiąc „getto”?
Pacerier
Dla tego słowa słownik miejski nie zawiera żadnych definicji z pozytywną konotacją, mógłbym założyć, że „rozwiązanie żebraka” może być odpowiednim tłumaczeniem.
Jasen,
5

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.

Amal
źródło
Czy serwery nazw nie propagują zbyt wiele? Jeśli zmienisz rekord DNS z niskim TTL, będzie on działał natychmiast, ale kiedy zmienisz serwer nazw, rozpowszechnienie zajmie 24 horus lub więcej, dlatego nie rozumiem, jak mogłoby to być rozwiązanie przełączania awaryjnego.
Marco Demaio
4

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.

Kyle Hodgson
źródło
4
Rozwiązania oparte na BGP nie są jednak dostępne dla wszystkich. I są o wiele łatwiejsze do złamania w szczególnie okropny sposób niż DNS. Huśtawki i ronda, jak sądzę.
Cian
3

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.

thelsdj
źródło
2
Szkolenie użytkowników w ten sposób ... Czy to nie zwiększa ich podatności na ataki typu phishing?
Pacerier
2

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.

Greeblesnort
źródło
2

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.

Eric - CloudfloorDNS
źródło
1

„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”.

dozownik
źródło
0

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.


źródło
0

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.

Seth
źródło
-1

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ą.

Matt Bram
źródło
5
„NAPRAWDĘ mało prawdopodobne jest, że EC2, HP lub IBM upadną” - Ta „nieprawdopodobna” rzecz ugryzła nas wiele razy. Wszystko zawodzi.
talonx
3
Gdyby to było tak „mało prawdopodobne”, ludzie nie przychodziliby tutaj z prośbą o systemy przełączania awaryjnego.
Marco Demaio