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

Mehrere A-Einträge, die auf dieselbe Domäne verweisen, werden anscheinend fast ausschließlich zum Implementieren von DNS Round Robin als billige Lastausgleichstechnik verwendet.

Die übliche Warnung vor DNS RR ist, dass es nicht gut für eine hohe Verfügbarkeit ist. Wenn eine IP-Adresse ausfällt, wird sie von den Clients minutenlang verwendet.

Ein Load Balancer wird häufig als bessere Wahl vorgeschlagen.

Beide Behauptungen sind nicht ganz richtig:

1. Wenn der Datenverkehr dann HTTP ist, können die meisten HTML-Browser automatisch den nächsten A-Eintrag versuchen, wenn der vorherige nicht verfügbar ist, ohne dass eine neue DNS-Suche durchgeführt wird. Lesen Sie hier Kapitel 3.1 und hier .

2. Wenn mehrere Rechenzentren beteiligt sind, ist DNS RR die einzige Option, um den Datenverkehr auf diese 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:

• Selbstverständlich verfügt jedes Rechenzentrum über einen lokalen Load Balancer mit Hot Spare.
• Es ist in Ordnung, die Sitzungsaffinität für ein sofortiges Failover zu opfern.
• AFAIK Die einzige Möglichkeit für einen DNS, ein Rechenzentrum anstelle eines anderen vorzuschlagen, besteht darin, nur mit der IP (oder den IPs) zu antworten, die diesem Rechenzentrum zugeordnet sind. Wenn das Rechenzentrum nicht mehr erreichbar ist, sind auch alle diese IP-Adressen nicht mehr erreichbar. Dies bedeutet, dass alle Versuche fehlschlagen, bis der lokale Cache - Eintrag abläuft und eine neue DNS - Suche durchgeführt wird und die neuen funktionierenden IP - Adressen abgerufen werden (ich nehme an, DNS schlägt a automatisch vor) neues Rechenzentrum, wenn einer ausfällt). "Smart DNS" kann also kein sofortiges Failover gewährleisten.
• Umgekehrt erlaubt ein DNS-Round-Robin dies. Wenn ein Rechenzentrum ausfällt, versuchen die (meisten) intelligenten HTML-Browser sofort, die anderen zwischengespeicherten A-Datensätze in ein anderes (funktionierendes) Rechenzentrum zu verschieben. DNS Round-Robin sichert also nicht die Sitzungsaffinität oder die niedrigste RTT, sondern scheint die einzige Möglichkeit zu sein, ein sofortiges Failover zu gewährleisten, wenn die Clients "intelligente" HTML-Browser sind.

Bearbeiten 2:

• Einige Leute schlagen TCP Anycast als endgültige Lösung vor. In diesem Artikel (Kapitel 6) wird erklärt, dass Anycast-Failover mit der BGP-Konvergenz zusammenhängt. Aus diesem Grund kann Anycast zwischen 15 Minuten und 20 Sekunden Zeit in Anspruch nehmen. In Netzwerken, in denen die Topologie dafür optimiert wurde, sind 20 Sekunden möglich. Wahrscheinlich können nur CDN-Betreiber solche schnellen Ausfälle gewähren.

Edit 3: *

