Warum wird DNS-Failover nicht empfohlen?

Aus der Lektüre geht hervor, dass DNS-Failover nicht empfohlen wird, nur weil DNS nicht dafür entwickelt wurde. Wenn Sie jedoch zwei Webserver in verschiedenen Subnetzen haben, die redundanten Inhalt hosten, welche anderen Methoden stehen zur Verfügung, um sicherzustellen, dass der gesamte Datenverkehr an den Live-Server weitergeleitet wird, wenn ein Server ausfällt?

Für mich scheint DNS-Failover die einzige Failover-Option zu sein, aber der Konsens ist, dass dies keine gute Option ist. Dienste wie DNSmadeeasy.com bieten es jedoch an, daher muss es Verdienste geben. Irgendwelche Kommentare?

Mit "DNS-Failover" meine ich DNS Round Robin in Kombination mit einer gewissen Überwachung, dh das Veröffentlichen mehrerer IP-Adressen für einen DNS-Hostnamen und das Entfernen einer toten Adresse, wenn die Überwachung feststellt, dass ein Server ausfällt. Dies kann für kleine, weniger frequentierte Websites sinnvoll sein.

Wenn Sie eine DNS-Anfrage beantworten, geben Sie standardmäßig auch eine Time To Live (TTL) für die Antwort an, die Sie aushändigen. Mit anderen Worten, Sie teilen anderen DNS-Servern und Caches mit, dass Sie diese Antwort speichern und x Minuten lang verwenden können, bevor Sie sie erneut bei mir abrufen. Die Nachteile ergeben sich daraus:

• Bei einem DNS-Failover werden Ihre DNS-Daten bei einem unbekannten Prozentsatz Ihrer Benutzer mit unterschiedlichem TTL-Anteil zwischengespeichert. Bis zum Ablauf der TTL können diese eine Verbindung zum toten Server herstellen. Es gibt schnellere Wege, ein Failover durchzuführen.
• Aus diesem Grund neigen Sie dazu, den TTL-Wert ziemlich niedrig einzustellen, beispielsweise auf 5-10 Minuten. Eine höhere Einstellung bietet jedoch einen (sehr geringen) Leistungsvorteil und kann dazu beitragen, dass die DNS-Weitergabe zuverlässig funktioniert, auch wenn der Netzwerkverkehr nur kurzzeitig unterbrochen wird. Die Verwendung eines DNS-basierten Failovers wirkt sich also gegen hohe TTLs aus. Hohe TTLs sind jedoch Teil von DNS und können nützlich sein.

Die gebräuchlichsten Methoden, um eine gute Betriebszeit zu erreichen, sind:

• Zusammenstellen von Servern im selben LAN.
• Platzieren Sie das LAN in einem Rechenzentrum mit hochverfügbaren Stromversorgungs- und Netzwerkebenen.
• Verwenden Sie einen HTTP-Lastenausgleich, um die Last zu verteilen und bei einzelnen Serverausfällen ein Failover durchzuführen.
• Erhalten Sie den Grad der Redundanz / erwarteten Verfügbarkeit, den Sie für Ihre Firewalls, Load Balancer und Switches benötigen.
• Verfügen Sie über eine Kommunikationsstrategie für Ausfälle des gesamten Datencenters und den gelegentlichen Ausfall eines Switches / Datenbankservers / einer anderen Ressource, die nicht einfach gespiegelt werden können.

Eine sehr kleine Minderheit von Websites verwendet Multi-Rechenzentrums-Setups mit "Geo-Balancing" zwischen Rechenzentren.

DNS-Failover funktioniert auf jeden Fall sehr gut. Ich benutze es seit vielen Jahren, um den Datenverkehr zwischen Rechenzentren manuell oder automatisch zu verschieben, wenn Überwachungssysteme Ausfälle, Konnektivitätsprobleme oder überlastete Server feststellen. Wenn Sie die Geschwindigkeit sehen, mit der es funktioniert, und das Volumen des realen Datenverkehrs, das problemlos verschoben werden kann, werden Sie nie zurückblicken. Ich verwende Zabbix für die Überwachung aller meiner Systeme. Die grafischen Darstellungen, die zeigen, was während eines DNS-Failovers passiert, zerstreuen alle meine Zweifel. Möglicherweise gibt es einige ISPs, die TTLs ignorieren, und es gibt noch einige Benutzer mit alten Browsern. Wenn Sie jedoch den Datenverkehr von Millionen von Seitenaufrufen pro Tag über zwei Rechenzentrumsstandorte hinweg betrachten und eine DNS-Verkehrsverlagerung durchführen, Der verbleibende Datenverkehr, der TTLs ignoriert, ist lächerlich.

