web-dev-qa-db-fra.com

Haproxy devant le vernis ou inversement?

Je peux imaginer deux configurations:

Load-balance puis 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 puis équilibrage de charge

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

Le problème avec la première configuration est qu'il existe plusieurs caches, ce qui gaspille beaucoup de mémoire et rend l'invalidation du cache plus compliquée.

Le problème avec la deuxième configuration est qu'il pourrait y avoir un impact sur les performances et deux points de défaillance uniques (vernis et haproxy) au lieu d'un seul (haproxy)?

Je suis tenté d'aller avec la deuxième configuration car haproxy et vernis sont censés être rapides et stables: quelle est votre opinion?

architecturevarnishhaproxy
44
MiniQuark

J'ai construit une configuration similaire il y a quelques années pour une application Web chargée (seulement je l'ai fait avec Squid au lieu de Varnish), et cela a bien fonctionné.

Je recommanderais d'utiliser votre première configuration (HAProxy -> Varnish) avec deux modifications:

  1. Ajouter un serveur HAProxy secondaire en utilisant keepalived et une IP virtuelle partagée
  2. Utilisez le balance uri algorithme d'équilibrage de charge pour optimiser les accès au cache

Avantages:

  • Tranquillité d'esprit avec la redondance HAProxy (x2) et Varnish (x3)
  • Meilleure efficacité du taux de réussite sur le vernis avec l'option d'équilibrage de charge HAProxy URI
  • Meilleures performances des serveurs de cache car ils n'ont pas besoin de garder autant de mémoire
  • L'invalidation du cache est plus facile car le même URI ira au même serveur à chaque fois

Les inconvénients:

  • L'équilibrage d'URI fonctionne bien, mais si un serveur de cache tombe en panne, vos serveurs d'arrière-plan seront touchés car les autres serveurs de cache qui prennent le relais du hachage d'équilibrage d'URI mis à jour devront récupérer à nouveau les données mises en cache. Peut-être pas un gros con, mais je devais garder cela à l'esprit pour mon système.
38
Matt Beckman

Les deux ont des avantages et des inconvénients. Plus dans l'article de blog ci-dessous, y compris la configuration pour HAProxy et Varnish: http://blog.exceliance.fr/2012/08/25/haproxy-varnish-and-the-single-hostname-website/

Baptiste

11
Baptiste

Pourquoi ne pas utiliser 2 LB, le premier LB peut utiliser balance uri option, le deuxième LB peut utiliser la stratégie de votre choix (charge de travail, round robin)

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

Échelle là où vous en avez besoin, combien vous en avez besoin. Si vous trouvez que vous n'êtes pas goulot d'étranglement dans Cache, supprimez simplement LB # 1 et placez un seul serveur Cache devant

1
rocketspacer

Bien sûr, le premier!

Avec HAProxy configuré pour l'équilibrage basé sur l'URI. (Vous devez distribuer votre session utilisateur d'application si vous en avez d'autres en mode d'équilibrage IP).

Surtout si vous avez besoin d'un point de terminaison HTTPS, car Varnish ne parle pas HTTPS.

1
Thomas Decaux