• Ich habe ein paar DNS-Lookups und Traceroutes durchgeführt (vielleicht kann ein Experte dies noch einmal ü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 Reverse-Proxys verwendet werden können. Sie können daher nicht zum Gewähren eines sofortigen Failovers verwendet werden.
  • Akamai und LimeLight scheinen geobewusstes DNS zu verwenden. Aber! Sie geben mehrere A-Datensätze zurück. Aus Traceroutes geht hervor, dass sich die zurückgegebenen IPs im selben Rechenzentrum befinden. Ich bin verwirrt darüber, wie sie eine 100% SLA anbieten können, wenn ein Rechenzentrum ausfällt.

Wenn ich den Begriff "DNS Round Robin" verwende, meine ich im Allgemeinen im Sinne der "billigen Lastausgleichstechnik", wie sie OP beschreibt.

Dies ist jedoch nicht die einzige Möglichkeit, DNS für eine globale Hochverfügbarkeit zu verwenden. Meist fällt es Menschen mit unterschiedlichem (technischem) Hintergrund schwer, gut zu kommunizieren.

Die beste Lastverteilungsmethode (wenn Geld kein Problem ist) wird im Allgemeinen 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 des Verkehrsflusses sind in gewisser Weise für die "intelligenten" DNS-Knoten verfügbar,
5. Damit die DNS-Anforderung des Benutzers über IP Anycast an den nächsten DNS-Server weitergeleitet wird ,
6. und dieser DNS-Server verteilt über 'intelligentes' Split-Horizon-DNS einen Low-TTL-A-Record / Satz von A-Records für das nächstgelegene / beste Datencenter für diesen Endbenutzer.

Die Verwendung von Anycast für DNS ist im Allgemeinen in Ordnung, 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 weniger für längere und zustandsbehaftete HTTP-Konversationen 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 mit "set of A Records" angegeben habe, kann das, was ich als "DNS Round Robin" bezeichne, zusammen mit dem obigen Setup verwendet werden. Es wird in der Regel verwendet, um die Datenverkehrslast auf mehrere hochverfügbare Load-Balancer in jedem Rechenzentrum zu verteilen (damit Sie eine bessere Redundanz erzielen, kleinere / billigere Load-Balancer verwenden und die Unix-Netzwerkpuffer eines einzelnen Host-Servers nicht überfordern usw.).

Stimmt es also, dass bei mehreren Rechenzentren und HTTP-Datenverkehr die Verwendung von DNS RR die EINZIGE Möglichkeit ist, um eine hohe Verfügbarkeit sicherzustellen?

Nein, es ist nicht wahr, nicht wenn wir mit "DNS Round Robin" einfach mehrere A-Einträge für eine Domain verteilen wollen. Es ist jedoch richtig, dass der kluge Einsatz von DNS eine entscheidende Komponente in jedem globalen Hochverfügbarkeitssystem ist. Das Obige zeigt einen gemeinsamen (oft besten) Weg.

Bearbeiten: Das Google-Papier "Über End-to-End-Pfadinformationen hinausgehen, um die CDN-Leistung zu optimieren" scheint mir bei der globalen Lastverteilung auf dem neuesten Stand zu sein, um die bestmögliche Leistung für Endbenutzer zu erzielen.

Edit 2: Ich habe den Artikel "Why DNS Based .. GSLB .. Does not Works" gelesen, der mit OP verlinkt ist, und er bietet einen guten Überblick - ich empfehle, ihn anzuschauen . Lesen Sie es von oben.

Im Abschnitt "Die Lösung für das Browser-Caching-Problem" werden DNS-Antworten mit mehreren A-Einträgen empfohlen, die auf mehrere Rechenzentren verweisen. Dies ist die einzig mögliche Lösung für ein sofortiges Failover.

Im Abschnitt "Verwässern" im unteren Bereich wird deutlich, dass das Senden mehrerer A-Datensätze nicht geeignet ist, wenn sie auf Datencenter auf mehreren Kontinenten verweisen, da der Client eine zufällige Verbindung herstellt und daher häufig eine "langsame" Verbindung erhält. Gleichstrom auf einem anderen Kontinent. Damit dies wirklich gut funktioniert, sind mehrere Rechenzentren auf jedem Kontinent erforderlich.

Dies ist eine andere Lösung als meine Schritte 1 - 6. Ich nicht eine perfekte Antwort auf diese liefern kann, denke ich , ein DNS - Spezialist von den Gleichen von Akamai oder Google ist erforderlich, weil ein großer Teil davon läuft darauf hinaus, praktisches Know-how auf die Einschränkungen der heute bereitgestellten DNS-Caches und Browser. AFAIK, meine Schritte 1-6 sind das, was Akamai mit seinem DNS macht (kann das jemand bestätigen?).

Ich habe das Gefühl, als PM auf mobilen Browser-Portalen (Mobiltelefonen) gearbeitet zu haben, dass die Vielfalt und der Grad der totalen Zerstörung der Browser dort draußen unglaublich ist. Ich persönlich würde einer HA-Lösung nicht vertrauen, bei der das Endbenutzerterminal das Richtige tun muss. Aus diesem Grund glaube ich, dass ein globales sofortiges Failover ohne Unterbrechung einer Sitzung heute nicht möglich ist.

Ich denke, meine Schritte 1-6 oben sind die besten, die mit der Commodity-Technologie verfügbar sind. Diese Lösung bietet kein sofortiges Failover.

Ich würde es begrüßen, wenn einer dieser DNS-Spezialisten von Akamai, Google usw. vorbeikommt und mir das Gegenteil beweist. :-)

