Ist Round-Robin-DNS "gut genug" für den Lastenausgleich statischer Inhalte?

66

Wir haben eine Reihe von gemeinsamen statischen Inhalten, die wir auf unseren Websites unter http://sstatic.net bereitstellen . Leider ist dieser Inhalt derzeit überhaupt nicht lastausgeglichen - er wird von einem einzelnen Server aus bereitgestellt. Wenn dieser Server Probleme hat, sind alle Sites, die darauf angewiesen sind, effektiv inaktiv, da die gemeinsam genutzten Ressourcen wesentliche gemeinsam genutzte Javascript-Bibliotheken und Bilder sind.

Wir suchen nach Möglichkeiten, den statischen Inhalt auf diesem Server auszugleichen, um die Abhängigkeit von einem einzelnen Server zu vermeiden.

Mir ist klar, dass Round-Robin-DNS bestenfalls eine Low-End- Lösung (manche sagen sogar Ghetto ) ist, aber ich frage mich, ob Round-Robin-DNS eine "ausreichend" Lösung für den grundlegenden Lastenausgleich statischer Inhalte ist ?

Es gibt eine Diskussion darüber in den [dns] [load-balancing] -Tags, und ich habe einige großartige Beiträge zu diesem Thema gelesen.

Mir sind die gemeinsamen Nachteile des DNS-Lastenausgleichs durch mehrere Round-Robin-A-Datensätze bekannt:

  • Normalerweise werden bei DNS-Einträgen keine Heartbeats oder Fehler erkannt. Wenn ein bestimmter Server in der Rotation ausfällt, muss sein A-Eintrag manuell aus den DNS-Einträgen entfernt werden
  • Damit dies überhaupt funktioniert, muss die TTL-Zeit (Time to Live) unbedingt recht niedrig eingestellt sein, da DNS-Einträge im gesamten Internet aggressiv zwischengespeichert werden
  • Die Client-Computer müssen sicherstellen, dass mehrere A-Datensätze vorhanden sind, und den richtigen auswählen

Aber ist Round-Robin-DNS als Starter gut genug, besser als gar nichts, während wir nach besseren Alternativen suchen und diese implementieren? Oder ist DNS Round Robin unter keinen Umständen so gut wie wertlos ?

Jeff Atwood
quelle
3
HAProxy keine Option?
Howiecamp
6
Wie ich in dem Beitrag sagte, ist dies eine spezifische Frage zu dieser Lösung - können wir beim Thema bleiben?
Jeff Atwood
4
Der Lastenausgleich ( en.wikipedia.org/wiki/Load_balancing_%28computing%29 ) unterscheidet sich stark von der Redundanz ( en.wikipedia.org/wiki/Redundancy_%28engineering%29 ). Wie Jeff in seinem einleitenden Absatz feststellte, sucht er nach einer Möglichkeit, Single Point of Failure (Redundanz) zu entfernen, nicht nach einem tatsächlichen Lastausgleich. Kann jemand nachkreuzen?
antony.trupe
3
@jeff - ein dummer Load Balancer (der ein einfaches Round-Robin-DNS ist) macht auf keinen Fall Redundanz. Es ist noch schwieriger, wenn Sie über das Ausgleichen / Redundanz über mehrere Standorte sprechen.
Alnitak,
2
@symcbean Ich bin mit den in RFC 2119 dokumentierten Terminologiebegriffen bestens vertraut. Sie sagten, der DNS-Server definiere die Einstellungsliste. Es sei denn, Sie haben eine besonders merkwürdige Definition von "Präferenzlisten", die einfach nicht wahr ist.
Alnitak,

Antworten:

57

Jeff, ich bin anderer Meinung, Load Balancing impliziert keine Redundanz, es ist genau das Gegenteil. Je mehr Server Sie haben, desto wahrscheinlicher ist ein Ausfall zu einem bestimmten Zeitpunkt. Das ist der Grund, warum Redundanz für den Lastenausgleich obligatorisch ist. Leider gibt es viele Lösungen, die nur einen Lastenausgleich ohne Integritätsprüfung ermöglichen, was zu einem weniger zuverlässigen Service führt.

DNS-Roundrobin eignet sich hervorragend zur Kapazitätserhöhung, indem die Last auf mehrere (möglicherweise geografisch verteilte) Punkte verteilt wird. Es wird jedoch kein Failover bereitgestellt. Sie müssen zunächst beschreiben, welche Art von Fehler Sie abdecken möchten. Ein Serverausfall muss lokal mithilfe eines standardmäßigen IP-Adressübernahmemechanismus (VRRP, CARP, ...) behoben werden. Ein Switch-Fehler wird durch ausfallsichere Verbindungen auf dem Server zu zwei Switches abgedeckt. Ein WAN-Verbindungsfehler kann durch einen Mehrfachverbindungsaufbau zwischen Ihnen und Ihrem Anbieter unter Verwendung eines Routing-Protokolls oder einer Layer2-Lösung (z. B. Mehrfachverbindungs-PPP) behoben werden. Ein Standortfehler sollte von BGP abgedeckt werden: Ihre IP-Adressen werden über mehrere Standorte repliziert und Sie melden sie nur dann im Netz an, wenn sie verfügbar sind.

