L'équilibrage de charge (LoadBalance) en détail : aussi appelé F5, avec des cas concrets

En exploitation et en sécurité, on ne peut quasiment pas esquiver un terme : l'équilibrage de charge. Dès qu'on le mentionne, la première machine qui vient à l'esprit de beaucoup, c'est « F5 ». Le plus amusant, c'est que F5 est avant tout un nom d'entreprise (F5 Networks), mais ses produits sont si célèbres que le nom est devenu peu à peu synonyme d'équilibreur de charge, comme « googler » est devenu synonyme de recherche.

Cet article fait le tour complet : ce qu'est vraiment F5, ce qui distingue les couches 4 et 7, et comment configurer dans des cas réels.

1. À quel problème répond l'équilibrage de charge

L'équilibrage de charge (Load Balance) consiste, dans son principe, à répartir les tâches sur plusieurs unités de traitement — serveurs web, serveurs FTP, serveurs d'applications critiques d'entreprise — pour qu'ils accomplissent le travail ensemble.

D'un point de vue technique, il expose vers l'extérieur une adresse de serveur virtuel. Lorsqu'un utilisateur se connecte, il transfère la connexion vers le serveur réel le plus approprié via une traduction d'adresses réseau bidirectionnelle (NAT). L'utilisateur ne voit toujours qu'une seule entrée ; derrière, c'est tout un parc de machines qui porte la charge.

