Il fut un temps où les dinosaures parcouraient la terre ; les êtres humains ont commencé à travailler avec des outils tels que des pierres et des équilibreurs de charge basés sur la couche 4 DSR.
À l’époque, ces outils étaient utiles parce qu’ils permettaient d’atteindre les serveurs, mais aussi parce qu’il était facile de s’assurer que le serveur d’application était présenté avec l’adresse IP réelle du client.
Un équilibreur de charge se situe entre le client et l’application, donc en regardant depuis l’application, qui est l’expéditeur ? Le client (oui, s’il vous plaît) ou l’équilibreur de charge ?
C’était assez facile, et plusieurs choix s’offraient à vous.
Mode DSR – Direct Server Return (retour direct du serveur).
- Le client se connecte à l’équilibreur de charge.
- L’équilibreur de charge l’enverra à l’application avec le SourceIP du client.
- L’application enverrait alors une réponse directement au client. Elle remarquerait probablement que le SourceIP est une IP externe, puis acheminerait la réponse vers la passerelle, évitant ainsi l’équilibreur de charge sur la réponse.
Les dinosaures ont donc apprécié cette approche, car elle utilise moins de ressources sur l’infrastructure, et l’application obtient l’IP réelle du client.
L’inconvénient est que vous devez effectuer une configuration réseau spéciale sur le serveur d’application ET la grande révélation … L’équilibreur de charge ne reçoit pas ou ne voit pas la réponse, de sorte que tout changement de SSL ou de contenu est hors de la fenêtre.
L’autre inconvénient est que le LB n’a aucune idée de la performance du serveur d’application, il est donc plus difficile d’équilibrer la charge vers des serveurs qui seraient probablement plus performants. L’ADC utiliserait les serveurs qui répondent le plus rapidement ou qui ont le moins de connexions. (L’homme de l’âge de pierre peut installer un agent sur le serveur d’application pour le signaler.) Ou un ADC pourrait utiliser SNMP pour obtenir ces informations.
Quoi qu’il en soit, cette configuration a bien fonctionné pendant de nombreuses années, comme le cheval et la charrette, et il y a d’ailleurs encore des situations où c’est la meilleure option, comme les courses de chars ou certains protocoles plus anciens, par exemple.
La prochaine étape est la suivante :
Mode passerelle
- Le client se connecte à l’équilibreur de charge
- L’équilibreur de charge l’enverra à l’App Server avec le SourceIP du client.
- L’application enverra alors une réponse directement au client MAIS PAR L’intermédiaire de l’équilibreur de charge car vous avez changé la passerelle par défaut du serveur d’application pour celle de l’équilibreur de charge. Cela signifie que l’équilibreur de charge recevra la réponse.
C’est beaucoup mieux à certains égards, mais TOUT le trafic externe du serveur d’application, comme les mises à jour logicielles, passe par l’équilibreur de charge, ce qui crée un certain désordre.
Cette situation était plus fréquente lorsque les équilibreurs de charge ressemblaient à des commutateurs et que tout était directement branché sur des liaisons réseau à haut débit et à cordes.
L’homme apprend à cultiver et à utiliser l’équilibrage de charge basé sur le proxy
À cette époque, les réseaux et les vitesses des processeurs devenaient plus rapides, et nous avons commencé à voir apparaître l’approche Proxy.
Nous avons décidé de faire preuve de transparence et d’utiliser l’équilibreur de charge comme IP source plutôt que de tromper le serveur d’application. Nous l’avons fait pour de nombreuses raisons, notamment les performances TCP, la sécurité et la possibilité de fournir des services supplémentaires sur l’équilibreur de charge.
Mais l’abandon de la chasse et de la cueillette s’est accompagné d’un prix et d’un défi importants.
Comment envoyez-vous l’IP du client au serveur d’application ?
Heureusement, le bon vieux HTTP avait une bonne réponse tant que vous utilisiez HTTP.
X_Forwarded_For Header – vous permet de mettre l’IP du client dans l’en-tête et de l’envoyer ensuite.
Je ne m’étendrai pas trop sur le sujet, car c’est assez simple, mais il suffit de dire qu’il s’agit d’un en-tête que tout le monde peut facilement mettre en place. De plus, cela peut devenir complexe. Par exemple, que se passe-t-il si l’équilibreur de charge reçoit déjà une IP X_Forwareded_For ? Doit-il l’utiliser ou utiliser l’IP source et la modifier ? Il est normalement possible de configurer ces éléments sur un LB décent, mais ils ont tous des considérations de sécurité, etc.
Quoi qu’il en soit, 99% du temps, chaque fois qu’une application web a besoin de la source, c’est ainsi qu’elle l’obtient (Note : 99% des statistiques sont inventées).
Qu’en est-il des autres protocoles ?
Quelques-uns d’entre eux disposent de quelques astuces spécifiques au protocole, mais il n’y a rien de générique qui soit plus largement adopté.
C’était le cas jusqu’à ce que le protocole Proxy soit proposé et largement adopté.
Le protocole Proxy expliqué
Le protocole Proxy résout ce problème en ajoutant un en-tête à la requête transférée qui contient les détails de la connexion du client d’origine.
Il existe déjà deux versions de ce protocole.
- Protocole Proxy v1 : Utilise un format de texte simple et lisible par l’homme.
- Protocole Proxy v2 : Utilise un format binaire, qui est plus efficace et peut prendre en charge des fonctions supplémentaires comme IPv6 et les adresses de socket Unix.
Ce qui est différent, c’est que la plupart des serveurs d’application ne fonctionneront pas si vous activez ce protocole sans les configurer pour qu’ils l’acceptent. En effet, le protocole Proxy ajoute littéralement les détails requis au début des données.
Cependant, l’adoption est en hausse et de nombreux fournisseurs la prennent désormais en charge.
C’est un excellent outil pour le proxy DNS, par exemple.
Comme pour X_Forwardard_For, il reste des décisions à prendre :
Par exemple, que voulez-vous que l’équilibreur de charge fasse si l’on vous présente un en-tête Proxy Protocol ? Le supprimer et en définir un nouveau, ou le conserver ? Si vous ne vous attendez pas à ce qu’un tel en-tête soit envoyé, vous devriez l’ignorer et obtenir le vôtre, mais ces décisions doivent être prises en compte.
Le protocole Proxy est un moyen simple d’obtenir l’IP du client et il est désormais largement pris en charge, alors n’hésitez pas.
Je retourne à ma réflexion sur la haute disponibilité dans le nuage, Ciao !
