Frage Was ist eine typische Methode zum Skalieren eines Software Load Balancers?


Ich sehe oft Web-App-Architekturen mit einem SLB / Reverse-Proxy vor einer Reihe von App-Servern.

Was passiert, wenn die Anzahl der Verbindungen zum SLB zu viele Ressourcen für ein benötigt? Single SLB effektiv zu handhaben? Für ein konkretes und dennoch übertriebenes Beispiel sollten Sie zwei Millionen persistente HTTP-Verbindungen in Betracht ziehen. Eindeutig a Single SLB kann damit nicht umgehen.

Was ist die empfohlene Konfiguration für die Skalierung? aus ein SLB?

Ist es typisch, eine Gruppe / einen Cluster von LBs zu erstellen? Wenn ja, wie verteilt sich die Client-Last auf die Gruppe der LBs?


21
2018-05-11 14:24


Ursprung


z8000, Können Sie sagen, welche Software Load-Balancer Sie verwenden? Außerdem, wenn möglich, welcher Algorithmus / welches Protokoll für den Lastausgleich verwendet wird. - Martin
Ich habe keine Präferenz. Ich habe die Frage aktualisiert, um klarer zu sein. - z8000
Es ist mir nicht klar, warum ein Load Balancer intrinsisch 2 Millionen persistente HTTP-Verbindungen nicht verarbeiten kann. - womble♦


Antworten:


Load Balancer können nicht einfach durch andere Load Balancer skaliert werden, da es in der Regel einen einzelnen Load Balancer an der Kette gibt, der die Verbindungen aufrechterhält. Allerdings haben Balancer wie LVS oder HAProxy eine absurde Kapazität im Bereich von Gbps. Sobald Sie die Möglichkeiten eines einzelnen Load Balancers (Software, Hardware, was auch immer) hinter sich gelassen haben, müssen Sie in andere Techniken wie Round-Robin-DNS wechseln.


11
2018-05-11 14:45



Recht! Die Single LB ist das "Problem". Ich stimme zu, dass der Durchsatz im Allgemeinen kein Problem darstellt. Aber ich bin besorgt über andere Ressourcen wie RAM, die in meinem Fall begrenzt ist. Es gibt nur so viele Verbindungen, die auf einem einzelnen SLB gehostet werden können, bevor RAM ausgeht. - z8000
HAProxy kann ungefähr 20k-60k aktive Sitzungen pro GB RAM verarbeiten. Ich glaube, LVS kann viel mehr, da die gespeicherten Sitzungsdaten kleiner sind. Wenn Ihnen der Arbeitsspeicher ausgegangen ist, aktualisieren Sie ihn, oder erstellen Sie einen anderen Load Balancer mit einem Round-Robin-DNS-System. - Hyppy
Für mich ergibt das Sinn! Vielen Dank. - z8000
"Load Balancer können nicht einfach durch andere Load Balancer skaliert werden" - tatsächlich kann ein einzelner ASIC-basierter L4 Load Balancer oft vor einigen L7 HTTP-basierten Load Balancern mit exzellenten Ergebnissen platziert werden. Dasselbe Grundprinzip gilt für reine Software-Implementierungen, zum Beispiel Linux LVS vor nignx. - Jesper Mortensen


OK, es gibt bereits eine akzeptierte Antwort, aber es gibt etwas hinzuzufügen. Die gängigsten "klassischen" Methoden zur Skalierung der Load Balancer-Stufe sind: (In keiner bestimmten Reihenfolge):

  • DNS Round Robin um mehrere IP-Adressen für die Domäne bekannt zu machen. Implementieren Sie für jede IP-Adresse ein hochverfügbares Serverpaar (2 Server kooperieren, um eine IP-Adresse zu jeder Zeit aufrechtzuerhalten.) Jede IP entspricht einem Load Balancer-Cluster, entweder mit Appliances oder Servern mit Load-Balancing-Software. Skalieren Sie horizontal, indem Sie nach Bedarf weitere Load-Balancer-Paare hinzufügen.

  • Routing oder Firewall Tweaks Last auf mehrere Load Balancer verteilen. Haben der Front-Router oder Front-Firewall die eingehenden Verbindungen auf mehrere IP-Adressen verteilt (die jeweils ein Load-Balancer-Paar repräsentieren) durch Hashing der Quell-IP-Adressemit mehreren gleichwertigen Routen zu den Lastenausgleichern oder ähnlichem.

  • Eine Schicht von IP-Level Load Balancer vor einer Schicht von Lastenausgleichern auf HTTP-Ebene. Der IP-Layer Load Balancing kann in ASICs / Silizium implementiert werden und kann für einige Dinge sehr schnell sein. Daher kann ein einzelnes IP-Load-Balancer-Paar häufig mit einer Reihe von Lastenausgleichseinrichtungen auf HTTP / HTTPS-Ebene mithalten und Multi-Gigabit-Leistungsstufen bereitstellen, während die Architektur einfach gehalten wird.

