Vraag Meerdere datacenters en HTTP-verkeer: DNS Round Robin is de ENIGE manier om onmiddellijke failover te verzekeren?


Meerdere A-records die naar hetzelfde domein verwijzen, lijken bijna uitsluitend te worden gebruikt om DNS Round Robin te implementeren als een goedkope techniek voor load balancing.

De gebruikelijke waarschuwing tegen DNS RR is dat het niet goed is voor hoge beschikbaarheid. Wanneer 1 IP down gaat, zullen clients het blijven gebruiken voor minuten.

Een load-balancer wordt vaak voorgesteld als een betere keuze.

Beide beweringen zijn niet helemaal waar:

  1. Wanneer het verkeer HTTP is, kunnen de meeste HTML-browsers automatisch de volgende A-record proberen als de vorige niet beschikbaar is, zonder een nieuwe DNS-look-up. Lezen hier hoofdstuk 3.1 en hier.

  2. Wanneer er meerdere datacenters bij betrokken zijn, is DNS RR de enige optie om verkeer over hen te distribueren.

Dus, is het waar dat, met meerdere datacenters en HTTP-verkeer, het gebruik van DNS RR de ENIGE manier is om onmiddellijke failover te verzekeren wanneer een datacenter daalt?

Bedankt,

Valentino