DNS wurde nicht für Failover entwickelt, sondern mit TTLs, die in Kombination mit einem soliden Überwachungssystem hervorragend für Failover-Anforderungen geeignet sind. TTLs können sehr kurz eingestellt werden. Ich habe effektiv TTLs von 5 Sekunden in der Produktion verwendet, um schnelle DNS-Failover-basierte Lösungen zu vereinfachen. Sie müssen über DNS-Server verfügen, die die zusätzliche Last bewältigen können - und der Name wird sie nicht reduzieren. Powerdns ist jedoch genau das Richtige, wenn es mit einer von MySQL replizierten Datenbank auf redundanten Nameservern gesichert wird. Sie benötigen auch ein solides verteiltes Überwachungssystem, dem Sie für die automatisierte Failover-Integration vertrauen können. Zabbix funktioniert für mich - ich kann Ausfälle von mehreren verteilten Zabbix-Systemen fast sofort überprüfen - die von powerdns verwendeten MySQL-Datensätze im laufenden Betrieb aktualisieren - und bei Ausfällen und Verkehrsspitzen fast sofort ein Failover durchführen.

Aber hey - ich habe ein Unternehmen aufgebaut, das DNS-Failover-Dienste anbietet, nachdem es jahrelang für große Unternehmen funktioniert hat. Also nimm meine Meinung mit einem Körnchen Salz. Wenn Sie während eines Ausfalls einige zabbix-Verkehrsdiagramme von Websites mit hohem Datenaufkommen anzeigen möchten, um zu sehen, wie gut ein DNS-Failover funktioniert, senden Sie mir eine E-Mail.

Das Problem beim DNS-Failover ist, dass es in vielen Fällen unzuverlässig ist. Einige ISPs ignorieren Ihre TTLs, es kommt nicht sofort vor, selbst wenn sie Ihre TTLs einhalten, und wenn Ihre Site wieder hochgefahren wird, kann dies zu seltsamen Sitzungen führen, wenn das Zeitlimit des DNS-Caches eines Benutzers abläuft und sie sich überschlagen auf den anderen Server.

Leider ist dies so ziemlich die einzige Option, es sei denn, Sie sind groß genug, um Ihr eigenes (externes) Routing durchzuführen.

Die vorherrschende Meinung ist, dass mit DNS RR, wenn eine IP ausfällt, einige Clients die defekte IP für Minuten weiterverwenden. Dies wurde in einigen der vorherigen Antworten auf die Frage angegeben und es wird auch auf Wikipedia geschrieben.

Sowieso,

http://crypto.stanford.edu/dns/dns-rebinding.pdf erklärt, dass dies für die meisten aktuellen HTML-Browser nicht zutrifft. Sie werden die nächste IP in Sekunden versuchen.

http://www.tenereillo.com/GSLBPageOfShame.htm scheint noch stärker zu sein:

Die Verwendung mehrerer A-Datensätze ist kein Kunststück oder eine Funktion, die von Anbietern von Lastenausgleichsgeräten entwickelt wurde. Das DNS-Protokoll wurde aus diesem Grund mit Unterstützung für mehrere A-Einträge entwickelt. Anwendungen wie Browser, Proxys und Mailserver verwenden diesen Teil des DNS-Protokolls.

Vielleicht kann ein Experte einen Kommentar abgeben und klarer erklären, warum DNS RR nicht für hohe Verfügbarkeit geeignet ist.

Vielen Dank,

Valentino

PS: Entschuldigung für den defekten Link, aber als neuer Benutzer kann ich nicht mehr als 1 posten

Ich habe jahrelang ein DNS-RR-Failover auf einer produktionsintensiven, aber geschäftskritischen Website (über zwei Regionen hinweg) durchgeführt.

Es funktioniert gut, aber es gibt mindestens drei Feinheiten, die ich auf die harte Tour gelernt habe.

1) Browser werden nach 30 Sekunden (das letzte Mal, als ich es überprüft habe) von einer nicht funktionierenden IP-Adresse auf eine funktionierende IP-Adresse umgestellt, wenn beide in dem zwischengespeicherten DNS, das Ihren Clients zur Verfügung steht, als aktiv angesehen werden. Das ist im Grunde eine gute Sache.

Es ist jedoch inakzeptabel, "die Hälfte" Ihrer Benutzer 30 Sekunden warten zu lassen. Daher sollten Sie Ihre TTL-Datensätze wahrscheinlich auf einige Minuten und nicht auf einige Tage oder Wochen aktualisieren, damit Sie im Falle eines Ausfalls den ausgefallenen Server schnell entfernen können von Ihrem DNS. Andere haben in ihren Antworten darauf hingewiesen.

