Ist es möglich, mehrere Load Balancer zu verwenden, um den Datenverkehr auf meine Anwendungsserver umzuleiten?

Ich bin neu im Bereich Load Balancing und frage mich, ob es möglich ist, mehrere Load Balancer zu verwenden, um den Datenverkehr auf meine Anwendungsserver umzuleiten. Ich verstehe nicht wirklich, wie das gemacht werden kann. Sollte ein Domainname nicht eins zu eins mit der IP-Adresse eines bestimmten Servers übereinstimmen (in diesem Fall die IP eines Load Balancers)? Wenn jeder Load Balancing Server eine andere IP hat, wie kann die Anforderung von beiden Load Balancern (oder von 10 Load Balancern oder 50 oder 100) empfangen werden?

Die Verwendung von Round-Robin-DNS eignet sich nicht besonders für Hochverfügbarkeit. Wenn ein Server offline geschaltet wird, versuchen die Clients weiterhin, eine Verbindung herzustellen, und warten auf eine Zeitüberschreitung.

Es gibt andere Möglichkeiten, dies zu erreichen.
1) Aktive / Passive Load Balancer
Grundsätzlich verarbeitet ein Load Balancer den gesamten Datenverkehr für eine IP-Adresse.
Wenn dieser Balancer ausfällt, springt der passive Knoten ein und übernimmt die IP.
Beachten Sie, dass Load Balancer so gut wie nur Datenverkehr weiterleiten. Für kleine bis mittelgroße Websites kann dies also in Ordnung sein.

2) Aktiv / Aktiv-Load-Balancer
Auf beiden (oder vielen weiteren) Load-Balancern ist dieselbe Verkehrs-IP konfiguriert.
Eingehender Datenverkehr wird an alle Load Balancer gesendet, aber ein Algorithmus wählt aus, welcher Balancer reagieren soll. Alle anderen verwerfen diesen Datenverkehr.
Einfach ausgedrückt: Sie haben zwei Load Balancer:
Wenn die anfordernde IP mit einer geraden Zahl endet, antwortet Load Balancer A, andernfalls antwortet Load Balancer B.

Natürlich muss Ihre Infrastruktur dies unterstützen, und es entsteht Overhead, da Datenverkehr gesendet, aber verworfen wird.
Weitere Informationen, zB hier: http://community.brocade.com/t5/SteelApp-Docs/Feature-Brief-Deep-dive-on-Multi-Hosted-IP-addresses-in-Stingray/ta-p/73867

Die Hochverfügbarkeit mit Load Balancern wird üblicherweise mithilfe eines VIP-Protokolls ( Virtual IP Address ) implementiert, mit dem mehrere Hosts (dh Load Balancer) auf eine von mehreren möglichen Arten auf eine gemeinsame IP-Adresse antworten können (Variationen von Aktiv / Passiv, Aktiv / Aktiv). .

Es gibt eine gute Anzahl dieser Protokolle, die ich mit regulären Load Balancern am häufigsten gesehen habe, sind VRRP und NLB (sowie viele unscheinbare Blackbox-Protokolle in Appliances). Bei der Erweiterung auf Router und Firewalls kann es beispielsweise auch zu CARP , HRSP , GLSP kommen .

Diese Strategie bietet eine Reihe von Vorteilen gegenüber dem DNS-Lastausgleich, der eine einfachere Strategie darstellt (und in einer anderen Antwort behandelt wird).

Der DNS-Lastausgleich ist beispielsweise belastet mit:

• der langsame Umsatz von DNS-Caching-Mechanismen
• begrenzte Lastausgleichsalgorithmen (normalerweise nur Round-Robin)
• das Auslagern der Lastausgleichsentscheidung an den Kunden (durch Zwischenspeichern des DNS-Datensatzes)
• Langsames Entleeren von Dienstwarteschlangen, wenn ein Server (dh ein Load Balancer) aus der Rotation genommen wird (basierend auf DNS-Datensatz-TTLs, wie sie von ISPs und Clients verarbeitet werden )
• Langsames Failover bei Ausfall des Load Balancers

Wenn Sie ein virtuelles IP-Protokoll für HA verwenden, haben Sie möglicherweise die Wahl, Folgendes zu erreichen:

• Wahl des Lastausgleichsalgorithmus unter den Lastausgleichern
• Serverzentrierte Lastausgleichsentscheidungen (Erleichterung beispielsweise von auf dem Dienstzustand basierenden Maßnahmen und Routing)
• Schnelleres Entleeren von Servicewarteschlangen, wenn ein Load Balancer aus der Rotation genommen wird.
• Sofortiges Failover bei Load Balancer-Fehler

Nur Sie wissen, welche Strategie und welches Protokoll am besten zu Ihrem Szenario passt.