Aus Ihrer Frage geht hervor, dass Sie nur eine Server-Failover-Lösung bereitstellen müssen. Dies ist die einfachste Lösung, da keine Hardware erforderlich ist und kein Vertrag mit einem ISP besteht. Sie müssen lediglich die entsprechende Software auf Ihrem Server einrichten, und dies ist bei weitem die billigste und zuverlässigste Lösung.

Sie haben gefragt, was passiert, wenn ein Haproxy-Computer ausfällt. Es ist das gleiche. Alle mir bekannten Personen, die Haproxy zum Lastenausgleich und für hohe Verfügbarkeit verwenden, verfügen über zwei Computer, auf denen entweder ucarp, keepalived oder heartbeat ausgeführt wird, um sicherzustellen, dass einer von ihnen immer verfügbar ist.

Ich hoffe, das hilft!

Willy Tarreau
quelle
1
Übrigens könnte Sie ein Artikel interessieren, den ich vor ungefähr 4 Jahren über diese Konzepte geschrieben habe: 1wt.eu/articles/2006_lb (nehmen Sie das PDF, das Lesen des HTML durch die Seiten ist langweilig).
Willy Tarreau
1
-1: "Bietet kein Failover" - ja, und implementiert es an der einzigen Stelle, an der die Nichtverfügbarkeit zuverlässig festgestellt werden kann - beim Client.
Symcbean
7
Überhaupt nicht. Es würde funktionieren, wenn DNS keine Caches verwenden würde. Dies ist jedoch nicht der Fall und Clients können die Aktualisierung von Caches nicht erzwingen. Sprechen Sie mit jeder Person, die regelmäßig DNS-Einträge wechselt, und Sie werden darauf hingewiesen, dass es in der Regel mehr als eine Woche dauert, bis sich 100% der DNS-Einträge ändern. DNS bietet also kein Failover.
Willy Tarreau
12
Ein einfaches Beispiel für "Load Balancing ohne Redundanz" ist RAID0.
Robbyt
1
Willy, Sie sind richtig für DNS-Einträge, deren Aktualisierung Ewigkeiten in Anspruch nimmt. RR-DNS mit Browsern wird jedoch auf Browserebene gehandhabt und überprüft nacheinander alle IP-Adressen, wenn die erste vom DNS gesendete nicht funktioniert. In diesem Fall ändern Sie niemals Ihre DNS-Einträge, sodass Sie nicht auf Aktualisierungen warten müssen.
Yvan
20

Als Lastausgleich ist es Ghetto, aber mehr oder weniger effektiv. Wenn ein Server von der Last abgefallen ist und auf mehrere Server verteilt werden soll, ist dies möglicherweise ein guter Grund, zumindest vorübergehend.

Es gibt eine Reihe von berechtigten Kritikpunkten an Round-Robin-DNS als "Lastausgleich", und ich würde es nicht empfehlen, dies zu tun, außer als kurzfristige Hilfe.

Sie sagen jedoch, dass Ihre Hauptmotivation darin besteht, eine Abhängigkeit von nur einem Server zu vermeiden. Ohne eine automatisierte Möglichkeit, tote Server aus der Rotation zu entfernen, ist dies nicht sehr wertvoll, um Ausfallzeiten zu vermeiden. (Mit einer automatisierten Methode zum Entfernen von Servern aus der Rotation und einer kurzen TTL wird es zu einem Ghetto-Failover. Manuell ist es nicht einmal das.)

Wenn einer Ihrer beiden Round-Robin-Server ausfällt, fallen 50% Ihrer Kunden aus. Dies ist besser als ein 100% iger Ausfall mit nur einem Server, aber fast jede andere Lösung, die ein echtes Failover durchgeführt hat, wäre besser als diese.

Wenn die Ausfallwahrscheinlichkeit eines Servers N ist, beträgt Ihre Wahrscheinlichkeit bei zwei Servern 2N. Ohne automatisiertes, schnelles Failover erhöht dieses Schema die Wahrscheinlichkeit, dass einige Ihrer Benutzer einen Fehler feststellen.

Wenn Sie vorhaben, den toten Server manuell außer Betrieb zu setzen, sind Sie durch die Geschwindigkeit, mit der Sie dies tun können, und die DNS-TTL begrenzt. Was ist, wenn der Server um 4 Uhr morgens stirbt? Der beste Teil eines echten Failovers besteht darin, die Nacht durchzuschlafen. Sie verwenden bereits HAProxy , daher sollten Sie mit HAProxy vertraut sein. Ich empfehle dringend, es zu verwenden, da HAProxy genau für diese Situation ausgelegt ist.

