Bien, esto fue preguntado hace un tiempo, y llego tarde a la fiesta. Aún así, hay algo que agregar aquí.
Jackie, casi lo has clavado. Su ilustración muestra cómo se maneja el equilibrio de carga en la mayoría de las instalaciones pequeñas y medianas.
Debería leer la introducción de equilibrio de carga de Willy Tarreau con la que Nakedible se vinculó. Todavía es válido, y es una buena introducción.
Debe considerar cómo se ajustan a sus necesidades:
- Equilibradores de carga de nivel TCP / IP (Linux Virtual Server y otros). Más bajo por sobrecarga de conexión, velocidad más alta, no puede "ver" HTTP.
- Balanceadores de carga de nivel HTTP (HAProxy, nginx, Apache 2.2, Pound, Microsoft ARR y más). Mayor sobrecarga, puede ver HTTP, puede gzip HTTP, puede hacer SSL, puede hacer un equilibrio de carga de sesión fijo.
- Proxys inversos HTTP (Apache Traffic Server, Varnish, Squid). Puede almacenar objetos aptos para caché (algunas páginas web, css, js, imágenes) en RAM y reenviarlos a clientes posteriores sin involucrar al servidor web de fondo. A menudo puede hacer algunas de las mismas cosas que hacen los equilibradores de carga HTTP L7.
hay un segundo equilibrador ya que estoy seguro de que en algún momento el equilibrador también necesitará ayuda.
Pues claro. Pero el equilibrio de carga es simple y, a menudo, un solo equilibrador de carga puede ir rápido . Enlace a este artículo, que llamó la atención en la web, como solo un ejemplo del rendimiento que puede proporcionar un único servidor moderno . No use múltiples LB antes de que lo necesite. Cuando necesita un enfoque común es equilibradores de carga de nivel IP en el frente (o DNS Round Robin), yendo a equilibradores de carga de nivel HTTP, yendo a servidores proxy y servidores web.
ayuda sobre cuáles deberían ser los "equilibradores" y las mejores prácticas sobre cómo configurarlos.
El punto problemático es el manejo del estado de la sesión y, en cierta medida, el comportamiento del estado de falla. Configurar los equilibradores de carga en sí es relativamente sencillo.
Si solo está utilizando 2-4 servidores de aplicaciones web de back-end, el hash estático basado en la dirección IP de origen puede ser viable. Esto evita la necesidad de un estado de sesión compartido entre los servidores de aplicaciones web. Cada nodo de la aplicación web ve 1 / N del tráfico general, y la asignación de cliente a servidor es estática en el funcionamiento normal. Sin embargo, no es una buena opción para una instalación más grande.
Los dos mejores algoritmos de equilibrio de carga, en el sentido de que tienen un comportamiento benigno bajo una carga alta e incluso una distribución de carga, son round robin y verdadero equilibrio de carga aleatorio. Ambos requieren que su aplicación web tenga un estado de sesión global disponible en los nodos de aplicaciones web. Cómo se hace esto depende de la pila tecnológica de la aplicación web; pero generalmente hay soluciones estándar disponibles para esto.
Si ni el hashing estático ni el estado de sesión compartida son adecuados para usted, entonces la opción es generalmente el equilibrio de carga de ' sesión fija ' y el estado de sesión por servidor. En la mayoría de los casos, esto funciona bien y es una opción totalmente viable.
los equilibradores verían cuántas conexiones hay en cada instancia de apache (a través de alguna lista de configuración de IP internas o IP eternas) y distribuye las conexiones por igual
Sí, algunos sitios usan esto. Hay muchos nombres para los diferentes algoritmos de equilibrio de carga que existen. Si puede elegir round robin o aleatorio (o round robin ponderado, aleatorio ponderado), le recomendaría que lo haga, por las razones indicadas anteriormente.
Lo último: no olvide que muchos proveedores (F5, Cisco y otros de gama alta, tecnologías Coxote Point y Kemp a precios más razonables) ofrecen dispositivos de equilibrio de carga maduros .