it-swarm.com.de

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

Wir haben eine Reihe von gemeinsam genutzten statischen Inhalten, die wir zwischen unseren Websites unter http://sstatic.net bereitstellen. Leider ist dieser Inhalt derzeit überhaupt nicht ausgeglichen - er wird von einem einzelnen Server bereitgestellt. Wenn dieser Server Probleme hat, sind alle Sites, die darauf angewiesen sind, effektiv ausgefallen, 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 einzelnen Servern zu vermeiden.

Mir ist klar, dass Round-Robin-DNS bestenfalls eine Low-End-Lösung ist (manche sagen sogar Ghetto), aber ich kann nicht anders, als mich zu fragen - Ist Round-Robin-DNS eine "gute" Lösung für den grundlegenden Lastausgleich von statischen Inhalten?

In den Tags [dns] [load-balancing] wird darüber diskutiert, und ich habe einige großartige Beiträge zu diesem Thema gelesen.

Ich bin mir der gemeinsamen Nachteile des DNS-Lastausgleichs durch mehrere Round-Robin-A-Einträge bewusst:

  • bei DNS-Einträgen gibt es normalerweise keine Herzschläge oder Fehlererkennung. Wenn also ein bestimmter Server in der Rotation ausfällt, muss sein A-Eintrag manuell aus den DNS-Einträgen entfernt werden
  • die Zeit zum Leben (TTL) muss unbedingt ziemlich niedrig eingestellt sein, damit dies überhaupt funktioniert, da DNS-Einträge im gesamten Internet aggressiv zwischengespeichert werden
  • die Client-Computer sind dafür verantwortlich, dass mehrere A-Datensätze vorhanden sind, und wählen den richtigen aus

Aber ist Round-Robin-DNS als Starter besser als nichts, "während wir nach besseren Alternativen suchen und diese implementieren", als Form des Lastausgleichs für unseren statischen Inhalt? Oder ist DNS Round Robin unter any Umständen ziemlich wertlos?

66
Jeff Atwood

Jeff, ich bin anderer Meinung, Load Balancing bedeutet keine Redundanz, im Gegenteil. Je mehr Server Sie haben, desto wahrscheinlicher ist es, dass Sie zu einem bestimmten Zeitpunkt einen Fehler haben. Aus diesem Grund ist Redundanz IS obligatorisch, wenn ein Lastausgleich durchgeführt wird), aber leider gibt es viele Lösungen, die nur einen Lastausgleich ohne Durchführung einer Integritätsprüfung ermöglichen, was zu einem weniger zuverlässigen Dienst führt.

DNS Roundrobin eignet sich hervorragend zur Erhöhung der Kapazität, indem die Last auf mehrere Punkte verteilt wird (möglicherweise geografisch verteilt). Es bietet jedoch kein Failover. Sie müssen zunächst beschreiben, welche Art von Fehler Sie abdecken möchten. Ein Serverausfall muss lokal mithilfe eines Standardmechanismus zur Übernahme von IP-Adressen (VRRP, CARP, ...) abgedeckt werden. Ein Switch-Fehler wird durch ausfallsichere Verbindungen auf dem Server zu zwei Switches abgedeckt. Ein WAN Link-Fehler kann durch ein Multi-Link-Setup zwischen Ihnen und Ihrem Provider abgedeckt werden, das entweder ein Routing-Protokoll oder eine Layer2-Lösung verwendet (z. B. Multi-Link-PPP). Ein Site-Fehler sollte auftreten von BGP abgedeckt werden: Ihre IP-Adressen werden über mehrere Standorte repliziert und Sie geben sie nur dann im Internet bekannt, 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 weder Hardware noch ein Vertrag mit einem ISP erforderlich sind. 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 für den Lastenausgleich und die Hochverfü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!

58
Willy Tarreau

Als Lastausgleich ist es ein Ghetto, aber mehr oder weniger effektiv. Wenn Sie einen Server hatten, der von der Last gefallen ist und ihn auf mehrere Server verteilen wollte, ist dies möglicherweise ein guter Grund, dies zumindest vorübergehend zu tun.