Schof
quelle
3
Völlig unangebracht, aber wir haben auch das Problem, dass mehrere HAProxy-Instanzen für das Failover benötigt werden - was ist, wenn der HAProxy-Rechner ausfällt? Thema zukünftiger Fragen, aber für dieses Thema WIRKLICH unangemessen.
Jeff Atwood
2
+1 - Die "Mit einem automatisierten Weg ... wird es Ghetto-Failover. Manuell ist es nicht einmal das." sollte in großen, fetten Buchstaben sein. DNS-Round-Robin wird zur Pflicht, wenn Sie Computer nicht überwachen und sie aus dem DNS entfernen, wenn sie ausfallen. Dies kann nur mit einer automatisierten Lösung zumutbar sein. Es gibt viel bessere Lösungen als DNS Round-Robin.
Evan Anderson
1
Stimmen Sie vollkommen zu, aber 20% Ihrer Kunden, die Sie mit Beschwerden anrufen, sind besser als 100%, die Sie mit Beschwerden anrufen.
Jeff Atwood
1
Der entscheidende Punkt (für mich), den Schof bei der Beantwortung von Jeffs Frage macht, ist, dass ohne schnelles Failover Round Robin im Laufe der Zeit mehr Kunden betroffen sind als ohne, aber jeder (häufigere) Vorfall wirkt sich eher auf eine Teilmenge als auf alle Kunden aus. Ob dies "besser" ist oder nicht, hängt vom Szenario ab, aber in den meisten Fällen würde ich sagen, dass dies nicht der Fall ist.
Helvick
1
The best part of true failover is getting to sleep through the night.Das ist eine klare Definition!
Basil Bourque
15

Round-Robin-DNS ist nicht das, was die Leute denken. Als Autor von DNS-Server-Software (namentlich BIND ) haben wir Benutzer, die sich fragen, warum ihr Round-Robin-Verfahren nicht mehr wie geplant funktioniert. Sie verstehen nicht, dass es auch bei einer TTL von 0 Sekunden zu einem gewissen Caching kommen wird, da einige Caches eine minimale Zeit (oft 30-300 Sekunden) benötigen, egal was passiert.

Auch wenn Ihre AUTH-Server ein Round-Robin-Verfahren ausführen, gibt es keine Garantie dafür, dass diejenigen, die Sie interessieren - die Caches, mit denen Ihre Benutzer sprechen - dies tun. Kurz gesagt, Round Robin garantiert aus Sicht des Kunden keine Bestellung, sondern nur das, was Ihre Authentifizierungsserver einem Cache zur Verfügung stellen.

Wenn Sie ein echtes Failover wünschen, ist DNS nur ein Schritt. Es ist keine schlechte Idee, mehr als eine IP-Adresse für zwei verschiedene Cluster aufzulisten, aber ich würde dort eine andere Technologie (z. B. einfaches Anycast) verwenden, um den tatsächlichen Lastenausgleich durchzuführen. Ich persönlich verabscheue Hardware zum Lastenausgleich, die mit DNS muckt, da es normalerweise falsch läuft. Und vergessen Sie nicht, dass DNSSEC kommt. Wenn Sie also etwas in diesem Bereich auswählen, fragen Sie Ihren Händler, was passiert, wenn Sie Ihre Zone unterzeichnen.

Michael Graff
quelle
1
und einige DNS-Server (oder die Kontrollfelder) sind so konfiguriert, dass Sie unabhängig von der Einstellung eine TTL von 7200 erhalten - einige große Hosting-Unternehmen führen diese IIRC durch.
gbjbaanb
15

Ich habe es schon mehrmals gesagt, und ich werde es noch einmal sagen - wenn Ausfallsicherheit das Problem ist, dann sind DNS-Tricks nicht die Antwort .

Mit den besten HA-Systemen können Ihre Kunden bei jeder Anfrage die exakt gleiche IP-Adresse verwenden. Dies ist der einzige Weg , um sicherzustellen , dass die Kunden den Ausfall nicht einmal bemerken.

Die Grundregel lautet also, dass echte Ausfallsicherheit Tricks auf IP- Routing- Ebene erfordert . Verwenden Sie eine Load-Balancer-Appliance oder OSPF (Equal Cost Multi-Path) oder sogar VRRP.

DNS hingegen ist eine Adressierungstechnologie . Es besteht nur darin, einen Namespace einem anderen zuzuordnen. Es wurde nicht entwickelt, um sehr kurzfristige dynamische Änderungen an dieser Zuordnung zuzulassen. Wenn Sie also versuchen, solche Änderungen vorzunehmen, werden sie von vielen Clients entweder nicht oder bestenfalls erst nach einer langen Zeit bemerkt.

Ich würde auch sagen, dass, da das Laden für Sie kein Problem ist, Sie genauso gut einen anderen Server als Hot-Standby-Server bereit haben könnten. Wenn Sie dummes Round-Robin verwenden, müssen Sie Ihre DNS-Einträge proaktiv ändern, wenn etwas kaputt geht. Sie können also auch den Hot-Standby-Server proaktiv in Aktion setzen und Ihr DNS nicht ändern.

Alnitak
quelle
7

Ich habe alle Antworten durchgelesen und eine Sache, die ich nicht gesehen habe, ist, dass die meisten modernen Webbrowser eine der alternativen IP-Adressen ausprobieren, wenn ein Server nicht antwortet. Wenn ich mich richtig erinnere, versucht Chrome sogar mehrere IP-Adressen und fährt mit dem Server fort, der zuerst antwortet. Meiner Meinung nach ist DNS Round Robin Load Balancing immer besser als nichts.

Übrigens: Ich sehe DNS Round Robin eher als einfache Lastverteilungslösung.

SjorsH
quelle
Hoppla, habe deine Antwort vor dem Posten meiner nicht gesehen, also +1 für deine, damit die Wahrheit herauskommt!
Yvan
5

