L’équilibrage de charge sous Linux avec LVS (théorie)

Source de l'image : Wikimédia Foundation

Source de l’image : Wikimédia Foundation

Je continue mes expériences dans le cadre de mon projet de fin d’année, et je me penche aujourd’hui sur les machines qui vont héberger l’API du projet. Cette fois-ci pas de pratique mais juste un peu de théorie. L’article technique ne devrait pas tarder.

Ces machines sont au nombre de deux et proposeront simplement un service web fourni par le couple Apache / PHP (je rappelle que notre API est développée avec CakePHP). Comme indiqué dans le cahier des charges, la future infrastructure devra être en mesure de supporter des montées en charge importantes et un serveur seul ne suffira jamais à tout supporter, aussi puissant soit-il.

Ma problématique est donc : comment répartir la charge sur plusieurs serveurs ?

Technologie choisie : Linux Virtual Server

Un peu de théorie

Après des recherches et mûre réflexion, notre choix s’est orienté vers Linux Virtual Server (LVS pour les intimes). LVS est une technologie d’équilibrage de charge fonctionnant sur la couche 4 du modèle OSI, là où HAProxy fonctionne sur la couche 7.

Notre machine LVS est donc une sorte de répartiteur qui va capter tous les flux entrant pour les répartir sur un ensemble de serveurs, invisible au reste du monde, et ainsi répartir la charge. De ce fait, lorsque les clients contacteront notre API, ils contacteront notre LVS, qui se chargera de répartir le trafic à tour de rôle sur la machine API-01 et API-02.

Bon alors évidemment pour notre projet nous n’avons pas des ressources en illimité, c’est pourquoi nous nous limitons à 2 machines. Mais sachez qu’en fonction de la configuration et du mode de fonctionnement choisi, un LVS pourra aisément fédérer plusieurs dizaines de serveurs réels. Vous permettant ainsi de proposer plus de services, avec plus de capacités et plus de débits, sans parler de la partie redondance / tolérance de panne (que nous aborderons plus tard)… Du moment que votre service repose sur un protocole type TCP ou UDP, votre seule limite sera votre imagination !

Ce que LVS n’est pas

Attention cependant à ne pas vous mélanger les pinceaux, je parle ici uniquement d’équilibrage de charge, et non pas de clustering. En effet, dans un cluster tous les hôtes ont conscience les uns des autres et fonctionnent de concert. Ici, API-01 ne sait absolument pas que API-02 existe ! Elle se charge simplement de répondre aux requêtes qu’elle reçoit du LVS, appelé directeur.

LVS n’est pas non plus un cluster Beowulf.

Bon allez, pour garder les choses simples, voici un schéma qui résume l’idée, avec un peu de vocabulaire en bonus :

J'espère que c'est clair pour tout le monde... (Cliquez pour agrandir)

J’espère que c’est clair pour tout le monde… (Cliquez pour agrandir)

  • Le directeur possède au moins deux adresses IP :
    1. Une adresse IP virtuelle (la VIP) qui sera publique, et donc exposée à Internet.
    2. Une seconde adresse, privée cette fois, destinée aux échanges avec les serveurs réels.
  • On trouve ensuite les adresses IP des serveurs réels. Ce sont ces serveurs qui fournissent le service désiré (service web dans mon cas).

Les modes de fonctionnement de LVS

Il existe trois principaux modes de fonctionnement d’un LVS.

LVS par traduction d’adresse (LVS-NAT)

Dans ce mode, lorsqu’un client accède au LVS, le directeur joue le rôle de routeur et effectue une traduction d’adresse. Tous les échanges passeront par le directeur et il n’y aura jamais de connexion directe entre vos clients et vos serveurs réels qui n’auront de toute façon aucune conscience ni de l’un, ni de l’autre !

Schéma LVS-NAT

Le gros avantage du LVS-NAT est que serveurs réels et clients peuvent être sur des réseaux différents, et un même service peut fonctionner sur des ports différents en fonction du serveur réel (ben oui on fait du NAT !). On pourrait d’ailleurs faire l’analogie entre le LVS-NAT et le service fourni par nos box Internet. Celles-ci ont une IP publique et font des traductions d’adresses avec tous les PC du réseau local de la maison…

L’inconvénient en revanche est lié au fait que tout notre trafic entrant et sortant passe forcément par le directeur, qui peut devenir un goulot d’étranglement en cas de fort trafic. Si c’est la cas, prévoyez un ou plusieurs directeurs sur du réseau Gigabit, ou songez à configurer plusieurs LVS en cluster 🙂

LVS par retour direct (LVS-DR)

Une autre solution en cas de fort trafic, et si votre topologie le permet, est l’utilisation de LVS en mode Direct Routing. Dans ce mode, les requêtes clients transitent par le directeur, qui les redistribue aux serveurs réels, mais les réponses sont renvoyées directement au client par les serveurs réels, sans passer par le directeur. Celui-ci perd donc son rôle de passerelle par défaut vis à vis des serveurs réels (dans le cas du LVS-NAT) et la VIP est partagée entre le directeur et tous les serveurs réels !

Schéma LVS-DR

Avantages : un gain non négligeable en performances puisque le directeur ne traite que les paquets en entrée, généralement de taille plus réduite que ceux en sortie. Un LVS seul pourra sans problème fédérer plusieurs dizaines de serveurs réels !

Par contre, comme la VIP est partagée entre tous les serveurs réels, ceci devront être configurés pour ne répondre qu’au trafic venant du directeur. Il y aura donc un peu de manipulation ARP à faire, nous verrons cela.

LVS par tunnel (LVS-TUN)

Dans ce mode, qui ressemble fortement au LVS-DR, un tunnel IP est mis en place entre votre directeur et chaque serveur réel. L’avantage étant que vos serveurs réels peuvent se trouver absolument n’importe où, puisque le tunnel IP garantit l’accès au serveur réel : sur un autre réseau à l’autre bout du monde, peu importe !

Cette avantage reste cependant à double tranchant car d’une part vous dépendez des aléas possibles d’Internet si vos serveurs réels sont éloignés, et d’autres part toutes vos machines doivent supporter la mise en place du tunnel IP. Ce qui peut nécessiter un peu de configuration supplémentaire, notamment à cause d’ARP.

Affaire à suivre…

J’espère que cette mise au point vous a donné envie d’essayer LVS car la mise en pratique arrive très bientôt ! J’espère aussi que vous saurez réaliser de grandes choses avec LVS, que je découvre et qui me semble encore très prometteur !

Si vous chercher plus de détails sur LVS, sachez que je me suis fortement inspiré de l’excellent ouvrage de Sébastien Rohaut : Linux, Solutions de Haute-Disponibilité publié aux Éditions ENI. Un livre à mettre entre les mains de tous les sysadmin Linux 🙂

Cet article vous a plu ? Partagez-le sur les réseaux sociaux !

Twitter Facebook Google Plus email