Es gibt eine Reihe berechtigter Kritikpunkte an Round-Robin-DNS als Lastausgleich, und ich würde es nicht empfehlen, dies als kurzfristige Pflasterung zu tun.

Sie sagen jedoch, dass Ihre Hauptmotivation darin besteht, eine Abhängigkeit von einem einzelnen Server zu vermeiden. Ohne eine automatisierte Methode, um tote Server aus der Rotation zu entfernen, ist dies nicht sehr wertvoll, um Ausfallzeiten zu vermeiden. (Mit einer automatisierten Methode zum Ziehen 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-Robined-Server ausfällt, werden 50% Ihrer Kunden einen Fehler erhalten. Dies ist besser als ein 100% iger Fehler 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 beträgt, beträgt Ihre Wahrscheinlichkeit bei zwei Servern 2N. Ohne automatisiertes schnelles Failover erhöht dieses Schema die Wahrscheinlichkeit, dass einige von Bei Ihren Benutzern tritt ein Fehler auf.

Wenn Sie vorhaben, den toten Server manuell aus der Rotation zu entfernen, sind Sie durch die Geschwindigkeit begrenzt, mit der Sie dies tun können und die DNS-TTL. 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 damit vertraut sein es. Ich empfehle dringend, es zu verwenden, da HAProxy genau für diese Situation entwickelt wurde.

20
Schof

Round Robin DNS ist nicht das, was die Leute denken. Als Autor der DNS-Serversoftware (nämlich BIND ) erhalten wir Benutzer, die sich fragen, warum ihr Round Robin nicht mehr wie geplant funktioniert. Sie verstehen nicht, dass selbst bei einer TTL von 0 Sekunden) eine gewisse Menge an Caching vorhanden sein wird, da einige Caches eine Mindestzeit (oft 30-300 Sekunden) festlegen, egal was passiert.

Auch wenn Ihre AUTH-Server Round-Robin-Server ausführen, gibt es keine Garantie dafür, dass diejenigen, die Ihnen wichtig sind - die Caches, mit denen Ihre Benutzer sprechen -. Kurz gesagt, Round Robin garantiert aus Sicht des Clients keine Bestellung, sondern nur das, was Ihre Authentifizierungsserver für einen Cache bereitstellen.

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 andere Technologien (wie einfache Anycasts) verwenden, um den eigentlichen Lastausgleich durchzuführen. Ich persönlich verachte Hardware-Load-Balancing-Hardware, die mit DNS Mist macht, da es normalerweise falsch ist. Und vergessen Sie nicht, dass DNSSEC kommt. Wenn Sie also etwas in diesem Bereich auswählen, fragen Sie Ihren Anbieter, was passiert, wenn Sie Ihre Zone unterschreiben.

15
Michael Graff

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 für jede Anfrage genau dieselbe IP-Adresse verwenden. Dies ist der nur Weg, um sicherzustellen, dass Clients den Fehler nicht einmal bemerken.

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

DNS hingegen ist eine Adressierung Technologie. Es besteht ausschließlich die Zuordnung von einem Namespace zu einem anderen. Es wurde nicht entwickelt, um sehr kurzfristige dynamische Änderungen an diesem Mapping zuzulassen. Wenn Sie also versuchen, solche Änderungen vorzunehmen, werden viele Clients sie entweder nicht bemerken oder es wird bestenfalls lange dauern merke sie.

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

15
Alnitak

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 der DNS-Round-Robin-Lastausgleich immer besser als nichts.

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

7
SjorsH

Ich bin zu spät zu diesem Thread, daher wird meine Antwort wahrscheinlich nur ganz unten schweben, vernachlässigt, schnüffeln.