Ich bin zu spät zu diesem Thread, so dass meine Antwort wahrscheinlich nur am unteren Rand schwebt, vernachlässigt, schnüffelt.

Zunächst einmal ist die richtige Antwort auf die Frage nicht die Beantwortung der Frage, sondern zu sagen:

  1. "Sie möchten wahrscheinlich stattdessen Windows- Netzwerklastenausgleich ." ODER
  2. "Gehen Sie mit der Zeit, platzieren Sie Ihre statischen Inhalte auf Cloud Files oder S3 und lassen Sie sie weltweit von einem CDN spiegeln."

NLB ist ausgereift, für die Aufgabe gut geeignet und ziemlich einfach einzurichten. Cloud-Lösungen haben ihre eigenen Vor- und Nachteile, die sich dem Rahmen dieser Frage entziehen.

Frage

Ist Round-Robin-DNS als Starter gut genug, besser als gar nichts, während wir nach besseren Alternativen suchen und diese implementieren?

Zum Beispiel zwischen 2 oder 3 statischen Webservern? Ja, es ist besser als gar nichts, da es DNS-Anbieter gibt, die DNS Round Robin in Server-Integritätsprüfungen integrieren und vorübergehend tote Server aus den DNS-Einträgen entfernen. Auf diese Weise erhalten Sie eine angemessene Lastverteilung und eine hohe Verfügbarkeit. Die Einrichtung dauert weniger als 5 Minuten.

Die von anderen in diesem Thread beschriebenen Einschränkungen gelten jedoch:

  • In aktuellen Microsoft-Browsern werden DNS-Daten 30 Minuten lang zwischengespeichert , sodass für eine Teilmenge Ihrer Benutzer eine Failover-Zeit von mehr als 30 Minuten in Abhängigkeit von ihrem anfänglichen DNS-Cache-Status ermittelt wird.
  • Was die Benutzer während des Failovers sehen, kann ... seltsam sein (Sie verwenden Auth nicht für statische Inhalte und schon gar nicht für Formularauth, aber der Link zeigt etwas, auf das Sie achten müssen).

Andere Lösungen

HAProxy ist fantastisch, aber da sich Stack Overflow auf dem Microsoft-Technologie-Stack befindet, wird die Verwendung der Microsoft-Tools für Lastenausgleich und Hochverfügbarkeit möglicherweise weniger Verwaltungsaufwand verursachen. Der Netzwerklastenausgleich behebt einen Teil des Problems, und Microsoft verfügt derzeit über einen L7-HTTP-Reverse-Proxy / Load-Balancer .

Ich habe ARR selbst noch nie verwendet, aber da es in der zweiten Hauptversion veröffentlicht wurde und von Microsoft stammt, gehe ich davon aus, dass es gut genug getestet wurde. Es sind leicht verständliche Dokumente enthalten . Hier erfahren Sie, wie statische und dynamische Inhalte auf Webnodes verteilt werden. Hier erfahren Sie, wie Sie ARR mit NLB verwenden , um sowohl eine Lastverteilung als auch eine hohe Verfügbarkeit zu erzielen.

Jesper Mortensen
quelle
5

Es ist bemerkenswert, wie viele der Mitwirkenden dazu beitragen, Fehlinformationen über DNS Round Robin als Mechanismus zur Lastverteilung und Ausfallsicherheit beizutragen. Normalerweise funktioniert es, aber Sie müssen verstehen, wie es funktioniert, und die Fehler vermeiden, die durch all diese Desinformationen verursacht werden.

1) Die TTL für DNS-Einträge, die für Round Robin verwendet werden, sollte kurz sein - aber NICHT NULL. Wenn die TTL auf Null eingestellt ist, ist dies die wichtigste Voraussetzung für die Ausfallsicherheit.

2) DNS RR breitet sich aus, verteilt aber nicht die Last, da sie über einen großen Kundenstamm hinweg dazu neigen, den DNS-Server unabhängig abzufragen, und so zu unterschiedlichen DNS-Einträgen der ersten Wahl führen. Diese verschiedenen ersten Auswahlmöglichkeiten bedeuten, dass die Clients von verschiedenen Servern bedient werden und die Last verteilt ist. Es hängt jedoch davon ab, auf welchem ​​Gerät die DNS-Abfrage ausgeführt wird und wie lange das Ergebnis gespeichert bleibt. Ein häufiges Beispiel ist, dass alle Clients hinter einem Unternehmensproxy (der die DNS-Abfrage für sie ausführt) auf einen einzelnen Server abzielen. Die Last ist verteilt - aber nicht gleichmäßig verteilt.

3) DNS RR bietet Ausfallsicherheit, solange die Client-Software dies ordnungsgemäß implementiert (und die Aufmerksamkeitsspanne von TTL und Benutzern nicht zu kurz ist). Dies liegt daran, dass DNS-Round-Robin eine geordnete Liste von Server-IP-Adressen bereitstellt und die Client-Software versuchen sollte, nacheinander eine Verbindung zu jedem dieser Server herzustellen, bis ein Server gefunden wird, der die Verbindung akzeptiert.

Wenn also der Server der ersten Wahl ausfällt, die TCP / IP-Verbindung des Clients abläuft und weder die TTL noch die Aufmerksamkeitsspanne abgelaufen sind, unternimmt die Client-Software einen weiteren Verbindungsversuch zum zweiten Eintrag in der Liste - und so weiter bis zum TTL läuft ab oder es kommt zum Ende der Liste (oder der Benutzer gibt angewidert auf).

