Capa 4 vs Capa 7 Equilibrio de carga

Estoy tratando de decidir entre usar una solución de equilibrio de carga de capa 4 para mi centro de datos o una solución de capa 7. Desafortunadamente (para mi cordura, es decir), mi caso de uso es lo suficientemente simple como para que ambas soluciones funcionen bien, evitando la mayoría de las debilidades y realmente no utilizando las fortalezas del otro. Cualquiera sea la solución que terminemos usando, debe tener una alta disponibilidad y un alto rendimiento. Pero solo estamos planeando usarlo para equilibrar la carga en un clúster de servidores web, ninguno de los cuales tiene requisitos para la administración de sesión "permanente" (cookie o IP), reglas de reescritura complejas o, para el caso, reglas de reescritura en todos.

Los equilibradores de carga se conectarán a dos conmutadores, ambos con una conexión independiente hasta la capa de agregación del centro de datos y se fusionarán utilizando Rapid Spanning Tree y cualquier protocolo patentado que los conmutadores utilicen para la virtualización. Los equilibradores de carga también se vincularán entre sí a través de un cable cruzado. Todos los servidores del clúster están conectados a ambos conmutadores. Todo lo que los equilibradores de carga tienen que hacer es dirigir el tráfico sobre ellos.

Como es solo HTTP, puedo usar una solución de equilibrio de carga de capa 7 como HAProxy o nginx. Pero también podría usar el proyecto LVS con ldirectord o keepalived o lo que sea.

He tratado de romper los pros y los contras tal como los veo, pero simplemente termina en un lavado. ¿Que recomendaria y porque? ¿Me estoy perdiendo de algo?

Un beneficio útil de "L7" como haproxy es poder usar cookies para mantener el mismo navegador golpeando el mismo servidor de fondo. Esto hace que la depuración de clientes sea mucho más fácil.

El equilibrio de L4 puede hacer rebotar a un solo usuario en varios servidores de fondo. (que en ciertos casos puede ser ventajoso, pero en un sentido de depuración / perfil, usar "L7" es mucho más valioso).

EDITAR: También hay una ventaja potencial de velocidad al usar el equilibrio HTTP. Con Keep-Alives, los clientes pueden establecer una única sesión TCP a su equilibrador y luego enviar muchos HIT sin necesidad de restablecer nuevas sesiones TCP (protocolo de enlace de 3 vías). Del mismo modo, muchos LB mantienen sesiones de mantenimiento de vida en los sistemas de back-end eliminando la necesidad de hacer el mismo apretón de manos en el back-end.

Es posible que el equilibrio de carga TCP estricto no logre ambas cosas tan fácilmente.

/ * FWIW: No diría "L7" o "L4", diría HTTP o TCP. Pero soy un fanático de evitar usar el OSI para describir cosas con las que no coincide bien. * /

Creo que fundamentalmente si no está seguro de qué implementar, elija lo que le parezca simple y natural. Pruébelo (¿usa apache bench?) Y asegúrese de que funcione para sus necesidades. Para mí, HTTP LB es más natural.

Dada la falta de ventaja para usted de hacer el equilibrio L7, me conformaría con el equilibrio L4. Soy un gran fanático de mantenerlo lo más simple posible, sin sacrificar demasiado.

L7 requiere que los equilibradores inspeccionen los encabezados http en los paquetes que los atraviesan para un enrutamiento apropiado, agregando una sobrecarga adicional y un aumento marginal en la latencia para el usuario final. Me parece un gasto inútil si no ganas nada con eso.

Algunos proveedores de DNS tienen una funcionalidad simple de conmutación por error. Usted ha mencionado cuáles son sus requisitos y no cuáles son, pero si todo lo que necesita es un round robin con conmutación por error si algo falla, puede usar, por ejemplo, la conmutación por error de zoneedit.com . Dependiendo de sus necesidades de alta disponibilidad, eso puede ser lo suficientemente bueno y puede omitir un nivel completo en su arquitectura.