La répartition de charge est l’un des concepts essentiels à la mise en place d’architectures capables d’absorber une charge importante et résistantes aux pannes. Il s’agit d’un ensemble de techniques permettant de distribuer une charge de travail entre différents ordinateurs d'un groupe.
Les domaines d’utilisation de la répartition de charge sont de plus en plus nombreux en particulier avec l’avènement du cloud et des architectures de données décentralisées. Ainsi ces techniques sont utilisées dans : les supercalculateurs, les services http à forte audience, les bases de données nécessitant un accès permanent, le bigdata, l’entrainement des réseaux neuronaux, etc...
L’ensemble des serveurs de traitements (appelés serveurs réels) et des répartiteurs de charges est appelé « serveur virtuel » (ou une ferme de serveurs).
La répartition de charge utilise des algorithmes dans le but de définir le serveur réel qui sera chargé de traiter la requête.
Couche 2 du modèle OSI : Il s’agit de la couche liaison du modèle OSI, il se base uniquement sur les adresses MAC pour appliquer son algorithme de répartition. Certaines solutions utilisant cette méthode sont capables de faire du routage à la volée. Utilisé par des équipements réseaux.
Couche 4 du modèle OSI : Il s’agit de la couche transport du modèle OSI, il se base uniquement sur l’adresse IP pour appliquer son algorithme de répartition. Exemple de logiciel utilisant cette méthode : HaProxy.
Couche 7 du modèle OSI : C’est la couche applicative du modèle OSI, l’algorithme de répartition pourra ainsi se baser sur des données de l’application. Exemple de logiciel utilisant cette méthode : Nginx.
Les sticky sessions
Certaines applications nécessitent des « sticky sessions », c’est-à-dire que les utilisateurs devront d’avoir toujours le même serveur de traitement dans le but de garder leur fichier de session accessible.
Pour faire ceci il y a deux méthodes, soit on utilise un algorithme de répartition par hachage source qui se basera sur une constante du client pour obtenir un serveur de traitement, soit on applique un algorithme plus classique mais on envoie au client un token qui indiquera lors des prochaines requêtes sur quel serveur est disponible la session, ainsi les requêtes suivantes seront automatiquement redirigées vers le bon serveur.
Certains services mettent en place des clusters capables de partager les données, ainsi, tous les serveurs du pool peuvent avoir accès aux fichiers de session et la problématique des sessions est descendue plus bas dans l’architecture du service.
Haute disponibilité
Le principe de la haute disponibilité est de mettre en place un « failover », lorsqu’un serveur est hors ligne et que le répartiteur de charge essaye de le contacter sans succès, la requête sera attribuée à un autre serveur réel.
La pondération
La pondération consiste à attribuer à chaque serveur réel un poids dans le but de lui donner plus ou moins de tâche à effectuer. L’utilité est de pouvoir avoir des modèles de serveurs différents mais de faire en sorte que chaque un d’entre eux soit utilisé selon sa capacité. Cette technique est compatible avec tous les algorithmes de répartition de charge.
Quelques projets de répartition de charge
Traefik est un répartiteur de charge développé spécifiquement pour les architectures modernes basées sur docker. Le principe est de rendre la répartition de charge automatique seulement en indiquant à quoi sert chaque conteneur.
Kong est un projet se basant sur nginx, ce qui lui permet d’avoir de très bonnes performances. Ce projet est construit pour la gestion centralisée d’un ensemble d’APIs (par exemple pour une architecture en micro-services).
ProxySQL est un projet qui a pour but de gérer la répartition de charge et la réplication des données entre plusieurs serveurs SQL.