Vraag Waarom wordt DNS-failover niet aanbevolen?


Vanaf het lezen lijkt het erop dat DNS-failover niet wordt aanbevolen, alleen omdat DNS er niet voor is ontworpen. Maar als u twee webservers op verschillende subnetten hebt die redundante inhoud hosten, welke andere methoden zijn er dan om ervoor te zorgen dat al het verkeer naar de live server wordt gerouteerd als een server uitvalt?

Voor mij lijkt het erop dat DNS-failover de enige failoveroptie is, maar de consensus is dat het geen goede optie is. Maar diensten als DNSmadeeasy.com bieden het, dus er moet wel wat aan te danken zijn. Eventuele opmerkingen?


166
2017-08-30 17:57


oorsprong


Kijken hier voor een bijgewerkte discussie over het onderwerp. De failover wordt nu automatisch uitgevoerd door moderne browsers. - GetFree


antwoorden:


Met 'DNS failover' bedoel ik dat je DNS Round Robin combineert met wat monitoring, dat wil zeggen dat je meerdere IP-adressen publiceert voor een DNS-hostnaam en een dood adres verwijdert wanneer monitoring detecteert dat een server down is. Dit kan werkbaar zijn voor kleine, minder verhandelde websites.

Door ontwerp, wanneer u een DNS-verzoek beantwoordt, verstrekt u ook een Time To Live (TTL) voor het antwoord dat u uitdeelt. Met andere woorden, u vertelt andere DNS-servers en caches "u kunt dit antwoord opslaan en het voor x minuten gebruiken voordat u het met mij terugkrijgt". De nadelen komen hiervan:

  • Bij DNS-failover worden aan een onbekend percentage van uw gebruikers uw DNS-gegevens in de cache opgeslagen met verschillende hoeveelheden TTL over. Totdat de TTL verloopt, kunnen deze verbinding maken met de dode server. Er zijn snellere manieren om failover te voltooien dan dit.
  • Vanwege het bovenstaande ben je geneigd om de TTL vrij laag in te stellen, zeg 5-10 minuten. Maar hoger instellen geeft een (zeer klein) prestatievoordeel en kan uw DNS-verspreiding betrouwbaar helpen, zelfs als er een korte storing in het netwerkverkeer is. Dus het gebruik van DNS-gebaseerde failover gaat in tegen hoge TTL's, maar hoge TTL's zijn een onderdeel van DNS en kunnen nuttig zijn.

De meer gebruikelijke methoden om een ​​goede uptime te krijgen, zijn:

  • Servers op hetzelfde LAN plaatsen.
  • Plaats het LAN in een datacenter met sterk beschikbare stroom- en netwerkvlakken.
  • Gebruik een HTTP-load balancer om belasting te spreiden en te falen over afzonderlijke serverstoringen.
  • Krijg het niveau van redundantie / verwachte uptime dat u nodig hebt voor uw firewalls, load balancers en switches.
  • Zorg voor een communicatiestrategie voor storingen in het volledige datacenter en het incidenteel falen van een switch / databaseserver / andere bron die niet gemakkelijk kan worden gespiegeld.

Een zeer kleine minderheid van websites gebruikt multi-datacenteropstellingen, met 'geo-balancing' tussen datacenters.


93
2017-08-30 18:39



Ik denk dat hij specifiek probeert om failover tussen twee verschillende datacenters te beheren (let op de opmerkingen over verschillende subnetten), dus het plaatsen van de servers / het gebruik van load balancers / extra redundacy zal hem niet helpen (behalve redundante datacenters. moet nog steeds het internet vertellen om naar degene te gaan die nog in de lucht is). - Cian
Voeg anycast toe aan de installatie van meerdere datacenters en het wordt een datacenter-failure proof. - petrus
wikipedia entry op anycast (en.wikipedia.org/wiki/Anycast) bespreekt dit in relatie tot de veerkracht van DNS-rootservers. - dunxd
DDoS-aanvallen komen zo vaak voor nu complete datacenters offline kunnen worden gebracht (gebeurde in december 2015 met Linode London en hun andere datacenters). Dus het gebruik van dezelfde provider in hetzelfde datacenter wordt niet aanbevolen. Daarom zouden meerdere datacenters met verschillende providers een goede strategie zijn, die ons terugbrengt naar DNS failover, tenzij er een beter alternatief bestaat. - Laurence Cope
Is er geen failover, omdat u uw site live moet houden wanneer een apparaat defect is? Wat goed is uw failover wanneer deze zich in hetzelfde netwerk bevindt dat dezelfde apparaten deelt, bijvoorbeeld routers? - user2128576