Eine lange Liste defekter Server (Ihr Fehler) und große TCP / IP-Verbindungswiederholungslimits (Clientkonfigurationsfehler) können lange dauern, bis der Client tatsächlich einen funktionierenden Server findet. Zu kurzes TTL bedeutet, dass es sich nie ans Ende der Liste durcharbeitet, stattdessen eine neue DNS-Abfrage ausgibt und eine neue Liste bereitgestellt wird (hoffentlich in einer anderen Reihenfolge).

Manchmal hat der Client Pech und die neue Liste beginnt immer noch mit kaputten Servern. Um dem System die beste Chance zu geben, Client-Ausfallsicherheit zu bieten, sollten Sie sicherstellen, dass die TTL länger als die typische Aufmerksamkeitsspanne ist und der Client am Ende der Liste angekommen ist.

Sobald der Client einen funktionierenden Server gefunden hat, sollte er sich daran erinnern, und wenn er die nächste Verbindung herstellen muss, sollte er die Suche nicht wiederholen (es sei denn, die TTL ist abgelaufen). Eine längere TTL verringert die Häufigkeit, mit der Benutzer Verzögerungen erleben, während der Client nach einem funktionierenden Server sucht.

4) DNS TTL kommt zum Tragen, wenn Sie die DNS-Einträge manuell ändern möchten (z. B. um einen langfristig defekten Server zu entfernen), dann ermöglicht eine kurze TTL, dass sich diese Änderung schnell verbreitet (sobald Sie sich daran gewöhnt haben) Überlegen Sie, wie lange es dauern wird, bis Sie über das Problem informiert sind, und nehmen Sie diese manuelle Änderung vor. Außerdem müssen normale Clients erst nach Ablauf der TTL eine neue Suche nach einem funktionierenden Server durchführen.

DNS Round Robin verfügt über zwei herausragende Funktionen, die es in einer Vielzahl von Szenarien sehr kostengünstig machen: Zum einen ist es kostenlos und zum anderen ist es fast so geografisch verteilt wie Ihr Kundenstamm.

Es wird keine neue "Einheit des Scheiterns" eingeführt, wie es alle anderen "cleveren" Systeme tun. Es gibt keine zusätzlichen Komponenten, bei denen über eine ganze Reihe miteinander verbundener Elemente ein gemeinsamer und gleichzeitiger Ausfall auftreten kann.

Die 'cleveren' Systeme sind großartig und bieten wunderbare Mechanismen zum Koordinieren und Bereitstellen eines nahtlosen Ausgleichs- und Failover-Mechanismus. Letztendlich sind jedoch genau die Methoden, mit denen sie diese nahtlose Erfahrung ermöglichen, ihre Achillesferse - die zusätzliche komplizierte Sache, die schief gehen kann. und wenn dies der Fall ist, erhalten Sie eine nahtlose systemweite Erfahrung mit Fehlern.

JA, DNS Round Robin ist definitiv "gut genug" für Ihren ersten Schritt über einen einzelnen Server hinaus, auf dem alle statischen Inhalte an einem Ort gehostet werden.

Alter Fogy
quelle
1
Und ich habe vergessen zu sagen, dass der Mechanismus ziemlich dumm ist. Es funktioniert, wenn der Server vollständig ausfällt, aber nicht, wenn er nur "nicht hilfreich" oder "ungesund" ist. Ein Server, der lediglich HTTP 500-Fehler als Antwort auf jede einzelne Anforderung zurückgibt, wird nicht aus der DNS RR-Liste entfernt und frustriert weiterhin seinen zufälligen Anteil an Ihrer Client-Basis. Die 'cleveren' Mechanismen sollten immer einen robusten Gesundheitscheck durchführen, der einen solchen Zombie aus dem Weg räumen kann.
Old Fogy
Wenn Sie nach dem RR-DNS eine gute Logik haben, werden Sie keine 500 Fehler zurückgeben. Verwenden Sie beispielsweise Varnish mit Direktoren, und Sie können mehrere Back-End-Server abfragen, bis einer richtig antwortet. Wenn Sie RR haben, bedeutet dies, dass Sie mehrere Backends haben. Sie sollten diese also nicht behandeln, da sie alle alleine sind. Oder Sie sollten 500 Fehler überwachen und dabei automatische oder manuelle Maßnahmen ergreifen. Sie weisen jedoch zu Recht darauf hin, dass der Webserver ausgefallen sein muss, damit RR von den Browsern entsprechend verarbeitet werden kann.
Yvan
Nur ein Kommentar, um Ihnen für Ihre Antwort zu danken. Ich verstehe nicht, warum die beste Antwort RR nicht empfiehlt. Dies ist ein erster Schritt zur HA-Infrastruktur, die einfach und leicht zu implementieren ist.
Jérôme B
4

Windows Vista und Windows 7 implementieren die Clientunterstützung für Round-Robin unterschiedlich, da die IPv6-Adressauswahl auf IPv4 zurückportiert wurde. ( RFC 3484 )

