¿Es posible utilizar múltiples equilibradores de carga para redirigir el tráfico a mis servidores de aplicaciones?

Soy nuevo en el equilibrio de carga y me pregunto si es posible usar múltiples equilibradores de carga para redirigir el tráfico a mis servidores de aplicaciones. Realmente no entiendo cómo se puede hacer esto. ¿No debería un nombre de dominio coincidir uno a uno con la dirección IP de un determinado servidor (en este caso, la IP de un equilibrador de carga)? Si cada servidor de equilibrio de carga tiene una IP diferente, ¿cómo pueden recibir la solicitud ambos equilibradores de carga (o 10 equilibradores de carga o 50 o 100)?

El uso de DNS round robin no es tan bueno para la alta disponibilidad: si un servidor se desconecta, los clientes aún intentarán conectarse y esperar un tiempo de espera.

Hay otras formas de lograr esto.
1) Balanceadores de carga activos / pasivos
Básicamente, un balanceador de carga maneja todo el tráfico para una dirección IP.
Si ese equilibrador se cae, el nodo pasivo salta y se hace cargo de la IP.
Tenga en cuenta que los equilibradores de carga prácticamente solo reenvían tráfico, por lo que para sitios pequeños y medianos esto puede funcionar bien.

2) Balanceadores de carga activos / activos
La misma IP de tráfico se configura en ambos (o muchos más) equilibradores de carga.
El tráfico entrante se envía a todos los equilibradores de carga, pero un algoritmo elige qué equilibrador debe responder, todos los demás descartan ese tráfico.
Una forma simple de pensarlo, tiene dos equilibradores de carga:
cuando la IP solicitante finaliza con un número par, el equilibrador de carga A responde, de lo contrario, el equilibrador de carga B responde.

Por supuesto, su infraestructura debe admitir esto y hay una sobrecarga debido al tráfico que se envía pero se descarta.
Más información, p. Ej. Aquí: http://community.brocade.com/t5/SteelApp-Docs/Feature-Brief-Deep-dive-on-Multi-Hosted-IP-addresses-in-Stingray/ta-p/73867

La alta disponibilidad con equilibradores de carga se implementa comúnmente utilizando un protocolo de dirección IP virtual (VIP) que permite que varios hosts (es decir, equilibradores de carga) respondan a una dirección IP común de una de varias maneras posibles (variaciones en activo / pasivo, activo / activo) .

Hay una buena cantidad de estos protocolos, los que más he visto con equilibradores de carga regulares son VRRP y NLB (así como también una buena cantidad de protocolos de caja negra no descriptos en dispositivos). Expandiéndose a enrutadores y cortafuegos también se puede encontrar CARP , HRSP , GLSP , por ejemplo.

Esta estrategia tiene una serie de beneficios sobre el equilibrio de carga de DNS, que es una estrategia más simple (y que se trata en otra respuesta).

El equilibrio de carga de DNS está cargado, por ejemplo, con:

• la lenta rotación de los mecanismos de almacenamiento en caché de dns
• Algoritmos limitados de equilibrio de carga (generalmente solo round-robin)
• la externalización de la decisión de equilibrio de carga al cliente (mediante el almacenamiento en caché del registro dns)
• Drenaje lento de las colas de servicio cuando un servidor (es decir, un equilibrador de carga) se retira de la rotación (según los TTL de registro de DNS manejados por los ISP y los clientes )
• Conmutación por error lenta en la falla del balanceador de carga

El uso de un protocolo de IP virtual para HA puede tener una opción para lograr, por ejemplo:

• Elección del algoritmo de equilibrio de carga entre los equilibradores de carga.
• Decisiones de equilibrio de carga centradas en el servidor (fascinante, por ejemplo, medidas y enrutamiento basados ​​en el estado del servicio)
• Drenaje más rápido de las colas de servicio cuando se quita la rotación de un equilibrador de carga.
• Conmutación por error instantánea en caso de falla del equilibrador de carga

Solo usted sabe qué estrategia y protocolo se ajusta mejor a su escenario.

