IPVS et ipvsadm : répartir en couche 4, dans le noyau

1. Ce que « couche 4 » veut dire vraiment

IPVS répartit des connexions, pas des requêtes. Il regarde une adresse et un port, choisit une cible, et laisse passer les paquets sans jamais ouvrir ce qu'ils transportent. Il ne sait pas si c'est du HTTP, du SQL ou du SMTP — et c'est exactement ce qui fait sa force.

Ce que ça apporte

• Des performances difficiles à égaler : le travail se fait dans le noyau, sans copie vers l'espace utilisateur
• La pondération : un serveur deux fois plus gros reçoit deux fois plus
• L'indépendance au protocole : tout ce qui passe par TCP ou UDP est répartissable
• Un test de santé sur la cible, pour la retirer quand elle ne répond plus

Ce que ça interdit

• Router selon l'URL : elle est dans le contenu, invisible à ce niveau
• Terminer le chiffrement : il faudrait déchiffrer, donc ouvrir
• Un test de santé réellement applicatif — le port ouvert ne prouve pas que l'application va bien
• Réécrire quoi que ce soit dans la requête

2. Les trois modes, et celui qu'on choisit

IPVS peut acheminer le trafic de trois façons, et le choix a des conséquences très concrètes sur le réseau — bien plus que sur la configuration.

Mode	Chemin du retour	Contrainte
NAT	Repasse par le répartiteur	Le plus simple à mettre en place, mais tout le trafic retour transite par le répartiteur, qui devient le goulot
Routage direct	Va directement au client	Les cibles doivent être sur le même segment et porter l'adresse virtuelle en loopback sans y répondre en ARP
Tunnel	Va directement au client	Permet des cibles distantes, au prix d'un encapsulage et d'une taille de paquet réduite

Notre choix par défaut : le routage direct

Parce que seul l'aller passe par le répartiteur. Pour un service web, le retour représente l'essentiel du volume : le sortir du chemin change complètement le dimensionnement de la machine qui répartit. En contrepartie, il faut configurer les cibles avec soin — l'adresse virtuelle en loopback, et surtout la discrétion ARP, faute de quoi plusieurs machines répondent pour la même adresse et le réseau devient incohérent.

3. C'est le même keepalived

Le point qui change la décision, et qu'on oublie souvent : on n'ajoute pas un outil. Le démon qui porte déjà l'adresse flottante sait piloter IPVS. On passe d'un rôle à deux dans la même configuration, avec la même exploitation et la même astreinte.

virtual_server 192.0.2.10 443 {
    delay_loop      6            # intervalle entre deux vérifications
    lb_algo         wlc          # moins chargé, pondéré
    lb_kind         DR           # routage direct
    protocol        TCP

    real_server 10.0.0.11 443 {
        weight 100               # cette machine encaisse 2x plus
        TCP_CHECK { connect_timeout 3 }
    }
    real_server 10.0.0.12 443 {
        weight 50
        TCP_CHECK { connect_timeout 3 }
    }
}

Le même fichier contient le bloc vrrp_instance qui fait vivre l'adresse. Les deux répartiteurs se surveillent, l'un porte l'adresse, et celui qui la porte distribue. L'outil ipvsadm sert alors surtout à observer : il montre en direct les connexions actives par cible, ce qui est la façon la plus rapide de vérifier que la pondération fait ce qu'on croit.

La limite du test de santé en couche 4

Un TCP_CHECK vérifie qu'un port accepte les connexions. Il ne dit rien de l'application derrière : un serveur web qui renvoie une erreur 500 sur chaque requête passe le test sans difficulté. Quand cette distinction compte, il faut monter en couche 7 — ou accepter que la supervision applicative se fasse ailleurs.

4. Notre retour d'expérience : un flux de lecture pur

Nous avons réparti un flux de base de données strictement en lecture seule avec IPVS, sans aucun proxy SQL. Le réflexe habituel, devant une base, est d'aller chercher un proxy qui comprend le protocole. Ici, il n'y en avait pas besoin.

