Haproxy przed lakierem lub odwrotnie?

Question

mogę sobie wyobrazić dwie konfiguracje:

Load-balance następnie 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 następnie obciążenie bilansu

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

Problem z pierwszej konfiguracji jest to, że istnieją wiele pamięci podręcznych, które marnują dużo pamięci i sprawiają, że unieważnianie pamięci podręcznej jest bardziej skomplikowane.

Problem z drugą konfiguracją polega na tym, że może wystąpić uderzenie wydajności i dwa pojedyncze punkty awarii (lakier i haproxy) zamiast tylko jednego (haproxy)?

Kusi mnie, aby przejść z drugą konfiguracją, ponieważ zarówno haproxy, jak i lakier mają być szybkie i stabilne: jaka jest Twoja opinia?

Answer 1

Oba mają za i przeciw. Więcej w artykule na blogu poniżej, w tym konfiguracji zarówno HAProxy i lakierów: http://blog.exceliance.fr/2012/08/25/haproxy-varnish-and-the-single-hostname-website/

Baptiste

Answer 2

I zbudował podobną konfigurację kilka lat wstecz na ruchliwej aplikacji internetowej (tylko zrobiłem to z Squid zamiast Lakier) i wszystko dobrze się ułożyło.

Polecam przy użyciu pierwszej konfiguracji (HAProxy -> lakier) z dwoma zmianami:

1. dodać pomocniczy serwer HAProxy korzystając keepalived i wspólną wirtualną IP
2. użyć algorytmu równoważenia balance uri obciążenie do optymalizacji cache uderza

Plusy:

• Spokój z HAProxy (x2) i lakierów (x3) redundancja
• Lepsza skuteczność trafień na lakier z opcją
równoważenia obciążenia HAProxy URI
• Lepsza wydajność z serwerów cache, gdyż nie trzeba trzymać w tyle pamięć
• unieważniania pamięci podręcznej jest łatwiejsze, ponieważ samo URI trafi do tego samego serwera za każdym razem

Wady:

wyważanie

• URI działa dobrze, ale jeśli serwer cache idzie d Własne, twoje serwery zaplecza zostaną trafione, ponieważ inne serwery pamięci podręcznej, które wychwycą luki ze zaktualizowanego mieszania równoważnika URI, będą musiały ponownie pobrać buforowane dane. Może nie jest to wielka przeszkoda, ale musiałem o tym pamiętać w moim systemie.

Answer 3

Oczywiście pierwszy!

Z HAProxy skonfigurowanym do równoważenia opartego na identyfikatorze URI. (Musisz rozprowadzić swoją sesję użytkownika aplikacji, jeśli masz te w przeciwieństwie do trybu równoważenia IP).

Szczególnie jeśli potrzebujesz punktu końcowego HTTPS, ponieważ Varnish nie mówi HTTPS.

Answer 4

Dlaczego nie wykorzystać 2 LB, pierwszy LB mogą korzystać balance uri opcję, drugi LB mogą korzystać strategię swojego wyboru (obciążenia, round robin)

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

Scale, gdzie trzeba, tylko ile trzeba . Jeśli zauważysz, że nie masz do czynienia z wąskim gardłem w pamięci podręcznej, po prostu usuń LB # 1 i umieść tylko jeden serwer z pamięcią podręczną z przodu