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

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, 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!

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.

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.

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.

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.

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.

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.

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.

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).

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?

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.

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.

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.

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. .

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).

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.

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?

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.