Frage Mehrere Rechenzentren und HTTP-Datenverkehr: DNS Round Robin ist der einzige Weg, um ein sofortiges Failover zu gewährleisten.


Mehrere A-Datensätze, die auf dieselbe Domäne verweisen, scheinen fast ausschließlich dazu verwendet zu werden, DNS-Round-Robin als billige Lastverteilungstechnik zu implementieren.

Die übliche Warnung vor DNS RR ist, dass es nicht gut für hohe Verfügbarkeit ist. Wenn 1 IP ausfällt, werden Clients es für Minuten verwenden.

Ein Load Balancer wird oft als eine bessere Wahl vorgeschlagen.

Beide Behauptungen stimmen nicht vollständig überein:

  1. Wenn der Datenverkehr HTTP ist, können die meisten HTML-Browser automatisch den nächsten A-Eintrag versuchen, wenn der vorherige nicht aktiv ist, ohne eine neue DNS-Suche. Lesen hier Kapitel 3.1 und Hier.

  2. Wenn mehrere Rechenzentren beteiligt sind, ist DNS RR die einzige Option, um Datenverkehr über sie zu verteilen.

Stimmt es also, dass die Verwendung von DNS RR bei mehreren Rechenzentren und HTTP-Datenverkehr die einzige Möglichkeit ist, ein sofortiges Failover zu gewährleisten, wenn ein Rechenzentrum ausfällt?

Vielen Dank,

Valentino

Bearbeiten:

  • Natürlich hat jedes Rechenzentrum einen lokalen Load Balancer mit Hotspare.
  • Es ist in Ordnung, die Sitzungsaffinität für ein sofortiges Failover zu opfern.
  • AFAIK Die einzige Möglichkeit für einen DNS, statt eines anderen ein Rechenzentrum vorzuschlagen, besteht darin, nur mit der IP (oder den IPs) zu antworten, die diesem Rechenzentrum zugeordnet ist. Wenn das Rechenzentrum unerreichbar wird, sind alle diese IP ebenfalls nicht erreichbar. Dies bedeutet, dass, selbst wenn intelligente HTML-Browser sofort einen anderen A-Eintrag ausprobieren können, alle Versuche fehlschlagen werden, bis der lokale Cache-Eintrag abläuft und eine neue DNS-Suche durchgeführt wird, wobei die neuen funktionierenden IPs abgerufen werden neues Rechenzentrum bei einem Fehler). So kann "Smart DNS" kein sofortiges Fail-Over sicherstellen.
  • Umgekehrt erlaubt ein DNS-Round-Robin dies. Wenn ein Datencenter ausfällt, versuchen die intelligenten HTML-Browser (die meisten von ihnen) sofort, die anderen zwischengespeicherten A-Datensätze in ein anderes (funktionierendes) Datencenter zu springen. Daher garantiert das DNS-Round-Robin nicht die Sitzungsaffinität oder die niedrigste RTT, sondern scheint die einzige Möglichkeit zu sein, sofortiges Fail-Over zu gewährleisten, wenn die Clients "intelligente" HTML-Browser sind.

Bearbeiten 2:

  • Einige Leute schlagen TCP Anycast als eine endgültige Lösung vor. Im diese Papier (Kapitel 6) wird erklärt, dass Anycast Fail-Over mit BGP-Konvergenz verwandt ist. Aus diesem Grund kann Anycast zwischen 15 Minuten und 20 Sekunden verwenden. In Netzwerken, in denen die Topologie dafür optimiert wurde, sind 20 Sekunden möglich. Wahrscheinlich können nur CDN-Betreiber so schnelle Ausfälle gewähren.