Bewerk:

  • Natuurlijk heeft elk datacenter een lokale Load Balancer met hot spare.
  • Het is OK om sessieafhankelijkheid te offeren voor een instant fail-over.
  • AFAIK de enige manier voor een DNS om een ​​datacenter te suggereren in plaats van een ander is om te antwoorden met alleen de IP (of IP's) die aan dat datacenter zijn gekoppeld. Als het datacenter onbereikbaar wordt, zijn al die IP's ook onbereikbaar. Dit betekent dat, zelfs als slimme HTML-browsers onmiddellijk een ander A-record kunnen proberen, alle pogingen zullen mislukken totdat het lokale cachevermelding verloopt en een nieuwe DNS-lookup wordt uitgevoerd, waarbij de nieuwe werkende IP's worden opgehaald (ik neem aan dat DNS automatisch een suggestie doet voor een nieuwe datacenter wanneer een mislukt). Dus, "slimme DNS" kan geen directe fail-over garanderen.
  • Omgekeerd staat een DNS round-robin dit toe. Wanneer een datacenter faalt, proberen de slimme HTML-browsers (de meeste van hen) onmiddellijk de andere in de cache opgeslagen A-records naar een ander (werkend) datacenter te springen. DNS-round-robin garandeert dus geen sessieafhankelijkheid of de laagste RTT, maar lijkt de enige manier te zijn om directe failover te garanderen wanneer de clients 'slimme' HTML-browsers zijn.

Bewerk 2:

  • Sommige mensen suggereren TCP Anycast als een definitieve oplossing. In deze paper (hoofdstuk 6) wordt uitgelegd dat de fail-over van Anycast gerelateerd is aan de BGP-convergentie. Om deze reden kan Anycast van 15 minuten tot 20 seconden gebruiken om te voltooien. 20 seconden zijn mogelijk op netwerken waar de topologie hiervoor is geoptimaliseerd. Waarschijnlijk kunnen CDN-operatoren zulke snelle fail-overs toestaan.

Bewerk 3: *

  • Ik heb wat DNS-look-ups en traceroutes gedaan (misschien kan een expert dit dubbel controleren) en:
    • De enige CDN die TCP Anycast gebruikt lijkt CacheFly te zijn, andere operatoren zoals CDN-netwerken en BitGravity gebruiken CacheFly. Het lijkt erop dat hun randen niet kunnen worden gebruikt als tegenproxies. Daarom kunnen ze niet worden gebruikt om onmiddellijke failover te verlenen.
    • Akamai en LimeLight lijken geo-aware DNS te gebruiken. Maar! Ze retourneren meerdere A-records. Van traceroutes lijkt het erop dat de geretourneerde IP's zich in hetzelfde datacenter bevinden. Dus ik ben verbaasd over hoe ze een 100% SLA kunnen aanbieden wanneer een datacenter daalt.

76
2017-09-30 08:44


oorsprong


Met hoge beschikbaarheid heb ik bijna onmiddellijke fail-over geïmpliceerd. De klant moet geen enkel probleem opmerken, zelfs als een datacenter daalt. Ik heb de vraag verfijnd. - Valentino Miazzo
MaxCDN gebruikt anycast TCP en de randen ervan kunnen worden gebruikt in de caching proxy-modus ("origin fetch" in terminologie van de CDN-industrie). - rmalayter
@vmiazzo, je pdf-link is weg ... Bedoel je 15 minuten of 20 seconden tot 15 minuten? - Pacerier


antwoorden:


Wanneer ik de term "DNS Round Robin" gebruik, bedoel ik meestal in de zin van de "goedkope load balancing-techniek", zoals OP het beschrijft.

Maar dat is niet de enige manier waarop DNS kan worden gebruikt voor wereldwijde hoge beschikbaarheid. Meestal is het gewoon moeilijk voor mensen met verschillende (technologie) achtergronden om goed te communiceren.

De beste load balancing-techniek (als geld geen probleem is) wordt algemeen beschouwd als:

  1. Een Anycast'ed wereldwijd netwerk van 'intelligente' DNS-servers,
  2. en een reeks wereldwijd verspreide datacenters,
  3. waarbij elk DNS-knooppunt Split Horizon DNS implementeert,
  4. en monitoring van beschikbaarheid en verkeersstromen zijn op de een of andere manier beschikbaar voor de 'intelligente' DNS-knooppunten,
  5. zodat de DNS-verzoek van gebruiker gaat naar IP-adres via Anycast naar de dichtstbijzijnde DNS-server,
  6. en dit DNS-server deelt een TTL A-record / set van A-records uit voor de dichtstbijzijnde / beste datacenter voor deze eindgebruiker via 'intelligente' split horizon DNS.

Het gebruik van anycast voor DNS is over het algemeen prima, omdat DNS-reacties stateloos en bijna extreem kort zijn. Dus als de BGP-routes veranderen, is het hoogst onwaarschijnlijk dat een DNS-query wordt onderbroken.

Anycast is minder geschikt voor de langere en stateful HTTP-conversaties, dus dit systeem maakt gebruik van split horizon DNS. Een HTTP-sessie tussen een client en een server wordt bijgehouden in een datacenter; het kan over het algemeen niet overgaan naar een ander datacenter zonder de sessie te verbreken.

Zoals ik al aangaf met "set A Records" kan wat ik 'DNS Round Robin' zou noemen, worden gebruikt in combinatie met de bovenstaande opzet. Het wordt meestal gebruikt om de verkeersbelasting te spreiden over meerdere zeer beschikbare load balancers in elk datacenter (zodat u betere redundantie kunt krijgen, kleinere / goedkopere load balancers kunt gebruiken, de Unix-netwerkbuffers van een enkele hostserver niet kunt overbelasten, enz.).

Dus, is het waar dat, met meerdere datacenters   en HTTP-verkeer, het gebruik van DNS RR is de ENIGE   manier om hoge beschikbaarheid te verzekeren?

Nee, het is niet waar, niet als we met 'DNS Round Robin' gewoon meerdere A-records voor een domein willen delen. Maar het is waar dat slim gebruik van DNS een kritieke component is in elk wereldwijd systeem met hoge beschikbaarheid. Het bovenstaande illustreert een gemeenschappelijke (vaak de beste) manier om te gaan.

Bewerk: Het Google-document "Verder gaan dan end-to-end padinformatie om de CDN-prestaties te optimaliseren" lijkt mij state-of-the-art in wereldwijde verdeling van de belasting voor de beste prestaties van eindgebruikers.

Bewerk 2: Ik heb het artikel gelezen "Waarom DNS Based ... GSLB .. Does not Work" waar OP gekoppeld is, en het is een goed overzicht - ik raad aan ernaar te kijken. Lees het vanaf de top.

In de sectie "De oplossing voor het probleem met browsercaches" pleit het voor DNS-antwoorden met meerdere A-records die naar meerdere datacenters verwijzen als de enige mogelijke oplossing voor onmiddellijke fail-over.

In de sectie "Watering it down" aan de onderkant, breidt het uit naar voor de hand liggend, dat het verzenden van meerdere A-records niet cool is als ze naar datacenters op meerdere continenten wijzen, omdat de client willekeurig verbinding maakt en dus vrij vaak een 'trage' verbinding krijgt DC op een ander continent. Om dit echt goed te laten werken, zijn meerdere datacenters op elk continent nodig.

Dit is een andere oplossing dan mijn stappen 1 - 6. Ik kan hier geen perfect antwoord op geven, ik denk dat een DNS-specialist van bijvoorbeeld Akamai of Google nodig is, want veel hiervan komt neer op praktische knowhow over de beperkingen van geïmplementeerde DNS-caches en browsers vandaag. AFAIK, mijn stappen 1-6 zijn wat Akamai doet met hun DNS (kan iemand dit bevestigen?).

Mijn gevoel - afkomstig van het werken als PM op mobiele browserportals (mobiele telefoons) - is dat de diversiteit en het niveau van totale gebrokenheid van de browsers die er zijn, is ongelooflijk. Persoonlijk zou ik geen HA-oplossing vertrouwen die vereist dat de eindgebruikersterminal 'het goede doet'; dus geloof ik dat mondiaal instantaan falen na het breken van een sessie vandaag niet haalbaar is.

Ik denk dat mijn stappen 1-6 hierboven de beste zijn die beschikbaar zijn met commodity-technologie. Deze oplossing heeft geen onmiddellijke fail-over.

Ik zou dol zijn op een van die DNS-specialisten van Akamai, Google enz. Om me te bewijzen dat ik ongelijk had. :-)