2) Wenn einer Ihrer Nameserver (oder einer Ihrer beiden Standorte) ausfällt, der Ihrer Round-Robin-Domain dient, und der primäre davon ausfällt, kann ich Sie vage daran erinnern, dass Sie auf andere Probleme stoßen, die versuchen, dies zu beheben Nameserver von DNS heruntergefahren, wenn Sie Ihre SOA-TTL / das Ablaufdatum für den Nameserver nicht ebenfalls auf einen ausreichend niedrigen Wert eingestellt haben. Ich könnte die technischen Details hier falsch haben, aber es gibt mehr als nur eine TTL-Einstellung, die Sie benötigen, um richtig gegen einzelne Fehlerpunkte zu verteidigen.

3) Wenn Sie Web-APIs, REST-Services usw. veröffentlichen, werden diese in der Regel nicht von Browsern aufgerufen. Meiner Meinung nach weist das DNS-Failover also echte Mängel auf. Dies mag der Grund sein, warum manche sagen, wie Sie es ausdrückten, "es ist nicht empfehlenswert". Hier ist, warum ich das sage. Erstens sind die Apps, die diese URLs verwenden, in der Regel keine Browser, sodass ihnen die 30-Sekunden-Failover-Eigenschaften / -Logik gängiger Browser fehlen. Zweitens hängt die Frage, ob der zweite DNS-Eintrag aufgerufen oder sogar DNS erneut abgefragt wird, stark von den Programmierdetails der Netzwerkbibliotheken in den von diesen API / REST-Clients verwendeten Programmiersprachen sowie deren Aufruf ab die API / REST-Client-App. (Ruft die Bibliothek unter dem Deckmantel get_addr auf und wann? Wenn Sockets hängen oder geschlossen werden, öffnet die App neue Sockets erneut? Gibt es eine Art Timeout-Logik? Usw. usw.)

Es ist billig, gut getestet und "meistens funktioniert". Wie bei den meisten Dingen kann Ihr Kilometerstand variieren.