Um die verschiedenen Möglichkeiten, die oben genannten zu tun, vollständig zu vertiefen, wäre eine sehr lange Antwort erforderlich. Aber im Allgemeinen, Es ist nicht so schwer, die Load-Balancer-Ebene zu skalierenEs ist viel schwieriger, die Anwendungsserverebene und insbesondere die Datenbankebene zu skalieren.

Ob Sie einen Appliance-Formfaktor (F5, Cisco, A10) oder einen generischen Server (Windows / Linux + Software) wählen, ist weniger wichtig. Die wichtigsten Überlegungen beim Skalieren der Load Balancer-Ebene sind:

  • State-voll gegen staatenlos. Brauchen Sie unbedingt klebrige Sitzungen oder können Sie ohne leben? Wenn man den Staat nicht hält, wird alles einfacher.
  • "Hardware" (ASICs) versus "Software" (Allzweckserver) zum Lastenausgleich. Jeder hat seine Vor- und Nachteile, siehe die oben verlinkte HAProxy-Übersichtsdokumentation.
  • L3 / 4 (IP / TCP / IP) Lastverteilung im Vergleich zu L7 (HTTP) Lastverteilung. Noch einmal, Vor- und Nachteile, der HAProxy Doc bietet einen guten Überblick.
  • SSL-Kündigung, wo, auf den Webnodes oder auf dem Load Balancer.

Im Allgemeinen müssen Sie sich vor Ihrer Website keine Gedanken darüber machen sehr groß - ein einziger moderner Server mit fx nginx wird Zehntausende einfacher HTTP-Anfragen pro Sekunde verarbeiten. Tun Sie also keine vorzeitige Optimierung, behandeln Sie das nicht bevor Sie es tun müssen.


18
2018-05-12 09:33



Du tust es nicht wirklich brauchen Jede IP-Adresse ist über DNS RR hoch verfügbar. Browser werden im allgemeinen auf eine andere IP zurückgreifen, wenn sie nicht erreichbar sind. Wenn Sie jedoch öffentliche Webdienste haben, benötigen Sie HA für jede IP-Adresse, da viele Webdienstbibliotheken das Failover für andere IPs nicht automatisch durchführen. - rmalayter


Der Schlüssel zum Skalieren einer HTTP-Lastausgleichsebene besteht darin, zuerst eine weitere Schicht des Load-Balancing auf unterer Ebene (IP oder TCP) hinzuzufügen. Diese Schicht kann vollständig mit Open-Source-Software erstellt werden, obwohl Sie bessere Ergebnisse erzielen, wenn Sie moderne Router haben.

Die Flüsse (TCP-Sitzungen) sollten sein Hashed Verwenden von Headern wie Quell- / Ziel-IP und TCP-Ports, um zu entscheiden, an welches Frontend sie gehen. Sie benötigen auch einen Mechanismus, um sicherzustellen, dass wenn ein Frontend stirbt, es nicht mehr benutzt wird.

Es gibt verschiedene Strategien, ich werde ein Paar beschreiben, das ich in der Produktion auf Websites verwendet habe, die Millionen von Nutzern bedienen, damit Sie die Idee bekommen können. Es wäre zu lang, um alles im Detail zu erklären, aber ich hoffe, diese Antwort gibt Ihnen genug Informationen / Hinweise, um loszulegen. Um diese Lösungen zu implementieren, brauchen Sie jemanden, der sich wirklich mit Netzwerken auskennt.

