¿Cómo hacer equilibradores de carga redundantes?

Entiendo que el propósito de los equilibradores de carga es equilibrar la carga entre sus servidores y realizar un seguimiento del estado de la instancia, etc. Pero, ¿qué sucede si el equilibrador de carga falla? ¿Cómo se configuran los equilibradores de carga redundantes? (equilibrio de carga equilibradores de carga?)

Pude ver cómo las comprobaciones de estado de DNS podrían ser útiles, pero obviamente hay problemas importantes de latencia, ¿no es así?

Esto supone que no está utilizando servicios de terceros como AWS ELB o algo similar. ¿Qué hacer si solo estás usando say Nginx?

Hay dos formas de lograr HA (alta disponibilidad) de un equilibrador de carga, o en lo que respecta a cualquier servicio. Supongamos que tiene dos máquinas, con direcciones IP:

• 192.168.100.101
• 192.168.100.102

Los usuarios se conectan a una IP, por lo que lo que desea hacer es separar la IP de la casilla específica, por ejemplo, crear una IP virtual. Esa IP será 192.168.100.100.

Ahora, puede elegir el servicio HA que se encargará de la conmutación por error / recuperación automática de la dirección IP. Algunos de los servicios más simples para Unix son (u) carpa y keepalived, algunos de los más complejos son, por ejemplo, RedHat Cluster Suite o Pacemaker.

Tomemos keepalived como ejemplo: dos servicios keepalived, cada uno de los cuales se ejecuta en su propia caja, y se comunican juntos. Esa comunicación a menudo se llama latido del corazón.

|   VIP   |                           |         |
|  Box A  | ------v^-----------v^---- |  Box B  |
|   IP1   |                           |   IP2   |

Si un keepalived deja de responder (cualquiera de los servicios deja de funcionar por cualquier motivo, o la caja rebota o se apaga) - keepalived en otra caja notará latidos perdidos, y supondrá que otro nodo está muerto, y tomará medidas de conmutación por error. Esa acción en nuestro caso traerá la IP flotante.

                                      |   VIP   |
    ------------------ -------------- |  Box B  |
                                      |   IP2   |

El peor caso que puede suceder en este caso es la pérdida de sesiones para los clientes, pero podrán volver a conectarse. Si desea evitar eso, dos equilibradores de carga deben poder sincronizar los datos de la sesión entre ellos, y si pueden hacerlo, los usuarios no notarán nada, excepto tal vez un breve retraso.

Otro escollo de esta configuración es el cerebro dividido: cuando ambas cajas están en línea pero el enlace se corta, y ambas cajas muestran la misma IP. Esto a menudo se resuelve a través de algún tipo de mecanismo de cercado (reserva SCSI, reinicio de IPMI, corte de energía de PDU inteligente, ...) o un número impar de nodos que requieren que la mayoría de los miembros del clúster estén vivos para que se inicie el servicio.

|   VIP   |                           |   VIP   |
|  Box A  |                           |  Box B  |
|   IP1   |                           |   IP2   |

Un software de administración de clúster más complejo (como Pacemaker) puede mover todo el servicio (por ejemplo: detenerlo en un nodo e iniciarlo en otro), y esta es la forma en que se puede lograr HA para servicios como bases de datos.

Otra forma posible: si está controlando enrutadores cerca de sus equilibradores de carga, es utilizar ECMP. Este enfoque también le permite escalar equilibradores de carga horizontalmente. Esto funciona por cada una de sus dos cajas que hablan BGP a su enrutador (s). Cada casilla debe anunciar IP virtual (192.168.100.100) y el enrutador cargará el tráfico de equilibrio a través de ECMP. Si una máquina muere, dejará de anunciar VIP, lo que a su vez evitará que los enrutadores le envíen tráfico. Lo único que debe tener en cuenta en esta configuración es dejar de anunciar IP si el equilibrador de carga en sí mismo muere.

Usar Nginx como su equilibrador de carga debería permitirle seguir la redirección detallada en esta publicación alterando su configuración para detectar un tiempo de espera sin respuesta:

equilibrio de carga de conmutación por error automática nginx

En teoría, si tiene un entorno de alta disponibilidad, los equilibradores de carga múltiples agrupados deberían permitir que se mantenga el servicio si uno falla.

Espero que esto ayude.

Los equilibradores de carga de hardware han soportado configuraciones "activo / pasivo" o "activo / activo" durante años, en ambos casos se configuran en paralelo desde una perspectiva de capa 1/2 ... activo / pasivo utiliza mecanismos de monitoreo / keepalive como se describe , active / active se puede implementar de muchas maneras. Para aparecer como una sola IP en la interfaz, dos o más equilibradores pueden, siempre que estén todos / ambos en línea, hacer cosas como:

• Responda selectivamente las solicitudes ARP a la IP compartida en función de una dirección de la dirección MAC o IP de origen cuando los clientes están en la misma red
• negociar entre sí quién maneja el tráfico de una nueva conexión TCP dada
• deje que el tráfico duplicado o erróneo de la capa 3-7 ocurra imprudentemente y confíe en las pilas TCP del cliente / enrutador para solucionarlo

Y luego cambie su modo para aceptar todo o más tráfico cuando se pierda la comunicación con el / un dispositivo asociado.

en el lado del backend:

• cada uno de los equilibradores, en funcionamiento normal, solo puede usar un subgrupo de servidores de aplicaciones
• o, las solicitudes duplicadas también podrían generarse aquí también ...
• o, la negociación entre equilibradores podría hacerse