Es gibt eine Menge Leute, die uns (Dyn) für Failover verwenden. Es ist der gleiche Grund, warum Websites entweder eine Statusseite erstellen können, wenn sie eine Ausfallzeit haben (denken Sie an Dinge wie Twitter's Fail Whale) ... oder einfach nur den Verkehr basierend auf den TTLs umleiten. Einige Leute denken vielleicht, dass DNS-Failover ein Ghetto ist ... aber wir haben unser Netzwerk von Anfang an ernsthaft mit Failover ausgestattet ... damit es genauso gut funktioniert wie Hardware. Ich bin mir nicht sicher, wie DME das macht, aber wir haben 3 von 17 unserer engsten Anycasted PoPs, die Ihren Server vom engsten Standort aus überwachen. Wenn es von zwei der drei erkennt, dass es nicht funktioniert, leiten wir den Datenverkehr einfach auf die andere IP um. Die einzige Ausfallzeit ist für diejenigen, die für den Rest dieses TTL-Intervalls zu dem angeforderten Zeitpunkt waren.

Manche Leute möchten beide Server gleichzeitig nutzen ... und können in diesem Fall so etwas wie einen Round-Robin-Lastenausgleich durchführen ... oder einen geobasierten Lastenausgleich. Für diejenigen, die sich wirklich um die Leistung kümmern ... überwacht unser Echtzeit-Traffic-Manager jeden Server ... und wenn einer langsamer ist ... leitet er den Verkehr auf den schnellsten um, basierend auf den IPs, die Sie in Ihren Hostnamen verknüpfen. Wieder ... dies funktioniert basierend auf den Werten, die Sie in unserer Benutzeroberfläche / API / Portal eingegeben haben.

Ich denke, mein Punkt ist ... wir haben DNS-Failover absichtlich entwickelt. Während DNS nicht für Failover gedacht war, als es ursprünglich erstellt wurde, wurde unser DNS-Netzwerk so konzipiert, dass es von Anfang an implementiert wird. Es kann in der Regel genauso effektiv sein wie Hardware. Ohne Wertminderung oder Hardwarekosten. Hoffe, das macht mich nicht traurig, weil ich Dyn gestopft habe ... es gibt viele andere Unternehmen, die das tun ... Ich spreche nur aus der Sicht unseres Teams. Hoffe das hilft...

Eine andere Möglichkeit wäre, den Nameserver 1 an Position A und den Nameserver 2 an Position B einzurichten, aber jeweils so einzurichten, dass alle A-Datensätze in NS1 auf IPs für Position A verweisen und in NS2 alle A-Datensätze auf IPs für Standort B. Stellen Sie dann Ihre TTLs auf einen sehr niedrigen Wert ein und stellen Sie sicher, dass Ihr Domain-Eintrag bei der Registrierungsstelle für NS1 und NS2 eingerichtet wurde. Auf diese Weise wird der Lastenausgleich automatisch durchgeführt und ein Failover ausgeführt, falls ein Server oder eine Verbindung zu einem Standort ausfällt.

Ich habe diesen Ansatz etwas anders verwendet. Ich habe einen Standort mit zwei ISPs und verwende diese Methode, um den Datenverkehr über jede Verbindung zu leiten. Es ist zwar etwas wartungsintensiver als erwartet, aber ich konnte eine einfache Software erstellen, mit der NS1-Datensätze automatisch abgerufen, die IP-Adressen von A-Datensätzen für ausgewählte Zonen aktualisiert und an diese Zonen übertragen werden NS2.

Die Alternative ist ein BGP-basiertes Failover-System. Es ist nicht einfach einzurichten, aber es sollte kugelsicher sein. Richten Sie Standort A an einem Ort ein, Standort B an einem zweiten, alle mit lokalen IP-Adressen. Rufen Sie dann einen IP-Block der Klasse C oder einen anderen portablen IP-Block ab und richten Sie die Umleitung von den portablen IP-Adressen zu den lokalen IP-Adressen ein.

Es gibt Fallstricke, aber es ist besser als DNS-basierte Lösungen, wenn Sie diese Kontrolle benötigen.

Eine Option für das Failover mehrerer Rechenzentren besteht darin, die Benutzer zu schulen. Wir machen unseren Kunden bekannt, dass wir mehrere Server in mehreren Städten und in unseren Anmelde-E-Mails bereitstellen und Links direkt zu jedem "Server" enthalten, damit Benutzer wissen, wenn ein Server ausfällt, dass sie den Link zum anderen Server verwenden können.

Dadurch wird das Problem des DNS-Failovers vollständig umgangen, indem nur mehrere Domänennamen verwaltet werden. Benutzer, die zu www.company.com oder company.com gehen und sich anmelden, werden zu server1.company.com oder server2.company.com weitergeleitet und haben die Wahl, eines dieser Lesezeichen zu setzen, wenn sie feststellen, dass sie mit dem einen oder anderen eine bessere Leistung erzielen . Wenn einer ausfällt, werden die Benutzer geschult, auf den anderen Server zuzugreifen.

Ich verwende seit zehn Jahren DNS-basiertes Site-Balancing und Failover, und es gibt einige Probleme, die jedoch behoben werden können. BGP ist zwar in mancher Hinsicht überlegen, ist aber auch keine 100% ige Lösung mit erhöhter Komplexität, wahrscheinlich zusätzlichen Hardwarekosten, Konvergenzzeiten usw.

Ich habe festgestellt, dass die Kombination von lokalem (LAN-basiertem) Lastenausgleich, GSLB und Cloud-basiertem Zonenhosting recht gut funktioniert, um einige der Probleme zu beheben, die normalerweise mit dem DNS-Lastenausgleich verbunden sind.

Alle diese Antworten haben eine gewisse Gültigkeit, aber ich denke, es hängt wirklich davon ab, was Sie tun und wie hoch Ihr Budget ist. Hier bei CloudfloorDNS besteht ein großer Teil unseres Geschäfts aus DNS und bietet nicht nur schnelles DNS, sondern auch Optionen mit niedriger TTL und DNS-Failover. Wir wären nicht im Geschäft, wenn dies nicht funktioniert und gut funktioniert hätte.

Wenn Sie ein multinationales Unternehmen mit unbegrenztem Budget für die Verfügbarkeit sind, sind die Hardware-GSLB-Load-Balancer und Tier-1-Rechenzentren großartig, aber Ihr DNS muss immer noch schnell und solide sein. Wie viele von Ihnen wissen, ist DNS ein kritischer Aspekt jeder Infrastruktur, abgesehen vom Domainnamen selbst, es ist der Service der untersten Ebene, auf dem jeder andere Teil Ihrer Online-Präsenz basiert. Beginnend mit einem soliden Domain-Registrar ist DNS genauso wichtig wie das Verhindern, dass Ihre Domain abläuft. DNS geht aus, es bedeutet, dass der gesamte Online-Aspekt Ihrer Organisation ebenfalls ausgefallen ist!

Bei der Verwendung von DNS-Failover sind die anderen kritischen Aspekte die Serverüberwachung (immer mehrere Geostandorte, von denen aus geprüft werden soll, und immer mehrere (mindestens 3) sollten überprüft werden, um Fehlalarme zu vermeiden) und die ordnungsgemäße Verwaltung der DNS-Einträge, wenn ein Fehler erkannt wird. Niedrige TTLs und einige Optionen mit dem Failover können dies zu einem nahtlosen Prozess machen und sind kein Problem, wenn Sie mitten in der Nacht mit einem Pager aufwachen, wenn Sie ein Systemadministrator sind.

Insgesamt funktioniert DNS Failover wirklich und kann sehr erschwinglich sein. In den meisten Fällen erhalten Sie von uns oder den meisten verwalteten DNS-Anbietern Anycast-DNS zusammen mit Serverüberwachung und Failover zu einem Bruchteil der Kosten für Hardwareoptionen.

Die eigentliche Antwort lautet also: Ja, es funktioniert, aber ist es für jeden und jedes Budget geeignet? Vielleicht auch nicht, aber bis Sie es ausprobieren und die Tests selbst durchführen, ist es schwer zu ignorieren, wenn Sie ein kleines bis mittleres Unternehmen mit einem begrenzten IT-Budget sind, das die bestmögliche Verfügbarkeit wünscht.

"und warum Sie Ihr Risiko eingehen, es für die meisten Produktionsumgebungen zu nutzen (obwohl es besser als nichts ist)."

Tatsächlich wird "besser als nichts" besser als "die einzige Option" ausgedrückt, wenn die Präsenz geografisch unterschiedlich ist. Hardware-Load-Balancer eignen sich hervorragend für einen einzelnen Präsenzpunkt, ein einzelner Präsenzpunkt ist jedoch auch ein einzelner Ausfallpunkt.

Es gibt viele Big-Dollar-Sites, die DNS-basierte Traffic-Manipulationen effektiv einsetzen. Sie sind die Art von Websites, die stündlich wissen, ob der Verkauf ausfällt. Es scheint, dass sie die letzten sind, die "Ihr Risiko eingehen, es in den meisten Produktionsumgebungen einzusetzen". In der Tat haben sie ihre Optionen sorgfältig geprüft, die Technologie ausgewählt und gut dafür bezahlt. Wenn sie dachten, etwas wäre besser, würden sie sofort gehen. Die Tatsache, dass sie sich immer noch dafür entscheiden, zu bleiben, spricht für die reale Nutzung.

DNS-basiertes Failover leidet unter einer gewissen Latenz. Daran führt kein Weg vorbei. Es ist jedoch immer noch der einzige praktikable Ansatz für das Failover-Management in einem Multi-Pop-Szenario. Als einzige Option ist es weit mehr als "besser als nichts".

Heute funktionieren gute globale Load Balancer, die diese Technik anwenden und recht gut funktionieren. Überprüfen Sie beispielsweise Azure Traffic Manager https://azure.microsoft.com/en-us/services/traffic-manager/.

Wenn Sie mehr erfahren möchten, lesen Sie die Anwendungshinweise unter

http://edgedirector.com

Sie decken Folgendes ab: Failover, globaler Lastenausgleich und eine Vielzahl von verwandten Themen.

Wenn Ihre Back-End-Architektur dies zulässt, ist der globale Lastausgleich mit der Failover-Option die bessere Option. Auf diese Weise sind alle Server und die Bandbreite so weit wie möglich im Spiel. Anstatt bei einem Ausfall einen zusätzlichen verfügbaren Server einzufügen, wird bei diesem Setup ein ausgefallener Server aus dem Dienst genommen, bis er wiederhergestellt ist.

Die kurze Antwort: Es funktioniert, aber Sie müssen die Einschränkungen verstehen.

Ich glaube, die Idee des Failovers war für das Clustering gedacht, aber weil es auch solo laufen konnte, war es dennoch möglich, in einer Eins-zu-Eins-Verfügbarkeit zu arbeiten.

Ich würde empfehlen, dass Sie entweder A, ein Rechenzentrum auswählen, das sich auf einem eigenen AS befindet, oder B, Ihre Nameserver in einer öffentlichen Cloud hosten. Es ist WIRKLICH unwahrscheinlich, dass EC2, HP oder IBM ausfallen. Nur ein Gedanke. Während DNS als Fehlerbehebung funktioniert, handelt es sich in diesem Fall lediglich um eine Fehlerbehebung für ein schlechtes Design in der Netzwerkgrundlage.

Abhängig von Ihrer Umgebung können Sie auch eine Kombination aus IPSLA, PBR und FHRP verwenden, um Ihre Redundanzanforderungen zu erfüllen.