Wenn Sie also eine erhebliche Anzahl von Vista, Windows 7 und Windows 2008-Benutzern haben, werden Sie wahrscheinlich feststellen, dass das Verhalten Ihrer ersatz-Load-Balancing-Lösung nicht mit Ihrem geplanten Denken übereinstimmt.

duffbeer703
quelle
Ah, danke, ausgezeichnet, ich habe nach diesem Link gesucht - ich hatte davon gehört, konnte aber den Verweis nicht finden!
Jeff Atwood
2

Ich habe immer Round-Robin-DNS mit langer TTL als Load-Balancer verwendet. Es funktioniert wirklich gut für HTTP / HTTPS-Dienste mit Browsern .

Ich bin mit Browsern sehr gestresst, da die meisten Browser eine Art "Wiederholung auf einer anderen IP" implementieren, aber ich weiß nicht, wie andere Bibliotheken oder Software mit der Lösung mit mehreren IPs umgehen würden.

Wenn der Browser keine Antwort von einem Server erhält, ruft er automatisch die nächste IP-Adresse an und bleibt dann dabei (bis er ausfällt ... und versucht es dann mit einer anderen).

Im Jahr 2007 habe ich den folgenden Test durchgeführt:

  • Fügen Sie auf meiner Website einen Iframe hinzu, der auf einen Round-Robin-Eintrag verweist, z http://roundrobin.test:10080/ping.php
  • Die Seite wurde von 3 PHP-Sockets bedient, die 3 verschiedene IP-Adressen an Port 10080 abhörten (ich konnte es mir nicht leisten, auf Port 80 zu testen, da meine Website darauf lief).
  • Ein Socket (sagen wir A ) war da, um zu überprüfen, ob der Browser eine Verbindung zum 10080-Port herstellen konnte (da viele Unternehmen nur Standardports zulassen).
  • Die anderen beiden Buchsen (z. B. B und C ) können im laufenden Betrieb aktiviert oder deaktiviert werden.

Ich ließ es eine Stunde laufen, hatte viele Daten. Das Ergebnis war, dass ich für 99,5% der Treffer auf Buchse A entweder auf Buchse B oder C getroffen habe (ich habe natürlich nicht beide gleichzeitig deaktiviert). Die Browser waren: iPhone, Chrome, Opera, MSIE 6/7/8, BlackBerry, Firefox 3 / 3.5.

Bis heute habe ich es nie wieder getestet, aber vielleicht werde ich eines Tages einen neuen Test einrichten oder den Code auf Github veröffentlichen, damit andere ihn testen können.

Wichtiger Hinweis: auch wenn es die meiste Zeit arbeiten, ist es nicht die Tatsache entfernen , dass einige Anfragen wird fehlschlagen. Ich verwende es auch für POST-Anfragen, da meine Anwendung eine Fehlermeldung zurückgibt, falls es nicht funktioniert, so dass der Benutzer die Daten erneut senden kann und höchstwahrscheinlich der Browser in diesem Fall eine andere IP verwendet und das Speichern funktioniert . Und für statische Inhalte funktioniert es wirklich großartig.

Wenn Sie also mit Browsern arbeiten, verwenden Sie Round-Robin-DNS für statische oder dynamische Inhalte. Server können auch mitten in einer Transaktion ausfallen, und selbst mit dem besten Load-Balancer können Sie einen solchen Fall nicht bewältigen. Bei dynamischen Inhalten müssen Sie Ihre Sitzungen / Datenbanken / Dateien synchronisieren, sonst können Sie dies nicht verarbeiten (dies gilt jedoch auch für einen echten Lastenausgleich).

Zusätzlicher Hinweis: Mit können Sie das Verhalten auf Ihrer eigenen IP testen iptables. Fügen Sie beispielsweise vor Ihrer Firewall-Regel für HTTP-Datenverkehr Folgendes hinzu:

iptables -A INPUT -p tcp --dport 80 --source 12.34.56.78 -j REJECT

(wo 12.34.56.78ist offensichtlich deine IP)

Nicht verwenden DROP, da der Port gefiltert bleibt und Ihr Browser bis zum Timeout wartet. Jetzt können Sie einen oder den anderen Server aktivieren oder deaktivieren. Der naheliegendste Test besteht darin, Server A zu deaktivieren, die Seite zu laden, dann Server A zu aktivieren und Server B zu deaktivieren. Wenn Sie die Seite erneut laden, werden Sie feststellen, dass der Browser etwas wartet und dann vom Server geladen wird A schon wieder. In Chrome können Sie die IP-Adresse des Servers überprüfen, indem Sie sich die Anfrage im Netzwerkfenster ansehen. In der GeneralRegisterkarte von sehen HeadersSie eine gefälschte Kopfzeile mit dem Namen Remote Address:. Dies ist die IP, von der Sie eine Antwort erhalten haben.

Wenn Sie also auf einem Server in den Wartungsmodus wechseln müssen, deaktivieren Sie einfach den HTTP / HTTPS-Verkehr mit einer iptables REJECTRegel. Alle Anforderungen werden an andere Server weitergeleitet (mit einer kurzen Wartezeit, die für Benutzer fast nicht spürbar ist).

Yvan
quelle
1