Los requisitos: tener una solución práctica que funcione para la nube o cualquier tipo de entorno donde no haya acceso a equilibradores de carga de hardware, protocolos BGP y todo eso.

Se desconoce el número de solicitud de ingresos de una aplicación, pero debe ser lo suficientemente alto como para satisfacer una mayor expectativa de carga sin temor.

Busquemos una aplicación con una naturaleza de carga similar, por ejemplo, la tienda de registro y la aplicación de búsqueda. Encontré uno .

Que quieren ellos:

1. Balancear la carga entre colectores
2. Ofrecer tolerancia a fallas, lo que nos permite continuar ingiriendo datos si uno de los recolectores muere o tiene problemas
3. Escale horizontalmente con el crecimiento en nuestros volúmenes de registro

¿Qué intentaron y aprendieron sobre ELB?

1. No funciona como se esperaba
2. Problemas de latencia debido al aumento de carga
3. No hay suficiente instalación de monitoreo
4. Demasiadas limitaciones (número de puertos y protocolos abiertos)

¿Por qué eligieron con Route53:

1. "Round robin es un equilibrio de carga bastante básico, pero nos funciona bien desde el punto de vista de la eficiencia"
2. "Aprovechamos las comprobaciones de estado de conmutación por error de la ruta 53".
3. "Si hay un problema con un recolector, Route 53 lo elimina automáticamente del servicio; nuestros clientes no verán ningún impacto".
4. No se requiere precalentamiento con la ruta 53

La ruta 53 resultó ser la mejor manera para que Loggly aprovechara nuestros recolectores de alto rendimiento dados nuestros enormes volúmenes de registros, variaciones impredecibles y crecimiento constante en nuestro negocio. Se alinea con los propósitos centrales de los recolectores: recopilar datos a la velocidad de la línea de red con pérdida cero, y nos permite beneficiarnos de la elasticidad de todos los servicios de AWS que utilizamos en Loggly.

Ese ejemplo en particular muestra que en algunos escenarios (recopilador de registros, servicio de anuncios o similar) el balanceador de carga es redundante y la "solución round robin de verificación de estado de DNS" hace su trabajo muy bien.

Veamos qué dice AWS sobre la conmutación por error de DNS:

Con DNS Failover, Route 53 puede detectar una interrupción de su sitio web y redirigir a sus usuarios finales a ubicaciones alternativas o de respaldo que usted especifique. Route 53 DNS Failover se basa en comprobaciones de estado, realizando regularmente solicitudes de Internet a los puntos finales de sus aplicaciones desde múltiples ubicaciones en todo el mundo, para determinar si cada punto final de su aplicación está activo o inactivo.

Esa técnica también hace que el ELB (no requerido, solo por una nota) sea más robusto, nuevamente se basa en RR + Health Check:

Route 53 DNS Failover maneja todos estos escenarios de falla al integrarse con ELB detrás de escena. Una vez habilitado, Route 53 configura y administra automáticamente las comprobaciones de estado de los nodos ELB individuales.

Veamos ahora cómo funciona detrás de escena. La pregunta obvia es cómo lidiar con el almacenamiento en caché de DNS:

Sin embargo, el almacenamiento en caché de DNS aún puede ser un problema aquí (consulte nuestra publicación anterior donde se cubre el problema de "cola larga") si TTL no es respetado por todas las capas entre su cliente y la Ruta 53. Luego, podría aplicar una técnica de "eliminación de caché": enviar una solicitud a un dominio único

("http://<unique-id>.<your-domain>") 

y definir un recurso comodín

Record "*.<your-domain>" to match it.

Algolia introdujo la "estrategia de reintento del cliente" que funciona bastante bien si su cliente (JS en su caso) puede manejar eso:

Terminamos implementando una estrategia básica de reintento en nuestros clientes API. Cada cliente API fue desarrollado para poder acceder a tres máquinas diferentes. Tres registros DNS diferentes representaban a cada usuario: USERIDID-1.algolia.io, USERID-2.algolia.io yUSERID-3.algolia.io. Nuestra primera implementación fue seleccionar aleatoriamente uno de los registros y luego volver a intentarlo con uno diferente en caso de falla.