DNS-failover werkt zeker prima. Ik gebruik het al vele jaren om handmatig verkeer tussen datacenters te verplaatsen of automatisch wanneer bewakingssystemen uitval, connectiviteitsproblemen of overbelaste servers detecteerden. Wanneer je de snelheid ziet waarmee het werkt en de volumes van echt verkeer dat gemakkelijk kan worden verplaatst, zul je nooit terugkijken. Ik gebruik Zabbix voor het monitoren van al mijn systemen en de visuele grafieken die laten zien wat er gebeurt tijdens een DNS-failover-situatie brengen al mijn twijfels aan het einde. Er zijn mogelijk enkele ISP's die TTL's negeren, en er zijn sommige gebruikers die er nog steeds zijn met oude browsers - maar als je kijkt naar verkeer van miljoenen pageviews per dag op 2 datacenterlocaties en je doet een DNS-verkeersshift - het overblijvende verkeer dat binnenkomt dat TTL's negeert is lachwekkend. DNS-failover is een solide techniek.

DNS is niet ontworpen voor failover - maar het is ontworpen met TTL's die verbazingwekkend werken voor failover-behoeften in combinatie met een solide monitoringsysteem. TTL's kunnen erg kort worden ingesteld. Ik heb TTL's van 5 seconden effectief gebruikt voor het verlichten van snelle DNS failover-gebaseerde oplossingen. U moet DNS-servers hebben die in staat zijn om de extra belasting te verwerken - en de naam zal het niet snijden. Powerdns past echter in de factuur wanneer deze wordt ondersteund door een mysql-gerepliceerde database op redundante naamservers. U hebt ook een degelijk gedistribueerd controlesysteem nodig dat u kunt vertrouwen voor de geautomatiseerde failover-integratie. Zabbix werkt voor mij - ik kan storingen van meerdere gedistribueerde Zabbix-systemen vrijwel onmiddellijk verifiëren - mysql-records die door powerdns worden gebruikt tijdens de vlucht bijwerken - en bieden vrijwel onmiddellijke failover tijdens uitval en verkeerspieken.

Maar goed, ik heb een bedrijf gebouwd dat DNS-failover-services biedt na jarenlang werken voor grote bedrijven. Dus neem mijn mening met een korrel zout. Als je tijdens een storing een aantal Zabbix-verkeersgrafieken van sites met een hoog volume wilt zien - om zelf te zien hoe goed DNS-failover werkt - kun je me een e-mail sturen die ik graag deel.


44
2017-10-20 17:17



Cian's antwoord serverfault.com/a/60562/87017 is direct in tegenspraak met jouw ..... dus wie heeft gelijk? - Pacerier
Het is mijn ervaring dat korte TTL's NIET WERKEN op internet. Je hebt misschien DNS-servers die de RFC's respecteren - maar er zijn veel servers die dat niet doen. Veronderstel alsjeblieft niet dat dit een argument is tegen Round Robin DNS - zie ook het antwoord van vmiazzo hieronder - Ik heb drukke sites gerund met behulp van RR DNS en het getest - het werkt. De enige problemen die ik tegenkwam waren met een aantal op Java gebaseerde clients (geen browsers) die niet eens probeerden opnieuw verbinding te maken bij een storing, laat staan ​​de lijst met hosts op een RST te doorlopen - symcbean
Ik wed dat de mensen die zeggen dat de gecontroleerde DNS-failover goed is, en de mensen die zeggen dat het zuigt, vergelijkbare ervaringen hebben, maar met andere verwachtingen. DNS-failover is NIET naadloos, maar het voorkomt wel aanzienlijke downtime. Als u een volledig naadloze toegang nodig hebt (verlies nooit een enkel verzoek, zelfs niet tijdens een serverfout), hebt u waarschijnlijk een veel geavanceerdere - en dure - architectuur nodig. Dat is niet vereist voor veel toepassingen. - Tom Wilson


