Server Load Balancer:SLB scheduling algorithms

Server Load Balancer (SLB) répartit les requêtes entrantes vers les serveurs backend selon un algorithme de planification que vous configurez dans chaque règle de transfert. SLB prend en charge le round-robin, le round-robin pondéré, la méthode des moindres connexions pondérées et le hachage cohérent, chacun étant adapté à différents modèles de trafic et configurations de serveur.

ALB, NLB et CLB prennent en charge différents sous-ensembles de ces algorithmes :

• ALB prend en charge le round-robin pondéré, la méthode des moindres connexions pondérées et le hachage cohérent basé sur les adresses IP source et les URL.

• NLB prend en charge le round-robin, le round-robin pondéré, la méthode des moindres connexions pondérées et le hachage cohérent basé sur les adresses IP source, la combinaison des quatre éléments et les ID QUIC.

• CLB prend en charge le round-robin, le round-robin pondéré et le hachage cohérent basé sur les adresses IP source, la combinaison des quatre éléments et les ID QUIC.

Round-robin

Présentation

Le round-robin distribue les requêtes aux serveurs backend un par un, selon une séquence fixe. Cette méthode convient particulièrement bien aux connexions éphémères et sans état, comme HTTP, où chaque requête est indépendante et le temps de traitement globalement uniforme.

Par exemple, avec deux instances Elastic Compute Service (ECS) dans un groupe de serveurs backend, chaque instance reçoit les requêtes à tour de rôle : la première requête est envoyée à ECS01, la seconde à ECS02, la troisième à ECS01, et ainsi de suite.

Avantages

1. Simplicité d'utilisation : aucune configuration spécifique par serveur n'est requise, ce qui rend la mise en place et la maintenance simples.

2. Répartition homogène : les requêtes sont distribuées uniformément sur tous les serveurs backend lorsque les temps de traitement et les capacités des serveurs sont similaires.

Inconvénients

1. Absence de conscience de la charge en temps réel : l'algorithme ignore le niveau d'occupation actuel de chaque serveur. Si les performances des serveurs varient considérablement, les serveurs plus rapides peuvent être sous-utilisés tandis que les plus lents deviennent surchargés.

2. Déséquilibre avec les connexions persistantes : la durée des connexions n'est pas prise en compte. Si certaines connexions restent ouvertes beaucoup plus longtemps que d'autres, ces serveurs accumulent davantage de connexions actives au fil du temps, augmentant les délais d'attente pour les requêtes suivantes.

Cas d'utilisation

1. Capacité serveur uniforme : le round-robin offre les meilleures performances lorsque les serveurs backend disposent de ressources CPU et mémoire similaires. Avec un matériel comparable, la répartition homogène maintient tous les serveurs à peu près au même niveau de charge.

2. Requêtes courtes et sans état : cette méthode est idéale pour les charges de travail où chaque requête s'exécute rapidement et ne nécessite pas d'affinité avec un serveur spécifique, comme la diffusion de contenus statiques ou les appels API simples.

Round-robin pondéré

Présentation

Le round-robin pondéré étend le principe du round-robin en permettant d'attribuer un poids à chaque serveur backend. Les serveurs dotés d'un poids plus élevé reçoivent proportionnellement plus de requêtes. Comme le round-robin standard, cette méthode est bien adaptée aux connexions non persistantes telles que HTTP.

Par exemple, avec deux instances ECS auxquelles sont attribués des poids de 60 et 40, la première instance traite 60 % des requêtes et la seconde 40 %.

Avantages

1. Distribution proportionnelle : le trafic est alloué en fonction du poids de chaque serveur, permettant aux serveurs de plus grande capacité de supporter une part plus importante de la charge sans être saturés.

2. Contrôle explicite : vous décidez exactement du volume de trafic reçu par chaque serveur, ce qui facilite la prise en compte des serveurs aux spécifications matérielles différentes.

Inconvénients

