OK, das wurde vor einiger Zeit gefragt, und ich bin zu spät zur Party. Trotzdem gibt es hier noch etwas hinzuzufügen.
Jackie, du hast es so ziemlich geschafft. Ihre Abbildung zeigt, wie der Lastenausgleich bei den meisten kleineren und mittelgroßen Installationen gehandhabt wird.
Lesen Sie die Einführung zum Lastenausgleich von Willy Tarreau , mit der Nakedible verknüpft ist. Es ist immer noch gültig und eine gute Einführung.
Sie müssen überlegen, wie diese Ihren Anforderungen entsprechen:
- Lastausgleicher auf TCP / IP-Ebene (Linux Virtual Server et al.). Niedrigster Overhead pro Verbindung, höchste Geschwindigkeit, HTTP kann nicht "gesehen" werden.
- HTTP-Level-Load-Balancer (HAProxy, Nginx, Apache 2.2, Pound, Microsoft ARR und mehr). Höherer Overhead, kann HTTP sehen, kann HTTP gzipen, kann SSL tun, kann einen Lastausgleich für Sticky-Sitzungen durchführen.
- HTTP-Reverse-Proxys (Apache Traffic Server, Varnish, Squid). Kann cachefähige Objekte (einige Webseiten, CSS, JS, Bilder) im RAM speichern und an nachfolgende Clients weiterleiten, ohne den Back-End-Webserver einzubeziehen. Kann oft die gleichen Aufgaben ausführen wie L7-HTTP-Load-Balancer.
Es gibt einen zweiten Balancer, da ich mir sicher bin, dass der Balancer irgendwann auch Hilfe brauchen würde.
Ja, natürlich. Der Lastenausgleich ist jedoch einfach, und häufig kann ein einzelner Lastenausgleich schnell ausgeführt werden . Ich verweise auf diesen Artikel, der im Web einen Nerv getroffen hat, als nur ein Beispiel für die Leistung, die ein einzelner moderner Server bieten kann. Verwenden Sie nicht mehrere LBs, bevor Sie müssen. Wenn Sie einen allgemeinen Ansatz benötigen, gehen Sie zu IP-Level-Load-Balancern (oder DNS Round Robin), zu HTTP-Level-Load-Balancern, zu Proxies und zu Webapp-Servern.
Hilfe zu den "Balancern" und bewährten Methoden zu deren Einrichtung.
Die Problemstelle ist die Behandlung des Sitzungszustands und bis zu einem gewissen Grad das Verhalten im Fehlerzustand. Das Einrichten der Load Balancer selbst ist vergleichsweise einfach.
Wenn Sie nur 2-4 Back-End-Webanwendungsserver verwenden, kann das statische Hashing basierend auf der Ursprungs-IP-Adresse sinnvoll sein. Dies vermeidet die Notwendigkeit eines gemeinsam genutzten Sitzungszustands zwischen Webanwendungsservern. Jeder Webanwendungsknoten sieht 1 / N des gesamten Datenverkehrs, und die Kunden-Server-Zuordnung ist im normalen Betrieb statisch. Es ist jedoch keine gute Lösung für größere Installationen.
Die beiden besten Lastausgleichsalgorithmen sind Round-Robin- Algorithmen und echte zufällige Lastausgleichsverfahren , da sie unter hoher Last und gleichmäßiger Lastverteilung ein harmloses Verhalten aufweisen . Beides setzt voraus, dass Ihre Webanwendung über einen globalen Sitzungsstatus verfügt, der auf den Webanwendungsknoten verfügbar ist. Wie dies gemacht wird, hängt vom Webapp Tech Stack ab. Hierfür stehen jedoch in der Regel Standardlösungen zur Verfügung.
Wenn weder statisches Hashing noch der Status einer gemeinsam genutzten Sitzung für Sie in Frage kommen, wählen Sie in der Regel den Lastausgleich für " Klebesitzungen " und den Sitzungsstatus pro Server. In den meisten Fällen funktioniert dies einwandfrei und es ist eine voll funktionsfähige Wahl.
Der Balancer / die Balancer würden sehen, wie viele Verbindungen sich auf jeder Apache-Instanz befinden (über eine Konfigurationsliste von internen IPs oder ewigen IPs) und die Verbindungen gleichmäßig verteilen
Ja, einige Websites verwenden dies. Es gibt viele Namen für die vielen verschiedenen Lastausgleichsalgorithmen , die existieren. Wenn Sie Round Robin oder Random (oder Weighted Round Robin, Weighted Random) auswählen können, würde ich Ihnen dies aus den oben genannten Gründen empfehlen.
Last thing: Vergessen Sie nicht, dass viele Anbieter (F5, Cisco und andere High-End-Anbieter, fx Coyote Point und Kemp Technologies zu günstigeren Preisen) ausgereifte Load-Balancing-Appliances anbieten .