Het probleem met DNS-failover is dat deze in veel gevallen onbetrouwbaar is. Sommige internetproviders negeren uw TTL's, dit gebeurt niet meteen, zelfs als ze uw TTL's respecteren, en wanneer uw site weer wordt weergegeven, kan dit leiden tot een beetje gekheid bij sessies wanneer de DNS-cache van een gebruiker een time-out krijgt en ze uiteindelijk worden weergegeven naar de andere server.

Helaas is het vrijwel de enige optie, tenzij je groot genoeg bent om je eigen (externe) routering te doen.


31
2017-08-30 18:27



+1 Langzaam en onbetrouwbaar - Chris S
Zie ook serverfault.com/q/315199/87017 - Pacerier


De heersende opvatting is dat met DNS RR, wanneer een IP-adres daalt, sommige clients de verbroken IP minutenlang zullen blijven gebruiken. Dit stond in enkele van de vorige antwoorden op de vraag en het staat ook op Wikipedia.

Hoe dan ook,

http://crypto.stanford.edu/dns/dns-rebinding.pdf legt uit dat dit niet geldt voor de meeste van de huidige HTML-browsers. Ze zullen de volgende IP binnen enkele seconden proberen.

http://www.tenereillo.com/GSLBPageOfShame.htm lijkt nog sterker te zijn:

Het gebruik van meerdere A-records is geen list van het vak, of een kenmerk van leveranciers van leveranciers van load balancing-apparatuur. Het DNS-protocol is om deze reden ontworpen met ondersteuning voor meerdere A-records. Toepassingen zoals browsers en proxies en mailservers maken gebruik van dat deel van het DNS-protocol.

Misschien kan een expert iets zeggen en een duidelijkere uitleg geven waarom DNS RR niet goed is voor hoge beschikbaarheid.

Bedankt,

Valentino

PS: sorry voor de verbroken link maar als nieuwe gebruiker kan ik niet meer dan 1 plaatsen


19
2017-09-29 10:06



Meerdere A-records zijn ontworpen in, maar voor taakverdeling, in plaats van voor failover. Clients cachen de resultaten en blijven de volledige pool (inclusief het defecte IP-adres) een paar minuten gebruiken nadat u de record hebt gewijzigd. - Cian
Dus, is waar op wordt geschreven crypto.stanford.edu/dns/dns-rebinding.pdf hoofdstuk 3.1 onjuist? << Internet Explorer 7 pinnen DNS-bindingen gedurende 30 minuten.1 Helaas, als het domein van de aanvaller meerdere A-records heeft en de huidige server niet meer beschikbaar is, probeert de browser binnen één seconde een ander IP-adres. >> - Valentino Miazzo
Verplaatst mijn deelvraag hier serverfault.com/questions/69870/... - Valentino Miazzo


Ik heb gedurende vele jaren DNS RR-failover uitgevoerd op een matig-verhandelde maar bedrijfskritieke website met een matige productie (verspreid over twee geografische gebieden).

Het werkt prima, maar er zijn minstens drie subtiliteiten die ik op de harde manier heb geleerd.

1) Browsers zullen na 30 seconden (de laatste keer dat ik heb gecontroleerd) overschakelen van een niet-werkende IP naar een werkend IP-adres als beide worden beschouwd als actief in het cachegeheugen dat beschikbaar is voor uw clients. Dit is eigenlijk een goede zaak.

Maar "de helft" van uw gebruikers wacht 30 seconden is onaanvaardbaar, dus u wilt uw TTL-records waarschijnlijk een paar minuten, niet een paar dagen of weken bijwerken, zodat u in geval van een storing snel de downserver kunt verwijderen van uw DNS. Anderen hebben hierop gezinspeeld in hun antwoorden.

