metal3d.org :: Linux Virtual Server

LVS, qu'est ce que c'est ?

Lorsque vous entrez dans le monde de l'administration Linux avancée, vous pouvez être certain que vous allez devoir répondre à une demande typique: monter un système de serveur haute disponibilité. Sous Linux, créer un cluster permettant de répartir la charge sur plusieurs autres serveur revient à utiliser le système "LVS" ou "Linux Virtual Server" à ne pas confondre avec LVM ou encore les machines virtuelles. Vous trouverez des exemples et des manuels plus ou moins compliqués sur le net, c'est pourquoi je me suis dis que ce serait bien de simplifier les explications afin que vous vous en sortiez plus aisément.

Contrairement à ce que vous pouvez penser, monter un système LVS n'est pas si complexe que cela. Beaucoup de didacticiels vous demandent de recompiler le noyau, de faire des manipulations dans tous les sens... n'ayez crainte ! La plupart des distributions modernes ayant un noyau récent ne demandent pas une recompilation. Tout est largement déjà packagé par la communauté, et je n'ai pas eut à me casser le tête pour monter un LVS en quelques minutes. Je vous jure, cela ne prend que quelques minutes si l'on comprend tout ce que l'on fait.

Alors commençons, il nous faut 3 machines, une sera le client, une sera le directeur (serveur qui va répartir), et la dernière sera le serveur "réel" qui est en fait le serveur qui supportera le calcul. Le mieux serait d'avoir 2 serveurs réels pour vous rendre compte de la répartition de charge... mais avez vous 4 machines sous la main ? Déjà 3 machines pour tester n'est pas si simple à trouver...

Ne voyez pas trop grand, des vieilles machines feront l'affaire, nous allons tester la répartition sur des services simples, comme telnet ou ssh...

Il y a aussi 2 notions à connaître:

• le DIRECTOR est le serveur qui va se charger de répartir la charge
• les REAL SERVER ou serveurs réels qui sont des serveurs qui répondent à la charge

Voici un schéma de réseau type:

Le but de l'exercice: Faire en sorte que le client se connecte sur 88.88.88.88:23 (telnet), la passerelle redirrige les paquets sur DIRECTOR:23, le director va ensuite envoyer la connexion à RealServer1 ou RealServer2 selon sa charge

Passons maintenant à nos notions à connaitre.

Il existe 4 types de répartitions de charges.

• REVERSE PROXY - ou proxy inversé, ne demande quasiment aucune configuration mais l'un des moins performant, cela n'entre pas dans la notion LVS donc nous n'allons pas en parler très longtemps dans cet article
• NAT - Network Address Translation - certainement l'une des plus simples à utiliser mais solution peu performante
• TUN - Tunneling IP - Permet de router les paquets dans un tunnel lié à un serveur réel, le serveur réel répondra lui même au travers de la passerelle sans repasser par le director. Je ne vais pas traiter ce principe pour le moment.
• DR - Direct Routing - Permet de router les paquets sur des serveurs réel qu répondront eux même, le serveur réel répondra lui même au travers de la passerelle sans repasser par le director

Dans le premier cas: REVERSE PROXY
DIRECTOR va devoir écouter sur le port 23. Chaque nouveau client qui vient à se connecter sur ce port reste connecté au DIRECTOR. DIRECTOR va ouvrir une connexion sur REALSERVER1 ou REALSERVER2 et envoit tout ce qu'il reçoit depuis la connexion sur le port 23 vers le serveur réel. Ensuite, tout ce qui revient du serveur réel est envoyé dans le port 23 de DIRECTOR en sortie.

• Avantage: Le principe est simple, ne demande pas de configuration complexe
• Inconvénient: Le serveur réel ne voit plus le client mais un seul client: DIRECTOR. En effet, c'est bel et bien DIRECTOR qui se connecte aux serveurs réels et fait transiter les paquets. De plus, DIRECTOR va prendre en charge de retourner les réponses à tout les clients connectés. Cela peut suffire pour des charges de connexion modérées...

Ce cas n'est pas du tout un système LVS... Passons plutôt aux autres méthodes.

Notion de Serveur Virtuel

Si nous utilisons le nom "LVS ou Linux Virtual Server" c'est bel et bien que nous allons créer un seul serveur à partir de plusieurs machines. L'idée à retenir c'est qu'il faut faire croire aux clients qu'un seul serveur répond alors qu'en réalité nous en avons plusieurs.

Prérequis

