Equilibrio de carga: DNS round robin delante de balanceadores de carga de hardware. ¿Cómo compartir la pegajosidad?

Question

DNS Round Robin (DRR) 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) se encarga de este tipo de fallas en el servidor web de forma transparente, pero no puede escalar su ancho de banda de forma indefinida. También se necesita un repuesto en caliente.

Una buena solución parece usar DRR 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 (AFAIK) sesión pegajosidad no puede trabajar.

tan sólo pudiera evitar utilizar sesión de pegajosidad pero hace un mejor uso de cachés, por tanto, es algo que quiero conservar.

Pregunta: ¿es posible/existir una implementación HLB donde una instancia puede compartir su (sessionid, servidor web) mapeo con otros casos?

Si esto es posible, entonces el cliente serían encaminados a un mismo servidor web de forma independiente por el HLB que encamina la solicitud.

Gracias de antemano.

Answer 1

Balanceadores de carga modernos tienen muy capacidades de alto rendimiento (gigabit). Entonces, a menos que esté ejecutando un sitio huuuuuuuuuuge (por ejemplo google), agregar ancho de banda no es la razón por la que necesitará 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 límites de ancho de banda, los sitios tienden a agregar pares LB adicionales para la distribución geográfica de servidores en centros de datos separados para garantizar que los usuarios distribuidos por todo el mundo puedan hablar con un servidor cercano. Para este último caso, 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 DNS personalizadas que analizaban las IP de los clientes y resolvían el equilibrador de carga empareja la dirección IP virtual que está "más cercana" (en topología de red o rendimiento) con el cliente. En la actualidad, CDN como Akamai también ofrece 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 continentes en el transcurso de una sola sesión, automáticamente obtiene afinidad (también conocido como "pegajoso") con equilibrio geográfico de carga, suponiendo que sus pares se encuentran en centros de datos separados.

Tenga en cuenta que la ubicación geográfica es Realmente realmente difícil, ya que también tiene que ubicar geográficamente sus datos para garantizar que su red de centro de datos cruzados de back-end no se inunde.

Sospecho que F5 y otros proveedores también ofrecen soluciones de un solo centro de datos que cumplan los mismos fines, si está realmente preocupado por el punto único de fallo de infraestructura de red (routers, 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 usted 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 de 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 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 esta información sea ú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) para que Puede que quiera verificar mis suposiciones arriba con hechos que puede sacar de la web de F5 y otros proveedores de LB.

Answer 2

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

hice un poco de lectura y encontrado:

• Flickr: http://highscalability.com/flickr-architecture
  4 mil millones de consultas por día -> unos 50.000 consultas/s

• Youtube: http://highscalability.com/youtube-architecture
  100 millones de reproducciones de vídeo/día -> alrededor de 1200 vistas de video/segundo

• PlentyOfFish: http://highscalability.com/plentyoffish-architecture
  600 páginas/segundo
  200 Mbps utilizan
  CDN utiliza

• Twitter: http://highscalability.com/scaling-twitter-making-twitter-10000-percent-faster
  300 ecotweets/segundo
  600 req/s

Un extremo superior LB como this puede escalar:

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

tanto, usted es un derecho LB difícilmente podrían convertirse en un cuello de botella.

De todos modos encontré este (antiguo) artículo 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

Answer 3

Ok, esto es una antigua cuestión, la que acabo de encontrar a través de una búsqueda en Google. Sin embargo, para todos los visitantes futuros, aquí es algunas aclaraciones adicionales:

Problema: [DNS Round Robin] mueve los clientes de forma aleatoria entre los pares de HLB y, por tanto, (que yo sepa) sesión de adherencia no puede trabajar.

Esta premisa es la mejor que puedo decir que no es precisa. Parece que nadie sabe realmente qué old browsers might do, 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 recientes probablemente obey the "match longest prefix" rule. Por lo tanto, no debería haber mucho 'aleteo', cambiando aleatoriamente de una IP de equilibrador de carga a otra.

Sin embargo, si usted todavía está preocupado acerca de los usuarios siendo reasignados al azar a un nuevo par equilibrador de carga, a continuación, una pequeña modificación del clásico L3/4 & carga L7 configuración de equilibrio pueden 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 avancen a pares de equilibradores de carga L7 basados ​​en origen dirección IP, es decir, utilice hashing consistente basado en la IP de los usuarios finales para enrutar siempre a los usuarios finales al mismo equilibrador de carga L7.
• Haga que sus equilibradores de carga L7 utilicen "sesiones adhesivas" como lo desee.

Esencialmente esto es solo una pequeña modificación de lo que Willy Tarreau (the creator of HAProxy) wrote years ago.

Answer 4

¿Por qué no mantenerlo simple y hacer que el servidor DNS proporcione una determinada dirección IP (o direcciones) basada en la dirección IP de origen (es decir, usar hashing consistente basado en la IP de los usuarios finales para dar siempre la misma IP dirección (es))?

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).