Zunächst einmal besteht die richtige Antwort auf die Frage nicht darin, die Frage zu beantworten, sondern zu sagen:

  1. "Sie möchten wahrscheinlich stattdessen Windows Network Load Balancing ." [~ # ~] oder [~ # ~]
  2. "Gehen Sie mit der Zeit, platzieren Sie Ihren statischen Inhalt auf so etwas wie Cloud Files oder S und lassen Sie ihn weltweit von einem CDN spiegeln."

NLB ist ausgereift, gut für die Aufgabe geeignet und ziemlich einfach einzurichten. Cloud-Lösungen haben ihre eigenen Vor- und Nachteile, die außerhalb des Rahmens dieser Frage liegen.

Frage

ist Round-Robin-DNS als Starter besser als nichts, "während wir nach besseren Alternativen suchen und diese implementieren", als Form des Lastausgleichs für unseren statischen Inhalt?

Zwischen beispielsweise 2 oder 3 statischen Webservern? Ja, es ist besser als nichts, denn es gibt DNS-Anbieter, die DNS Round Robin mit Server Health Checks und integrieren entfernt vorübergehend tote Server aus den DNS-Einträgen. Auf diese Weise erhalten Sie anständig Lastverteilung und einige Hochverfügbarkeit; Die Einrichtung dauert weniger als 5 Minuten.

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

  • Aktuelle Microsoft-Browser zwischenspeichern DNS-Daten für Minuten . Sie sehen also eine Failover-Zeit von mehr als 30 Minuten für eine Teilmenge Ihrer Benutzer, abhängig von ihrem anfänglichen DNS-Cache-Status.
  • Was die Benutzer sehen während des Failovers kann ... seltsam sein (Sie verwenden keine Authentifizierung für statische Inhalte und sicherlich keine Formularauthentifizierung, 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, hat die Verwendung der Microsoft-Tools für Lastausgleich und Hochverfügbarkeit möglicherweise weniger Verwaltungsaufwand. Der Netzwerklastenausgleich behebt einen Teil des Problems, und Microsoft verfügt derzeit über einen L7-HTTP-Reverse-Proxy/Lastenausgleich .

Ich habe ARR selbst noch nie verwendet, aber da es sich um die zweite Hauptversion handelt und von Microsoft stammt, gehe ich davon aus, dass es gut genug getestet wurde. Es hat leicht verständliche Dokumente , hier ist eine, wie sie sehen Verteilung von statischen und dynamischen Inhalten auf Webknoten, und hier ist ein Stück, wie man verwendet) ARR mit NLB , um sowohl Lastverteilung als auch hohe Verfügbarkeit zu erreichen.

5
Jesper M

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

1) Das TTL bei DNS-Einträgen, die für Round Robin verwendet werden, sollte kurz sein - aber NICHT NULL. Wenn Sie das TTL bei Null) haben, wird die Hauptmethode für die Bereitstellung von Ausfallsicherheit unterbrochen .

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

3) DNS RR bietet Ausfallsicherheit, solange die Client-Software sie ordnungsgemäß implementiert (und sowohl die TTL als auch die Aufmerksamkeitsspanne des Benutzers sind nicht zu kurz). Dies liegt daran, dass DNS Round Robin eine geordnete bereitstellt Liste der Server-IP-Adressen, und die Client-Software sollte versuchen, nacheinander Kontakt mit ihnen aufzunehmen, bis ein Server gefunden wird, der die Verbindung akzeptiert.

Wenn also der Server erster Wahl ausfällt, läuft die TCP/IP-Verbindung des Clients ab und vorausgesetzt, dass weder die TTL noch die Aufmerksamkeitsspanne abgelaufen ist), unternimmt die Client-Software einen weiteren Verbindungsversuch zum zweiten Eintrag in der Liste - und so weiter, bis das TTL abläuft oder das Ende der Liste erreicht ist (oder der Benutzer angewidert aufgibt).

Eine lange Liste defekter Server (Ihre Schuld) und große Grenzwerte für TCP/IP-Verbindungswiederholungen (Fehlfunktion der Clientkonfiguration) können lange dauern, bis der Client tatsächlich einen funktionierenden Server findet. Ein zu kurzes TTL bedeutet, dass es sich nie bis zum Ende der Liste durcharbeitet und stattdessen eine neue DNS-Abfrage ausgibt und eine neue Liste erhält (hoffentlich in einer anderen Reihenfolge).