Je vous demande d'avoir des notions réseau assez solides, du moins de savoir ce qu'est un paquet, une ip, une carte réseau (et une interface du point de vue système). Vous avez déjà entendu parler de passerelle, de routeur, de redirrection de paquet...

Sur vos systèmes, il vous faudra:

• le module ip_vs sur les serveurs
  • sur le DIRECTOR dans le cas d'un montage LVS-NAT
  • sur le DIRECTOR et les REALSERVERS pour un montage LVS-DR
• accès root ou un sudo permissif sur les machines
• au moins 3 machines pour tester
• un réseau 192.168.0.0/24

Si votre réseau est sur une autre classe (10.xx.xx.xx, 172.28.xx.xx) il faudra adapter les IP et les masques en conséquence

Important: Il est important que le client ne fasse pas parti du LVS, c'est à dire qu'il ne soit ni DIRECTOR, ni un REALSERVER. Le mieux étant carrément d'avoir le client en dehors du réseau...

Module ipvs

Pour effectuer les opérations qui vont suivre, chargez le module ip_vs sur les machines qui vont avoir besoin d'ip virtuelles:

• sur DIRECTOR dans le cas d'un LVS-NAT
• sur DIRECTOR et les REALSERVERS dans le cas d'un LVS-DR

La commande pour charger le module dans le noyau est:

En ce qui concerne la commande ipvsadm, elle est largement packagée dans la plupart des distributions Linux modernes, voici des exemples:

Vérifez enfin les versions de votre noyau, cet article s'adresse à des kernel ≥ 2.6.18, par exemple:

Enfin, la version de ipvsadm qui doit être au moins 1.24

Si tout est ok, passons à la suite

LVS-NAT

Dans ces cas précis, le shéma de conception est le suivant:

Problème de route

Le DIRECTOR va avoir besoin de 2 adresse IP. Cela va pouvoir se faire de deux manières différentes:

• soit vous avez 2 cartes réseau sur deux réseau ou sous réseau différents
• soit vous créez une interface virtuelle qui aura une IP sur un réseau ou sous-réseau différent

Dans les deux cas, dans le système LVS-NAT, vous devez utiliser 2 réseaux ou sous-réseaux différents. Cela implique une problématique particulière: que la route vers le réseau LVS soit accessible si vous avez besoin de vous connecter sur le DIRECTOR.

Si vous configurez votre Director avec un client sur le réseau 192.168.0.0/24, il faudra connaître la route vers le réseau 192.168.1.0/24. Cela va sans dire que dans notre cas, toutes les machines sont connecté sur le même brin, dans ce cas il suffira au routeur de connaitre le réseau 192.168.1.0/24.

