Comprendre les principes de la répartition de charge réseau et applicative : algorithmes, niveaux OSI concernés et solutions courantes.
Avancé — SISR 2ème année
⏱️ 20 min
📁 Réseau
🎯 Objectifs de la fiche
- Qu'est-ce que la répartition de charge ? — Définition, objectifs, lien avec la HA
- Niveaux d'intervention (L4 vs L7) — Répartition transport vs applicative
- Algorithmes de répartition — Round robin, least connections, pondéré...
- Vérification de l'état des serveurs — Health check, retrait automatique
- Solutions courantes — HAProxy, Nginx, solutions matérielles
Prérequis
Connaître les bases de la haute disponibilité (voir fiche précédente) et du modèle OSI. Cette fiche complète le Bloc 2 SISR 2ème année sur la disponibilité et la performance des services.
1. Qu'est-ce que la répartition de charge ?
La répartition de charge (load balancing) consiste à distribuer le trafic entrant entre plusieurs serveurs afin d'optimiser l'utilisation des ressources, d'améliorer les temps de réponse et d'éviter la surcharge d'un seul serveur.
| Bénéfice | Explication |
|---|
| Performance | Le trafic est réparti, évitant qu'un seul serveur ne sature |
| Disponibilité | Si un serveur tombe en panne, les autres continuent à traiter les requêtes |
| Scalabilité | Ajouter un nouveau serveur au pool augmente facilement la capacité globale |
| Maintenance facilitée | Un serveur peut être retiré temporairement du pool pour maintenance sans interruption de service |
ℹ️ La répartition de charge est un mécanisme clé de la haute disponibilité, mais elle répond aussi à un objectif de performance distinct : même sans panne, répartir la charge améliore les temps de réponse pour les utilisateurs.
2. Niveaux d'intervention — L4 vs L7
| Niveau OSI | Type de répartition | Critère de décision | Exemple d'usage |
|---|
| Couche 4 (Transport) | Répartition L4 | Adresse IP et port source/destination uniquement | Répartition rapide sans analyse du contenu applicatif |
| Couche 7 (Application) | Répartition L7 | Contenu de la requête (URL, en-têtes HTTP, cookies) | Répartir selon le chemin d'URL, gérer les sessions utilisateur |
💡 La répartition L7 permet des décisions plus fines (par exemple, diriger /api/ vers un pool de serveurs et /images/ vers un autre) mais nécessite plus de ressources de traitement que la répartition L4, plus simple et plus rapide.
3. Algorithmes de répartition de charge
| Algorithme | Principe | Cas d'usage adapté |
|---|
| Round Robin | Distribution séquentielle, un serveur après l'autre | Serveurs de capacité équivalente |
| Round Robin pondéré | Distribution proportionnelle à un poids attribué à chaque serveur | Serveurs de capacités différentes |
| Least Connections | Envoie la requête au serveur ayant le moins de connexions actives | Requêtes de durée variable |
| Least Response Time | Envoie la requête au serveur répondant le plus rapidement | Optimisation de la latence perçue |
| Hachage IP source | Le même client est systématiquement dirigé vers le même serveur | Maintien de session sans cookie |
Exemple — Round Robin simple avec 3 serveurs (A, B, C) :
Requête 1 → Serveur A
Requête 2 → Serveur B
Requête 3 → Serveur C
Requête 4 → Serveur A (le cycle reprend)
Requête 5 → Serveur B
...
4. Vérification de l'état des serveurs — health check
Un répartiteur de charge doit vérifier en permanence que les serveurs du pool sont opérationnels avant de leur envoyer du trafic. C'est le rôle du health check (vérification de santé).
| Type de health check | Vérification effectuée |
|---|
| Vérification réseau (ping/TCP) | Le serveur répond-il sur le réseau et sur le port concerné ? |
| Vérification HTTP | Une requête HTTP sur une URL spécifique renvoie-t-elle un code de succès (200) ? |
| Vérification applicative avancée | L'application répond-elle correctement avec un contenu attendu (pas juste un code 200) ? |
⚠️ Un serveur qui répond au ping mais dont l'application est en réalité défaillante (erreur applicative, base de données inaccessible) peut continuer à recevoir du trafic si le health check se limite à une simple vérification réseau. Un health check applicatif plus poussé est recommandé pour les services critiques.
Fonctionnement du retrait automatique :
1. Le répartiteur teste périodiquement chaque serveur (ex: toutes les 5 secondes)
2. Si un serveur échoue à N vérifications consécutives → il est retiré du pool
3. Le trafic est redirigé vers les serveurs restants, sans interruption visible
4. Le répartiteur continue de tester le serveur défaillant en arrière-plan
5. Dès que le serveur répond correctement à nouveau → il est réintégré au pool
5. Solutions courantes de répartition de charge
| Solution | Type | Particularité |
|---|
| HAProxy | Logiciel, open source | Très performant, répartition L4 et L7, très utilisé en production |
| Nginx | Logiciel, open source | Serveur web pouvant aussi agir comme reverse proxy/load balancer |
| Traefik | Logiciel, open source | Conçu pour les environnements conteneurisés (Docker, Kubernetes) |
| Keepalived + VRRP | Logiciel, open source | Plutôt orienté haute disponibilité que répartition de charge pure |
| Load balancer matériel | Matériel, commercial | Appliances dédiées (F5, Citrix ADC) pour très gros volumes |
| Load balancer cloud | Service managé | AWS ELB, Azure Load Balancer — gérés par le fournisseur cloud |
- ☐ 4 bénéfices de la répartition de charge identifiés
- ☐ Différence entre répartition L4 et L7 comprise avec un exemple
- ☐ 5 algorithmes de répartition distingués selon leur cas d'usage
- ☐ Notion de health check comprise, avec ses 3 niveaux de vérification
- ☐ Mécanisme de retrait/réintégration automatique d'un serveur du pool assimilé
- ☐ Solutions courantes identifiées (HAProxy, Nginx, Traefik)