Zugegebenermaßen ist das, was ich hier beschreibe, viel schwieriger zu implementieren als das, was in anderen Antworten beschrieben wird, aber dies ist wirklich State-of-the-Art, wenn Sie eine stark frequentierte Website mit großen Skalierbarkeitsproblemen und Verfügbarkeitsanforderungen über 99,9% haben. . Vorausgesetzt, Sie haben bereits einen Netzwerktechniker an Bord, kostet die Einrichtung und Ausführung (in Capex und Opex) weniger als Load Balancer-Appliances und kann fast ohne zusätzliche Kosten weiter skaliert werden (im Gegensatz zum Kauf eines neuen, noch mehr) teure Appliance, wenn Sie Ihr derzeitiges Modell hinter sich lassen).

Erste Strategie: mit einer Firewall

Vermutlich haben Sie ein paar Router, auf denen Ihre ISP-Uplinks verbunden sind. Ihr ISP stellt 2 Links zur Verfügung (aktiv / passiv, unter Verwendung von VRRP). Auf Ihren Routern verwenden Sie auch VRRP und leiten den Datenverkehr zu Ihrem öffentlichen Netzwerk an eine Firewall weiter. Die Firewalls (FW 1 und FW 2 unten) sind auch aktiv / passiv und filtern den Verkehr und senden jeden Fluss an einen gesunden Frontend-Server (Ihre HTTP Load Balancer, FE 1 und FE 2 unten).

      + -------------- + + -------------- +
      | ISP-Router A | | ISP-Router B |
      + -------------- + + -------------- +
             | |
           == # ============================ (öffentliches Netzwerk)
             | |
      + --------------- + + --------------- +
      | Ihr Router A | | Ihr Router B |
      + --------------- + + --------------- +
             | |
           == # ===== # ========== # ===== # == (RFC 1918 privates Netzwerk)
             | | | |
       + ------ + + ------ + + ------ + + ------ +
       | FW 1 | | FE 1 | | FE 2 | | FW 2 |
       + ------ + + ------ + + ------ + + ------ +

Das Ziel ist es, einen Flow wie folgt aussehen zu lassen:

  1. Der ISP leitet den Verkehr zu Ihren IP-Adressen an Ihren aktiven Router weiter.
  2. Ihre Router leiten den Datenverkehr an einen VIP weiter, der ein RFC 1918 Adresse. Dieser VIP gehört der aktiven Firewall, ähnlich wie VRRP. Wenn du OpenBSD für deine Firewall benötigst, dann kannst du verwenden KARPFEN, eine patentfreie Alternative zu VRRP / HSRP.
  3. Ihre Firewall wendet den Filter an (z. B. "nur 80 / tcp und 443 / tcp zu dieser bestimmten IP-Adresse zulassen").
  4. Ihre Firewall fungiert auch als Router und leitet die Pakete an ein gesundes Frontend weiter.
  5. Ihr Frontend beendet die TCP-Verbindung.

Jetzt geschieht die Magie in den Schritten 4 und 5, also lasst uns genauer sehen, was sie tun.

Ihre Firewall kennt die Liste der Frontends (FE 1 und FE 2), und es wird eines von ihnen basierend auf einem bestimmten Aspekt des Flusses auswählen (z. B. durch Hashing der Quell-IP und des Ports unter anderen Headern). Aber es muss auch sicherstellen, dass es Traffic an ein gesundes Frontend weiterleitet. Wenn Sie beispielsweise OpenBSD verwenden, können Sie verwenden relayd. Was relayd does ist ganz einfach: Es prüft alle Ihre Frontends (zB indem Sie ihnen eine Probe-HTTP-Anfrage senden), und wenn ein Frontend fehlerfrei ist, fügt es es einer Tabelle hinzu, die die Firewall verwendet, um den nächsten Hop der Pakete eines gegebenen Flusses auszuwählen . Wenn ein Frontend die Integritätsprüfung nicht besteht, wird es aus der Tabelle entfernt und es werden keine Pakete mehr gesendet. Beim Weiterleiten eines Pakets an ein Frontend tauscht die gesamte Firewall die Ziel-MAC-Adresse des Pakets mit der des ausgewählten Frontend aus.