Bearbeiten 3: *

  • Ich habe einige DNS-Lookups und Tracerouten gemacht (vielleicht kann ein Experte das überprüfen) und:
    • Das einzige CDN, das TCP-Anycast verwendet, scheint CacheFly zu sein, andere Betreiber wie CDN-Netzwerke und BitGravity verwenden CacheFly. Scheint, dass ihre Kanten nicht als umgekehrte Proxies verwendet werden können. Daher können sie nicht zum sofortigen Failover verwendet werden.
    • Akamai und LimeLight scheinen Geo-Aware-DNS zu verwenden. Aber! Sie geben mehrere A-Datensätze zurück. Von Traceroutes scheint, dass die zurückgegebenen IPs im selben Rechenzentrum sind. Daher bin ich verwirrt darüber, wie sie ein 100% SLA anbieten können, wenn ein Rechenzentrum ausfällt.

76
2017-09-30 08:44


Ursprung


Mit hoher Verfügbarkeit habe ich fast sofortiges Fail-Over angedeutet. Der Client sollte kein Problem bemerken, selbst wenn ein Rechenzentrum ausfällt. Ich habe die Frage präzisiert. - Valentino Miazzo
MaxCDN verwendet Anycast-TCP und seine Kanten können im Caching-Proxy-Modus verwendet werden ("Origin Fetch" in der CDN-Industrie-Terminologie). - rmalayter
@vmiazzo, Dein PDF-Link ist ausgefallen ... Meinst du 15 Minuten oder 20 Sekunden bis 15 Minuten? - Pacerier


Antworten:


Wenn ich den Begriff "DNS Round Robin" benutze, dann meine ich im Allgemeinen die "billige Lastausgleichstechnik", wie OP es beschreibt.

Aber das ist nicht die einzige Möglichkeit, DNS für globale Hochverfügbarkeit zu verwenden. Meistens ist es schwierig für Menschen mit unterschiedlichen (Technologie-) Hintergründen, gut zu kommunizieren.

Die beste Lastverteilungstechnik (wenn Geld kein Problem ist) wird allgemein betrachtet als:

  1. Ein anycast'ed globales Netzwerk von "intelligenten" DNS-Servern,
  2. und eine Reihe von global verteilten Rechenzentren,
  3. wo jeder DNS-Knoten Split Horizon DNS implementiert,
  4. und Überwachung der Verfügbarkeit und der Verkehrsflüsse sind für die "intelligenten" DNS-Knoten in gewisser Weise verfügbar,
  5. so, dass die Benutzer-DNS-Anfrage fließt über IP-Anycast zum nächsten DNS-Server,
  6. und das Der DNS-Server verteilt einen Niedrig-TTL-A-Datensatz / Satz von A-Datensätzen für die am nächsten / am besten Rechenzentrum für diesen Endbenutzer über 'intelligente' Split-Horizon-DNS.

Die Verwendung von Anycast für DNS ist im Allgemeinen gut, da DNS-Antworten zustandslos und fast extrem kurz sind. Wenn sich die BGP-Routen ändern, ist es sehr unwahrscheinlich, dass eine DNS-Abfrage unterbrochen wird.

Anycast ist für die längeren und statusbehafteten HTTP-Konversationen weniger geeignet, daher verwendet dieses System Split-Horizon-DNS. Eine HTTP-Sitzung zwischen einem Client und einem Server wird in einem Datencenter gespeichert. Es kann im Allgemeinen nicht auf ein anderes Datencenter umgeschaltet werden, ohne die Sitzung zu unterbrechen.

Wie ich bei "Set of A Records" angegeben habe, kann das, was ich "DNS Round Robin" nennen würde, zusammen mit dem obigen Setup verwendet werden. Es wird normalerweise verwendet, um die Verkehrslast über mehrere hoch verfügbare Load Balancer in jedem Rechenzentrum zu verteilen (damit Sie eine bessere Redundanz erhalten, kleinere / billigere Load Balancer verwenden, die Unix-Netzwerkpuffer eines einzelnen Host-Servers nicht überlasten).

Stimmt es also, dass es mehrere Rechenzentren gibt?   und HTTP-Verkehr, die Verwendung von DNS RR ist die einzige   So sichern Sie hohe Verfügbarkeit?

