2013-03-16 12 views
43

kann ich zwei Setups vorstellen:Haproxy vor Lack oder umgekehrt?

Load Balance dann Cache

      +-- Cache server #1 (varnish) -- App server #1 
         /
Load Balancer (haproxy)-+---- Cache server #2 (varnish) -- App server #2 
         \ 
          +-- Cache server #3 (varnish) -- App server #3 

Cache dann Lastenausgleich

             +-- App server #1 
                /
Cache Server (varnish) --- Load Balancer (haproxy) --+---- App server #2 
                 \ 
                 +-- App server #3 

Das Problem mit dem ersten Setup ist, dass es mehrere Caches, die viel Speicher verschwenden und den Cachespeicher komplizierter machen.

Das Problem mit dem zweiten Setup ist, dass es einen Leistungseinbruch und zwei einzelne Fehlerpunkte (Lack und Haproxy) anstelle von nur einem (Haproxy) geben könnte?

Ich bin versucht, mit dem zweiten Setup zu gehen, weil sowohl Haproxy als auch Firnis schnell und stabil sein sollen: Was ist deine Meinung?

Antwort

11

Beide haben Vor- und Nachteile. Mehr im Blog-Artikel unten, einschließlich der Konfiguration für beide HAProxy und Lack: http://blog.exceliance.fr/2012/08/25/haproxy-varnish-and-the-single-hostname-website/

Baptiste

+7

Diese Antwort wäre nützlicher, wenn Sie die relevanten Informationen aus dem Artikel hinzufügen und nicht nur verlinken möchten es. – ASGM

+0

@Baptiste: Der Autor des Blog-Artikels (Sie?) Schlägt eine interessante Architektur vor. Aber ich bin mir seiner Definition von "dynamischem Inhalt" nicht sicher. Beispielsweise kann die Startseite eines Nutzers 90% Inhalte enthalten, die mit jedem anderen Nutzer geteilt werden (Banner, Fußzeile, Anzeigen, heutige Nachrichten ...), und nur 10% wirklich personalisierte Inhalte (von denen sich die meisten wahrscheinlich nicht jede Sekunde ändern). Daher wäre es schön, die ESI-Funktion von Varnish zu verwenden, um den gemeinsamen abspeicherbaren Teil der Homepage des Benutzers tatsächlich zwischenzuspeichern. Und kann Varnish nicht die persönlichen, aber ziemlich statischen Daten des Benutzers zwischenspeichern? Danke für deinen Rat. – MiniQuark

36

ich ein ähnliches Setup (nur ein paar Jahre zurück für eine beschäftigte Web-Anwendung gebaut Ich habe es mit Tintenfisch statt von Varnish), und es hat gut geklappt.

würde ich mit Ihrem ersten Setup empfehlen - mit zwei Modifikationen (HAProxy> Varnish):

  1. hinzufügen sekundären HAProxy Server mit keepalived und einem gemeinsamen virtuellen IP
  2. Verwenden Sie den balance uri Load-Balancing-Algorithmus zur Optimierung Cache-Treffer

Pro:

  • Seelisches mit HAProxy (x2) und Lack (x3) Redundanz
  • bessere Trefferquote Effizienz auf Varnish mit HAProxy URI Load-Balancing-Option
  • Bessere Leistung von den Cache-Servern, da sie nicht so viel halten müssen in Speicher
  • Annullierung eines Cache ist einfacher, da die gleiche URI auf den gleichen Server
  • jedes Mal gehen

Nachteile:

  • URI-Balancing gut funktioniert, aber wenn ein Cache-Server d geht Eigene, Ihre Backend-Server werden betroffen sein, da die anderen Cache-Server, die den Puffer aus dem aktualisierten URI-Balancing-Hash aufnehmen, die zwischengespeicherten Daten erneut abrufen müssen. Vielleicht kein großer Betrug, aber das musste ich mir für mein System merken.
+0

Aber es scheint, dass URI Balancing würde bedeuten, dass: 1) Ich kann keine andere Balancing (zB Workload-basierte Balancing) für die Elemente, die nicht zwischengespeichert werden und – GroovyDotCom

+0

Aber es scheint, dass URI Balancing würde bedeuten, dass ich kann Machen Sie keinen anderen Ausgleich (z. B. Workload-basierter Ausgleich) für die Elemente, die nicht im Cache gespeichert sind? Wäre es sinnvoll, alle nicht zwischengespeicherten Anfragen zu einem anderen Paar von HAProxys weiterzuleiten? – GroovyDotCom

1

Natürlich der erste!

Mit HAProxy für URI-basierten Ausgleich konfiguriert. (Sie müssen Ihre Anwendungsbenutzer-Sitzung verteilen, wenn Sie über einen Modus verfügen, der dem IP-Balancing-Modus entgegengesetzt ist).

Besonders wenn Sie HTTPS-Endpunkt benötigen, da Varnish nicht HTTPS spricht.

0

Warum nicht 2 LB verwenden, die erste LB balance uri Option verwenden können, kann die zweite LB Strategie Ihrer Wahl verwenden (Workload, Round Robin)

  +-- Cache Server #1 --+    +-- App server #1 
     /      \   /
LB #1 --+       + -- LB #2 --+---- App server #2 
     \      /   \ 
      +-- Cache Server #2 --+    +-- App server #3 

Maßstab, wo Sie brauchen, wie viel Sie brauchen . Wenn Sie feststellen, dass Sie keine Engpässe im Cache haben, entfernen Sie LB # 1 und platzieren Sie nur einen Cache-Server davor