Il répond à trois préoccupations : la crainte de la panne(point de défaillance unique), la crainte de la saturation(goulot d'étranglement de performances), la crainte de l'impossibilité d'étendre(absence de montée en charge horizontale).

2. Couche 4 vs couche 7 : la confusion la plus fréquente

La différence tient en une phrase : faut-il ou non analyser les protocoles de la couche application. Cette différence détermine directement les limites de capacités et les performances.

Équilibrage de charge en couche 4 (couche transport)

• Niveau de travail : couche 4 du modèle OSI, protocoles TCP/UDP
• Critères de transfert : IP source, IP destination, ports — sans toucher aux données applicatives
• Capacités clés : redirection de ports, réutilisation des connexions TCP, health checks de couche 4 (handshake TCP), protection DDoS de base
• Performances : efficacité de transfert extrême, proche de la limite matérielle, latence de l'ordre de la microseconde
• Cas d'usage typiques : bases de données (MySQL/Redis), services TCP (serveurs de jeux, services Netty), répartition de charge entre centres de données
• Produits représentatifs : LVS, F5 (mode couche 4), HAProxy (mode couche 4), Nginx (module stream)

Équilibrage de charge en couche 7 (couche application)

• Niveau de travail : couche 7 du modèle OSI, protocoles applicatifs HTTP/HTTPS, DNS, FTP, etc.
• Critères de transfert : URL, cookies, en-têtes HTTP, paramètres de requête, contenu JSON
• Capacités clés : routage par contenu, déchargement SSL, cache, limitation et délestage de débit, intégration WAF, persistance de session, déploiement progressif (canary)
• Performances : riches en fonctions, mais l'analyse des protocoles applicatifs entraîne une latence un peu plus élevée (millisecondes), compensée par l'extension en cluster
• Cas d'usage typiques : applications web, API de microservices, services HTTPS, déploiement canary, passerelles d'API
• Produits représentatifs : Nginx, HAProxy (mode couche 7), F5 (module couche 7), Kong, Spring Cloud Gateway

Moyen mnémotechnique en une phrase : en couche 4, on lit le « panneau indicateur » (IP et port) et on transfère ; en couche 7, on « déballe le colis » (on examine le contenu) avant de décider où l'envoyer. Pour la performance, choisissez la couche 4 ; pour les fonctions avancées, la couche 7.

3. Où se situe réellement la force de F5 BIG-IP

Le produit phare de F5, BIG-IP LTM, porte officiellement le nom de gestionnaire de trafic local, capable d'équilibrer de la couche 4 à la couche 7. Ce n'est pas un simple transitaire : la liste des fonctions est longue — commutation applicative, commutation de sessions, supervision d'état, NAT intelligent, persistance universelle, traitement des erreurs de réponse, passerelle IPv6, routage avancé, accélération SSL, compression HTTP intelligente, optimisation TCP, mise en mémoire tampon du contenu, chiffrement des cookies, filtrage des attaques applicatives, protection contre les DoS et le SYN Flood, filtrage de paquets pare-feu…

En voici les plus utiles :

1. Équilibrage et redondance multi-liaisons

Les activités critiques se connectent souvent à plusieurs lignes ISP pour garantir la qualité et éliminer les points de défaillance uniques. Deux directions se distinguent :

• le trafic OUTBOUND(accès de l'interne vers l'extérieur) : BIG-IP LC répartit intelligemment le trafic sur différentes interfaces Internet et effectue le NAT d'adresse source
• le trafic INBOUND(accès de l'extérieur vers l'interne) : liaison des adresses publiques des deux ISP, résolution des requêtes DNS des deux FAI, avec des réponses intelligentes selon la santé des serveurs et les temps RTT

2. Équilibrage de charge des serveurs

Le service est exposé via une VIP (IP virtuelle, composée d'une adresse IP et d'un port TCP/UDP), avec des health checks continus de L4 à L7 sur les serveurs cibles. Dès qu'un serveur défaillant est détecté, il est retiré du groupe d'équilibrage. Avec les iRules, il est même possible d'ouvrir les paquets TCP/UDP et d'appliquer des règles selon le contenu — par exemple diriger le trafic vers différents serveurs selon l'URL.

3. Haute disponibilité du système

C'est le point dont F5 est le plus fier. En mode de redondance à deux machines, le basculement se fait en millisecondes(en 200 ms au plus rapide), pour une disponibilité revendiquée de 99,999 %. Le principe : toutes les sessions qui transitent par l'équipement Active sont synchronisées vers l'équipement Backup via le câble de synchronisation — c'est pourquoi l'accès utilisateur n'est pas interrompu lors du basculement. La puce watchdog de chaque équipement surveille l'autre via le câble de heartbeat ; si l'Active tombe, le Backup est immédiatement notifié pour prendre le relais de l'IP partagée et des VIP.

4. Sécurité

BIG-IP suit les principes de conception d'un pare-feu : refus par défaut. Il peut démanteler les connexions inactives pour contrer les DoS, exécuter un traçage de route source contre l'usurpation d'IP, et refuser les SYN sans ACK contre les attaques SYN. Sa fonctionnalité Dynamic Reaping supprime efficacement les connexions inactives pendant une attaque DoS, et accélère le rythme de coupure des connexions à mesure que l'attaque s'intensifie — un point plutôt redoutable. La technique Delay Binding, elle, offre aux serveurs backend une protection complète contre le SYN Flood.

5. Accélération SSL

Chaque BIG-IP embarque une puce d'accélération SSL matérielle, avec une licence de 100 TPS incluse, sans frais supplémentaires. Pour monter en puissance ensuite, il suffit de mettre à niveau la licence.

4. F5 ou Nginx ? Comparatif pour bien choisir

C'est la question qui revient le plus sur le terrain. Les deux ne sont pas concurrents, mais plutôt complémentaires.

F5 BIG-IP (matériel)

• Forme de déploiement : appliance matérielle dédiée (avec puces sur mesure)
• Performances : connexions TCP à l'échelle du million, latence de transfert en microsecondes
• Fonctions : polyvalence totale — couches 4+7, déchargement SSL, protection DDoS, WAF, VPN, répartition de liaison
• Fiabilité : redondance matérielle (haute disponibilité à deux machines), disponibilité de 99,999 %
• Coût : très élevé (des centaines de milliers au million), entretien par des ingénieurs spécialisés requis
• Scalabilité : dépendante des mises à niveau matérielles, faible flexibilité
• Exploitation : complexe, nécessite la maîtrise de l'interface de configuration dédiée et de la CLI

Nginx (logiciel)

• Forme de déploiement : logiciel, sur serveurs génériques ou instances cloud
• Performances : connexions TCP à l'échelle de la centaine de milliers, latence en millisecondes, montée en charge par cluster possible
• Fonctions : léger et efficace — couche 7 au cœur, avec prise en charge de la couche 4, déchargement SSL, cache, limitation de débit, proxy inverse
• Fiabilité : haute disponibilité à deux machines à configurer manuellement (Keepalived), dépend de la stabilité matérielle des serveurs
• Coût : gratuit en open source, Nginx Plus reste assez abordable
• Scalabilité : déploiement en cluster pris en charge, extension élastique dans le cloud
• Exploitation : simple, fichiers de configuration lisibles, prise en main rapide pour un développeur backend

Les carrefours de choix, à suivre tels quels :

• services TCP à forte concurrence (jeux, bourse) + disponibilité maximale → F5 en couche 4
• entrée du cœur de métier + besoins de sécurité (WAF/DDoS) → F5 en couche 7
• passerelle d'API de microservices + déploiement cloud → Nginx en couche 7
• charge de bases de données/Redis + bon rapport qualité-prix → Nginx en couche 4
• activités de petite ou moyenne taille + itération rapide → Nginx (couche 4/couche 7)
• centre de données d'entreprise + multi-liaisons → F5 à l'entrée, Nginx pour la charge des services internes

Cette dernière combinaison est très courante chez les grands acteurs — F5 garde la frontière, Nginx gère l'intérieur.

5. Cas pratique : à quel point la configuration de F5 est déroutante

Face à un F5 pour la première fois, beaucoup pensent : « ce n'est absolument pas la logique d'un commutateur, impossible de savoir par où commencer ». Sa logique de configuration appartient à un tout autre univers.

Scénario : deux serveurs web servent l'extérieur avec les IP 192.168.192.10-20/24 ; l'équilibrage de charge doit se faire via l'adresse externe 192.168.27.100 sur le port 80.

L'équilibrage le plus simple ne demande que trois paramètres, imbriqués les uns dans les autres :

• Node (nœud) : la définition de base ; chaque serveur est un Node
• Pool (bassin de ressources) : un ensemble de Nodes qui reçoivent et traitent le trafic, par exemple un cluster de serveurs web
• Virtual Server (serveur virtuel) : l'entrée exposée vers l'extérieur, associée à un Pool

Flux de données : requête client → Virtual Server → Pool → Node.

Étapes pratiques (interface d'administration BIG-IP) :

• Étape 1 : activer l'équipement. À réception du F5, activez-le d'abord ; l'assistant est simple, mais retenez que une connexion Internet est indispensable, idéalement avant la mise en baie — c'est du vécu
• Étape 2 : se connecter. Ouvrez https://IP-Admin dans le navigateur ; identifiant et mot de passe par défaut : admin
• Étape 3 : créer les VLAN. Network → VLANs : créez les VLAN et ajoutez les interfaces (en Untagged)
• Étape 4 : configurer les IP. Networks → Self IPs : définissez une adresse pour chaque VLAN
• Étape 5 : configurer le routage. Networks → Routes : définissez la passerelle par défaut ou des routes statiques
• Étape 6 : configurer le Pool. Local Traffic → Virtual Servers → Pools : définissez le nom, le health check (TCP par exemple), l'algorithme de répartition (comme observed-member) ainsi que les IP et ports des serveurs réels
• Étape 7 : configurer le Virtual Server. Local Traffic → Virtual Servers : associez le Pool ci-dessus et choisissez la méthode de répartition (RoundRobin est courant)
• Étape 8 : configurer le Monitor. Local Traffic → Monitors : vérifiez l'état de santé des serveurs et associez le Pool
• Étape 9 : configurer le Redundant, pour la redondance à deux machines

6. Les paramètres clés du Virtual Server

Le cœur de F5, c'est le Virtual Server ; quelques paramètres négligés suffisent à créer des ennuis.

VS Type (type) — trois types courants :

• Performance L4 : transfert purement couche 4 ; le TMM se charge uniquement de la distribution des connexions, sans modifier les paramètres TCP, et la connexion client-serveur est 1:1. Vitesse de transfert élevée, très utilisé en entreprise. Pour limiter l'impact sur les applications, choisissez celui-ci en priorité dès que possible
• Standard VS : les connexions TCP client et serveur sont totalement indépendantes. À utiliser pour les fonctions de couche 7 (persistance par cookie, par Session ID, par Header, découpage de connexions longues par transaction, protection contre les attaques SYN). Attention à une particularité : son port reste toujours ouvert vers l'extérieur — même si tous les Nodes backend sont down, le port 80 de la VIP reste joignable en telnet ; seule la page ne s'affiche pas. Gardez-le en mémoire lors du diagnostic
• Forwarding IP : pour les connexions entre réseaux interne et externe ; pas de Pool Member, le transfert dépend du routage local. Par défaut, F5 n'assure pas de routage : il faut créer un VS tout en 0 pour activer cette fonction

Les Timeout doivent être alignés(c'est un vrai piège). Si un TCP Profile est configuré sur le VS, les connexions UDP ne seront pas acceptées. Attention surtout à la valeur d'Idle Timeout dans tcp — elle doit être coordonnée avec le serveur. Si F5 est réglé à 150 secondes alors que le serveur IIS est à 300 secondes, une pluie d'erreurs s'ensuit. Les deux côtés doivent se mettre d'accord sur le délai.

Address/Port Translation : activés par défaut tous les deux. Ouvrez Address Translation quand l'IP du VS diffère de celle des machines réelles ; ouvrez Port Translation quand le port 8080 du VS correspond au port 80 de l'adresse réelle.

SNAT AutoMap : l'adresse source SNAT est le Self IP du VLAN par lequel la requête sort. Lorsqu'un VLAN compte plusieurs Self IP, ils sont utilisés en rotation.

7. Pourquoi la « persistance de session » est incontournable

C'est le concept le plus souvent négligé de l'équilibrage de charge, et le plus prompt à causer des incidents.

Dans les systèmes d'e-commerce ou d'authentification en ligne, un client doit passer par de multiples interactions pour mener une transaction à terme. Ces interactions sont étroitement liées : pour traiter la deuxième étape, le serveur doit souvent connaître le résultat de la première. Cela exige que toutes ces interactions soient traitées par le même serveur, et non dispersées par l'équilibreur de charge sur différentes machines.

C'est tout l'intérêt de la persistance de session (Persistence). F5 la met en œuvre via la Connectivité, avec plusieurs modes au choix :

• persistance par adresse source : liaison selon l'IP source du client
• persistance par Cookie : F5 insère automatiquement un cookie de session, le plus courant en couche 7
• persistance par SSL Session ID : réutilisation des sessions SSL
• table de persistance de session : prend en charge plusieurs règles de timeout et de correspondance

Quelles conséquences en cas d'erreur de configuration ? L'utilisateur ajoute un article à son panier, rafraîchit la page, et tout a disparu — la requête a été envoyée à un autre serveur. Ce genre d'incident en production est épuisant à diagnostiquer.

8. Quelques détails pratiques à ne pas esquiver

Pour finir, quelques pièges déjà subis par d'autres, avec les conclusions directes :

• Choisissez le bon niveau pour le health check : avec un simple handshake TCP, un serveur dont le port répond mais dont l'application est tombée continue de recevoir du trafic ; pour vérifier la couche application, utilisez un Monitor de type HTTP sondant des points comme /actuator/health
• Le pare-feu doit être monté « en sandwich » : un pare-feu seul plafonne souvent à 30 % du débit de la ligne ; augmenter la capacité impose d'en empiler plusieurs. Or un pare-feu exige que les données entrent et sortent par lui, sinon les connexions sont refusées — la solution d'équilibrage de pare-feu de F5 résout ce problème en assurant la persistance à travers les équipements transparents
• Le déchargement SSL est le plus gros économiseur de CPU : laissez F5 gérer le handshake HTTPS et le chiffrement/déchiffrement ; l'application Java en backend ne traite plus que du HTTP, avec un gain de performance manifeste
• Testez en charge avant de connecter la production : la couche 4 est rapide, mais si vous activez la persistance de session sur un VS de couche 4, vous introduisez de l'état ; les attentes de performance doivent être recalculées
• Surveillez trois métriques : l'état des pools, le débit des serveurs virtuels, la santé des nœuds
• Commandes de diagnostic : tmsh show ltm pool <pool-name> pour l'état du pool, tmsh show ltm virtual <vs-name> pour l'état du serveur virtuel

Pour finir

L'équilibrage de charge ressemble à un simple « équipement de transfert », mais il occupe en réalité la position la plus critique de toute l'architecture — tout le trafic passe entre ses mains. Bien configuré, les utilisateurs ne sentent même pas son existence ; mal configuré, c'est votre téléphone qui sonne en pleine nuit.

Avec la vague cloud native, des solutions logicielles comme LVS, Nginx ou HAProxy suffisent largement pour les scénarios de petite et moyenne envergure, avec un net avantage de coût. Mais pour les entrées critiques de la finance, de la bourse ou du grand e-commerce, la valeur de l'équilibrage matériel — stabilité, basculement en millisecondes, sécurité intégrée de bout en bout — reste irremplaçable à court terme.

Quant au nom « F5 », son passage d'entreprise à catégorie d'équipements en dit long — quand un produit devient un verbe, il a déjà gagné ce marché.

Couche 4 lit le panneau, couche 7 déballe le colis ; la performance choisit la couche 4, les fonctions avancées la couche 7.

Références : documentation officielle F5 BIG-IP LTM, cas d'équilibrage de charge F5 de « Network Operations and Management », comparaisons techniques de l'équilibrage couche 4/couche 7