1. Surcharge de configuration : chaque serveur backend doit se voir attribuer une valeur de poids. Avec un grand nombre de serveurs ou des capacités changeant fréquemment, maintenir des poids précis exige un effort continu en matière d'exploitation et de maintenance.

2. Risque de mauvaise configuration des poids : des poids incorrects entraînent une répartition déséquilibrée de la charge. Si les performances des serveurs évoluent (en raison de mises à niveau, de dégradations ou de variations de trafic), les poids doivent être mis à jour manuellement.

Cas d'utilisation

1. Serveurs de capacités mixtes : lorsque les serveurs backend ont des capacités CPU, mémoire ou réseau différentes, définissez des poids proportionnels à leurs performances relatives afin que les serveurs les plus puissants absorbent davantage de trafic.

2. Transferts de trafic progressifs : pour migrer le trafic entre différentes générations de serveurs ou déployer progressivement une nouvelle instance, ajustez les poids de manière incrémentielle plutôt que de basculer tout le trafic d'un coup.

3. Contrôle granulaire du trafic : lorsque vous avez besoin d'un contrôle précis des ratios de trafic, par exemple en envoyant 20 % des requêtes vers un serveur canari, le round-robin pondéré vous permet d'exprimer directement ce ratio via les valeurs de poids.

Moindres connexions pondérées

Présentation

La méthode des moindres connexions pondérées achemine chaque nouvelle requête vers le serveur backend présentant le moins de connexions actives par rapport à son poids. Si deux serveurs partagent le même poids, celui qui compte le moins de connexions en cours reçoit la requête suivante. Cet algorithme fonctionne mieux avec des connexions persistantes, telles que les connexions de base de données, où le nombre de connexions constitue un indicateur pertinent de la charge du serveur.

Par exemple, avec deux instances ECS ayant toutes deux un poids de 100, l'une gérant 100 connexions actives et l'autre 50, les nouvelles requêtes sont dirigées vers l'instance comptant 50 connexions jusqu'à ce que les comptes s'équilibrent.

Avantages

1. Conscience de la charge en temps réel : l'algorithme suit continuellement le nombre de connexions actives par serveur et dirige les nouvelles requêtes loin des serveurs les plus occupés, maintenant ainsi un équilibre de charge malgré les fluctuations du trafic.

2. Équité ajustée par le poids : il combine le nombre de connexions avec le poids du serveur pour éviter à la fois la surcharge des serveurs à haute capacité et la sous-utilisation de ceux à faible capacité.

Inconvénients

1. Surcoût de planification plus élevé : comparé au round-robin et au round-robin pondéré, cet algorithme doit interroger et comparer le nombre de connexions actives sur tous les serveurs backend avant d'en sélectionner un, ce qui ajoute un coût computationnel à grande échelle.

2. Vue incomplète de la charge du serveur : il ne suit que les connexions entre SLB et le serveur backend. Si les données de surveillance sont inexactes ou obsolètes, les requêtes peuvent ne pas être distribuées au serveur ayant le moins de connexions. De plus, si un même serveur appartient à plusieurs instances SLB, le décompte des connexions d'une seule instance SLB sous-estime la charge réelle du serveur, ce qui peut entraîner une surcharge ou une sous-charge.

3. Pics de charge lors de l'ajout de nouveaux serveurs : les nouveaux serveurs démarrent avec zéro connexion et attirent soudainement un afflux de requêtes. Cela peut les surcharger avant qu'ils ne soient pleinement opérationnels, potentiellement déstabilisant le cluster.

Cas d'utilisation

1. Serveurs de capacités mixtes avec connexions persistantes : combinez les poids avec le suivi des connexions en temps réel pour maintenir une charge proportionnelle à la capacité de chaque serveur, même lorsque les durées de connexion varient considérablement.

2. Modèles de trafic dynamiques : lorsque les connexions actives fluctuent significativement au fil du temps, l'algorithme rééquilibre continuellement le trafic sans nécessiter d'ajustements manuels des poids.

