Que renvoie un équilibreur de charge?

Lorsqu'un utilisateur atteint l'équilibreur de charge et que l'équilibreur de charge détermine vers quel serveur Web transmettre, que se passe-t-il ensuite? L'équilibreur de charge transmet-il la demande et toutes ses données au serveur Web, reçoit-il la réponse du serveur Web et la renvoie-t-elle à l'utilisateur?

Ou est-ce plus comme une redirection où l'équilibreur de charge renvoie littéralement l'adresse IP du serveur sélectionné au navigateur et le navigateur doit ouvrir une nouvelle connexion avec le serveur donné?

Mon instinct dit que ce ne serait pas le dernier car cela impliquerait que toutes les adresses IP des serveurs Web seraient publiques et je pensais que pour des raisons de sécurité, il était préférable d'exposer uniquement les adresses d'équilibrage de charge au public. Mais là encore, je ne suis pas exactement sûr car si vous activez SSL terminationl'équilibreur de charge, SSL ne devrait-il pas être à nouveau rétabli avec le serveur redirigé?

L'IP de fin n'est pas publiée. Le processus fonctionne en fait d'une manière que le client (un utilisateur frappant l'équilibreur) pense qu'ils communiquent avec l'équilibreur, tout en parlant à un nœud réel.

Dans une explication très simple , la plupart des transactions fonctionnent comme ceci:

1. Un utilisateur fait une demande à l'équilibreur de charge.
2. L'équilibreur décide quel nœud est le plus approprié (en fonction de la stratégie que vous utilisez pour l'équilibrage) et choisit (modifie) l'IP de destination.
3. (C'est là que la magie opère.) Le nœud reçoit une demande, accepte la connexion et répond en retour à l'équilibreur.
4. L'équilibreur modifie l'IP de réponse en une adresse virtuelle, celle de l'équilibreur et transmet la réponse à l'utilisateur.
5. Voilà, l'utilisateur reçoit une réponse avec l'IP de la demande initiale, même si elle a été traitée ailleurs.

Gardez à l'esprit que la réécriture des paquets (le changement de l'adresse IP à l'étape 4) est très importante. Sans cela, le client, recevant un paquet d'une adresse IP à laquelle il ne fait pas confiance, rejetterait simplement la réponse.

L'équilibreur Lad travaille sur la couche 4 OSI. Il décapsule le paquet jusqu'au numéro de port, puis dirige le paquet avec l'un des 3 modes.

L'équilibreur de charge peut fonctionner en 3 modes: 1. Routage direct Dans ce mode, votre serveur réel utilise IP public. L'équilibreur reçoit le paquet et décapsule jusqu'à la couche 4. S'il correspond à la règle d'équilibrage de charge, il sera redirigé le paquet (sans modification) vers l'un des serveurs réels. Le serveur réel a une adresse d'alias identique à l'adresse d'équilibrage de charge, donc lorsque le serveur réel reçoit un paquet avec une destination xxx.xxx.xxx.xxx, il définit ce paquet directement à son adresse (alias). Et puis la vraie demande de réponse du serveur au client directement (pas par le biais de l'équilibrage de charge).

2. NAT Dans ce mode, redirigez les paquets vers le serveur réel avec la modification de l'adresse de destination. L'adresse de destination sera remplacée par l'adresse de serveur réel (NAT). Dans ce mode, votre serveur réel n'a pas besoin d'IP public, il peut utiliser votre réseau local. Et puis le paquet sera livré sans nouvelle adresse de destination. Lorsque le serveur réel reçoit un paquet, il sera répondu à la passerelle d'adresse de demande client (équilibre de charge). Dans ce mode, votre équilibre de charge est utilisé comme routeur et comme passerelle de votre serveur réel.

3. Tunnel Dans ce mode, le paquet sera tunnellisé avec une nouvelle adresse src-dst (comme vpn) vers le paquet de livraison vers le serveur réel. lorsque le paquet est reçu dans realserver, realserver sera répondu via un tube tunnelé à l'équilibrage de charge. Et puis la réponse de livraison d'équilibrage de charge à l'adresse source de la demande réelle.

Pour HTTPS / SSL, l'équilibrage de charge ne le traite pas, processus d'équilibrage de charge jusqu'à la couche 4 OSI. La couche 5 ci-dessus sera traitée dans realserver. Donc TCP 3 voies hanshake, SSL / HTTPS il procède en realserver. Directeur d'équilibrage de charge uniquement du paquet.

J'espère que ma petite explication sera utile à quelque chose.

Un équilibreur de charge peut être un routeur ou un proxy inverse:

LVS est le module d'équilibrage de charge standard de couche 4 (basé sur le routage) pour le noyau Linux. Il est utilisé dans divers équilibreurs de charge commerciaux, notamment Barracuda, Loadbalancer.org et Kemp Technologies. Barracuda et Loadbalancer.org utilisent également HAProxy pour l'équilibrage de charge de la couche 7 ( basé sur un proxy inverse ).

Ps. J'ai oublié que cela ne montre pas d'où je viens, ce qui est évidemment Loadbalancer.org