Manchmal hat der Client Pech und die neue Liste beginnt immer noch mit defekten Servern. Um dem System die beste Chance zu geben, die Ausfallsicherheit des Clients zu gewährleisten, sollten Sie sicherstellen, dass TTL länger als die typische Aufmerksamkeitsspanne ist und der Client am Ende der Liste steht.

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, TTL ist abgelaufen). A länger TTL reduziert die Häufigkeit, mit der Benutzer eine Verzögerung feststellen, während der Client nach einem funktionierenden Server sucht - und bietet so eine bessere Erfahrung.

4) DNS TTL kommt zur Geltung, wenn Sie die DNS-Einträge manuell ändern möchten (z. B. um einen langfristig defekten Server zu entfernen), dann ein kurzes TTL Ermöglicht, dass sich diese Änderung schnell verbreitet (sobald Sie damit fertig sind). Berücksichtigen Sie also das Gleichgewicht zwischen der Zeit, die benötigt wird, bis Sie über das Problem informiert sind, und nehmen Sie diese manuelle Änderung vor - und der Tatsache, dass normale Clients dies nur müssen Führen Sie eine neue Suche nach einem funktionierenden Server durch, wenn TTL abläuft).

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 Versagens" eingeführt, wie es alle anderen "cleveren" Systeme tun. Es gibt keine hinzugefügten Komponenten, bei denen ein häufiger und gleichzeitiger Ausfall über eine ganze Last miteinander verbundener Elemente auftreten könnte.

Die "cleveren" Systeme sind großartig und bieten wunderbare Mechanismen zur Koordinierung und Bereitstellung eines nahtlosen Ausgleichs- und Failover-Mechanismus. Letztendlich sind jedoch genau die Methoden, mit denen sie dieses nahtlose Erlebnis ermöglichen, ihre Achillesferse - die zusätzliche komplizierte Sache, die schief gehen kann. und wenn dies der Fall ist, wird eine nahtlose Erfahrung des Ausfalls systemweit bereitgestellt.

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.

5
Old Fogey

Windows Vista und Windows 7 Client-Unterstützung für Round Robin anders implementieren , da die Auswahl der IPv6-Adresse 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 ein Verhalten feststellen, das nicht mit Ihrem geplanten Denken in Ihrer Ersatz-Lastausgleichslösung übereinstimmt.

4
duffbeer703

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 betone mit Browsern , da die meisten Browser eine Art "Wiederholungsversuch auf einer anderen IP" implementieren, aber ich nicht wissen, wie andere Bibliotheken oder Software mit der Mehrfach-IP-Lösung umgehen würden.

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