3. Charges de travail sensibles à la stabilité : pour les applications nécessitant des temps de réponse constants, comme les bases de données ou les pools de connexions, l'acheminement des nouvelles requêtes vers le serveur le moins chargé aide à empêcher certains serveurs de devenir des goulets d'étranglement.

Hachage cohérent

Présentation

Le hachage cohérent associe chaque requête à un serveur backend sur la base d'un hachage calculé à partir d'un ou plusieurs attributs de la requête (facteurs de hachage). Les requêtes partageant la même valeur de hachage sont toujours dirigées vers le même serveur, même lorsque le nombre de serveurs backend change. Lorsqu'un serveur est ajouté ou supprimé, seul un sous-ensemble minimal de requêtes est rerouté.

Les facteurs de hachage incluent :

• Adresse IP source : les requêtes provenant de la même adresse IP client atteignent toujours le même serveur backend.

• Quatre éléments : le hachage utilise la combinaison de l'adresse IP source, du port source, de l'adresse IP de destination et du port de destination. Les requêtes partageant ces quatre valeurs sont dirigées vers le même serveur.

• ID QUIC : le hachage utilise l'ID de connexion QUIC, qui identifie de manière unique chaque connexion QUIC. Le hachage basé sur les ID QUIC permet d'équilibrer la charge entre les connexions. Les requêtes avec le même ID QUIC sont distribuées au même serveur backend.

• Chaîne de requête URL : les requêtes avec la même chaîne de requête URL sont routées vers le même serveur backend.

Par exemple, avec deux instances ECS dans un groupe de serveurs, si la dernière requête a été routée vers ECS01, toute requête suivante ayant la même valeur de hachage sera également envoyée à ECS01.

Avantages

1. Persistance de session : les requêtes provenant d'une même source sont systématiquement routées vers le même serveur backend, préservant ainsi l'état de la session sans nécessiter de magasin de session séparé. Cela rend le hachage cohérent particulièrement adapté aux applications qui s'appuient sur des données de session côté serveur ou un cache spécifique à l'utilisateur.

2. Perturbation minimale lors des changements de serveur : lorsque des serveurs sont ajoutés ou supprimés, seules les requêtes dont les valeurs de hachage correspondent au slot modifié sont reroutées. Les autres requêtes continuent d'atteindre les mêmes serveurs qu'auparavant.

Inconvénients

1. Déséquilibre temporaire après modification des serveurs : l'ajout ou la suppression d'un serveur entraîne la redistribution des requêtes mappées au slot de hachage de ce serveur. Si le nombre de serveurs backend augmente, moins de requêtes sont replanifiées ; s'il diminue, davantage de requêtes le sont. Jusqu'à ce que le trafic se rééquilibre, certains serveurs peuvent supporter une part disproportionnée de la charge.

2. Complexité opérationnelle accrue lors du scale-out : chaque modification de serveur déclenche un rehachage partiel. Dans les environnements soumis à des événements de mise à l'échelle fréquents, ce reroutage continu ajoute une surcharge opérationnelle et peut compliquer la planification de la capacité.

Cas d'utilisation

1. Applications nécessitant la persistance de session : utilisez le hachage cohérent lorsque votre application stocke des données de session ou l'état utilisateur sur des serveurs backend individuels et ne peut tolérer que les requêtes d'un même utilisateur atteignent différents serveurs au milieu d'une session.

2. Backends fortement dépendants du cache : lorsque les serveurs backend maintiennent des caches locaux, router les mêmes requêtes vers le même serveur maximise les taux de succès du cache et réduit les calculs redondants à travers le cluster.

3. Exigences de localité des données : pour les charges de travail où les données partitionnées par clé doivent être traitées sur un serveur spécifique, comme les bases de données shardées ou le traitement de flux avec état, le hachage cohérent garantit que les requêtes pour chaque clé atteignent toujours la bonne partition.

Références

• Qu'est-ce que SLB ?

• Qu'est-ce que ALB ?

• Qu'est-ce que NLB ?

• Qu'est-ce que CLB ?