Par contre, si vous êtes sur deux brins (c'est à dire que le réseau ressemble au schéma de conception ci-dessus), et sachant que DIRECTOR va devenir un routeur, il suffira de dire au client que la route pour 192.168.1.0/24 passe par 192.168.0.100

Le mieux, pour ne pas trop s'ennerver, est configurer le LVS sur DIRECTOR physiquement.

Si vos serveurs se trouvent sur le réseau 192.168.0.0/24, sortez les de ce réseau avant de commencer en les plaçant sur un nouveau sous-réseau ou un nouveau réseau (passez en 192.168.1.0/24 ou carrément 10.0.0.0/8). Les machines sur le LVS doivent pouvoir se pinger entre elle.

Créez les IP, les routes et assignez correctement la ou les passerelles nécessaires avant de commencer. N'oubliez pas que vous êtes en train de configurer une grappe de serveur et non un ensemble de service.

Attention car si vous étiez en train de configurer le serveur DIRECTOR à distance, il faut éviter de perdre la connexion... sinon, un accès physique sera nécessaire.

Notez aussi que l'adresse d'entrée pour le LVS sera 192.168.0.100.

Chemin des paquets

Le paquet doit passer par DIRECTOR dans un sens comme dans l'autre. Voici le trajet parcourus par un paquet:
Client → PASSERELLE → DIRECTOR → REALSERVER 1 ou REALSERVER 2 → DIRECTOR → PASSERELLE → Client

Mise en place

• Avantage: Il n'y a que le director à configurer avec ipvsadm, les serveurs réels n'auront besoin que de connaître la route vers le serveur DIRECTOR comme passerelle.
• Inconvénient: DIRECTOR va répondre à tous les clients, ce qui peut créer un goulot d'étranglement comme pour le reverse proxy. Il faut aussi utiliser 2 sous-réseaux différents

Dans ce premier cas, seul DIRECTOR doit avoir une ip virtuelle. Rappelons d'abord les IP réelles qui nous intéressent:

• Passerelle utilisé par DIRECTOR: 192.168.0.254
• IP de Director 192.168.1.1
• IP des serveurs réels: 192.168.1.10 et 192.168.1.20
• Passerelle utilisée par les serveurs réels: 192.168.0.254

Dans le système LVS-NAT, il suffit de créer une fausse ip sur DIRECTOR, que nous allons assigner à 192.168.0.100, cette ip va se trouver sur la même carte réseau utilisée pour le réseau 192.168.1.0/24. De ce fait, elle sera accessible par le réseau à condition que les routes soient bien définies sur la passerelle ou sur les clients.

Il faut utiliser un réseau différent pour le LVS-NAT bien qu'il soit possible de créer un LVS-NAT sur le même réseau, cela permet de limiter le cache ARP.

Nous pourrions nous passer de cette ip virtuelle, mais cela implique que nous ne pourrons plus utiliser le service virtualisé sur DIRECTOR... Par exemple si nous virtualisons le service telnet sans créer d'adresse virtuelle sur director, nous ne pourrons plus nous connecter sur DIRECTOR en telnet puisque toute connexion sera envoyée à un serveur réel.

Il suffira d'utiliser l'outil "ipvsadm" pour dirriger les paquets vers les deux serveur réels. Là où se trouve l'astuce, c'est que les serveurs réels vont avoir comme route par défaut non pas la passerelle, mais DIRECTOR. Et pour ne pas tronquer le paquet, nous lui donnons l'adresse réelle...

Donc je résume ce que nous allons faire:

• ajouter une ip virtuelle 192.168.0.100 sur la carte eth0 de DIRECTOR
  • résultat: deux ip sur la même carte réseau de DIRECTOR: eth0 → 192.168.1.1 et eth0:virt → 192.168.0.100
• donner comme passerelle 192.168.1.1 (adresse du DIRETOR) à nos deux serveurs réels
• ajouter les serveurs réels à la table virtuelle grâce à ipvsadm sur DIRECTOR

Configurons nos serveurs, en premier DIRECTOR:

Voilà, reste à faire sur nos serveurs réels:

Après avoir fait cette manipulation sur les serveurs réels, prenez un client et tenter de vous connecter au serveur en telnet sur 192.168.0.100.

N'utilisez pas un ordinateur faisant parti du LVS, je le répète, la connexion risque de ne pas passer!

Selon toute vraisemblance, ce sera un serveur réel qui va répondre, mais vous (client) ne vous en rendez pas compte. Pour voir ce qu'il se passe, connectez vous au serveur DIRECTOR (avec l'adresse réelle 192.168.0.1) et tapez:

Le résultat devrait être du genre:

Sur la colonne "ActiveConn" apparait le nombre de connexion sur le serveur réel. La colonne "Forward" vous indique aussi que nous utilisons le mode "Masquerade", comprenez "NAT".

Ouvrez une autre session telnet sans couper l'autre et regardez encore ce que donne ipvsadm:

Cette fois, c'est l'autre serveur qui a répondu ! Voilà ça marche.

Que s'est-il passé réellement ?
Prenons l'exemple d'un client sur le LAN:
Le client se connecte sur 192.168.0.100 port 23. Les paquets ont donc ceci dans les entêtes:

• ip destinataire: ip du client
• ip destination : 192.168.0.100

Prenons un de ces paquets, le paquet arrive sur l'interface eth0:virt, la règle ipvsadm demande à "forwarder" le paquet sur un des serveurs.

Le masquerading modifie l'entête du paquet puis l'envoit au serveur réel ciblé, par exemple le RealServer 1 (192.168.1.10).

Le paquet a désormais en entêtes:

• ip destinataire: 192.168.0.100 (modifiée pour que ce soit DIRECTOR qui récupère le paquet)
• ip destination : 192.168.1.10

Lors la réponse, les paquets retourne au destinaitaire donc 192.168.0.100. Puis le masquerading remet les entêtes correctement, soit:

• ip destinataire: ip du client
• ip destination : 192.168.0.100

Le paquet retourne au destinataire et le client n'y a vu que du feu. Pour le client, c'est DIRECTOR (192.168.0.100) qui a répondu, alors qu'en réalité, c'est RealServer 1 (192.168.1.10).

La méthode reste simple à mettre en place, il s'agit simplement:

• de définir une règle de port à transmettre, ici c'était telenet mais vous pourriez utiliser http, ssh ou un numéro de port
• d'ajouter à cette règle les serveurs réels qui répondront à la demande
• de définir aux serveurs réels un routeur par défaut qui est le serveur DIRECTOR

LVS-DR

LVS-DR est un peu plus compliqué, mais cela reste humainement réalisable. L'idée est de faire transiter les paquets depuis le Director vers les serveurs réels mais que le retours (la réponse) se fasse au travers de la passerelle.

• Avantage: soulagement de DIRECTOR qui ne fait plus qu'un seul transit dans un seul sens. De plus, chaque serveur réel répond directement, les paquets n'ont pas à être modifiés ce qui fait encore gagner du temps
• Inconvénient: Il va falloir ajouter des IP virtuelles sur les serveurs réels et modifier quelques routes. Cela implique une logique un peu plus étendue.

Dans ces cas précis, le shéma de conception est le suivant:

Problématique de routes

Dans le cas d'un LVS-DR, tous les serveurs peuvent se trouver sur le même réseau, cela permet d'utiliser le même routeur pour la réception et l'envoi de données.

Le principe sera d'avoir:

• soit 2 cartes par serveurs, y compris les director
• soit configurer une interface virtuelle par serveur (ce que nous allons faire)

Cette fois, le LVS se trouve dans le même réseau que toutes les machines du réseau, c'est en fait très logique puisque le but est de simuler un seul serveur à partir d'une seule IP.

Chemin des paquets

Les paquets font un trajet direct vers le client sur le retour:
Client → PASSERELLE → DIRECTOR → REALSERVER 1 ou REALSERVER 2 → PASSERELLE → Client

Mise en place

L'IP a utiliser sera donc 192.168.0.100

• Avantage: Plus de sous-réseau à configurer, plus de route particulière à assigner aux client et/ou au gateway
• Inconvénient: Il faut configurer une interface virtuelle pour chaque serveurs, que ce soit DIRECTOR ou les RealServers.

Passons au principe:
Désormais, le but est de donner une ip qui sera partagée par tous les serveurs du réseau. Oui, c'est tout à fait possible. Rappelons nos adresses réelles:

• DIRECTOR a une adresse 192.168.0.1
• Passerelle à l'adresse 192.168.0.254
• Realserver 1 et 2 ont les adresses 192.168.0.10 et 192.168.0.20

Ce qu'il va se passer:

• ajouter une ip virtuelle 192.168.0.100 sur la carte eth0 de DIRECTOR
  • résultat: deux ip sur la même carte réseau de DIRECTOR: eth0→192.168.0.1 et eth0:virt→192.168.0.100
• ajouter une ip virtuelle 192.168.0.100 à Realserver 1 et 2
  • résultat: deux ip sur la boucle LOCALE réseau (lo) pour chaque serveur réel:
  • RealServer 1 : eth0: 192.168.0.10 et lo:virt 192.168.0.100
  • RealServer 2 : eth0: 192.168.0.20 et lo:virt 192.168.0.100
  • définir que la route pour l'adresse 192.168.0.100 est par défaut sur lo:virt pour ne pas retourner vers DIRECTOR
• donner comme passerelle 192.168.0.254 à nos deux serveurs réels
• ajouter les serveurs réels à la table virtuelle grâce à ipvsadm

Pourquoi mettre les IP virtuelles sur la boucle locale et non sur eth0 pour les serveurs réels ? C'est très simple. Il ne faut pas que le réseau voit cette ip sur plusieurs points différents. Sinon, il y aurait un conflit.

