it-swarm.com.de

Mehrere Rechenzentren und HTTP-Verkehr: DNS Round Robin ist der EINZIGE Weg, um ein sofortiges Failover sicherzustellen?

Mehrere A-Einträge, die auf dieselbe Domäne verweisen, werden anscheinend fast ausschließlich zur Implementierung von DNS Round Robin als kostengünstige Lastausgleichstechnik verwendet.

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

Ein Load Balancer wird oft als bessere Wahl vorgeschlagen.

Beide Behauptungen sind nicht ganz richtig:

  1. Wenn der Datenverkehr HTTP ist, können die meisten HTML-Browser automatisch den nächsten A-Eintrag versuchen, wenn der vorherige nicht verfügbar ist, ohne eine neue DNS-Suche. 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 bei mehreren Rechenzentren und HTTP-Verkehr die Verwendung von DNS RR die EINZIGE Möglichkeit ist, ein sofortiges Failover zu gewährleisten, wenn ein Rechenzentrum ausfällt?

Vielen Dank,

Valentino

Bearbeiten:

  • Natürlich verfügt jedes Rechenzentrum über einen lokalen Load Balancer mit Ersatzlaufwerk.
  • Es ist in Ordnung, die Sitzungsaffinität für ein sofortiges Failover zu opfern.
  • AFAIK Die einzige Möglichkeit für ein 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 selbst wenn intelligente HTML-Browser sofort einen anderen A-Eintrag versuchen können, alle Versuche fehlschlagen, bis der lokale Cache-Eintrag abläuft und eine neue DNS-Suche durchgeführt wird, bei der die neuen funktionierenden IPs abgerufen werden (ich gehe davon aus, dass DNS automatisch einen Vorschlag für a vorschlägt neues Rechenzentrum bei Ausfall). "Smart DNS" kann also kein sofortiges Failover gewährleisten.
  • Umgekehrt erlaubt es ein DNS-Round-Robin. Wenn ein Rechenzentrum ausfällt, versuchen die intelligenten HTML-Browser (die meisten von ihnen) sofort die anderen zwischengespeicherten A-Datensätze, die zu einem anderen (funktionierenden) Rechenzentrum springen. DNS-Round-Robin gewährleistet also keine Sitzungsaffinität oder die niedrigste RTT, scheint jedoch die einzige Möglichkeit zu sein, ein sofortiges Failover sicherzustellen, wenn die Clients "intelligente" HTML-Browser sind.

Bearbeiten 2:

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

Edit 3: *

  • Ich habe einige 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 Operatoren wie CDN-Netzwerke und BitGravity verwenden CacheFly. Ihre Kanten können anscheinend nicht als Reverse-Proxys verwendet werden. Daher können sie nicht zum Gewähren von Instant verwendet werden Failover.
    • 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 also verwirrt darüber, wie sie 100% SLA anbieten können, wenn ein Rechenzentrum ausfällt).
79

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

Dies ist jedoch nicht die einzige Möglichkeit, DNS für eine globale Hochverfügbarkeit zu verwenden. Meistens ist es für Menschen mit unterschiedlichen (Technologie-) Hintergründen nur schwer, gut zu kommunizieren.

Die beste Lastausgleichstechnik (wenn Geld kein Problem darstellt) gilt im Allgemeinen als:

  1. Ein globales Anycast-Netzwerk von "intelligenten" DNS-Servern,
  2. und eine Reihe von global verteilten Rechenzentren,
  3. wobei jeder DNS-Knoten Split Horizon DNS implementiert,
  4. die Überwachung der Verfügbarkeit und des Verkehrsflusses steht den "intelligenten" DNS-Knoten in gewisser Weise zur Verfügung.
  5. damit die Benutzer-DNS-Anfrage über IP Anycast zum nächsten DNS-Server fließt,
  6. und dieser DNS-Server verteilt einen A-Datensatz/Satz von A-Datensätzen mit niedriger TTL für das nächstgelegene/beste Datencenter für diesen Endbenutzer über 'intelligentes' Split-Horizon-DNS.

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 DNS mit geteiltem Horizont. Eine HTTP-Sitzung zwischen einem Client und einem Server wird in einem Datencenter gespeichert. Im Allgemeinen kann kein Failover auf ein anderes Rechenzentrum durchgeführt werden, ohne die Sitzung zu unterbrechen.

Wie ich mit "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 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-Verkehr die Verwendung von DNS RR der EINZIGE Weg ist, um eine hohe Verfügbarkeit sicherzustellen?

Nein, es ist nicht wahr, nicht wenn wir mit 'DNS Round Robin' einfach das Verteilen mehrerer A-Einträge für eine Domain meinen. Es ist jedoch richtig, dass die clevere Verwendung von DNS eine wichtige Komponente in jedem globalen Hochverfügbarkeitssystem ist. Das Obige zeigt einen gängigen (oft besten) Weg.

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

Edit 2: Ich habe den Artikel gelesen "Warum DNS-basiert .. GSLB .. funktioniert nicht" das OP verknüpft mit und es ist eine gute Übersicht - ich empfehle es 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, als einzig mögliche Lösung für ein sofortiges Failover.

In dem Abschnitt "Verwässerung" im unteren Bereich wird deutlich, dass das Senden mehrerer A-Datensätze nicht cool ist, wenn sie auf Rechenzentren auf mehreren Kontinenten verweisen, da der Client eine zufällige Verbindung herstellt und daher häufig 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 bis 6. Ich kann keine perfekte Antwort darauf geben. Ich denke, ein DNS-Spezialist wie Akamai oder Google wird benötigt, da ein Großteil davon auf praktisches Know-how zu den Einschränkungen der heute bereitgestellten DNS-Caches und -Browser. AFAIK, meine Schritte 1-6 sind das, was Akamai mit seinem DNS macht (kann jemand dies bestätigen?).

