Frage Load Balancing Best Practices für die Persistenz


Wir betreiben eine Web-Anwendung, die Web-APIs für eine wachsende Anzahl von Clients bereitstellt. Zu Beginn waren die Clients in der Regel zu Hause, im Büro oder in anderen drahtlosen Netzwerken, die Chunked-HTTP-Uploads an unsere API übermittelten. Wir haben uns jetzt darauf konzentriert, mehr mobile Kunden zu betreuen. Die Dateien reichen von ein paar k bis zu mehreren Gigs, werden in kleinere Stücke zerlegt und auf unserer API wieder zusammengesetzt.

Unser derzeitiger Lastenausgleich wird auf zwei Ebenen durchgeführt. Zuerst verwenden wir Round-Robin-DNS, um mehrere A-Datensätze für unsere api.company.com-Adresse zu bewerben. Bei jedem IP hosten wir ein Linux LVS: http://www.linuxvirtualserver.org/Load-Balancer, der die Quell-IP-Adresse einer Anfrage untersucht, um zu bestimmen, an welchen API-Server die Verbindung übergeben werden soll. Diese LVS-Boxen sind mit Heartbeat konfiguriert, um externe VIPs und interne Gateway-IPs voneinander zu übernehmen.

In letzter Zeit haben wir zwei neue Fehlerbedingungen gesehen.

Der erste Fehler ist, wo Clients oszillieren oder von einem LVS zu einem anderen migrieren. Dies führt wiederum dazu, dass unsere Load Balancer den Überblick über die permanente Verbindung verlieren und den Datenverkehr an einen neuen API-Server senden, wodurch der Chunked-Upload auf zwei oder mehr Servern unterbrochen wird. Unsere Absicht war, dass der Round Robin DNS-TTL-Wert für unsere api.company.com (die wir auf 1 Stunde festgelegt haben) von Downstream-Caching-Nameservern, Betriebssystem-Caching-Schichten und Client-Anwendungsschichten geehrt wird. Dieser Fehler tritt bei ungefähr 15% unserer Uploads auf.

Der zweite Fehler, den wir viel seltener gesehen haben. Ein Client wird den Datenverkehr zu einer LVS-Box initiieren und auf den dahinter liegenden Realserver A weitergeleitet. Danach wird der Client über eine neue Quell-IP-Adresse hereinkommen, die die LVS-Box nicht erkennt, wodurch laufender Verkehr zu Realserver B auch hinter diesem LVS geleitet wird.

Angesichts unserer Architektur, wie sie oben beschrieben wurde, würde ich gerne wissen, welche Erfahrungen die Menschen mit einem besseren Ansatz machen, der es uns ermöglicht, jeden der oben genannten Fehlerfälle eleganter zu behandeln?

Bearbeiten 5/3/2010:

Das sieht wie das aus, was wir brauchen. Weighted GSLB Hashing auf der Quell-IP-Adresse.

http://www.brocade.com/support/Product_Manuals/ServerIron_ADXGlobalServer_LoadBalancingGuide/gslb.2.11.html#271674


8
2018-04-20 02:00


Ursprung


Ihre Frage ist momentan nicht spezifisch für Mobilgeräte. Vielleicht würden Sie überlegen, es zu überarbeiten und zu vereinfachen? - Jesper Mortensen


Antworten:


Die kanonische Lösung ist, sich nicht auf die IP-Adresse des Endanwenders zu verlassen, sondern stattdessen Verwenden Sie einen Layer 7 (HTTP / HTTPS) Load Balancer mit "Sticky Sessions" über einen Cookie.

Sticky-Sitzungen bedeutet, dass der Load Balancer immer einen bestimmten Client an denselben Backend-Server weiterleitet. Via Cookie bedeutet, dass der Load Balancer (der selbst ein voll funktionsfähiges HTTP-Gerät ist) einen Cookie einfügt (den der Load Balancer automatisch erstellt und verwaltet), um sich zu merken, welcher Backend-Server eine bestimmte HTTP-Verbindung verwenden soll.

Der Hauptnachteil von Sticky-Sessions ist, dass die Beckend-Serverlast etwas uneben werden kann. Der Lastenausgleich kann die Last nur dann gerecht verteilen, wenn neue Verbindungen hergestellt werden. Da jedoch bestehende Verbindungen in Ihrem Szenario eine lange Lebensdauer haben, wird die Last in einigen Zeiträumen nicht vollständig verteilt.

Fast jeder Layer 7 Load Balancer sollte dazu in der Lage sein. Unter Unix / Linux sind einige gängige Beispiele nginx, HAProxy, Apsis Pound, Apache 2.2 mit mod_proxy und viele mehr. Unter Windows 2008+ gibt es Microsoft Application Request Routing. Als Geräte sind Coyote Point, loadbalancer.org, Kemp und Barracuda im Low-End-Bereich üblich; und F5, Citrix NetScaler und andere in High-End.

