Wiele centrów danych i ruch HTTP: DNS Round Robin to jedyny sposób na zapewnienie natychmiastowego przełączenia awaryjnego?

Wiele rekordów A wskazujących na tę samą domenę wydaje się być używanych prawie wyłącznie do implementacji DNS Round Robin jako taniej techniki równoważenia obciążenia.

Zwykle ostrzeżenie przed RR RR jest takie, że nie jest dobre dla wysokiej dostępności. Po zaniku 1 adresu IP klienci będą go używać przez kilka minut.

Moduł równoważenia obciążenia jest często sugerowany jako lepszy wybór.

Oba twierdzenia nie są całkowicie prawdziwe:

1. Gdy ruch jest wtedy HTTP, większość przeglądarek HTML jest w stanie automatycznie wypróbować następny rekord A, jeśli poprzedni jest wyłączony, bez nowego wyszukiwania DNS. Przeczytaj tutaj rozdział 3.1 i tutaj .

2. Gdy w grę wchodzi wiele centrów danych, DNS RR jest jedyną opcją dystrybucji ruchu między nimi.

Czy to prawda, że ​​przy wielu centrach danych i ruchu HTTP użycie DNS RR jest JEDYNYM sposobem zapewnienia natychmiastowego przełączenia awaryjnego, gdy jedno centrum danych ulegnie awarii?

Dzięki,

Valentino

Edytować:

• Oczywiście każde centrum danych ma lokalny moduł równoważenia obciążenia z funkcją hot spare.
• Można poświęcić koligację sesji dla natychmiastowego przełączenia awaryjnego.
• AFAIK jedynym sposobem, aby DNS sugerował centrum danych zamiast innego, jest odpowiedź z samym adresem IP (lub adresami IP) powiązanymi z tym centrum danych. Jeśli centrum danych stanie się nieosiągalne, wówczas wszystkie te adresy IP również będą nieosiągalne. Oznacza to, że nawet jeśli inteligentne przeglądarki HTML mogą natychmiast wypróbować inny rekord A, wszystkie próby zakończą się niepowodzeniem, dopóki nie wygaśnie lokalny wpis w pamięci podręcznej i nie zostanie wykonane nowe wyszukiwanie DNS, pobierając nowe działające adresy IP (zakładam, że DNS automatycznie sugeruje nowe centrum danych, gdy jedno ulegnie awarii). Tak więc „inteligentny DNS” nie może zapewnić natychmiastowego przełączenia awaryjnego.
• Z drugiej strony okrągły DNS na to pozwala. Gdy jedno centrum danych ulegnie awarii, inteligentne przeglądarki HTML (większość z nich) natychmiast wypróbowują inne zapisane w pamięci podręcznej rekordy A, przeskakując do innego (działającego) centrum danych. Tak więc, round-robin DNS nie zapewnia koligacji sesji lub najniższego RTT, ale wydaje się być jedynym sposobem na zapewnienie natychmiastowego przełączenia awaryjnego, gdy klienci są „inteligentnymi” przeglądarkami HTML.

Edycja 2:

• Niektóre osoby sugerują TCP Anycast jako ostateczne rozwiązanie. W tym artykule (rozdział 6) wyjaśniono, że przełączenie awaryjne Anycast związane jest ze zbieżnością BGP. Z tego powodu Anycast może wykonać od 15 minut do 20 sekund. Możliwe są 20 sekund w sieciach, w których topologia została do tego zoptymalizowana. Prawdopodobnie tylko operatorzy CDN mogą zapewnić tak szybkie przełączanie awaryjne.

Edycja 3: *

• Zrobiłem kilka wyszukiwań DNS i traceroutes (może jakiś ekspert może sprawdzić dwukrotnie) i:
  • Jedynym CDN używającym TCP Anycast wydaje się być CacheFly, inni operatorzy, tacy jak sieci CDN i BitGravity, używają CacheFly. Wydaje się, że ich krawędzie nie mogą być używane jako odwrotne proxy. Dlatego nie można ich użyć do natychmiastowego przełączenia awaryjnego.
  • Wydaje się, że Akamai i LimeLight używają DNS z obsługą geo. Ale! Zwracają wiele rekordów A. Z traceroutes wydaje się, że zwrócone adresy IP znajdują się w tym samym centrum danych. Zastanawiam się więc, w jaki sposób mogą zaoferować 100% SLA, gdy jedno centrum danych ulegnie awarii.

Kiedy używam terminu „DNS Round Robin”, ogólnie mam na myśli w sensie „techniki równoważenia taniego obciążenia”, jak opisuje to OP.

Ale to nie jedyny sposób, w jaki DNS może być wykorzystywany do globalnej wysokiej dostępności. Przez większość czasu osobom z innym pochodzeniem (technologicznym) trudno jest dobrze się komunikować.