2007 habe ich folgenden Test durchgeführt:

  • fügen Sie auf meiner Website einen Iframe hinzu, der auf einen Round-Robin-Eintrag verweist, z. B. http://roundrobin.test:10080/ping.php
  • die Seite wurde von 3 PHP Sockets, die 3 verschiedene IP-Adressen abhören, alle auf Port 10080) bereitgestellt (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 (ebenso viele) Unternehmen erlauben nur Standard-Ports)
  • andere zwei Buchsen (sagen wir [~ # ~] b [~ # ~] und [~ # ~] c [~ # ~] ) kann im laufenden Betrieb aktiviert oder deaktiviert werden.

Ich ließ es eine Stunde laufen, hatte viele Daten. Die Ergebnisse waren, dass ich für 99,5% der Treffer auf Socket [~ # ~] a [~ # ~] einen Treffer auf beiden Sockets hatte [~ # ~] b [~ # ~] oder [~ # ~] c [~ # ~] (Ich habe natürlich nicht beide gleichzeitig deaktiviert). Browser waren: iPhone, Chrome, Opera, MSIE 6/7/8, BlackBerry, Firefox 3/3.5 ... Also haben auch nicht so kompatible Browser richtig damit umgegangen!

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 funktioniert, wird die Tatsache nicht beseitigt, dass einige Anforderungen werden fehlschlagen. Ich verwende es für POST Anfragen auch, 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 verwendet Eine andere IP in diesem Fall und Speichern wird funktionieren. Und für statische Inhalte funktioniert es wirklich großartig.

Wenn Sie also mit Browsern arbeiten, verwenden Sie Round-Robin-DNS, entweder 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 behandeln. Für dynamische Inhalte müssen Sie Ihre Sitzungen/Datenbanken/Dateien synchronisieren, sonst können Sie dies nicht verarbeiten (dies gilt jedoch auch für einen echten Load-Balancer).

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

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

(wo 12.34.56.78 ist offensichtlich deine IP)

Verwenden Sie nicht DROP, da der Port gefiltert bleibt und Ihr Browser bis zum Timeout wartet. Jetzt können Sie den einen oder 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, wird im Browser ein wenig gewartet, und dann wird sie vom Server geladen Wieder ein. In Chrome können Sie die IP-Adresse des Servers anhand der Anforderung im Netzwerkfenster bestätigen. Auf der Registerkarte General von Headers sehen Sie einen gefälschten Header 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 iptablesREJECT -Regel. Alle Anforderungen werden an andere Server gesendet (mit einer kurzen Wartezeit). für Benutzer fast nicht wahrnehmbar).

2
Yvan

Ich schlage vor, dass Sie jedem Ihrer Server eine zusätzliche IP-Adresse zuweisen (zusätzlich zu der statischen IP, die Sie beispielsweise für ssh verwenden), und diese in den DNS-Pool aufnehmen. 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 nicht um DNS-Caching oder TTL kümmern müssen. Sie können jedoch weiterhin den DNS-Round-Robin-Lastenausgleich nutzen. .

1

Es wird wahrscheinlich den Job machen, besonders wenn Sie mehrere IPs auf Ihren statischen Boxen haben können. haben eine IP "statischen Inhalt bedienen" und eine IP "Maschine verwalten". Wenn eine Box dann ausfällt, können Sie entweder eine vorhandene HA-Lösung oder einen manuellen Eingriff verwenden, um die IP-Adresse des ausgefallenen Computers entweder auf einem der anderen "Cluster-Mitglieder" oder auf einem völlig neuen Computer hochzufahren (je nachdem, wie schnell sie sein würde) um das zum Laufen zu bringen).

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

Ein Hardware-Load-Balancer kann wahrscheinlich die Last besser teilen und "Cluster-Verfügbarkeit" bereitstellen als DNS-Round-Robin. Auf der anderen Seite sind dies ein (oder zwei, da Sie idealerweise die LBs in einem HA-Cluster haben) Hardware-Teile, die gekauft, mit Strom versorgt und gekühlt werden müssen und (möglicherweise) einige Zeit benötigen, um sich mit ihnen vertraut zu machen (falls Sie dies noch nicht getan haben) dedizierte Load Balancer haben).

1
Vatine

Um die Frage kurz und bündig zu beantworten (ist Round-Robin-DNS als Starter besser als nichts, "während wir nach besseren Alternativen suchen und diese implementieren", würde ich sagen, dass es ist) besser als nichts, aber Sie sollten auf jeden Fall weiter nach anderen Formen des Lastausgleichs suchen.

1
hmallett

Als ich vor einigen Jahren den Windows-Lastenausgleich untersuchte, sah ich ein Dokument, in dem angegeben wurde, dass die Webfarm von Microsoft als mehrere Lastenausgleichsgruppen mit DNS-Round-Robin zwischen ihnen konfiguriert wurde. Da in jedem Namespace mehrere DNS-Server antworten können und der Lastausgleich von Microsoft selbstheilend ist, bietet dies sowohl Redundanz als auch Lastausgleich.

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

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

1
Graham Powell

