architecture - hashtags - instatag

Haproxy en frente de barniz o al revés?

Question

Puedo imaginar dos configuraciones:

Balance de carga luego caché

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

Caché y luego equilibrio de carga

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

El problema con la primera configuración es que hay múltiples cachés, lo que desperdicia mucha memoria y hace que la caché invalidante sea más complicada.

El problema con la segunda configuración es que podría haber un golpe de rendimiento y dos puntos únicos de falla (barniz y haproxy) en lugar de solo uno (haproxy).

Estoy tentado de ir con la segunda configuración porque se supone que tanto haproxy como barniz son rápidos y estables: ¿cuál es tu opinión?

Answer 1

¿Por qué no utilizar 2 LB, el primer LB puede usar la opción de balance uri , el segundo LB puede usar la estrategia de su elección (carga de trabajo, round robin)

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

Escala donde lo necesitas, cuánto necesitas. Si observa que no tiene un cuello de botella en Cache, simplemente elimine LB # 1 y coloque solo un servidor de caché en frente

Answer 2

Ambos tienen pros y contras. Más información en el artículo del blog a continuación, incluida la configuración tanto de HAProxy como de Varnish: http://blog.exceliance.fr/2012/08/25/haproxy-varnish-and-the-single-hostname-website/

Baptiste

Answer 3

Construí una configuración similar hace unos años para una aplicación web ocupada (solo lo hice con Squid en lugar de Varnish), y funcionó bien.

Yo recomendaría usar su primera configuración (HAProxy -> Barniz) con dos modificaciones:

1. Agregue un servidor secundario HAProxy usando keepalived y una IP virtual compartida
2. Use el algoritmo de equilibrio de carga de la balance uri para optimizar los hits de caché

Pros:

• Tranquilidad con la redundancia HAProxy (x2) y Varnish (x3)
• Mejor eficiencia de tasa de acierto en Varnish con la opción de equilibrio de carga HAProxy URI
• Mejor rendimiento de los servidores de caché, ya que no necesitan mantener tanto en la memoria
• La invalidación de la memoria caché es más fácil ya que el mismo URI irá al mismo servidor cada vez

Contras:

• El equilibrio de URI funciona bien, pero si un servidor de caché falla, los servidores de fondo recibirán un golpe ya que los otros servidores de caché que recogen la holgura del hash de equilibrio de URI actualizado necesitarán volver a recuperar los datos en caché. Tal vez no es una gran estafa, pero tenía que tener eso en cuenta para mi sistema.

Answer 4

Por supuesto, el primero!

Con HAProxy configurado para el equilibrio basado en URI. (Debe distribuir su sesión de usuario de la aplicación si tiene las que están en el modo de equilibrio IP opuesto).

Especialmente si necesita punto final HTTPS, ya que Varnish no habla HTTPS.