2) Als een van uw nameservers (of een van uw twee geografische regio's helemaal) naar beneden gaat, die uw round-robin-domein bedient, en als de primaire daarvan naar beneden gaat, herinner ik u vaag dat u andere problemen tegen kunt komen die proberen te verwijderen downed nameserver van DNS als je je SOA TTL / verloop voor de nameserver ook niet hebt ingesteld op een voldoende lage waarde. Ik zou de technische details hier verkeerd kunnen hebben, maar er is meer dan slechts één TTL-instelling die je nodig hebt om het recht te krijgen om je echt te verdedigen tegen enkele faalpunten.

3) Als u web-API's, REST-services, enz. Publiceert, worden die meestal niet door browsers aangeroepen en dus gaat naar mijn mening DNS-failover echte gebreken vertonen. Dit is misschien de reden waarom sommigen zeggen, zoals u het uitdrukte: "het wordt niet aanbevolen". Dit is waarom ik dat zeg. Ten eerste zijn de apps die deze URL's gebruiken meestal geen browsers, dus missen ze de 30-seconden failover-eigenschappen / logica van veelgebruikte browsers. Ten tweede, of de tweede DNS-invoer al dan niet wordt gebeld of zelfs DNS opnieuw wordt opgevraagd, hangt sterk af van de programmering op laag niveau van netwerkbibliotheken in de programmeertalen die door deze API / REST-clients worden gebruikt, plus precies hoe ze door de API / REST-client-app. (Onder deze covers, roept de bibliotheek get_addr, en wanneer? Als sockets hangen of sluiten, opent de app dan nieuwe sockets? Is er een bepaalde time-outlogica? Enz.)

Het is goedkoop, goed getest en "werkt meestal". Zoals met de meeste dingen, kan uw aantal kilometers variëren.


11
2018-04-12 01:21



een bibliotheek die niet opnieuw probeert op de andere RR's voor een adres is verbroken. wijs de ontwikkelaars naar de man-pagina's voor getaddrinfo () enz. - Jasen