Ich denke nicht, dass es eine ausreichend gute Lösung ist, da wir annehmen, dass Sie jetzt zwei Server haben und Sie das Round-Robin-Verfahren unter Verwendung von DNS auf die IP-Adresse jedes Servers anwenden. Wenn ein Server ausfällt, wissen die DNS-Server nicht, dass er ausgefallen ist, und stellen diese IP-Adresse im Rahmen des RR-Prozesses weiterhin bereit. Dann bekommen 50% Ihrer Zielgruppe eine kaputte Seite, auf der Javascript oder Bilder fehlen.

Möglicherweise ist es einfacher, auf eine gemeinsame IP-Adresse zu verweisen, die von der Windows-NLB verwaltet wird, die zwei Server dahinter darstellt. Wenn Sie keinen Linux-Server für Ihre statischen Inhalte verwenden, kann ich mich erinnern, dass ich das irgendwo gelesen habe?

icelava
quelle
NLB ist nur ein Round-Robin-Vorgang auf den Server-NICs und nicht auf dem DNS-Server. Hierfür benötigen Sie unter Linux eine HA-Lösung - RedHat hat eine oder schauen Sie sich UltraMonkey für viele Details an.
gbjbaanb
Ja, ich weiß, was NLB tut. Ich empfehle dies über DNS RR, da ein Serverausfall nicht die Hälfte der Benutzer lähmt.
Icelava
@gbjbaanb oder anders ausgedrückt, NLB ist Round-Robin auf Schicht 2. DNS-basiertes Round-Robin befindet sich auf (oder hängt davon ab) Schicht 7
Alnitak,
1

Round-Robin-Lastenausgleich funktioniert nur, wenn Sie auch die DNS-Zone steuern, sodass Sie die Liste der Server ändern und zeitnah an die Zonenmaster übertragen können.

Wie in einer der anderen Antworten erwähnt, ist das verborgene Übel von Round-Robin das DNS-Caching, das überall zwischen Ihren Servern und dem Client auftreten kann und den kleinen Vorteil dieser Lösung vollständig zunichte macht. Selbst wenn DNS TTL auf einen sehr niedrigen Wert eingestellt ist, haben Sie wenig Kontrolle darüber, wie lange ISPs oder sogar der DNS-Cache des Clients die jetzt tote IP-Adresse aktiv halten.

Es ist sicher eine Verbesserung gegenüber einem SPOF, aber nur am Rande. Ich würde einen Blick darauf werfen, wer jemals Ihren Server hostet und sehen, was er zu bieten hat. Viele haben einen grundlegenden Load-Balancer-Service, den sie anbieten können.

Sie können auch einen einzelnen Server mit dem in S3 duplizierten statischen Inhalt haben und zu S3 CNAME wechseln, wenn Ihre primäre ausfällt. Sie werden die gleiche Verzögerung haben, jedoch ohne die Kosten für mehrere Server.

Bär
quelle
1

Dies hängt wirklich davon ab, wovon Sie sprechen und wie viele Server Sie durchlaufen. Ich hatte einmal eine Site, die auf mehreren Servern lief, und ich habe DNS-Round-Robin verwendet, da ich zu dieser Zeit hauptsächlich Anfänger war. Das war wirklich kein großes Problem. Es war kein großes Problem, weil es nicht abstürzte. Es war ein wirklich dummes, unkompliziertes System, daher hielt es und hatte ein ziemlich konstantes Verkehrsniveau. Wenn es durch den Verkehr abstürzte, war es tagsüber und etwas, worauf ich mich leicht einstellen konnte. Ich würde sagen, dass Ihr statischer Inhalt so einfach ist, dass er selbst keine Abstürze verursacht.

Wie stabil war Ihr Server, abgesehen von Hardwarefehlern usw.? Wie "spikey" ist Ihr Traffic auf diesen Inhalten? Vorausgesetzt, Apache oder so und relativ flacher Verkehr, wird es nicht viel zum Absturz bringen, und ich würde sagen, Round-Robin ist "gut genug".

Ich bin mir sicher, dass ich runtergestimmt werde, weil ich keine 100% HA-Lösung predige, aber darum haben Sie nicht gebeten. Es kommt auf das an, was Sie als Lösung akzeptieren wollen, und nicht auf den Aufwand.

UltimateBrent
quelle
1

Wenn Sie RR DNS für den Lastenausgleich verwenden, ist dies in Ordnung, aber nicht. Sie aktivieren damit einen redundanten Server. In diesem Fall ist dies nicht ausreichend.

Wie bereits in einem früheren Beitrag erwähnt, benötigen Sie etwas, um den Herzschlag zu erkennen und zu stoppen, bis er wieder auftritt.

Die gute Nachricht ist, dass Heartbeat sehr günstig erhältlich ist, entweder in Switches oder in Windows.

Keine Ahnung über andere Betriebssysteme, aber ich gehe davon aus, dass es auch da ist.


quelle
1

Ich schlage vor, dass Sie jedem Ihrer Server eine zusätzliche IP-Adresse zuweisen (zusätzlich zu der statischen IP-Adresse, die Sie beispielsweise für ssh verwenden) und diese in den DNS-Pool übernehmen. Und dann verwenden Sie eine Software, um diese IP-Adressen umzuschalten, falls ein Server ausfällt. Heartbeat oder CARP können das zum Beispiel, aber es gibt andere Lösungen.