Seule DIRECTOR doit pouvoir répondre aux clients sur cette adresse. Par contre les serveurs virtuelles doivent utiliser leur propre carte... la seule "carte" (disons plutôt interface) qui ne soit pas visible sur le réseau est "lo", interface local ou "boucle locale" (qui correspond à l'ip 127.0.0.1).

Le masque de sous-réseau doit être complet sur les serveurs réels et le director, la raison est simple, avec un masque ouvert, l'interface virtuelle risque de répondre à toutes les demandes envoyées sur l'adresse virtuelle. Notre but étant de ne répondre que si le paquet entre bien dans le circuit LVS, donc nous routerons le paquet sur l'interface depuis les serveurs réels. Le but étant de cacher l'interface sur le réseau

Je vais expliquer cela dans les deux scripts qui suivent.

Voici comment faire, on commence par DIRECTOR:

Maintenant, passons à nos serveurs réels:

Dans la même optique, utiliser un poste client et tentez de vous connecter sur 192.168.0.100 en telnet (port 23), puis sur DIRECTOR regarder ce qu'il se passe avec la commande ipvsadm

Et ainsi de suite en tentant plusieur connexions. Les paquets passent désomais par la passerelle et non sur DIRECTOR lors du retour.

Vous remarquez que la colonne "Forward" utilise le routage de paquet et non le masquerading (NAT).

Que s'est-il passé réellement ?
Le client se connecte sur 192.168.0.100 port 23. Les paquets ont donc ceci dans les entêtes:

• ip destinataire: ip du client
• ip destination : 192.168.0.100

Prenons l'exemple d'un paquet, il arrive sur l'interface virtuelle et est directement envoyé à un serveur réel, par exemple RealServer 1 (192.168.0.10)

La différence est que cette fois ci, le paquet n'est pas modifié.

Le serveur réel a lui aussi l'adresse 192.168.0.100 et on a, de plus, spécifié que la route à prendre pour cette adresse est sur son propre système (interface lo).

Comme cette adresse existe localement sur le serveur réel, l'adresse de destinataire est valide pour ce serveur. Cela implique que le serveur peut répondre directement au client sans repasser par DIRECTOR afin de changer le paquet. On va pouvoir aller directement sur la passerelle par défaut. L'entête du paquet n'a pas bougé:

• ip destinataire: ip du client
• ip destination : 192.168.0.100

Et encore une fois, le client au bout de la chaîne n'y a vu que du feu.

Algorithmes de répartition

Comme vous l'avez vu, pour le moment, je n'ai utilisé que l'algorithme "RR" soit "Round Robin". Cela dit, ipvsadm permet de gérer 10 algorithmes de répartition. Choisir un algorithme n'est pas une mince affaire, sachant que "WLC" (Weighted Least-Connection) est très utilisé puisqu'il couvre la plupart des problématiques rencontrées: poid du serveur en terme de performance, répartition équilibrée...

Le Round Robin est par contre le plus simple à utiliser, il ne fait que répartir la charge à tour de rôle sur chaque serveur les uns après les autres...

Voici quelques uns des algorithmes utilisés par ipvs, je vous laisserai aller sur la page de man pour comprendre les autres algorithmes:

• rr - Robin Robin: distribue la charge de manière équitable sur les serveurs réel.
• wrr - Weighted Round Robin: assigne les travaux proportionnellement sur les serveur selon leur poids. Les serveurs qui ont un poids élevés reçoivent en premier les nouvelles demandes et prennent en charge plus de travau que les serveurs don le poids est plus faible. Les serveurs à poids égaux reçoivent une charge égales lors de la distribution de nouvelles demandes
• lc - Least-Connection: assigne les demandes aux serveurs qui ont le moins de charge en cours
• wlc - Weighted Least-Connection: idem que précédamment, mais réparti cela proportionnellement aux poids des serveurs

Le choix se fait surtout par expérience, il faut tester, tester et encore tester... jusqu'à trouve l'équilibre et le fonctionnement voulu.

Conclusion

Le principe de LVS est clairement de simuler un seul serveur. Que ce soit LVS-NAT ou LVS-DR, le loadbalancing est une technique appréciée et puissante permettant de réellement répondre rapidement à plusieurs clients tout en soulageant votre infrastructure.

Le choix entre LVS-NAT, LVS-DR et LVS-TUN se base sur plusieurs questions à se poser:

• mes serveurs réels sont sur différent domaines séparés (sur internet par exemple) : LVS-TUN
• mes serveurs vont générer un gros traffic risquant de surcharger le DIRECTOR: LVS-DR
• mes serveurs n'ont pas un gros traffic et/ou ne peuvent pas trop être modifié: LVS-NAT

Couplé à un système de monitoring et un HeartBeat, votre installation saura mettre un serveurs hors LVS si il ne répond plus ou si il devient trop lent.

N'hésitez pas à utiliser d'autres algorithmes comme lwc (Least Weight Connection) au lieu de rr (Round Robin), et augmentez aussi les poids (paramètre -w) si vous savez qu'un de vos serveurs réel peut répondre plus rapidement.

Je n'ai pas parlé du LVS-TUN pour le moment, il s'avère que je n'ai pas l'infrastructure pour tester cette configuration. En tout cas, j'espère que vous avez bien compris l'intérêt d'un LVS et que vous voyez comment le créer sans trop vous arracher les cheveux.