In Schritt 5 werden die Pakete vom Benutzer von Ihrem Lastenausgleich empfangen (sei es Varnish, nginx oder was auch immer). Zu diesem Zeitpunkt ist das Paket immer noch an Ihre öffentliche IP-Adresse gerichtet, sodass Sie Ihre VIPs auf der Loopback-Schnittstelle aliasieren müssen. Das nennt man DSR (Direct Server Return), weil Ihre Frontends die TCP-Verbindung beenden und die Firewall dazwischen nur den Simplex-Verkehr sieht (nur eingehende Pakete). Ihr Router leitet ausgehende Pakete direkt zu den Routern des ISP zurück. Dies ist besonders gut für HTTP-Datenverkehr, da Anfragen dazu neigen, kleiner als Antworten zu sein, manchmal sogar erheblich. Nur um es klar zu sagen: Dies ist keine OpenBSD-spezifische Sache und wird häufig in stark frequentierten Websites verwendet.

Gotchas:

  • Endbenutzer verbinden sich direkt mit Ihren Frontend-Servern, weil Sie DSR verwenden. Vielleicht war es schon der Fall, aber wenn nicht, müssen Sie sicherstellen, dass sie ausreichend gesichert sind.
  • Wenn Sie OpenBSD verwenden, achten Sie darauf, dass der Kernel single threaded ist, so dass die Leistung eines einzelnen CPU-Kerns den Durchsatz einer Firewall begrenzt. Je nach Art der Netzwerkkarte und der angezeigten Paketrate kann dies ein Problem sein. Es gibt Möglichkeiten, um dieses Problem zu lösen (mehr dazu unten).

Zweite Strategie: ohne Firewall

Diese Strategie ist effizienter, aber schwieriger einzurichten, da sie mehr von den Besonderheiten der Router abhängt, die Sie haben. Die Idee ist, die Firewall oben zu umgehen und die Router die ganze Arbeit der Firewalls erledigen zu lassen.

Sie benötigen Router, die L3 / L4-ACLs pro Port unterstützen. BGP und ECMP, und Richtlinienbasiertes Routing (PBR). Nur High-End-Router unterstützen diese Funktionen, und sie haben oft zusätzliche Lizenzgebühren für die Verwendung von BGP. Dies ist in der Regel immer noch billiger als Hardware Load Balancer und ist auch viel einfacher zu skalieren. Das Gute an diesen High-End-Routern ist, dass sie eine Leitungsrate haben (z. B. können sie die Verbindung selbst auf 10-GbE-Schnittstellen immer ausschöpfen, da alle Entscheidungen, die sie treffen, von ASICs in Hardware ausgeführt werden).

Wenden Sie an den Ports, auf denen Sie Ihre ISP-Uplinks haben, die ACL an, die sich zuvor auf der Firewall befand (z. B. "nur 80 / tcp und 443 / tcp zu dieser bestimmten IP-Adresse zulassen"). Dann sollte jedes Ihrer Frontends eine BGP-Sitzung mit Ihrem Router führen. Sie können das ausgezeichnete verwenden OpenBGPD (wenn Ihre Frontends auf OpenBSD sind) oder Quagga. Ihr Router wird den Verkehr an die Frontends, die gesund sind, ECMP geben (weil sie ihre BGP-Sitzungen beibehalten). Der Router leitet den Verkehr auch mit PBR entsprechend weiter.

Verfeinerungen

  • Mit der Firewall-Paar-Lösung ist es schön, wenn Sie die TCP-Zustände über die Firewalls hinweg synchronisieren können, so dass bei Ausfall einer Firewall alles reibungslos auf die andere übergeht. Sie können dies mit erreichen pfsync.
    • Bedenke, dass pfsync wird in der Regel die Paketrate auf Ihren Firewalls verdoppeln.
    • HTTP ist ein statusloses Protokoll. Es ist also nicht das Ende der Welt, wenn Sie alle Verbindungen während eines Firewall-Failovers zurücksetzen, weil Sie sie nicht verwenden pfsync.
  • Wenn Sie einer einzelnen Firewall entwachsen sind, können Sie ECMP auf Ihrem Router verwenden, um Ihren Datenverkehr an mehr als eine Firewall zu leiten.
  • Wenn Sie mehr als ein Paar Firewalls verwenden, können Sie sie auch alle aktiv / aktiv machen. Sie können dies erreichen, indem die Firewalls eine BGP-Sitzung mit den Routern aufrechterhalten, ähnlich wie die Frontends eine im 2. Design ohne Firewalls verwalten müssen.

Probe relayd Konfig

Siehe auch HOWTO unter https://calomel.org/relayd.html

vip = "1.2.3.4" # Ihre öffentliche IP-Adresse
               # (Sie können mehrere haben, müssen aber nicht)