Najlepszą techniką równoważenia obciążenia (jeśli pieniądze nie stanowią problemu) jest ogólnie uważana za:

1. Anycastowa globalna sieć „inteligentnych” serwerów DNS,
2. oraz zestaw globalnie rozproszonych centrów danych,
3. gdzie każdy węzeł DNS implementuje DNS Split Horizon,
4. a monitorowanie dostępności i przepływów ruchu jest w pewien sposób dostępne dla „inteligentnych” węzłów DNS,
5. aby żądanie DNS użytkownika przepływało do najbliższego serwera DNS za pośrednictwem IP Anycast ,
6. i ten serwer DNS przekazuje rekord A / zestaw rekordów A o niskim TTL dla najbliższego / najlepszego centrum danych dla tego użytkownika końcowego za pośrednictwem DNS „dzielonego” DNS z dzielonym horyzontem.

Korzystanie z anycast dla DNS jest ogólnie w porządku, ponieważ odpowiedzi DNS są bezstanowe i prawie niezwykle krótkie. Jeśli więc trasy BGP zmienią się, jest mało prawdopodobne, aby przerwać zapytanie DNS.

Anycast jest mniej odpowiedni do dłuższych i stanowych rozmów HTTP, dlatego ten system używa DNS DNS z podziałem horyzontu. Sesja HTTP między klientem a serwerem jest przechowywana w jednym centrum danych; ogólnie nie może przełączyć się do innego centrum danych bez przerwania sesji.

Jak wskazałem w „zestawie rekordów A”, to, co nazwałbym „DNS Round Robin”, może być używane razem z powyższą konfiguracją. Zwykle służy do rozkładania obciążenia ruchem na wiele wysoce dostępnych modułów równoważenia obciążenia w każdym centrum danych (w celu uzyskania lepszej redundancji, korzystania z mniejszych / tańszych modułów równoważenia obciążenia, aby nie przytłaczać buforów sieci Unix jednego serwera hosta itp.).

Czy to prawda, że ​​przy wielu centrach danych i ruchu HTTP korzystanie z RR DNS jest JEDYNYM sposobem na zapewnienie wysokiej dostępności?

Nie, to nie jest prawda, nie jeśli przez „DNS Round Robin” rozumiemy po prostu rozdawanie wielu rekordów A dla domeny. Ale prawdą jest, że inteligentne korzystanie z DNS jest kluczowym elementem każdego globalnego systemu wysokiej dostępności. Powyższe ilustruje jedną wspólną (często najlepszą) drogę.

Edycja: Wydaje mi się, że artykuł Google „Przechodzenie poza szczegółowe informacje o ścieżce w celu optymalizacji wydajności CDN” jest najnowocześniejszy w globalnym rozkładzie obciążenia dla najlepszej wydajności użytkownika końcowego.

Edycja 2: Przeczytałem artykuł „Dlaczego oparty na DNS .. GSLB .. nie działa”, z którym łączył się OP, i jest to dobry przegląd - polecam go obejrzeć. Przeczytaj to od góry.

W sekcji „Rozwiązanie problemu z pamięcią podręczną przeglądarki” zaleca odpowiedzi DNS z wieloma rekordami A wskazującymi wiele centrów danych jako jedyne możliwe rozwiązanie dla natychmiastowego przełączania awaryjnego.

W sekcji „Podlewanie” u dołu widać, że wysyłanie wielu rekordów A jest niefajne, jeśli wskazują one na centra danych na wielu kontynentach, ponieważ klient łączy się losowo, a zatem często uzyskuje „wolne” DC na innym kontynencie. Aby to działało naprawdę dobrze, potrzeba wielu centrów danych na każdym kontynencie.

To jest inne rozwiązanie niż moje kroki 1–6. Nie mogę udzielić idealnej odpowiedzi na to pytanie, myślę, że potrzebny jest specjalista DNS z takich firm jak Akamai czy Google, ponieważ wiele z tego sprowadza się do praktycznej wiedzy na temat ograniczenia obecnie wdrożonych pamięci podręcznych DNS i przeglądarek. AFAIK, moje kroki 1-6 są tym, co Akamai robi ze swoim DNSem (czy ktoś może to potwierdzić?).

Moje odczucie - wynikające z pracy jako PM na portalach przeglądarek mobilnych (telefony komórkowe) - jest takie, że różnorodność i poziom całkowitej łamliwości przeglądarek jest niesamowity. Osobiście nie ufam rozwiązaniu HA, które wymaga, aby terminal użytkownika końcowego „postępował właściwie”; dlatego uważam, że globalne natychmiastowe przełączanie awaryjne bez przerywania sesji nie jest dziś możliwe.