34
2017-09-30 10:56



Ik heb meer uitleg in de vraag toegevoegd. Als ik uw "best load balancing-techniek" (punt 6) begrijp, adverteert deze alleen de A-records van het 'beste' datacenter. Zoals ik in de vraag probeerde uit te leggen, staat dit geen onmiddellijke fail-over van de client toe. - Valentino Miazzo
@vmiazzo: Ja, je hebt me goed begrepen. Ik voeg een 2e bewerking toe aan mijn post om dit te verduidelijken - maar in principe denk ik dat het moment faalt dat je zoekt onpraktisch / onmogelijk is. - Jesper Mortensen
Wat ik interessant vind, is dat niemand heeft voorgesteld om de twee benaderingen samen te combineren. Hoewel het niet ideaal is, zou het zorgen voor een redelijke snelheid als de dingen correct functioneren en extra veerkracht als dat niet het geval is. De boete zou een grote vertraging betekenen omdat klanten overstapten van het ene op anycast-gebaseerde DNS-adres naar het andere. - Avery Payne
@JesperMortensen, Wanneer u 'intelligente' DNS zegt, bedoelt u split-horizon DNS? Of bedoel je iets anders (beslissen op basis van factoren voorbij bron IP)? - Pacerier


Uw vraag is: "Is DNS Round Robin de ENIGE manier om een ​​onmiddellijke fail-over te garanderen?"

Het antwoord is: "DNS Round Robin is NOOIT de juiste manier om een ​​onmiddellijke fail-over te verzekeren ".

(althans niet op zichzelf)

De juiste manier om instant fail-over te bereiken, is om BGP4-routering te gebruiken, zodat beide sites dezelfde IP-adressen gebruiken. Dit gebruikt de kern van het internet routing technologieën zijn gewend om route de verzoeken aan het juiste datacenter, in plaats van de kern van het internet te gebruiken aanpakken technologie.

In de eenvoudigste configuratie dit enkel en alleen biedt fail-over. Het kan ook worden gebruikt om Anycast te bieden, met het voorbehoud dat op TCP gebaseerde protocollen zullen mislukken op het moment van omschakeling als er enige instabiliteit in de routering is.


18
2017-09-30 16:04



