J'ai toujours utilisé le DNS Round-Robin, avec TTL long, comme équilibreur de charge. Cela fonctionne très bien pour les services HTTP / HTTPS avec les navigateurs .
Je suis vraiment stressé par les navigateurs, car la plupart des navigateurs implémentent une sorte de «nouvelle tentative sur une autre IP», mais je ne sais pas comment d’autres bibliothèques ou logiciels géreraient la solution à plusieurs adresses IP.
Lorsque le navigateur ne reçoit pas de réponse d'un serveur, il appelle automatiquement la prochaine adresse IP, puis s'en tient à celle-ci (jusqu'à ce qu'elle soit hors service ... et en tente une autre).
En 2007, j'ai effectué le test suivant:
- ajouter un iframe sur mon site Web, en pointant vers une entrée Round-Robin, telle que
http://roundrobin.test:10080/ping.php
- la page a été servie par 3 sockets PHP, écoutant sur 3 adresses IP différentes, toutes sur le port 10080 (je ne pouvais pas me permettre de tester sur le port 80, car mon site Web fonctionnait dessus)
- une prise (disons A ) était là pour vérifier que le navigateur pouvait se connecter sur le port 10080 (de nombreuses entreprises n'autorisant que des ports standard)
- deux autres sockets (disons B et C ) pourraient être activés ou désactivés à la volée.
Je l'ai laissé fonctionner une heure, j'avais beaucoup de données. Les résultats sont que pour 99,5% des hits sur le socket A , j'ai eu un hit sur le socket B ou C (je n'ai pas désactivé les deux en même temps, bien sûr). Les navigateurs étaient les suivants: iPhone, Chrome, Opera, MSIE 6/7/8, BlackBerry, Firefox 3 / 3.5 ... Ainsi, même les navigateurs non conformes se comportaient correctement!
À ce jour, je ne l'ai plus jamais testé, mais peut-être que je configurerai un nouveau test un jour ou que je publierai le code sur github afin que d'autres puissent le tester.
Remarque importante: même si cela fonctionne la plupart du temps, cela ne supprime pas le fait que certaines demandes vont échouer. Je l'utilise également pour les demandes POST, car mon application renvoie un message d'erreur au cas où cela ne fonctionnerait pas, afin que l'utilisateur puisse envoyer les données à nouveau, et le navigateur utilisera probablement une autre adresse IP dans ce cas et la sauvegarde fonctionnera. . Et pour le contenu statique, cela fonctionne vraiment bien.
Donc, si vous travaillez avec des navigateurs, utilisez Round-Robin DNS, que ce soit pour du contenu statique ou dynamique, tout ira bien. Les serveurs peuvent également tomber en cours de transaction et, même avec le meilleur équilibreur de charge, vous ne pouvez pas gérer un tel cas. Pour le contenu dynamique, vous devez rendre vos sessions / bases de données / fichiers synchrones, sinon vous ne pourrez pas gérer cela (mais c'est également vrai avec un véritable équilibreur de charge).
Remarque supplémentaire: vous pouvez tester le comportement sur votre propre adresse IP à l'aide de iptables
. Par exemple, avant votre règle de pare-feu pour le trafic HTTP, ajoutez:
iptables -A INPUT -p tcp --dport 80 --source 12.34.56.78 -j REJECT
(où 12.34.56.78
est évidemment votre adresse IP)
Ne l'utilisez pas DROP
, car le port est filtré , et votre navigateur attendra jusqu'à l'expiration du délai. Alors maintenant, vous pouvez activer ou désactiver l’un ou l’autre des serveurs. Le test le plus évident est de désactiver le serveur A, de charger la page, puis d'activer le serveur A et de désactiver le serveur B. Lorsque vous rechargerez la page, le navigateur affichera une petite attente, puis le serveur se chargera. Encore. Dans Chrome, vous pouvez confirmer l'adresse IP du serveur en consultant la demande dans le panneau de réseau. Dans l' General
onglet de Headers
, vous verrez un faux en-tête nommé Remote Address:
. Ceci est l'adresse IP d'où vous avez obtenu une réponse.
Donc, si vous devez passer en mode de maintenance sur un serveur, désactivez simplement le trafic HTTP / HTTPS avec une iptables
REJECT
règle, toutes les demandes iront sur d'autres serveurs (avec une petite attente, presque imperceptible pour les utilisateurs).