Ihre Frage lautet: "Ist DNS Round Robin der EINZIGE Weg, um ein sofortiges Failover zu gewährleisten?"

Die Antwort lautet: "DNS Round Robin ist NIE der richtige Weg, um ein sofortiges Failover zu gewährleisten."

(zumindest nicht alleine)

Der richtige Weg, um ein sofortiges Failover zu erreichen, besteht darin, das BGP4-Routing so zu verwenden, dass beide Standorte die gleichen IP-Adressen verwenden. Auf diese Weise werden die zentralen Routing- Technologien des Internets verwendet, um die Anforderungen an das richtige Rechenzentrum weiterzuleiten, anstatt die zentralen Adressierungstechnologien des Internets zu verwenden.

In der einfachsten Konfiguration wird nur ein Failover bereitgestellt. Es kann auch verwendet werden, um Anycast bereitzustellen, mit dem Vorbehalt, dass TCP-basierte Protokolle zum Zeitpunkt der Umschaltung fehlschlagen, wenn das Routing instabil ist.

Stimmt es also, dass bei mehreren Rechenzentren und HTTP-Datenverkehr die Verwendung von DNS RR die EINZIGE Möglichkeit ist, um eine hohe Verfügbarkeit sicherzustellen?

Dies ist eindeutig eine falsche Behauptung - Sie müssen sich nur Google, Akamai und Yahoo ansehen, um festzustellen, dass sie keine Round-Robin-Antworten [*] als einzige Lösung verwenden (einige verwenden sie möglicherweise teilweise, zusammen mit anderen Ansätzen) .)

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

Es ist möglich, Round-Robin-Techniken auf einem einfachen, lokalisierten Server-Ansatz anzuwenden, und Sie müssen sich keine Gedanken über Serverausfälle machen, wenn Sie auch das 'Failover' der IP-Adresse veranlassen. (Die meisten entscheiden sich jedoch für Load-Balancing-Techniken, eine einzelne IP-Adresse und Failover zwischen Load-Balancern.)

Möglicherweise benötigen Sie alle Anforderungen für eine einzelne Sitzung, um zu denselben Servern zu gelangen, möchten jedoch, dass die Anforderungen auf verschiedene regionale Servercluster verteilt werden? Round Robin ist dafür nicht geeignet: Sie müssen etwas tun, um sicherzustellen, dass ein bestimmter Client jedes Mal auf denselben physischen Servercluster zugreift (es sei denn, es treten Ausnahmen auf, z. B. ein Serverausfall). Entweder erhalten sie eine konsistente IP-Adresse von einer DNS-Abfrage oder sie werden an denselben physischen Servercluster weitergeleitet. Lösungen hierfür sind verschiedene kommerzielle und nichtkommerzielle DNS- "Load Balancer" oder (wenn Sie mehr Kontrolle über Ihr Netzwerk haben) BGP-Netzwerkwerbung. Sie könnten einfach dafür sorgen, dass die Nameserver Ihrer eigenen Domain ganz andere Antworten geben (aber da DNS-Anfragen überall gesendet werden können, haben Sie gewonnen).

[* Ich werde "Round-Robin" verwenden, da "RR" in der DNS-Terminologie "Ressourceneintrag" bedeutet.]

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

Nachfolgend meine Vermutung, wie CDN sein Netzwerk betreibt:

• Verwenden Sie Anycast DNS (von Jesper Mortensen erwähnt), um das nächstgelegene Rechenzentrum zu ermitteln
• Sie betreiben ein lokales Netzwerk, das sich über verschiedene Rechenzentren erstreckt, sodass sie auf ihren Hosts in verschiedenen Rechenzentren so etwas wie CARP ausführen können

Oder