fe1 = "10.1.2.101"
fe2 = "10.1.2.102"
fe3 = "10.1.2.103"
fe4 = "10.1.2.104" # Sie können eine beliebige Anzahl von Frontends haben.
int_if = "em0"
Tabelle <fe> {$ fe1 Wiederholung 2, $ fe2 Wiederholung 2, $ fe3 Wiederholung 2, $ fe4 Wiederholung 2}
Tabelle <Fallback> {127.0.0.1}

Webtraffic umleiten {
        höre auf $ vip port 80
        Sitzungszeitlimit 60
        Route zu <fe> check http "/healthcheck.html" Digest "(die sha1sum von healthcheck.html)" Schnittstelle $ int_if
}

9
2017-07-12 05:58





Persönlich gehe ich zu einfacheren, weniger konfigurierbaren Hardware Load Balancern über - wie Cisco ACE / ASAs, Foundry ServerIrons, vielleicht sogar Zeus ZXTMs (eine SW LB, die für sehr schwere Lasten entwickelt wurde).


2
2018-05-11 14:32



Mit anderen Worten Maßstab oben? Solch ein LB wird immer noch bei einer Anzahl von Verbindungen (usw.) ausgereizt sein. Was dann? Das ist wirklich meine Frage. Vielen Dank! - z8000
Wirklich große Websites verwenden einfach viele Heavy-Duty-LBs, die unter einer Art DNS-Round-Robin laufen - für die meisten ist es gut genug und kann Hunderte von Millionen Verbindungen verarbeiten. Da steht die Frage, warum so viele Verbindungen natürlich offen bleiben müssen ... - Chopper3
Ist dass intern RRDNS meinst du? Ordentlich, ich habe nicht daran gedacht. Re: offene Verbindungen ... Ich erkunde Optionen für eine App, die das Senden von Updates an verbundene Clients im Laufe der Zeit erfordert, wenn Ereignisse irgendwo im Backend auftreten. Ich bin zerrissen zwischen einem benutzerdefinierten TCP-Server oder viele offene HTTP-Verbindungen hinter einem SLB. Vielen Dank für Ihre Kommentare. - z8000
Ich würde denken, dass es externe RRDNS sein müsste. Zum Beispiel würde Twitter.com RRDNS verwenden, um Anfragen auf eine von vielen großen LBs aufzulösen und zu verteilen, die dann die Last auf die Server verteilen würde. - Robert
Ja, Robert, Sie haben recht, zum Beispiel verwenden wir Cisco GSS-Boxen, um Site-by-Site-RR zu erstellen. - Chopper3


Vielleicht, anstatt ständig so viele offene Verbindungen zu haben, um Antworten zu senden, programmieren Sie Ihre Anwendung so, dass die Clients Ihre Server regelmäßig so oft wie nötig abfragen.

Benötigt das, was Sie tun, tatsächlich eine Antwort in dieser Millisekunde oder kann ein Kunde 15/20 Sekunden bis zur nächsten Umfrage warten?


1
2017-07-08 18:41





Ein typischer Ansatz wäre die Erstellung eines Clusters, der groß genug ist, um die erforderliche Last zu bewältigen und einen SLB zu verwenden, der einen deterministischen Lastausgleich durchführen kann (für den Fall persistenter Verbindungen).

So etwas wie CARP verwendet einen Hash der anfordernden IP, um zu bestimmen, welcher Back-End-Webserver die Anforderung verarbeitet. Dies sollte deterministisch sein, aber nicht sehr nützlich, wenn sich vor Ihrem Load-Balancer eine Firewall oder NAT befindet.
Sie können auch etwas wie finden IPVS nützlich, wenn Sie unter Linux laufen.


0
2018-05-11 14:48



Was Sie über Karpfen behaupten, ist so weit weg von dem, wie es funktioniert, ich würde nicht wissen, wo ich anfangen soll! + -0 für die Erwähnung von IPVS. - 3molo
@ 3molo ... nicht wahr? siehe net.inet.carp.arpbalance bei linux.com/archive/feed/35482   "..CARP source - Hasht die Ursprungs-IP einer Anfrage. Der Hash wird dann verwendet, um einen virtuellen Host aus dem verfügbaren Pool auszuwählen, um die Anfrage zu bearbeiten." - Paul