Mein Gefühl - als ich als PM auf mobilen Browser-Portalen (Handys) gearbeitet habe - ist, dass die Vielfalt und das Niveau von totaler Brüchigkeit der Browser da draußen ist unglaublich. Ich persönlich würde einer HA-Lösung nicht vertrauen, bei der das Endbenutzerterminal "das Richtige tun" muss. Daher glaube ich, dass ein globales sofortiges Failover ohne Unterbrechung einer Sitzung heute nicht möglich ist.

Ich denke, meine obigen Schritte 1 bis 6 sind die besten, die mit Commodity-Technologie verfügbar sind. Diese Lösung verfügt nicht über ein sofortiges Failover.

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

34
Jesper M

Ihre Frage lautet: "Ist DNS Round Robin der EINZIGE Weg, um ein sofortiges Failover sicherzustellen?"

Die Antwort lautet: "DNS Round Robin ist NIE der richtige Weg, um ein sofortiges Failover sicherzustellen".

(zumindest nicht alleine)

Der richtige Weg, um ein sofortiges Failover zu erreichen, besteht darin, das BGP4-Routing so zu verwenden, dass beide Standorte dieselben IP-Adressen verwenden. Auf diese Weise werden die Kerntechnologien des Routings des Routings verwendet, um die Anforderungen an (== = ==) weiterzuleiten das richtige Rechenzentrum, anstatt die Kerntechnologie des Internets zu verwenden.

In der einfachsten Konfiguration bietet dies nur ein Failover. Es kann auch verwendet werden, um Anycast mit der Einschränkung bereitzustellen, dass TCP-basierte Protokolle zum Zeitpunkt der Umschaltung fehlschlagen, wenn eine Instabilität im Routing vorliegt.

18
Alnitak

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

Es 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, mit Ihrem Dienst/Ihrer Anwendung, für die Sie sich entscheiden.

Es ist möglich, Round-Robin-Techniken für einen einfachen Serveransatz am selben Ort zu verwenden und sich keine Sorgen über Serverausfälle machen zu müssen, wenn Sie auch das "Failover" der IP-Adresse veranlassen. (Die meisten entscheiden sich jedoch für Lastausgleichstechniken, eine einzelne IP-Adresse und ein Failover zwischen Lastausgleichern.)

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, das sicherstellt, dass ein bestimmter Client jedes Mal auf denselben physischen Servercluster zugreift (außer wenn Ausnahmen wie Serverausfälle auftreten). Entweder erhalten sie eine konsistente IP-Adresse von einer DNS-Abfrage oder sie werden an denselben physischen Servercluster weitergeleitet. Zu den Lösungen hierfür gehören verschiedene kommerzielle und nichtkommerzielle DNS- "Load Balancer" oder (wenn Sie mehr Kontrolle über Ihr Netzwerk haben) BGP-Netzwerkwerbung. Sie können einfach veranlassen, dass die Nameserver Ihrer eigenen 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, da "RR" in der DNS-Terminologie "Ressourceneintrag" bedeutet.]

6
jrg

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

Im Folgenden sind meine Vermutungen aufgeführt, wie CDN ihr Netzwerk betreiben:

  • Verwenden Sie Anycast DNS (von Jesper Mortensen erwähnt), um das nächstgelegene Rechenzentrum zu erhalten
  • Sie betreiben ein lokales Netzwerk , das sich über verschiedene Rechenzentren erstreckt und es ihnen ermöglicht, etwas wie [~ # ~] Karpfen [~ # ~] zu tun ] auf ihren Hosts in verschiedenen Rechenzentren

Oder

  • Sie verwenden Gateway Load Balancing Protocol auf ihren Routern oder Hot Standby Router Protocol (HSRP) . die sich mit dem Ausfall von Rechenzentren befassen.
  • Der Grund, warum sie mehrere IP-Adressen enthalten, besteht darin, dass der Client es erneut versucht und sich der Routing-Pfad möglicherweise geändert hat, wenn der Client es erneut versucht.

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 auf einen Reverse-Proxy in der Amazon Cloud, der intelligent an den verfügbaren Server übergeben wird (oder unter Wartungsseite bereitgestellt wird)

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

5
Rianto Wahyudi

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

3
pdga

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 meine Firma verwendet es seit Jahren. Es kann mit einigen Einschränkungen ziemlich gut funktionieren. Ja, es muss durch andere Maßnahmen ergänzt werden.

Der eigentliche Schlüssel ist, bereit zu sein, ein oder zwei Schluckaufe zu akzeptieren, wenn ein Server ausfällt. Wenn ich den Stecker eines Servers ziehe und ein Browser versucht, auf diesen Server zuzugreifen, tritt eine Verzögerung von etwa einer Minute auf, während der Browser erfährt, dass die IP-Adresse nicht verfügbar ist. Aber es geht dann sehr schnell zu einem anderen Server.

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

Failover ist scheiße. Die beste HA nutzt ständig alle Ressourcen.

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

Außerdem verteilt RR die Last, auch wenn sie eher passiv als aktiv ist. Unsere Serverprotokolle zeigen deutlich den angemessenen Prozentsatz des Datenverkehrs auf jedem Server - im Rahmen des Zumutbaren.

2
old_guy

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

(Auch wenn es einige Informationen gibt, mit denen Anycast schlecht ist TCP gibt es mehrere große Unternehmen, die es wie CacheFly verwenden)

2
rkthkr

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

1
Nico

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 die Einstellungen TTL) vollständig ignorieren. Es sollte nicht so sein und es gibt keine Entschuldigung dafür , aber leider aus meiner Erfahrung mit der Migration zahlreicher Websites und Dienste passiert es.

1
Twirrim

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

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

1
lg.