Ich denke nicht, dass dies eine ausreichend gute Lösung ist, da wir jetzt zwei Server haben und Round-Robin mit DNS an die IP-Adresse jedes Servers senden. Wenn ein Server ausfällt, wissen die DNS-Server nicht, dass er ausgefallen ist, und werden diese IP-Adresse im Rahmen des RR-Prozesses weiterhin bereitstellen. Dann erhalten 50% Ihrer Zielgruppe eine defekte Website, auf der Javascript oder Bilder fehlen.

Möglicherweise ist es einfacher, auf eine gemeinsame IP-Adresse zu verweisen, die von Windows NLB verarbeitet wird und zwei Server dahinter darstellt. Wenn ich mich daran erinnere, dass ich das irgendwo gelesen habe, es sei denn, Sie verwenden einen Linux-Server für Ihren statischen Inhalt?

1
icelava

Der Round-Robin-Lastausgleich funktioniert nur, wenn Sie auch die Kontrolle über die DNS-Zone haben, sodass Sie die Liste der Server ändern und rechtzeitig an die Zonenmaster senden 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 marginal. Ich würde einen Blick darauf werfen, wer jemals Ihren Server hostet, und sehen, was er zu bieten hat. Viele haben eine Art 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 zum S3-CNAME wechseln, wenn Ihr primärer Server ausfällt. Sie werden mit der gleichen Verzögerung enden, jedoch ohne die Kosten für mehrere Server.

1
bear

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 dies zu dieser Zeit hauptsächlich mein Anfänger war, und es war wirklich kein großes Problem. Es war kein großes Problem, weil es nicht abstürzte. Es war ein wirklich dummes, unkompliziertes System, also hielt es stand und hatte ein ziemlich konstantes Verkehrsniveau. Wenn es vom Verkehr abstürzte, war es tagsüber und etwas, um das ich mich leicht kümmern konnte. Ich würde sagen, Ihr statischer Inhalt ist so einfach, dass er selbst keine Abstürze verursacht.

Wie stabil war Ihr Server außerhalb von Hardwarefehlern usw.? Wie "spikey" ist Ihr Verkehr auf diesen Inhalten? Vorausgesetzt, Apache oder etwas anderes und relativ flacher Verkehr, wird es nicht viel abstürzen, und ich würde sagen, Round-Robin ist "gut genug".

Ich bin sicher, ich werde abgewählt, weil ich keine 100% HA-Lösung predige, aber darum haben Sie nicht gebeten. Es kommt darauf an, was Sie als Lösung akzeptieren wollen, im Vergleich zum Aufwand.

1
UltimateBrent

Wenn Sie RR-DNS für den Lastenausgleich verwenden würden, wäre dies in Ordnung, aber Sie sind es nicht. Sie verwenden es, um einen redundanten Server zu aktivieren. In diesem Fall ist dies nicht in Ordnung.

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

Die gute Nachricht ist, dass Heartbeat sehr günstig verfügbar ist, entweder in Switches oder unter Windows.

Keine Ahnung von anderen Betriebssystemen, aber ich gehe davon aus, dass es auch da ist.

1
Baron

Es hat nur einen sehr geringen Nutzen, genug, um Sie durchzuhalten, während Sie eine echte Lösung finden. Wie Sie sagen, müssen die TTLs ziemlich niedrig eingestellt werden. Dies hat jedoch den Nebeneffekt, dass ein problematischer Computer aus DNS herausgezogen wird, während Probleme auftreten. Angenommen, Sie haben SvrA, SvrB und SvrC, die Ihre Inhalte verteilen, und SvrA fällt aus. Sie ziehen es aus dem DNS heraus und nach dem kurzen Zeitraum, der durch Ihre niedrige TTL definiert ist, ermitteln Resolver einen anderen Server (SvrB oder SvrC), 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 geringer ist die Wahrscheinlichkeit, dass die Mehrheit der Benutzergruppen ausgefallen ist.

Sie werden sicherlich nicht die wirklich ausgeglichene Verteilung erhalten, die eine echte Lastausgleichslösung aufgrund der Topologie des Internets bietet. Ich würde immer noch die Last auf allen beteiligten Servern beobachten.

0
squillman