Un répartiteur de charge peut fournir de nombreuses méthodes de répartition de charge, qui sont ce que nous appelons communément méthodes d'ordonnancement ou algorithmes :

Round Robin

Cette méthode distribue cycliquement les requêtes reçues à chaque machine du cluster de serveurs, c'est-à-dire aux serveurs disponibles. Si cette méthode est utilisée, tous les serveurs marqués pour le service virtuel doivent avoir une capacité de ressources similaire et des applications hôtes avec des charges similaires. Si tous les serveurs ont des performances identiques ou similaires, choisir cette méthode rendra la charge des serveurs égale. Sur cette base, l'ordonnancement en tourniquet est un moyen simple et efficace de distribuer les requêtes. Cependant, pour les environnements où les serveurs diffèrent, choisir cette méthode signifie que les serveurs plus faibles recevront également des requêtes en tourniquet au cycle suivant, même si le serveur est déjà incapable de traiter la requête actuelle. Cela peut entraîner une surcharge des serveurs plus faibles.

Round Robin pondéré

Cet algorithme résout les insuffisances de l'algorithme d'ordonnancement simple round-robin : les requêtes entrantes sont distribuées dans l'ordre aux serveurs du cluster, mais les poids pré-attribués à chaque serveur sont pris en compte. L'administrateur définit simplement le poids de chaque serveur en fonction de sa capacité de traitement. Par exemple, le serveur A le plus puissant se voit attribuer un poids de 100, tandis que le serveur le moins puissant se voit attribuer un poids de 50. Cela signifie qu'avant que le serveur B ne reçoive sa première requête, le serveur A recevra 2 requêtes consécutives, et ainsi de suite.

Moins de connexions

Aucune des deux méthodes ci-dessus ne prend en compte le fait que le système ne peut pas identifier combien de connexions sont maintenues à un instant donné. Par conséquent, il peut arriver que le serveur B reçoive moins de connexions que le serveur A mais soit déjà surchargé, car les utilisateurs du serveur B gardent leurs connexions ouvertes plus longtemps. C'est-à-dire que le nombre de connexions, autrement dit la charge sur un serveur, est cumulatif. Ce problème potentiel peut être évité par l'algorithme « Moins de connexions » : les requêtes entrantes sont réparties en fonction du nombre de connexions actuellement ouvertes sur chaque serveur. Autrement dit, le serveur ayant le moins de connexions actives reçoit automatiquement la prochaine requête entrante. Le principe de base est le même que celui du simple round robin : tous les serveurs dotés de services virtuels doivent avoir une capacité de ressources similaire. Il convient de noter que dans les configurations à faible trafic, le trafic sur chaque serveur n'est pas identique, et le premier serveur sera privilégié. En effet, si tous les serveurs sont identiques, le premier serveur est priorisé ; tant que le premier serveur n'a pas de trafic actif continu, c'est toujours le premier serveur qui sera sélectionné en premier.

Temps de démarrage lent de Moins de connexions

Pour les méthodes d’ordonnancement de moindre connexion et de moindre connexion pondérée, lorsqu’un serveur vient de rejoindre l’environnement de production, une période de temps peut être configurée pour lui. Pendant cette période, le nombre de connexions est limité et augmente lentement. Cela fournit un « temps de transition » au serveur afin de garantir qu’il ne devienne pas surchargé immédiatement après son démarrage en raison d’un trop grand nombre de connexions attribuées. Cette valeur est définie dans l’interface de configuration L7.

Moindre connexion pondérée

Si les serveurs ont des capacités de ressources différentes, la méthode « Moindre connexion pondérée » est plus appropriée. Le nombre de connexions actives déterminé par les poids personnalisés par l’administrateur en fonction de l’état des serveurs offre généralement une utilisation très équilibrée des serveurs, car il combine les avantages de la moindre connexion et de la pondération. En règle générale, il s’agit d’une méthode de répartition très équitable, car elle utilise le rapport entre les connexions et le poids du serveur ; le serveur ayant le rapport le plus faible dans le cluster reçoit automatiquement la requête suivante. Toutefois, veuillez noter que lorsque vous utilisez cette méthode dans des conditions de faible trafic, reportez-vous aux mises en garde de la méthode « Moindre connexion ».