Myślę, że moje kroki 1-6 powyżej są najlepsze, jakie są dostępne w technologii towarowej. To rozwiązanie nie ma natychmiastowego przełączania awaryjnego.

Chciałbym, aby jeden z tych specjalistów DNS z Akamai, Google itp. Pojawił się i udowodnił, że się mylę. :-)

Twoje pytanie brzmi: „Czy DNS Round Robin jest jedynym sposobem na zapewnienie natychmiastowego przełączenia awaryjnego?”

Odpowiedź brzmi: „DNS Round Robin NIGDY nie jest właściwym sposobem na zapewnienie natychmiastowego przełączenia awaryjnego”.

(przynajmniej nie na własną rękę)

Właściwym sposobem na osiągnięcie natychmiastowego przełączenia awaryjnego jest użycie routingu BGP4, dzięki czemu obie witryny używają tych samych adresów IP. Korzystając z tego, podstawowe technologie routingu w Internecie są wykorzystywane do kierowania żądań do właściwego centrum danych, zamiast korzystania z podstawowej technologii adresowania w Internecie .

W najprostszej konfiguracji zapewnia to tylko przełączenie awaryjne. Może być również użyty do zapewnienia Anycast, z zastrzeżeniem, że protokoły oparte na TCP zawiodą w momencie przełączania, jeśli występuje jakakolwiek niestabilność w routingu.

Czy to prawda, że ​​przy wielu centrach danych i ruchu HTTP korzystanie z RR DNS jest JEDYNYM sposobem na zapewnienie wysokiej dostępności?

Oczywiście jest to fałszywe twierdzenie - wystarczy spojrzeć na Google, Akamai, Yahoo, aby zobaczyć, że nie używają odpowiedzi round-robin [*] jako jedynego rozwiązania (niektórzy mogą to wykorzystać częściowo, wraz z innymi podejściami) .)

Istnieje wiele możliwych opcji, ale tak naprawdę zależy to od innych ograniczeń, jakie masz, z usługą / aplikacją co do wyboru.

Możliwe jest stosowanie technik „round-robin” na prostym podejściu do serwera z lokalizacją i nie trzeba się martwić o awarię serwera, jeśli również zorganizuje się „przełączenie awaryjne” adresu IP. (Ale większość wybiera techniki równoważenia obciążenia, pojedynczy adres IP i przełączanie awaryjne między modułami równoważenia obciążenia).