Er zijn een heleboel mensen die ons gebruiken (Dyn) voor failover. Het is om dezelfde reden dat sites een statuspagina kunnen uitvoeren wanneer ze downtime hebben (denk aan zaken als Twitter's Fail Whale) ... of gewoon het verkeer op basis van TTL's omleiden. Sommige mensen denken misschien dat DNS Failover getto is ... maar we hebben ons netwerk vanaf het begin serieus ontworpen met failover ... zodat het net zo goed werkte als hardware. Ik weet niet zeker hoe DME het doet, maar we hebben 3 van de 17 van onze dichtstbijzijnde, zelf gemanipuleerde PoP's die je server volgen vanaf de dichtstbijzijnde locatie. Wanneer het van twee van de drie detecteert dat het defect is, verplaatsen we het verkeer eenvoudigweg naar het andere IP-adres. De enige downtime is voor degenen die op dat moment waren aangevraagd voor de rest van dat TTL-interval.

Sommige mensen gebruiken beide servers graag tegelijkertijd ... en kunnen in dat geval zoiets als een load-in voor round-robin doen ... of op basis van geo loadbalancing. Voor degenen die echt om de prestaties geven, zal onze real-time verkeersmanager elke server controleren ... en als een trager is ... het verkeer omleiden naar de snelste op basis van welke IP-adressen u koppelt in uw hostnamen. Nogmaals ... dit werkt op basis van de waarden die u hebt ingevoerd in onze UI / API / Portal.

Ik denk dat mijn punt is ... we hebben dns failover expres ontworpen. Hoewel DNS niet gemaakt was voor failover toen het oorspronkelijk werd gemaakt ... was ons DNS-netwerk ontworpen om het vanaf het begin te implementeren. Het kan meestal net zo effectief zijn als hardware ... zonder afschrijving of de kosten van hardware. Ik hoop dat dat me niet verlamd maakt voor het aansluiten van Dyn ... er zijn genoeg andere bedrijven die het doen ... Ik spreek alleen vanuit het perspectief van ons team. Ik hoop dat dit helpt...


9
2018-05-25 19:38



Wat bedoel je met "kan net zo effectief zijn als hardware"? Welke soort hardware voert DNS-routering uit? - mpen
@Ryan, wat bedoel je als je 'getto' zegt? - Pacerier
Voor dat woord geeft stedelijk woordenboek geen definities met positieve connotatie, ik zou aannemen dat "een bedelaarsoplossing" een geschikte vertaling zou kunnen zijn. - Jasen


Een andere optie is om naamserver 1 in locatie A en naamserver 2 in locatie B in te stellen, maar deze allemaal zodanig in te stellen dat alle A-records op NS1 verkeer naar IP's voor locatie A wijzen en op NS2 alle A-records naar IP's voor locatie B. Stel vervolgens uw TTL's in voor een zeer laag aantal en zorg ervoor dat uw domeinrecord bij de registrar is ingesteld voor NS1 en NS2. Op die manier wordt het saldo automatisch geladen en wordt er gefaald als een server of een link naar een locatie wordt verbroken.

Ik heb deze benadering op een enigszins andere manier gebruikt. Ik heb één locatie met twee ISP's en gebruik deze methode om verkeer over elke link te leiden. Nu is het misschien wat meer onderhoud dan je bereid bent te doen ... maar ik was in staat om een ​​eenvoudig stukje software te maken dat automatisch NS1-records trekt, een record-IP-adressen voor geselecteerde zones bijwerkt en die zones naar NS2.


5
2017-08-07 05:13



Gebruiken de naamservers niet teveel om te verspreiden? Als u een DNS-record met een lage TTL wijzigt, werkt dit onmiddellijk, maar als u de naamserver wijzigt, duurt het 24 uur of meer voordat deze wordt doorgegeven, dus ik zie niet in hoe dit een failover-oplossing kan zijn. - Marco Demaio


Het alternatief is een op BGP gebaseerd failover-systeem. Het is niet eenvoudig om in te stellen, maar het moet een kogelbestendig zijn. Zet site A op één locatie op, plaats B in een tweede met lokale IP-adressen, pak dan een klasse C of een ander blok met IP's die draagbaar zijn en een omleiding instellen van de draagbare IP's naar de lokale IP's.

Er zijn valkuilen, maar het is beter dan op DNS gebaseerde oplossingen als je dat niveau van controle nodig hebt.


4
2017-08-30 21:40



Op BGP gebaseerde oplossingen zijn echter niet voor iedereen beschikbaar. En zijn veel gemakkelijker te breken op bijzonder afschuwelijke manieren dan DNS is. Schommels en rotondes, denk ik. - Cian


Een optie voor multi-datacenter-failover is om uw gebruikers te trainen. We adverteren voor onze klanten dat we meerdere servers in meerdere steden en in onze aanmeldings-e-mails aanbieden en dergelijke koppelingen direct naar elke "server" bevatten, zodat gebruikers weten of een server niet bereikbaar is en de link naar de andere server gebruiken.

Hiermee wordt het probleem van DNS-failover volledig omzeild door slechts meerdere domeinnamen te onderhouden. Gebruikers die naar www.company.com of company.com gaan en zich aanmelden, worden doorgestuurd naar server1.company.com of server2.company.com en kunnen desgewenst een van de bookmarks toevoegen als ze merken dat ze betere prestaties behalen met het een of het ander . Als iemand naar beneden gaat, worden gebruikers getraind om naar de andere server te gaan.


3
2017-10-11 22:11



Uw gebruikers op deze manier trainen ... Maakt dit hen niet meer vatbaar voor phishing? - Pacerier


Ik gebruik de afgelopen tien jaar DNS-gebaseerde site-balancing en failover en er zijn enkele problemen, maar deze kunnen worden beperkt. BGP, hoewel superieur in sommige opzichten, is geen 100% oplossing, hetzij met verhoogde complexiteit, waarschijnlijk extra hardware kosten, convergentie tijden, enz ...

Ik heb gemerkt dat het combineren van lokale (op LAN gebaseerde) taakverdeling, GSLB en cloudgebaseerde zonhosting vrij goed werkt om enkele van de problemen te dichten die normaal samenhangen met DNS-taakverdeling.


2
2017-08-23 01:50