Toegevoegd wat info over Anycast failover over de vraag. In principe is TCP Anycast ook geen perfecte oplossing. - Valentino Miazzo
@vmiazzo re TCP Anycast - inderdaad, vandaar de opmerking in mijn antwoord over routeringsinstabiliteit en hoe dit TCP beïnvloedt. - Alnitak


Dus, is het waar dat, met meerdere datacenters en HTTP-verkeer, het gebruik van DNS RR de ENIGE manier is om hoge beschikbaarheid te verzekeren?

Het is duidelijk een valse claim - je hoeft alleen naar Google te kijken, Akamai, Yahoo, om te zien dat ze round-robin [*] - antwoorden niet als hun enige oplossing gebruiken (sommigen gebruiken het gedeeltelijk, samen met andere benaderingen) .)

Er zijn veel mogelijke opties, maar het hangt echt af van de andere beperkingen die u hebt, met uw service / applicatie die u kiest.

Het is mogelijk om round-robin-technieken te gebruiken op een eenvoudige, gelijktijdige serverbenadering, en u hoeft zich geen zorgen te maken over serverfouten, als u ook zorgt voor de 'fail-over' van het IP-adres. (Maar de meeste kiezen voor load-balancing-technieken, een enkel IP-adres en fail-over tussen load-balancers.)

Misschien moet u alle verzoeken voor één sessie naar dezelfde servers laten gaan, maar wilt u dat aanvragen over verschillende, regionale serverclusters worden verspreid? Round Robin is hiervoor niet geschikt: u moet iets doen dat ervoor zorgt dat een bepaalde client steeds dezelfde fysieke servercluster gebruikt (behalve wanneer 'uitzonderingen' voorkomen, zoals serverfouten). Of ze ontvangen een consistent IP-adres van een DNS-query of worden naar hetzelfde fysieke servercluster gerouteerd. Oplossingen hiervoor zijn verschillende commerciële en niet-commerciële DNS "load balancers", of (als u meer controle heeft over uw netwerk) BGP-netwerkadvertenties. Je zou eenvoudigweg kunnen regelen dat de nameservers van je eigen domein heel verschillende antwoorden geven (maar aangezien DNS-verzoeken overal naartoe kunnen worden verzonden, bereik je geen loc affiniteit met die aanpak.)

[* Ik ga "round-robin" gebruiken, omdat 'RR' in DNS-terminologie 'bronrecord' betekent.]


6
2017-09-30 09:47



Ik heb meer uitleg toegevoegd in het antwoord. Uw suggestie om DNS "loadbalancers" IMHO te gebruiken, staat geen directe fail-over toe. Over de BGP, verwijst u naar een Anycast TCP-oplossing? - Valentino Miazzo
Ik suggereer geen specifieke oplossing boven een andere - ik zeg dat je de juiste oplossing moet kiezen voor je probleem (wat je in je vraag niet echt hebt genoemd) en je beperkingen (idem.) DNS round-robin doet geen instant fail-over meer bieden dan DNS LB, omdat browsers er niet zeker van zijn dat ze "het goede doen" (vooral omdat het "juiste ding" niet strikt gedefinieerd of voorgeschreven is.) Ik geloof niet dat er genoeg "smart" is HTML-browsers ", zelfs nu - Ik ben het met Jesper eens dat ze te gevarieerd zijn in hun gedrag om er helemaal op te kunnen vertrouwen.) - jrg
Ik begrijp je scepticisme. Hoe dan ook, zoals je hier kunt lezen crypto.stanford.edu/dns/dns-rebinding.pdf de meeste huidige HTML-browsers zijn al "slim". - Valentino Miazzo


Zeer mooie observatie vmiazzo +1 voor jou !! Ik zit precies waar je bent ... verbijsterd over hoe deze CDN hun magie doen.

Hieronder volgt mijn schatting hoe CDN hun netwerk uitvoert:

  • Gebruik Anycast DNS (genoemd door Jesper Mortensen) om het dichtstbijzijnde datacenter te krijgen
  • Ze lopen een lokaal netwerk die zich uitstrekken over verschillende datacenters waardoor ze iets kunnen doen KARPER op hun hosts in verschillende datacenters

