software servidores funciona electrica como carga balanceo balanceador algoritmos session dns persistence load-balancing gslb

session - funciona - balanceo de carga servidores



Equilibrio de carga: DNS round robin delante de equilibradores de carga de hardware. ¿Cómo compartir la pegajosidad? (4)

Los balanceadores de carga modernos tienen capacidades de rendimiento muy altas (gigabit). Así que a menos que esté ejecutando un sitio huuuuuuuuuuge (por ejemplo, Google), no es necesario agregar ancho de banda para agregar un nuevo par de balanceadores de carga, especialmente porque la mayoría de los sitios grandes descargan gran parte de su ancho de banda a CDN (Content Delivery Networks) como Akamai. Si está transfiriendo un gigabit de datos no compatibles con CDN a través de su sitio y aún no cuenta con una estrategia global de equilibrio de carga, tiene problemas mayores que la afinidad de caché. :-)

En lugar de limitar el ancho de banda, los sitios tienden a agregar pares LB adicionales para la distribución geográfica de los servidores en centros de datos separados para garantizar que los usuarios distribuidos por todo el mundo puedan hablar con un servidor cercano a ellos.

Para este último escenario, las empresas de equilibrado de carga ofrecen soluciones de geolocalización, que (al menos hasta hace unos años, cuando yo seguí estas cosas) se basaban en implementaciones de DNS personalizadas que miraban las IP de los clientes y resolvían los pares de equilibradores de carga Dirección IP virtual que está "más cercana" (en topología de red o rendimiento) al cliente. En la actualidad, las CDN como Akamai también ofrecen servicios de equilibrio de carga global (por ejemplo, http://www.akamai.com/html/technology/products/gtm.html ). El alojamiento EC2 de Amazon también admite este tipo de características para los sitios alojados allí (consulte http://aws.amazon.com/elasticloadbalancing/ ).

Dado que los usuarios tienden a no moverse por los continentes en el transcurso de una sola sesión, automáticamente obtiene afinidad (también conocida como "adherencia") con el equilibrio de carga geográfica, suponiendo que sus pares se encuentran en centros de datos separados.

Tenga en cuenta que la ubicación geográfica es muy difícil ya que también debe ubicar geográficamente sus datos para asegurarse de que su red de centros de datos cruzados de back-end no se inunde.

Sospecho que F5 y otros proveedores también ofrecen soluciones de centro de datos único que logran los mismos fines, si realmente está preocupado por el único punto de falla de la infraestructura de red (enrutadores, etc.) dentro de su centro de datos. Pero los proveedores de enrutadores y conmutadores tienen soluciones de alta disponibilidad que pueden ser más apropiadas para abordar ese problema.

Net-net, si yo fuera tú, no me preocuparía por los múltiples pares de balanceadores de carga. Obtenga un par y, a menos que tenga mucho dinero y tiempo de ingeniería para quemar, asóciese con un proveedor de servicios de hospedaje que sea bueno para mantener en funcionamiento la red de su centro de datos.

Dicho esto, si la afinidad del caché es tan importante para su aplicación que está pensando en desembolsar grandes $$$ para varios pares de balanceadores de carga, puede valer la pena considerar algunos cambios en la arquitectura de la aplicación (como usar un clúster de almacenamiento en caché externo) . Las soluciones como memcached (para Linux) están diseñadas para este escenario. Microsoft también tiene una llamada llamada " Velocity ".

De todos modos, espero que esto sea información útil. Ha pasado un tiempo desde que estuve involucrado en este espacio (formé parte del equipo que diseñó un producto de equilibrio de carga de aplicaciones para un gran proveedor de software) por lo que es posible que desee duplicarlo. -compruebe mis suposiciones anteriores con hechos que puede sacar de la web de F5 y otros proveedores de LB.

DNS Round Robin (RRD) permite realizar un equilibrio de carga barato (la distribución es un término mejor). Tiene la ventaja de permitir escalas horizontales infinitas. La desventaja es que si uno de los servidores web se cae, algunos clientes continúan usando la IP rota por minutos (min TTL 300s) o más, incluso si el DNS implementa el fail-over.

Un equilibrador de carga de hardware (HLB) maneja dichas fallas del servidor web de forma transparente, pero no puede escalar su ancho de banda indefinidamente. También se necesita un repuesto en caliente.

Una buena solución parece usar DRR en frente a un grupo de pares de HLB. Cada par de HLB nunca baja y, por lo tanto, DRR nunca mantiene a los clientes deprimidos. Además, cuando el ancho de banda no es suficiente, puede agregar un nuevo par de HLB al grupo.

Problema: DRR mueve clientes al azar entre los pares de HLB y, por lo tanto, la adherencia de la sesión (AFAIK) no puede funcionar.

Simplemente podría evitar utilizar pegajosidad de sesión, pero hace un mejor uso de cachés, por lo tanto, es algo que quiero preservar.

Pregunta: ¿es posible / existe una implementación de HLB donde una instancia puede compartir su mapeo (sessionid, webserver) con otras instancias?

Si esto es posible, el HLB enrutará la solicitud a un cliente al mismo servidor web.

Gracias por adelantado.


gracias por haber puesto las cosas en la perspectiva correcta. Estoy de acuerdo contigo.

Leí un poco y encontré:

Un LB de extremo superior como este puede escalar:

  • 200,000 apretones de manos SSL por segundo
  • 1 millón de conexiones TCP por segundo
  • 3,2 millones de solicitudes HTTP por segundo
  • 36 Gbps de rendimiento TCP o HTTP

Por lo tanto, tienes razón, un LB difícilmente podría convertirse en un cuello de botella.

De todos modos, encontré este artículo (antiguo) http://www.tenereillo.com/GSLBPageOfShame.htm donde se explica que el DNS con reconocimiento geográfico podría crear problemas de disponibilidad.

¿Alguien podría comentar sobre ese artículo?

Gracias,

Valentino


Ok, esta es una pregunta antigua, que acabo de encontrar a través de una búsqueda en Google. Pero para cualquier visitante futuro, aquí hay algunas aclaraciones adicionales:

Problema: [DNS Round Robin] mueve clientes al azar entre los pares de HLB y, por lo tanto, la adherencia de la sesión (AFAIK) no puede funcionar.

Esta premisa es lo mejor que puedo decir que no es precisa. Parece que nadie sabe realmente qué pueden hacer los navegadores antiguos , pero es de suponer que cada ventana del navegador permanecerá en la misma dirección IP siempre que esté abierta. Los sistemas de operación más nuevos probablemente obedezcan la regla de "coincidir con el prefijo más largo" . Por lo tanto, no debería haber mucho ''aleteo'', cambiando aleatoriamente de una IP de equilibrador de carga a otra.

Sin embargo, si todavía le preocupa que los usuarios se reasignen aleatoriamente a un nuevo par equilibrador de carga, una pequeña modificación de la configuración clásica de equilibrio de carga L3 / 4 & L7 puede ayudar:

  • Publique registros de DNS Round Robin que vayan a direcciones IP virtuales de alta disponibilidad que manejan los equilibradores de carga L4.
  • Haga que los equilibradores de carga L4 se envíen a pares de equilibradores de carga L7 en función de la dirección IP de origen , es decir, utilice hashes consistentes basados ​​en la IP de los usuarios finales para encaminar siempre a los usuarios finales al mismo equilibrador de carga L7.
  • Haga que sus equilibradores de carga L7 usen "sesiones adhesivas" como lo desee.

Básicamente, esta es solo una pequeña modificación de lo que Willy Tarreau (el creador de HAProxy) escribió hace años .


Entonces, ¿por qué no mantenerlo simple y hacer que el servidor DNS proporcione una determinada dirección IP (o direcciones) en función de la dirección IP de origen (es decir, usar hashing consistente basado en la IP de los usuarios finales para darles siempre las mismas direcciones IP a los usuarios finales). )?

Soy consciente de que esto solo proporciona un mecanismo de distribución de carga simple y barato.

He estado buscando esto, pero no he encontrado un servidor DNS que implemente esto (aunque Bind tiene algunas posibilidades con las vistas).