Może potrzebujesz wszystkich żądań pojedynczej sesji, aby przejść do tych samych serwerów, ale chcesz, aby żądania były rozłożone na różne regionalne klastry serwerów? Okrągły robin nie jest do tego odpowiedni: musisz zrobić coś, co zapewni każdemu klientowi dostęp do tego samego fizycznego klastra serwerów za każdym razem (z wyjątkiem przypadków wystąpienia „wyjątków”, takich jak awaria serwera). Albo otrzymają spójny adres IP z zapytania DNS, albo zostaną skierowani do tego samego fizycznego klastra serwerów. Rozwiązania tego obejmują różne komercyjne i niekomercyjne usługi równoważenia obciążenia DNS lub (jeśli masz większą kontrolę nad siecią) reklamy sieciowe BGP. Możesz po prostu zorganizować, aby serwery nazw własnej domeny dawały zupełnie inne odpowiedzi (ale ponieważ żądania DNS mogą być wysyłane w dowolnym miejscu, wygrałeś „

[* Zamierzam użyć „round-robin”, ponieważ „RR” w terminologii DNS oznacza „rekord zasobu”.]

Bardzo ładna obserwacja vmiazzo +1 dla ciebie !! Utknąłem dokładnie tam, gdzie jesteś ... zaskoczony tym, jak te CDN wykonują swoją magię.

Poniżej zgaduję, w jaki sposób CDN uruchamia swoją sieć:

• Użyj Anycast DNS (wspomnianego przez Jespera Mortensena), aby uzyskać najbliższe centrum danych
• Prowadzą sieć lokalną, która rozciąga się na różne centra danych, co pozwala im na wykonywanie zadań typu CARP na swoich hostach w różnych centrach danych

Lub

• Używają protokołu równoważenia obciążenia bramy na swoich routerach lub protokołu Hot Standby Router Protocol (HSRP) . które dotyczą awarii centrów danych.
• Powodują, że zawierają wiele adresów IP, dlatego klient spróbuje ponownie, a zanim klient spróbuje ponownie, ścieżka routingu mogła ulec zmianie.

W tej chwili działają dla mnie następujące rozwiązania: - DNS zwraca wiele adresów IP, np .:

www -> CNAME www1 , www1 A -> 123.123.123.1
www -> CNAME www2 , www2 A -> 123.123.123.1 
www -> CNAME www3 , www3 A -> 123.123.123.1 
                    www3 A -> 8.4.56.7 <--- reverse proxy

• Ostatni punkt wejścia do zwrotnego serwera proxy w chmurze amazon, który inteligentnie przekazuje do dostępnego serwera (lub zapewnia stronę konserwacji)

Odwrotne proxy wciąż jest trafiane, ale bot tak ciężki jak główny.

Dlaczego RFC 2782 (zastosuj to samo co MX / priorytet dla usług takich jak http, imap, ...) nie jest zaimplementowany w żadnej przeglądarce? Wszystko byłoby łatwiejsze ... W Mozilli istnieje błąd, który jest otwierany od dziesięciu lat !!! bo to będzie koniec branży komercyjnego równoważenia obciążenia ??? Jestem z tego powodu bardzo rozczarowany.

2 - Można to zrobić z Anycast użyciu guagga

(Nawet jeśli istnieją pewne informacje, że Anycast jest zły w przypadku TCP, istnieje kilka dużych firm korzystających z niego, takich jak CacheFly)

Zastanawiam się, ile osób odpowiadających na te pytania prowadzi tak naprawdę dużą ogólnoświatową sieć serwerów? Google używa round robin, a moja firma używa go od lat. Może działać całkiem dobrze, z pewnymi ograniczeniami. Tak, należy go uzupełnić o inne środki.

Prawdziwym kluczem jest chęć zaakceptowania czkawki lub dwóch, jeśli serwer ulegnie awarii. Kiedy wyciągam wtyczkę z serwera, jeśli przeglądarka próbuje uzyskać dostęp do tego serwera, nastąpi opóźnienie około minuty, gdy przeglądarka dowie się, że adres IP jest wyłączony. Ale potem bardzo szybko przechodzi na inny serwer.

Działa świetnie, a ludzie, którzy twierdzą, że powoduje to wiele problemów, nie wiedzą o czym mówią. Wymaga tylko odpowiedniego projektu.

Tryb failover jest do bani. Najlepsze HA wykorzystuje cały czas wszystkie zasoby.

Pracuję z HA od 1986 roku. Przeszedłem intensywne szkolenie, aby stworzyć systemy przełączania awaryjnego i wcale nie jestem fanem przełączania awaryjnego.

Ponadto RR działa w celu rozłożenia obciążenia, nawet jeśli pasywnie niż aktywnie. Nasze dzienniki serwera wyraźnie pokazują odpowiedni procent ruchu na każdym serwerze - z uzasadnionego powodu.

Innym bardzo prostym wyborem jest użycie niskiego (jak niskie zależy od potrzeb) TTL w rekordzie DNS A lub CNAME i zaktualizowanie tego rekordu, aby wybrać, który adres IP będzie używany.

Mamy 2 usługodawców internetowych i kilka usług publicznych i z powodzeniem stosujemy tę metodę w celu zapewnienia wysokiej dostępności od 3 lat.

Jednym z kluczowych elementów prac jest to, że wielu dostawców usług internetowych ma źle skonfigurowane programy tłumaczące, które buforują rekordy przez określony czas i całkowicie ignorują ustawienia TTL. Nie powinno tak być i nie ma na to usprawiedliwienia, ale niestety z mojego doświadczenia z migracją wielu stron i usług tak się dzieje.

TCP Anycast jest w rzeczywistości bardzo stabilny i jest używany przynajmniej przez CacheFly (od 2002), Prolexic i BitGravity. Dobra prezentacja na temat Anycast TCP została wykonana na NANOG 37: http://198.108.95.21/meetings/nanog37/presentations/matt.levine.pdf

Wielokrotne rekordy A to jedyny sposób na wyeliminowanie możliwego pojedynczego punktu awarii. Każde inne rozwiązanie zmusza wszystkie przychodzące żądania do przechodzenia przez jedno urządzenie gdzieś pomiędzy serwerem a klientem.

Dlatego absolutna redundancja jest konieczna. Właśnie dlatego robi to Google lub każdy, kto chce mieć pewność ciągłej dostępności usług.

Jest całkiem oczywiste, dlaczego tak się dzieje ... wielokrotne rekordy A są jedynym sposobem przesunięcia punktu, w którym żądania są kierowane do przeglądarki klienta. Każda inna metoda będzie polegać na pojedynczym punkcie między przeglądarką klienta a serwerem, w którym może wystąpić awaria, powodując awarię usługi. Korzystając z rekordów A, jedynym pojedynczym punktem awarii od klienta do serwera staje się sam klient.

Jeśli nie masz skonfigurowanych wielu rekordów A, prosisz o przestój ...

Jednak w przypadku równoważenia obciążenia nie można oczywiście polegać na tej metodzie.