Dies hat den Vorteil, dass sich für die Clients Ihres Dienstes nichts am Setup ändern muss und Sie sich keine Sorgen um DNS-Caching oder TTL machen müssen. Sie können jedoch den DNS-Round-Robin-Lastenausgleich nutzen. .

Peter Eisentraut
quelle
1

Es wird wahrscheinlich den Job erledigen, besonders wenn Sie mehrere IPs auf Ihren statischen Boxen haben können. Sie haben eine IP-Adresse für die Bereitstellung statischer Inhalte und eine IP-Adresse für die Verwaltung von Computern. Wenn eine Box dann ausfällt, können Sie entweder eine vorhandene HA-Lösung oder einen manuellen Eingriff verwenden, um die IP vom ausgefallenen Computer auf eines der anderen "Cluster-Mitglieder" oder einen vollständig neuen Computer zu übertragen (abhängig von der Geschwindigkeit) um das zum Laufen zu bringen).

Eine solche Lösung wird jedoch einige kleine Probleme haben. Der Lastenausgleich ist bei weitem nicht perfekt und wenn Sie sich auf manuelle Eingriffe verlassen, kann es bei einigen Besuchern zu Ausfällen kommen.

Ein Hardwarelastausgleicher kann wahrscheinlich die Last besser gemeinsam nutzen und eine "Cluster-Betriebszeit" bereitstellen, als dies bei DNS-Round-Robin der Fall ist. Auf der anderen Seite ist dies eine (oder zwei, da Sie im Idealfall die LBs in einem HA-Cluster haben) Hardware-Komponenten, die gekauft, mit Strom versorgt und gekühlt werden müssen und (möglicherweise) einige Zeit zum Kennenlernen benötigen (sofern Sie dies nicht bereits tun) haben dedizierte Load Balancer).

Vatine
quelle
1

Um kurz und bündig die Frage zu beantworten (ist Round - Robin - DNS gut genug , um als Starter, besser als nichts „ während wir erforschen und umzusetzen bessere Alternativen“ Form Load - Balancing für unsere statischen Inhalte?), Würde ich sagen , dass es ist besser als nichts, Sie sollten aber auf jeden Fall weiter nach anderen Formen des Lastenausgleichs suchen.

hmallett
quelle
1

Bei der Untersuchung des Windows-Lastenausgleichs vor einigen Jahren habe ich in einem Dokument festgestellt, dass die Microsoft-Webfarm als mehrere Lastenausgleichsgruppen mit DNS-Round-Robin konfiguriert wurde. Da in jedem Namespace mehrere DNS-Server antworten können und der Lastenausgleich von Microsoft selbstheilend ist, werden sowohl Redundanz als auch Lastenausgleich bereitgestellt.

Nachteil: Sie benötigen mindestens 4 Server (2 Server x 2 Gruppen).

Gibt es eine Möglichkeit, DNS-Round-Robin zwischen HAProxy-Servern zu betreiben, wenn Jeffs Kommentar zu Schofs Antwort beantwortet wird?

Graham Powell
quelle
0

Es hat nur einen sehr geringen Nutzen, genug, um Sie davon zu überzeugen, während Sie eine echte Lösung einsetzen. Wie Sie sagen, müssen die TTLs ziemlich niedrig eingestellt werden. Dies hat jedoch den zusätzlichen Vorteil, dass ein problematischer Computer aus dem DNS entfernt wird, während Probleme auftreten. Angenommen, Sie haben SvrA, SvrB und SvrC, die Ihre Inhalte verteilen, und SvrA geht verloren. Sie ziehen es aus dem DNS heraus und nach dem kurzen Zeitraum, der durch Ihre niedrige TTL definiert ist, stellen Resolver einen anderen Server (SvrB oder SvrC) fest, der aktiv ist. Sie erhalten SvrA wieder online und stellen es wieder in DNS. Eine kurze Ausfallzeit für einige Leute, keine für andere. Nicht großartig, aber praktikabel. Je mehr statische Server Sie in den Mix aufnehmen, desto unwahrscheinlicher ist es, dass die Mehrheit der Benutzergruppen ausfällt.

Sie werden mit Sicherheit nicht die echte ausgeglichene Verteilung erhalten, die eine echte Lastausgleichslösung aufgrund der Topologie des Internets bietet. Ich würde immer noch die Auslastung aller beteiligten Server beobachten.

Squillman
quelle
Der Inhalt ist zu 100% statisch, sodass die Last selbst auf einem Server vernachlässigbar ist. Es ist meistens Bandbreite.
Jeff Atwood
1
Alles aus der gleichen Pfeife?
Squillman
TTL wird meistens nie von DNS verwendet, auf die Sie unterwegs stoßen. Jeder DNS würde tun, was sein Administrator wünscht. Und die meisten von ihnen würden niemals eine TTL von 5 Minuten zulassen, was bedeutet, dass alle 5 Minuten die Daten von der DNS-Quelle neu geladen werden. Dies ist der beste Weg, um einen DNS-Server ohne gültigen Grund außer Betrieb zu setzen. Und Sie irren sich mit der "Grenznutzung", Google nutzt sie für alle Suchserver ... und ich bezweifle wirklich, dass sie die einzigen sind, die das tun. RR-DNS ist großartig, wenn Sie wissen, was es tut.
Yvan