Nein, es ist nicht wahr, nicht wenn wir mit "DNS Round Robin" einfach mehrere A-Einträge für eine Domain verteilen. Aber es ist wahr, dass cleverer Einsatz von DNS eine kritische Komponente in jedem globalen Hochverfügbarkeitssystem ist. Das Obige illustriert einen gemeinsamen (oft besten) Weg zu gehen.

Bearbeiten: Das Google-Papier "Über die End-to-End-Pfadinformationen hinausgehen, um die CDN-Leistung zu optimieren" scheint mir bei der globalen Lastverteilung State-of-the-Art zu sein, um die beste Endbenutzerleistung zu erreichen.

Bearbeiten 2: Ich habe den Artikel gelesen "Warum DNS basiert .. GSLB .. funktioniert nicht" das OP verknüpft, und es ist ein guter Überblick - ich empfehle, es zu betrachten. Lesen Sie es von oben.

Im Abschnitt "Die Lösung für das Browser-Caching-Problem" werden DNS-Antworten mit mehreren A-Records empfohlen, die auf mehrere Datencenter als einzige mögliche Lösung für sofortiges Failover verweisen.

Im Abschnitt "Watering it down" im unteren Bereich wird deutlich, dass das Senden mehrerer A Records uncool ist, wenn sie auf Datenzentren auf mehreren Kontinenten verweisen, da der Client sich zufällig verbindet und somit oft eine "langsame" Verbindung erhält. DC auf einem anderen Kontinent. Damit dies wirklich gut funktioniert, werden mehrere Rechenzentren auf jedem Kontinent benötigt.

Dies ist eine andere Lösung als meine Schritte 1 - 6. Darauf kann ich keine perfekte Antwort geben. Ich denke, dass ein DNS-Spezialist von Akamai oder Google benötigt wird, weil vieles davon darauf hinausläuft praktisches Know-how über die Einschränkungen von bereitgestellten DNS-Caches und Browsern heute. AFAIK, meine Schritte 1-6 sind das, was Akamai mit ihrem DNS macht (kann jemand das bestätigen?).

Mein Gefühl - von der Arbeit als PM auf mobilen Browserportalen (Handys) zu kommen - ist die Vielfalt und das Niveau von totaler Bruch der Browser da draußen ist unglaublich. Ich persönlich würde einer HA-Lösung, die vom Endbenutzer-Terminal verlangt, dass sie "das Richtige tun", nicht vertrauen; daher glaube ich, dass ein sofortiges Failover ohne Unterbrechung einer Sitzung heute nicht durchführbar ist.

Ich denke, meine obigen Schritte 1-6 sind die besten, die es bei der Commodity-Technologie gibt. Diese Lösung hat kein sofortiges Failover.

Ich würde mich freuen, wenn einer dieser DNS-Spezialisten von Akamai, Google usw. herumkommt und mir beweisen würde, dass ich falsch liege. :-)


34
2017-09-30 10:56



Ich habe in der Frage weitere Erklärungen hinzugefügt. Wenn ich Ihre "beste Lastverteilungstechnik" (Punkt 6) verstehe, werden nur die A-Datensätze des "besten" Rechenzentrums beworben. Wie ich in der Frage zu erklären versuchte, erlaubt dies kein sofortiges Fail-Over auf dem Client. - Valentino Miazzo
@vmiazzo: Ja, du hast mich richtig verstanden. Ich füge meinem Beitrag einen zweiten Schnitt hinzu, um zu verdeutlichen - aber im Grunde denke ich, dass der sofortige Fehler, den du suchst, unpraktisch / unmöglich ist. - Jesper Mortensen
Was ich interessant finde, ist, dass niemand vorgeschlagen hat, die beiden Ansätze miteinander zu kombinieren. Obwohl es nicht ideal ist, würde es eine angemessene Geschwindigkeit bereitstellen, wenn die Dinge richtig funktionieren, und eine zusätzliche Ausfallsicherheit, wenn dies nicht der Fall ist. Die Strafe wäre eine große Verzögerung, wenn Clients von einer anycastbasierten DNS-Adresse zu einer anderen wechseln würden. - Avery Payne
@JesperMortensen, Wenn du "intelligentes" DNS sagst, meinst du Split-Horizon DNS? Oder meinst du etwas anderes (basierend auf Faktoren entscheiden darüber hinaus Quell-IP)? - Pacerier


