¿Qué devuelve un equilibrador de carga?

Cuando un usuario golpea el equilibrador de carga y el equilibrador de carga determina a qué servidor web reenviar, ¿qué sucede después? ¿El equilibrador de carga reenvía la solicitud y todos sus datos al servidor web, recibe la respuesta del servidor web y la devuelve al usuario?

¿O es más como una redirección en la que el equilibrador de carga literalmente solo devuelve la dirección IP del servidor seleccionado al navegador y el navegador tiene que abrir una nueva conexión con el servidor dado?

Mi instinto dice que no sería lo último porque eso implicaría que todas las direcciones IP del servidor web serían públicas y pensé que por razones de seguridad es mejor exponer las direcciones del equilibrador de carga al público. Pero, de nuevo, no estoy exactamente seguro porque si habilita SSL terminationen el equilibrador de carga, ¿no sería necesario restablecer SSL nuevamente con el servidor redirigido?

La IP final no se publica. El proceso realmente funciona de una manera que el cliente (un usuario que golpea el equilibrador) cree que se está comunicando con el equilibrador, mientras habla con un nodo real.

En una explicación muy simple , la mayoría de las transacciones funcionan así:

1. Un usuario realiza una solicitud al equilibrador de carga.
2. El equilibrador decide qué nodo es el más adecuado (según la estrategia que esté utilizando para equilibrar) y elige (cambia) la IP de destino.
3. (Aquí es donde ocurre la magia). El nodo recibe una solicitud, acepta la conexión y responde al equilibrador.
4. El equilibrador cambia la IP de respuesta a una virtual, la del equilibrador y reenvía la respuesta al usuario.
5. Voilà, el usuario recibe respuesta con la IP de la solicitud inicial, a pesar de que realmente se procesó en otro lugar.

Tenga en cuenta que la reescritura de paquetes (el cambio de la dirección IP en el paso 4) es muy importante. Sin él, el cliente, al recibir un paquete de una IP en la que no confía, simplemente descartaría la respuesta.

Lad Balancer es un trabajo en la capa 4 OSI. Decapsula el paquete hasta el número de puerto y luego dirige el paquete con uno de los 3 modos.

El equilibrador de carga puede funcionar en el modo 3: 1. Enrutamiento directo En este modo, su servidor real es usar IP público. El equilibrador recibe el paquete y se desencapsula hasta la capa 4. Si coincide con la regla de equilibrio de carga, se redirigirá el paquete (sin modificar) a uno de servidor real. Realserver tiene una dirección de alias igual que la dirección de equilibrio de carga, por lo que cuando el servidor real recibe un paquete con un destino xxx.xxx.xxx.xxx, define ese paquete directamente a su dirección (alias). Y luego la solicitud de respuesta del servidor real al cliente directo (no a través del equilibrio de carga).

2. NAT En este modo, el paquete se redirige al servidor real con la modificación de la dirección de destino. La dirección de destino se reemplazará con la dirección del servidor real (NAT). En este modo, su servidor real no necesita IP pública, puede usar su red local. Y luego el paquete será entregado sin nueva dirección de destino. Cuando el servidor real reciba el paquete, responderá a la dirección de solicitud del cliente a través de la puerta de enlace (equilibrio de carga). En este modo, su equilibrio de carga se utiliza como enrutador y como puerta de enlace de su servidor real.

3. Túnel En este modo, el paquete se tunelizará con una nueva dirección src-dst (como vpn) para entregar el paquete al servidor real. cuando el paquete se recibe en realserver, realserver responderá a través de una tubería tunelizada para equilibrar la carga. Y luego la entrega de balance de carga responde a la dirección de origen de la solicitud real.

Para HTTPS / SSL, el equilibrio de carga no lo procesa, el proceso de equilibrio de carga hasta la capa 4 OSI. La capa 5 anterior se procesará en el servidor real. Entonces TCP 3 way hanshake, SSL / HTTPS procesó en servidor real. Balanceo de carga único director del paquete.

Espero que mi pequeña explicación sea de ayuda.

Un equilibrador de carga puede ser un enrutador o un proxy inverso:

LVS es el módulo de equilibrio de carga de capa 4 (basado en enrutamiento) estándar de la industria para el kernel de Linux. Se utiliza en varios equilibradores de carga comerciales, incluidos Barracuda, Loadbalancer.org y Kemp Technologies. Barracuda y Loadbalancer.org también usan HAProxy para el equilibrio de carga de Capa 7 ( basado en proxy inverso ).

PD. Olvidé que esto no muestra de dónde soy, que obviamente es Loadbalancer.org