Parce que la séparation était déjà faite

L'application ouvrait déjà deux connexions distinctes : une pour écrire, une pour lire. Le flux de lecture était donc identifié en amont, et il ne restait plus qu'un problème de distribution — que la couche 4 résout parfaitement, avec un outil déjà en place et une seule pièce en plus.

C'est l'illustration la plus nette de la règle qui structure ce sujet : on ne monte d'un niveau que lorsqu'on a besoin de ce que ce niveau apporte en propre. Un proxy SQL sert à décider requête par requête. Si personne n'a besoin de cette décision, il n'apporte qu'un composant supplémentaire à exploiter, à mettre à jour et à redonder.

La réserve à garder à l'esprit reste la même qu'au niveau 5 : répartir des lectures sur des réplicas n'a de sens que si l'on sait à quel point ils sont à jour. IPVS ne surveille pas le retard de réplication — c'est à la supervision de le faire, et à l'application de tolérer un léger décalage. Le sujet est traité sur notre site MariaDB.

5. Où la couche 4 s'arrête

IPVS est excellent tant que la décision de répartition ne dépend pas du contenu. Quatre besoins imposent de monter en couche 7 — et un cinquième, souvent oublié, impose surtout de redonder.

• Router selon l'URL ou un en-tête : impossible sans lire la requête.
• Terminer le chiffrement à un endroit unique, pour ne pas gérer les certificats sur chaque cible.
• Des sessions collantes fiables : en couche 4 on ne dispose que de l'adresse source, qui est un critère fragile derrière un partage d'adresses.
• Un test de santé qui teste vraiment l'application, pas seulement le port.
• Et dans tous les cas : le répartiteur est devenu le chemin unique. Deux machines et une adresse flottante, sinon on a déplacé le point de panne au lieu de le supprimer.

Questions fréquentes

IPVS ou HAProxy : lequel choisir ?

La question est de savoir si la décision de répartition doit tenir compte du contenu des requêtes. Si non — un flux TCP homogène, des cibles interchangeables — IPVS fait le travail avec de meilleures performances et moins de pièces. Dès qu'il faut router selon l'URL, terminer le chiffrement ou tester réellement la santé applicative, HAProxy s'impose. Les deux peuvent d'ailleurs coexister : IPVS devant plusieurs HAProxy est un montage classique à très grande échelle.

Faut-il configurer les serveurs cibles en mode routage direct ?

Oui, et c'est la contrepartie du gain. Chaque cible doit porter l'adresse virtuelle sur son interface de bouclage et ne jamais y répondre en ARP. Si cette discrétion n'est pas configurée, plusieurs machines revendiquent la même adresse sur le réseau et le comportement devient erratique — c'est l'erreur classique de ce mode, et elle se manifeste par des symptômes intermittents difficiles à relier à leur cause.

Peut-on répartir une base de données avec IPVS ?

Oui, à une condition : que la séparation entre lectures et écritures soit déjà faite en amont, par l'application. Nous l'avons déployé sur un flux strictement en lecture seule et cela fonctionne très bien. Si tout passe par la même connexion, IPVS ne peut rien distinguer et il faut un proxy qui parle le protocole de la base.

ipvsadm sert-il à configurer ou à observer ?

Les deux, mais en pratique surtout à observer. La configuration durable passe par keepalived, qui gère aussi la bascule de l'adresse et les tests de santé. ipvsadm reste l'outil le plus direct pour voir en temps réel combien de connexions vont vers chaque cible — et donc pour vérifier que la pondération produit bien l'effet attendu.

Votre répartiteur teste-t-il le port, ou le service ?

C'est la première chose que nous regardons sur une infrastructure existante. La réponse détermine s'il faut monter en couche 7 ou simplement mieux superviser.

Demander un devis

IPVS et ipvsadm :
répartir en couche 4, dans le noyau

Sommaire