Ihre Frage lautet: "Ist DNS Round Robin der einzige Weg, sofortiges Fail-Over zu gewährleisten?"

Die Antwort lautet: "DNS Round Robin ist NOCH NIE der richtige Weg, um einen sofortigen Ausfall zu gewährleisten ".

(zumindest nicht alleine)

Der richtige Weg zum sofortigen Failover ist die Verwendung von BGP4-Routing, so dass beide Seiten die gleichen IP-Adressen verwenden. Mit diesem Kern des Internets Routing Technologien sind daran gewöhnt Route die Anfragen an das richtige Rechenzentrum, anstatt den Kern des Internets zu nutzen Adressierung Technologie.

In der einfachsten Konfiguration dies nur bietet Fail-Over. Es kann auch verwendet werden, um Anycast bereitzustellen, mit dem Vorbehalt, dass TCP-basierte Protokolle zum Zeitpunkt des Umschaltens fehlschlagen, wenn eine Instabilität im Routing vorliegt.


18
2017-09-30 16:04



Es wurden einige Informationen zu Anycast-Failover für die Frage hinzugefügt. Grundsätzlich ist TCP Anycast auch keine perfekte Lösung. - Valentino Miazzo
@vmiazzo re TCP Anycast - in der Tat, daher der Hinweis in meiner Antwort über Routing-Instabilität und wie es TCP beeinflusst. - Alnitak


Stimmt es also, dass bei mehreren Datenzentren und HTTP-Datenverkehr die Verwendung von DNS RR der einzige Weg ist, um eine hohe Verfügbarkeit sicherzustellen?

Offensichtlich ist es eine falsche Behauptung - Sie müssen nur auf Google, Akamai, Yahoo schauen, um zu sehen, dass sie keine Round-Robin [*] Antworten als ihre einzige Lösung verwenden (manche nutzen sie teilweise zusammen mit anderen Ansätzen) .)

Es gibt viele mögliche Optionen, aber es hängt wirklich davon ab, welche anderen Einschränkungen Sie mit Ihrem Dienst / Ihrer Anwendung haben, welche Sie auswählen.

Es ist möglich, Round-Robin-Techniken auf einem einfachen, co-located Server-Ansatz zu verwenden und sich keine Sorgen über einen Serverausfall zu machen, wenn Sie auch das "Fail-Over" der IP-Adresse arrangieren. (Aber die meisten entscheiden sich für Load-Balancing-Techniken, eine einzelne IP-Adresse und Failover zwischen Load-Balancern.)

Möglicherweise müssen alle Anforderungen für eine einzelne Sitzung an dieselben Server gesendet werden, Sie möchten jedoch, dass Anforderungen auf verschiedene regionale Servercluster verteilt werden. Round-Robin ist dafür nicht geeignet: Sie müssen etwas tun, das sicherstellt, dass ein bestimmter Client jedes Mal auf denselben physischen Servercluster zugreift (außer wenn "Ausnahmen" auftreten, wie z. B. Serverfehler). Entweder erhalten sie eine konsistente IP-Adresse von einer DNS-Abfrage oder sie werden an denselben physischen Servercluster weitergeleitet. Zu den Lösungen gehören verschiedene kommerzielle und nichtkommerzielle DNS-Load-Balancer oder (wenn Sie mehr Kontrolle über Ihr Netzwerk haben) BGP-Werbenetzwerke. Sie könnten einfach dafür sorgen, dass die Nameserver Ihrer Domain völlig unterschiedliche Antworten geben (da DNS-Anfragen jedoch überall gesendet werden können, erreichen Sie mit diesem Ansatz keine Standortaffinität).