Willy Tarreau, der Autor von HAProxy, hat eine schöner Überblick über die Lastverteilungstechniken hier.

Über den DNS Round Robin:

Unsere Absicht war, dass der Round Robin DNS-TTL-Wert für unsere api.company.com (die wir auf 1 Stunde festgelegt haben) von Downstream-Caching-Nameservern, Betriebssystem-Caching-Schichten und Client-Anwendungsschichten geehrt wird.

Es wird nicht sein. Und DNS Round Robin eignet sich nicht zum Lastenausgleich. Und wenn nichts anderes Sie überzeugt, denken Sie daran Moderne Clients bevorzugen möglicherweise einen Host über alle anderen aufgrund der längsten Präfix-Übereinstimmung pinning, wenn der mobile Client die IP-Adresse ändert, kann er zu einem anderen RR-Host wechseln.

Grundsätzlich ist es in Ordnung, DNS-Round-Robin als grobkörnige Lastverteilung zu verwenden, indem zwei oder mehr RR-Datensätze auf hochverfügbare IP-Adressen geleitet werden, die von echten Lastenausgleichern in aktiv / passiv oder aktiv / aktiv HA behandelt werden. Und wenn Sie das tun, können Sie diese DNS-RR-Einträge auch mit langen Time To Live-Werten versorgen, da die zugehörigen IP-Adressen bereits hochverfügbar sind.


11
2018-04-22 13:30



Vielen Dank. Wir sind im Aktiv / Aktiv-Modus mit LVS. Die IPs sind hochverfügbar und wir haben viel Kontrolle über die Clients, wenn wir sie selbst schreiben, und sie verlassen sich auf unseren API-Server, der, wie oben beschrieben, nicht vollständig zustandslos ist. Ich habe das Betriebssystem-Caching-Problem auf meiner Linux-Box bei der Arbeit (es hat kein Caching aktiviert) sowie meinen Mac OSX-Laptop zu Hause getestet (es speichert die Betriebssystemebene, die die IP an das eine oder das andere "anheft") ). - dmourati
Ich habe meinen eigenen DNS-Server geschrieben, um das Round-Robin-Problem zu beheben. Es untersucht die Quell-IP-Adresse und verwendet einen Hash, um mit einem konsistenten Datensatz zu antworten. Scheint zu funktionieren und reduzierte unser "Pop-Switch" -Problem um den Faktor 10. - dmourati


Um Ihre Frage zu Alternativen zu beantworten: Sie können einen soliden Layer-7 Load Balancing durchführen HAProxy.

Was die Behebung der LVS-Affinitätsprobleme anbelangt, bin ich ein wenig auf solide Ideen fixiert. Es könnte so einfach wie ein Timeout oder Überlauf sein. Einige mobile Clients wechseln IP-Adressen, während sie mit dem Netzwerk verbunden sind. Vielleicht ist dies die Quelle deiner Leiden? Ich würde zumindest vorschlagen, dass Sie die Affinitätsgranularität auf mindestens eine Klasse C verteilen.


4
2018-04-20 02:53



HAProxy war definitiv im Visier. Ich habe einen ziemlich interessanten Artikel über L4 / L7 Load Balancing gelesen. blog.loadbalancer.org/why-spieler-7-sucks   Meine Meinung: Ich möchte dies in den Händen der Anwendung lassen. Irgendwelche zusätzlichen "Smart", die ich der LB-Schicht hinzufüge, müssen nur gepatcht / readdressiert werden, wenn wir unsere Anwendung ändern. Die Lösung des Problems in der Anwendung selbst bedeutet, dass wir die Dinge bei der LB optimieren und feinabstimmen können, während wir darauf vertrauen, dass wir auch bei einem LB-Fehltritt die Daten erhalten. - dmourati
+1 für HAProxy. - Marco Ramos
@dmourati: Entschuldigung, aber dieser Blogpost ist voller ungenauer Annahmen. Folge ihm nicht blind. Es ist absolut richtig, dass eine "Shared Nothing" -Architektur für die Webanwendungsserver "am besten" ist. In diesem Fall sollten Sie Round Robin oder Random load balancing verwenden. Solange Sie jedoch HTTP-Uploads mit mehreren GBs durchführen, verfügen Sie über langlebige HTTP-Konversationen, und ein HTTP-Lastenausgleich ist besser geeignet, um diesen langen HTTP-Austausch zu verstehen und korrekt zu handeln. Die Verwendung eines HTTP-Balancers schließt nicht aus, dass Ihr Backend-App-Code "intelligenter" wird, Sie können dies jederzeit tun. - Jesper Mortensen