Équilibrage adaptatif basé sur agent

En plus des méthodes ci-dessus, le répartiteur de charge contient une logique adaptative permettant de surveiller périodiquement l'état des serveurs et les poids de ces serveurs. Pour la méthode très puissante « Agent Based Adaptive Balancing », le répartiteur de charge vérifie périodiquement la charge de tous les serveurs de la manière suivante : chaque serveur doit fournir un fichier contenant un nombre de 0 à 99 indiquant la charge réelle de ce serveur (0 = inactif, 99 = surchargé, 101 = en échec, 102 = désactivé par l'administrateur), et le serveur obtient ce fichier via HTTP GET ; en même temps, pour les serveurs du cluster, fournir leur propre charge sous la forme d'un fichier binaire fait aussi partie des tâches du serveur. Toutefois, il n'existe aucune restriction sur la manière dont les serveurs calculent leur propre charge. En fonction de la charge globale des serveurs, deux stratégies peuvent être choisies : en fonctionnement normal, l'algorithme d'ordonnancement calcule un rapport de pondération basé sur le ratio entre la valeur de charge collectée du serveur et le nombre de connexions attribuées à ce serveur. Par conséquent, si un serveur est surchargé, son poids sera réajusté de manière transparente par le système. Comme pour la méthode d'ordonnancement par tourniquet pondéré (weighted round-robin), les répartitions incorrectes peuvent être enregistrées afin que différents poids puissent être efficacement attribués à différents serveurs. Cependant, dans un environnement à très faible trafic, les valeurs de charge rapportées par les serveurs ne constitueront pas un échantillon représentatif ; répartir la charge en fonction de ces valeurs entraînera une perte de contrôle et une oscillation des commandes. Par conséquent, dans ce cas, il est plus raisonnable de calculer la répartition de la charge en fonction de rapports de poids statiques. Lorsque la charge de tous les serveurs est inférieure à la limite inférieure définie par l'administrateur, le répartiteur de charge passe automatiquement au tourniquet pondéré pour distribuer les requêtes ; si la charge est supérieure à la limite inférieure définie par l'administrateur, le répartiteur de charge revient au mode adaptatif.

Pondération fixe

Le poids le plus élevé n'est utilisé que lorsque les valeurs de poids des autres serveurs sont toutes très faibles. Toutefois, si le serveur ayant le poids le plus élevé tombe en panne, le serveur ayant la priorité la plus élevée suivante servira le client. Dans cette méthode, le poids de chaque serveur réel doit être configuré en fonction de la priorité du serveur.

Réponse pondérée

La planification du trafic est effectuée via un round-robin pondéré. Les poids utilisés dans le round-robin pondéré sont calculés en fonction des temps de réponse des contrôles de disponibilité des serveurs. Chaque contrôle de disponibilité est chronométré afin d'enregistrer le temps nécessaire pour répondre avec succès. Notez toutefois que cette méthode suppose que les contrôles de battement de cœur des serveurs sont basés sur la vitesse de la machine, mais cette hypothèse peut ne pas toujours être vraie. La somme des temps de réponse de tous les serveurs du service virtuel est additionnée, et cette valeur sert à calculer le poids d'un serveur physique individuel ; cette valeur de poids est calculée environ toutes les 15 secondes.

Hachage IP source

Cette méthode génère une valeur de hachage à partir de l'IP source de la requête et utilise cette valeur de hachage pour trouver le serveur réel correct. Cela signifie que, pour le même hôte, le serveur correspondant est toujours le même. Avec cette méthode, vous n'avez pas besoin d'enregistrer d'IP source. Toutefois, notez que cette méthode peut entraîner une charge de serveur déséquilibrée.

Source : http://www.codeceo.com/article/balanced-algorithm.html