Of

  • Ze gebruiken Gateway Load Balancing Protocol op hun routers of Hot Standby Router Protocol (HSRP). die te maken hebben met uitval van datacenters.
  • De reden dat ze meerdere IP-adressen bevatten, is dat de client het opnieuw probeert en tegen de tijd dat de client het opnieuw probeert, kan het routeringspad zijn gewijzigd.

Op het moment dat de oplossing voor mij werkt: - DNS retourneert meerdere IP-adressen, bijvoorbeeld:

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
  • Laatste toegangspunt tot een reverse proxy bij amazon cloud, die op intelligente wijze wordt doorgegeven aan de beschikbare server (of die wordt aangeboden onder de onderhoudspagina)

Reverse proxy wordt nog steeds geraakt, maar bot zo zwaar als de main.


5
2017-12-14 08:15



De volgorde van meerdere DNS-records die clients ontvangen, is opzettelijk willekeurig, dus uw omgekeerde proxy wordt waarschijnlijk ongeveer 1/6 van de tijd geraakt (1/2 van 1/3). Hoe is dat beter of anders dan het hebben van 6 A-records? - ColinM


Waarom is RFC 2782 (hetzelfde toepassen als MX / prioriteit voor services zoals http, imap, ...) niet geïmplementeerd in welke browser dan ook? Dingen zouden gemakkelijker zijn ... Er is een bug over, tien jaar lang geopend in Mozilla !!! omdat het het einde van de industrie van commerciële load-balancer wordt ??? Ik ben daar erg teleurgesteld over.


3
2018-04-16 15:05





2 - Je kunt dit doen met anycast gebruik makend van quagga

(Zelfs als er enige info is dat Anycast slecht is met TCP, zijn er verschillende grote bedrijven die het gebruiken zoals CacheFly)


2
2017-09-30 09:08



Absoluut, maar dat kun je niet doen met gehuurde servers, je hebt je eigen netwerk nodig. - Julien Tartarin
Toegevoegd wat info over Anycast failover over de vraag. In principe is TCP Anycast ook geen perfecte oplossing. - Valentino Miazzo


Ik vraag me af hoeveel mensen die deze vragen beantwoorden eigenlijk een groot wereldwijd netwerk van servers hebben? Google gebruikt Round Robin en mijn bedrijf gebruikt het al jaren. Het kan vrij goed werken, met enkele beperkingen. Ja, het moet worden aangevuld met andere maatregelen.

De echte sleutel is bereid te zijn om een ​​hik of twee te accepteren als een server uitvalt. Wanneer ik de plug op een server trek, zal een browser die probeert toegang te krijgen tot die server een vertraging van een minuut of zo hebben, terwijl de browser verneemt dat het IP-adres niet beschikbaar is. Maar het gaat dan heel snel naar een andere server.

Het werkt geweldig en mensen die beweren dat het veel problemen veroorzaakt, weten niet waar ze het over hebben. Het vereist gewoon het juiste ontwerp.

Failover is slecht. De beste HA gebruikt alle middelen altijd.

Ik werk al sinds 1986 met HA. Ik heb een uitgebreide training gevolgd om failover-systemen te maken en ik ben helemaal geen fan van failover.

RR werkt ook om de belasting te verdelen, zelfs als het passief in plaats van actief is. Onze serverlogs tonen duidelijk het juiste percentage verkeer op elke server - binnen redelijke grenzen.


2
2017-07-19 14:34





Een andere zeer eenvoudige keuze is om een ​​laag (hoe laag hangt van uw behoeften) TTL in de DNS A- of CNAME-record te gebruiken en deze record bij te werken om te kiezen welk IP-adres wordt gebruikt.

We hebben 2 ISP's en verschillende openbare diensten en we gebruiken deze methode met succes voor hoge beschikbaarheid vanaf 3 jaar.


1
2017-09-30 09:19



Ik heb meer uitleg in de vraag toegevoegd. Veel HTML-browsers negeren DNS TTL (DNS-pinning), zie het artikel dat in de vraag is gekoppeld. Wijzig de DNS-configuratie wanneer een datacenter daalt, laat geen directe fail-over toe op de client. - Valentino Miazzo