Cela dépend du protocole et du cas d'utilisation à équilibrer. Pour tout ce dont la quantité de connexions est corrélée à la charge / utilisation, il est préférable d'utiliser leastconn
. En raison du fonctionnement des réseaux et des applications, c'est à peu près toujours vrai et il vaut mieux utiliser leastconn
par défaut.
Ordinateurs de bureau / hôtes distants RDP / X11
Par exemple, une entreprise dispose d'un pool de bureaux distants auxquels les employés se connectent. Vous souhaitez que les employés soient répartis de manière assez uniforme sur les ordinateurs de bureau.
Le nombre de connexions actives dans ce cas d'utilisation est à peu près "combien d'employés utilisent ce bureau en ce moment". L'hôte ayant le moins de connexions utilise le moins d'employés et c'est probablement le moins chargé. Utilisez "lessconn" dans ces circonstances, cela répartit la charge uniformément avec le nombre d'utilisateurs.
Un équilibreur de charge idéal doit être conscient de la charge du bureau distant. Combien d'utilisateurs? Combien d'applications? Combien de mémoire et de CPU consommés? Il existe des solutions commerciales dédiées aux postes de travail distants (Microsoft / Citrix / etc ...), elles mesurent généralement ces métriques pour diffuser très bien l'utilisation. HAProxy est un simple équilibreur de charge réseau et il ne peut pas faire mieux que de compter les connexions avec leastconn
.
HTTP / HTTPS
Avec HTTP, une connexion active signifie que le serveur est occupé à traiter une demande. Les connexions sont directement proportionnelles à la charge. Vous souhaitez sélectionner le serveur avec le moins de connexions actives (requêtes en cours). À utiliser leastconn
pour le trafic HTTP (S).
Imaginez un scénario avec deux serveurs HTTP, où un serveur est plus lent à traiter les demandes (peut-être qu'il est surchargé, peut-être qu'il a un matériel plus ancien).
roundrobin
répartira les demandes à moitié entre les deux serveurs. C'est très inefficace, le serveur le plus rapide devrait en prendre plus. Pire encore, le serveur plus lent pourrait être surchargé, il deviendrait encore plus lent à mesure que davantage de demandes arriveraient et pourrait commencer à supprimer des demandes à tout moment. Tu ne veux pas ça.
leastconn
détecterait que les serveurs sont inégaux. Le serveur plus lent conserve les connexions plus longtemps, son nombre de connexions est plus élevé. leastconn
en tient compte et préfère l'autre serveur.
D'après mon expérience, y compris les rôles où je faisais exclusivement des tests de performance pour les sites Web de taille moyenne à grande. leastconn
peut être 300% aussi efficace que roundrobin
pour HTTP (S). roundrobin
ne distribue pas la connexion équitablement et entraînera une instabilité à forte charge.
Demande DNS
(Ignorons que HAProxy ne prend pas en charge UDP et UDP est sans connexion).
Un dernier exemple. DNS est un protocole simple. Les clients envoient un seul message UDP pour demander un domaine et le serveur DNS répond dans un seul message.
Dans ce cas, il n'y a pas vraiment de connexion. Même s'il y en avait, il serait instantanément fermé (théoriquement).
Il ne serait pas logique de compter les connexions dans ces circonstances, ce n'est pas optimal pour leastconn
. Un simple roundrobin
peut diffuser des messages.
Un malentendu commun
Les gens pensent parfois qu'ils ne devraient pas utiliser leastconn
pour des connexions de courte durée (similaire au dernier exemple). Même la documentation HAProxy est trompeuse à ce sujet.
leastconn
Use of this algorithm is recommended where very long sessions are
expected, such as LDAP, SQL, TSE, etc... but is not very well
suited for protocols using short sessions such as HTTP.
[misleading advice, should ignore it]
Dans le monde réel, ce short connections
n'est pas une chose.
Les applications sont construites sur TCP. Les messages sont livrés et souvent traités dans l'ordre. Lorsqu'un serveur est lent ou surchargé, les connexions "courtes" deviennent plus longues. S'il y a (plus) de connexions, il y a probablement (plus) de travail en cours. Le nombre de connexions et la durée de connexion varient et ont un sens.
Pensez à un serveur HTTP de base. Certains actifs prennent quelques millisecondes, certains appels d'API prennent quelques secondes, une page peut prendre n'importe quel temps pour se charger avec n'importe quelle quantité de demandes en elle, etc. Les demandes ne sont pas de courte durée, leur durée de vie suit ce qui est traité sur quel serveur. leastconn
comprend l'activité en cours et ajuste la distribution, ce qui est exactement ce que vous attendez d'un équilibreur de charge.