[* Ich werde Round-Robin verwenden, weil 'RR' in der DNS-Terminologie "Resource Record" bedeutet.]


6
2017-09-30 09:47



Ich fügte weitere Erklärungen in die Antwort ein. Ihr Vorschlag, DNS "Load Balancer" zu verwenden, erlaubt IMHO kein sofortiges Fail-Over. Über den BGP, beziehen Sie sich auf eine Anycast TCP-Lösung? - Valentino Miazzo
Ich schlage keine bestimmte Lösung vor - ich sage, dass Sie die richtige Lösung für Ihr Problem (die Sie nicht wirklich in Ihrer Frage angegeben haben) und Ihre Einschränkungen (dito.) DNS-Round-Robin auswählen müssen Sie bieten kein sofortiges Fail-Over mehr als DNS LB, weil Browser nicht garantiert "das Richtige" tun (hauptsächlich weil das "Richtige" nicht streng definiert oder vorgeschrieben ist. Ich glaube nicht, dass es genug "Smart" gibt HTML-Browser ", stimme ich Jesper schon jetzt zu, dass sie zu unterschiedlich in ihrem Verhalten sind, um sich auf sie zu verlassen.) - jrg
Ich verstehe deine Skepsis. Wie auch immer, wie Sie hier lesen können crypto.stanford.edu/dns/dns-rebinding.pdf Die meisten der aktuellen HTML-Browser sind bereits "intelligent". - Valentino Miazzo


Sehr schöne Beobachtung vmiazzo +1 für Sie! Ich stecke genau dort fest, wo du bist .. verblüfft darüber, wie diese CDN ihre Magie machen.

Nachfolgend sind meine Vermutungen darüber, wie CDN ihr Netzwerk betreibt:

  • Verwenden Sie Anycast DNS (von Jesper Mortensen erwähnt), um das nächste Datencenter zu erhalten
  • Sie laufen ein lokales Netzwerk die sich über verschiedene Rechenzentren erstrecken, die es ihnen ermöglichen, so etwas wie KARPFEN auf ihren Hosts über verschiedene Rechenzentren

Oder

  • Sie beschäftigen Gateway-Lastverteilungsprotokoll auf ihren Routern oder Hot-Standby-Router-Protokoll (HSRP). die sich mit dem Ausfall des Datenzentrums befassen.
  • Der Grund dafür, dass sie mehrere IP-Adressen enthalten, besteht darin, dass der Client dies erneut versucht. Wenn der Client dies erneut versucht, hat sich der Routingpfad möglicherweise geändert.

Im Moment folgende Lösungsarbeit für mich: - DNS return multiple IP, zB:

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
  • Letzter Eintragspunkt auf einen Reverse Proxy bei Amazon Cloud, der intelligent auf den verfügbaren Server übergibt (oder unter Wartungsseite bereitstellt)

Reverse-Proxy wird immer noch getroffen, aber Bot ist so schwer wie der erste.


5
2017-12-14 08:15



Reihenfolge von mehreren DNS-Datensätzen, die Clients erhalten, ist absichtlich randomisiert, so dass Ihr Reverse-Proxy wahrscheinlich um 1/6 der Zeit (1/2 von 1/3) geschlagen wird. Wie ist das besser oder anders als 6 A Aufzeichnungen? - ColinM


Warum RFC 2782 (gilt wie MX / Priorität für Dienste wie http, imap, ...) ist in keinem Browser implementiert? Die Dinge wären einfacher ... Es gibt einen Fehler über, seit zehn Jahren in Mozilla geöffnet !!! weil es das Ende der Industrie des kommerziellen Lastenausgleichers sein wird ??? Ich bin sehr enttäuscht darüber.


3
2018-04-16 15:05





2 - Sie können dies mit tun Anycast verwenden Quagga

(Selbst wenn es einige Informationen gibt, dass Anycast mit TCP schlecht ist, gibt es einige große Firmen, die es wie CacheFly benutzen)


2
2017-09-30 09:08



Absolut, aber Sie können das nicht mit gemieteten Servern tun, Sie brauchen Ihr eigenes Netzwerk. - Julien Tartarin
Es wurden einige Informationen zu Anycast-Failover für die Frage hinzugefügt. Grundsätzlich ist TCP Anycast auch keine perfekte Lösung. - Valentino Miazzo


Ich frage mich, wie viele Leute, die diese Fragen beantworten, tatsächlich ein großes weltweites Netzwerk von Servern betreiben? Google verwendet Round Robin und meine Firma verwendet es seit Jahren. Es kann ziemlich gut funktionieren, mit einigen Einschränkungen. Ja, es muss mit anderen Maßnahmen ergänzt werden.

Der wahre Schlüssel ist, bereit zu sein, ein oder zwei Schluckauf zu akzeptieren, wenn ein Server ausfällt. Wenn ein Browser versucht, auf diesen Server zuzugreifen, wird eine Verzögerung von etwa einer Minute auftreten, wenn der Browser erfährt, dass die IP-Adresse inaktiv ist. Aber dann geht es sehr schnell zu einem anderen Server.

Es funktioniert großartig, und Leute, die behaupten, dass es viele Probleme verursacht, wissen nicht, wovon sie reden. Es erfordert nur das richtige Design.

Failover saugt. Der beste HA nutzt alle Ressourcen die ganze Zeit.

Ich arbeite seit 1986 mit HA zusammen. Ich habe umfangreiche Schulungen absolviert, um Failover-Systeme zu entwickeln, und ich bin überhaupt kein Fan von Failover.

Außerdem funktioniert RR, um die Last zu verteilen, auch wenn sie passiv statt aktiv ist. Unsere Server-Protokolle zeigen deutlich den entsprechenden Prozentsatz des Datenverkehrs auf jedem Server - im Rahmen des Zumutbaren.


2
2017-07-19 14:34





Eine weitere sehr einfache Möglichkeit ist die Verwendung eines niedrigen TTL im DNS A- oder CNAME-Datensatz und die Aktualisierung dieses Datensatzes zur Auswahl der zu verwendenden IP-Adresse.

Wir haben 2 ISP und mehrere öffentliche Dienste und wir verwenden erfolgreich diese Methode für hohe Verfügbarkeit ab 3 Jahren.


1
2017-09-30 09:19



Ich habe in der Frage weitere Erklärungen hinzugefügt. Viele HTML-Browser ignorieren DNS-TTL (DNS-Pinning), siehe das in der Frage verlinkte Papier. Ändern Sie die DNS-Konfiguration, wenn ein Datencenter ausfällt, ist ein sofortiges Fail-Over auf dem Client nicht möglich. - Valentino Miazzo


Ein Schlüssel in der Arbeit ist, dass eine Reihe von ISPs schlecht konfigurierte Resolver haben, die Datensätze für ein festgelegtes Intervall zwischenspeichern und TTL-Einstellungen vollständig ignorieren. Es sollte nicht so sein, und es gibt keine Entschuldigung dafür, aber traurig aus meiner Erfahrung mit der Migration von zahlreichen Websites und Dienstleistungen passiert es.


1
2017-09-30 14:44



Es gibt eine Entschuldigung dafür. Niedrige TTLs haben einen hohen Leistungseinfluss auf ausgelastete DNS-Server und ihre permanente Verwendung und nicht nur vorübergehend, wenn eine Änderung fällig ist, ist ein Missbrauch des Systems und ihrer Ressourcen. Die meisten ISPs werden nur dann eine Mindest-TTL erzwingen, wenn sie länger als eine angemessene Zeitspanne niedrig gesetzt wurde. - JamesRyan