☰

¿Cómo hacer balanceadores de carga redundantes?

tag-icon • tag-icon nginx load-balancing redundancy load-balance
¿Cómo hacer balanceadores de carga redundantes?

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

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

Esto supone que no está utilizando ningún servicio de terceros como AWS ELB o algo similar. ¿Qué hacer si solo estás usando, por ejemplo, Nginx?

Respuesta1

Hay un par de formas de lograr HA (alta disponibilidad) de un Load Balancer, o en ese sentido, de 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 debe hacer es separar la IP de un cuadro específico; 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 o recuperación automática de la dirección IP. Algunos de los servicios más simples para Unix son (u)carp y keepalived, algunos de los más complejos son, por ejemplo, RedHat Cluster Suite o Pacemaker.

Tomemos a keepalived como ejemplo: dos servicios keepalived, cada uno ejecutándose en su propia caja, y se comunican entre sí. 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 (el servicio se cae por cualquier motivo, o el cuadro rebota o se apaga), keepalived en otro cuadro notará los latidos perdidos, supondrá que el otro nodo está muerto y tomará medidas de conmutación por error. Esa acción en nuestro caso será sacar a relucir la IP flotante.

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

Lo peor que puede pasar en este caso es la pérdida de sesiones de los clientes, pero podrán volver a conectarse. Si quiere evitar eso, dos balanceadores 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 error de esta configuración es el cerebro dividido: cuando ambos cuadros están en línea pero el enlace se corta y ambos cuadros muestran la misma IP. Esto a menudo se resuelve mediante algún tipo de mecanismo de protección (reserva SCSI, reinicio de IPMI, corte de energía de PDU inteligente,...) o un número impar de nodos que requiere que la mayoría de los miembros del clúster estén activos para que se inicie el servicio.

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

Un software de gestión de clústeres más complejo (como Pacemaker) puede mover un servicio completo (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 controla enrutadores cerca de sus balanceadores de carga, es utilizar ECMP. Este enfoque también le permite escalar horizontalmente los balanceadores de carga. Esto funciona cuando cada una de sus dos cajas comunica BGP con su(s) enrutador(es). Cada cuadro tiene que anunciar la IP virtual (192.168.100.100) y el enrutador equilibrará la carga del tráfico a través de ECMP. Si una máquina muere, dejará de anunciar VIP, lo que a su vez impedirá 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 balanceador de carga muere.

Respuesta2

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

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

En teoría, si tiene un entorno HA, varios balanceadores de carga agrupados deberían permitir que se mantenga el servicio si uno falla.

Espero que esto ayude.

Respuesta3

Los balanceadores de carga de hardware han admitido configuraciones "activa/pasiva" o "activa/activa" durante años; en ambos casos, se configuran en paralelo desde una perspectiva de capa 1/2... activo/pasivo utiliza mecanismos de monitoreo/mantenimiento activo como se describe , activo/activo se puede implementar de numerosas maneras. Para aparecer como una única IP en la interfaz, dos o más balanceadores pueden, siempre que estén todos/ambos en línea, hacer cosas como:

  • responder selectivamente solicitudes ARP a la IP compartida en funció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 determinada
  • permita que el tráfico duplicado o erróneo de las capas 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 dispositivo asociado.

en el lado trasero:

  • Cada uno de los equilibradores podría, en funcionamiento normal, utilizar solo un subgrupo determinado de servidores de aplicaciones.
  • o bien, es posible que aquí también se generen solicitudes duplicadas...
  • o bien, podría realizarse una negociación entre equilibradores

información relacionada