Die Anforderungen: Eine praktische Lösung, die für Clouds oder jede Art von Umgebung geeignet ist, in der kein Zugriff auf Hardware-Load-Balancer, BGP-Protokolle und all diese Dinge möglich ist.

Die Nummer der Einkommensanfrage einer Anwendung ist unbekannt, sollte jedoch hoch genug sein, um eine erhöhte Lasterwartung ohne Angst zu erfüllen.

Lassen Sie uns eine Anwendung mit ähnlicher Last finden, z. B. Protokollierungsspeicher und Such-App. Ich habe einen gefunden .

Was sie wollen:

1. Verteilen Sie die Last auf die Kollektoren
2. Bieten Sie Fehlertoleranz, damit wir weiterhin Daten erfassen können, wenn einer der Kollektoren stirbt oder Probleme auftreten
3. Skalieren Sie horizontal mit dem Wachstum unserer Protokollvolumina

Was haben sie versucht und über ELB gelernt:

1. Funktioniert nicht wie erwartet
2. Latenzprobleme aufgrund erhöhter Last
3. Nicht genügend Überwachungsmöglichkeit
4. Zu viele Einschränkungen (offene Ports und Protokollnummer)

Warum haben sie sich für Route53 entschieden:

1. "Round Robin ist ein ziemlich einfacher Lastausgleich, aber unter Effizienzgesichtspunkten funktioniert er gut für uns."
2. "Wir nutzen die Route 53-Failover-Integritätsprüfungen."
3. "Wenn es ein Problem mit einem Sammler gibt, wird es von Route 53 automatisch aus dem Dienst genommen. Unsere Kunden sehen keine Auswirkungen."
4. Bei Route 53 ist kein Vorwärmen erforderlich

Die Route 53 erwies sich für Loggly als die beste Möglichkeit, unsere Hochleistungssammler zu nutzen, da das Holzvolumen, die unvorhersehbaren Schwankungen und das stetige Wachstum unseres Geschäfts enorm sind. Es entspricht den Hauptzwecken der Kollektoren: Daten mit verlustfreier Netzwerkleitungsgeschwindigkeit zu erfassen und von der Elastizität aller AWS-Services zu profitieren, die wir bei Loggly verwenden.

Dieses spezielle Beispiel zeigt, dass in einigen Szenarien (Protokollkollektor, Werbedienst oder ähnliches) der Load Balancer redundant ist und die "DNS-Health-Check-Round-Robin-Lösung" ihre Aufgabe sehr gut erfüllt.

Mal sehen, was AWS zum DNS-Failover sagt :

Mit DNS Failover kann Route 53 einen Ausfall Ihrer Website erkennen und Ihre Endbenutzer an von Ihnen angegebene alternative oder Sicherungsspeicherorte umleiten. Route 53 DNS-Failover basiert auf Integritätsprüfungen, bei denen regelmäßig Internetanforderungen an Ihre Anwendungsendpunkte von mehreren Standorten auf der ganzen Welt gestellt werden, um festzustellen, ob jeder Endpunkt Ihrer Anwendung aktiv oder inaktiv ist.

Diese Technik macht ELB (nicht erforderlich, nur für eine Notiz) robuster, wiederum basiert es auf RR + Health Check:

Route 53 DNS-Failover behandelt alle diese Fehlerszenarien durch Integration in ELB hinter den Kulissen. Nach der Aktivierung konfiguriert und verwaltet Route 53 automatisch Integritätsprüfungen für einzelne ELB-Knoten.

Mal sehen, wie es hinter den Kulissen funktioniert . Die offensichtliche Frage ist, wie mit DNS-Caching umgegangen werden soll:

Das DNS-Caching kann hier jedoch immer noch ein Problem sein (siehe unseren vorherigen Beitrag, in dem das "Long Tail" -Problem behandelt wird), wenn TTL nicht von allen Ebenen zwischen Ihrem Client und Route 53 eingehalten wird. Sie können dann eine "Cache Busting" -Technik anwenden: Senden Sie eine Anfrage an eine eindeutige Domain

("http://<unique-id>.<your-domain>") 

und definieren Sie eine Platzhalterressource

Record "*.<your-domain>" to match it.

Algolia hat eine "Client-Wiederholungsstrategie" eingeführt, die ziemlich gut funktioniert, wenn Ihr Client (in Ihrem Fall JS) damit umgehen kann:

Am Ende haben wir eine grundlegende Wiederholungsstrategie in unseren API-Clients implementiert. Jeder API-Client wurde entwickelt, um auf drei verschiedene Computer zugreifen zu können. Jeder Benutzer wurde von drei verschiedenen DNS-Einträgen repräsentiert: USERIDID-1.algolia.io, USERID-2.algolia.io und USERID-3.algolia.io. Unsere erste Implementierung bestand darin, einen der Datensätze zufällig auszuwählen und im Fehlerfall erneut mit einem anderen zu versuchen.