• Sie verwenden das Gateway Load Balancing Protocol auf ihren Routern oder das Hot Standby Router Protocol (HSRP) . die sich mit Datencenter-Ausfällen befassen.
• Der Grund dafür, dass mehrere IP-Adressen enthalten sind, besteht darin, dass der Client es erneut versucht. Zum Zeitpunkt des erneuten Versuchs des Clients hat sich der Routing-Pfad möglicherweise geändert.

Im Moment funktioniert folgende Lösung für mich: - DNS gibt mehrere IP zurück, 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 Einstiegspunkt für einen Reverse-Proxy in der Amazon Cloud, der intelligent an den verfügbaren Server weitergeleitet wird (oder auf der Wartungsseite bereitgestellt wird)

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

Warum ist RFC 2782 (gilt für Services wie http, imap, ... wie MX / priority) in keinem Browser implementiert? Dinge wären einfacher ... Es gibt einen Bug, der seit zehn Jahren in Mozilla geöffnet ist !!! weil es das Ende der Industrie des kommerziellen Load-Balancers sein wird ??? Das enttäuscht mich sehr.

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

(Auch wenn es Informationen gibt, dass Anycast mit TCP nicht kompatibel ist, gibt es einige große Unternehmen, die es verwenden, wie CacheFly)

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

Der eigentliche Schlüssel ist, bereit zu sein, ein oder zwei Schluckauf zu akzeptieren, wenn ein Server ausfällt. Wenn ich den Stecker auf einen Server ziehe und ein Browser versucht, auf diesen Server zuzugreifen, tritt eine Verzögerung von ungefähr einer Minute auf, während der Browser erfährt, dass die IP-Adresse inaktiv ist. Es geht dann aber sehr schnell auf einen anderen Server.

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

Failover ist scheiße. Die beste HA nutzt die ganze Zeit alle Ressourcen.

Ich arbeite seit 1986 mit HA. Ich habe umfangreiche Schulungen zum Erstellen von Failover-Systemen absolviert und bin überhaupt kein Fan von Failover.

RR verteilt die Last auch dann, wenn sie eher passiv als aktiv ist. In unseren Server-Protokollen wird der entsprechende Prozentsatz des Datenverkehrs auf jedem Server deutlich angezeigt - und das innerhalb eines angemessenen Rahmens.

Eine andere sehr einfache Option ist die Verwendung einer niedrigen TTL (wie niedrig diese von Ihren Anforderungen abhängt) im DNS A- oder CNAME-Eintrag und die Aktualisierung dieses Eintrags, um auszuwählen, welche IP verwendet wird.

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

Ein Schlüssel in der Arbeit ist, dass eine Reihe von ISPs Resolver schlecht konfiguriert 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 leider aufgrund meiner Erfahrung mit der Migration zahlreicher Websites und Dienste.

TCP Anycast ist eigentlich sehr stabil und wird zumindest von CacheFly (seit 2002), Prolexic und BitGravity verwendet. Eine gute Präsentation zu TCP Anycast wurde unter NANOG 37: http://198.108.95.21/meetings/nanog37/presentations/matt.levine.pdf erstellt

Mehrere A-Datensätze sind die einzige Möglichkeit, einen möglichen Single Point of Failure zu beseitigen. Jede andere Lösung erzwingt, dass alle eingehenden Anforderungen ein einzelnes Gerät zwischen Server und Client durchlaufen.

Für absolute Redundanz ist es also notwendig. Das ist der Grund, warum Google es tut oder jeder andere, der sich auf eine kontinuierliche Verfügbarkeit des Dienstes verlassen möchte.

Es ist ziemlich offensichtlich, warum dies der Fall ist ... Mehrere A-Datensätze sind die einzige Möglichkeit, den Punkt zu verschieben, an dem Anforderungen an den Client-Browser weitergeleitet werden. Jede andere Methode basiert auf einem einzelnen Punkt zwischen dem Client-Browser und dem Server, an dem ein Fehler auftreten kann, der Ihren Dienst beeinträchtigt. Wenn Sie A-Datensätze verwenden, wird der Client selbst zum einzigen Fehlerpunkt von Client zu Server.

Wenn Sie nicht mehrere A-Datensätze eingerichtet haben, fragen Sie nach Ausfallzeiten ...

Diese Methode kann jedoch offensichtlich nicht für den Lastenausgleich herangezogen werden.