Layer 4 vs. Layer 7 Load Balancing

Ich versuche, mich zwischen einer Layer 4-Lösung für den Lastenausgleich für mein Rechenzentrum und einer Layer 7-Lösung zu entscheiden. Mein Anwendungsfall ist leider so einfach, dass beide Lösungen gut funktionieren, die meisten Schwächen vermeiden und die Stärken des anderen nicht wirklich ausnutzen. Unabhängig davon, welche Lösung wir letztendlich verwenden, muss sie eine hohe Verfügbarkeit und einen hohen Durchsatz aufweisen. Wir planen jedoch nur, den Lastenausgleich für einen Cluster von Webservern zu verwenden, von denen keiner Anforderungen an die Verwaltung von "Sticky" -Sitzungen (Cookie oder IP), komplexe Umschreibregeln - oder im Übrigen Umschreibregeln bei - stellt alle.

Die Load Balancer werden mit zwei Switches verbunden, die beide eine unabhängige Verbindung zur Rechenzentrumsaggregationsschicht haben und mithilfe von Rapid Spanning Tree und dem proprietären Protokoll, das die Switches für die Virtualisierung verwenden, zusammengeführt werden. Die Load Balancer werden auch über ein Crossover-Kabel miteinander vernetzt. Alle Server im Cluster sind mit beiden Switches verbunden. Alles, was die Load Balancer tun müssen, ist den Datenverkehr über sie zu lenken.

Da es sich nur um HTTP handelt, kann ich eine Layer 7-Lastausgleichslösung wie HAProxy oder Nginx verwenden. Ich könnte das LVS-Projekt aber auch mit ldirectord oder keepalived oder was auch immer verwenden.

Ich habe versucht, die Vor-und Nachteile zu trennen, wie ich sie sehe, aber es endet nur in einer Wäsche. Was würdest du empfehlen und warum? Vermisse ich etwas?

Ein nützlicher Vorteil von "L7" wie haproxy ist, dass Cookies verwendet werden können, um sicherzustellen, dass derselbe Browser denselben Back-End-Server erreicht. Dies erleichtert das Debuggen von Client-Treffern erheblich.

L4-Balancing kann einen einzelnen Benutzer auf mehreren Back-End-Servern herumspringen lassen. (Was in bestimmten Fällen vorteilhaft sein kann, aber im Sinne von Debugging / Profiling, ist die Verwendung von "L7" viel wertvoller.)

BEARBEITEN: Es gibt auch einen potenziellen Geschwindigkeitsvorteil der Verwendung von HTTP-Balancing. Mit Keep-Alives können Clients eine einzelne TCP-Sitzung zu Ihrem Balancer aufbauen und anschließend viele HITs senden, ohne dass neue TCP-Sitzungen aufgebaut werden müssen (3-Wege-Handshake). In ähnlicher Weise unterhalten viele LBs Keep-Alive-Sitzungen für Back-End-Systeme, sodass auf dem Back-End nicht mehr derselbe Handshake ausgeführt werden muss.

Ein strikter TCP-Lastausgleich führt möglicherweise nicht so einfach zu beiden Ergebnissen.

/ * FWIW: Ich würde nicht "L7" oder "L4" sagen, ich würde HTTP oder TCP sagen. Aber ich bin ein Sträfling, weil ich vermieden habe, das OSI zu verwenden, um Dinge zu beschreiben, mit denen es nicht gut übereinstimmt. * /

Ich denke, wenn Sie sich nicht sicher sind, was Sie einsetzen sollen, sollten Sie das tun, was sich für Sie einfach und natürlich anfühlt. Teste es (benutze Apache Bench?) Und stelle sicher, dass es für deine Bedürfnisse funktioniert. Für mich ist HTTP LB natürlicher.

Angesichts des Mangels an Vorteilen für Sie beim Auswuchten von L7 würde ich mich stattdessen für das Auswuchten von L4 entscheiden. Ich bin ein großer Fan davon, es so einfach wie möglich zu halten, ohne zu viel zu opfern.

In L7 müssen die Balancer die HTTP-Header in den Paketen, die sie durchlaufen, auf geeignetes Routing untersuchen, was zusätzlichen Overhead und eine geringfügige Erhöhung der Latenz für den Endbenutzer mit sich bringt. Es scheint mir eine sinnlose Ausgabe zu sein, wenn Sie dadurch nichts gewinnen.

Einige DNS-Anbieter verfügen über einfache Failover-Funktionen. Sie haben erwähnt, was Ihre Anforderungen nicht sind und was sie nicht sind, aber wenn alles, was Sie brauchen, Round Robin mit Failover ist, wenn etwas nicht funktioniert , können Sie z. B. das Failover von zoneedit.com verwenden . Abhängig von Ihren HA-Anforderungen ist dies möglicherweise ausreichend und Sie können eine ganze Ebene Ihrer Architektur überspringen.