Linux Virtual Server
Publié le jeudi 4 janvier 2007, mis a jour le samedi 15 mars 2008, par Stephane Malinet
- Introduction
- Les architectures LVS
- Les algorithmes
- Scénario
- Configuration du load balancer
- Configuration des serveurs réels
- Liens
Attention ne confondez pas Linux Virtual Server et Vserver : le second permet d’inserer un système dans un autre, de manière chrootée (pour plus d’info sur Vserver).
Linux Virual Server est un projet qui consiste à mettre en place un système d’équilibrage de charge fonctionnant sur les couches réseau et transport du modèle OSI afin d’apporter performance et disponibilité.
Cette architecture est basée sur un serveur node, appelé load balancer, redirigeant les requètes TCP et/ou UDP vers un pool de serveurs, appelés serveurs réels, de manière completement transparente pour l’utilisateur (voir l’image ci-dessous).
Vous pouvez implémenter LVS selon 3 méthodes aux choix :
1. NAT (Network Adress Translation) : c’est-à-dire la translation d’adresse IP entre le load balancer et les serveurs réels, cette méthode limite le nombre de serveurs réels :
2. le tunneling IP : la liaison entre le load balancer et les serveurs réels se fait via un tunnel IP, les serveurs réels répondent directement au client :
3. Le Direct Routing : le load balancer et les serveurs réels doivent se trouver sur le même segment réseau, les serveurs réels répondent directement au client :
C’est la méthode qui sera mise en place dans cette documentation.
Il vous faudra choisir entre les différents algorithmes de balancing selon vos besoins :
Round-Robin Scheduling : Dans cette configuration, la répartition fonctionne de manière cyclique, sans se préoccuper de la charge des serveurs. La première requête sera affectée au 1er serveur,
la seconde au second serveur, ainsi de suite en boucle.
Weighted Round-Robin Scheduling : Même technique, mais les real-serveurs peuvent être affectés par des poids, pour tenir compte des différentes capacités de traitement.
Least-Connection Scheduling : Le load-balancer possède une table des connections actives. Il renverra toute nouvelle requête au serveur possédant le moins de connexions actives, dynamiquement.
Weighted Least-Connection Scheduling : Même idée que l’algorithme précédent, en ayant la possibilité d’attribuer des poids aux serveurs.
Locality-Based Least-Connection Scheduling : Le load balancer choisit un serveur réel dans un groupe en fonction de l’adresse IP de destination. Il est utilisé dans les clusters de cache.
Locality-Based Least-Connection with Replication scheduling : Idem que le précédent, avec une
fonctionnalité supplémentaire : si tous les serveurs du groupe sont surchargés ou indisponibles, il choisit un serveur dans un autre groupe pour l’affecter au 1er groupe de serveurs.
Destination Hashing Scheduling : Affecte la requête arrivant à un serveur d’un groupe fixé dans
une table de hashage, en fonction de l’adresse IP de destination.
Source Hashing Scheduling : Affecte la requête à un serveur réel en fonction de l’adresse source.
Nous considererons dans le restant de cette documentation que notre architecture se compose de 3 serveurs sur un même réseau : le load balancer aura l’IP 192.168.0.1 et les serveurs réels auront respectivement 192.168.0.2 et 192.168.0.3. Nous souhaitons, dans le cadre d’un service web, équilibrer la charge sur le port 80. Nous mettrons donc en place LVS sur une architecture Direct routing avec l’algorithme Weighted Least-Connection Scheduling.
Dans un premier temps il va nous falloir recompiler le noyau afin d’activer le support LVS sachant qu’il vous faudra minimun une version 2.6.10 sinon vous devrez patcher votre noyau.
Networking --->
[*] Networking support
Networking options --->
IP: Virtual Server Configuration --->
<M> IP virtual server support (EXPERIMENTAL)
[*] IP virtual server debugging
(20) IPVS connection table size (the Nth power of 2)
--- IPVS transport protocol load balancing support
[*] TCP load balancing support
[*] UDP load balancing support
[*] ESP load balancing support
[*] AH load balancing support
--- IPVS scheduler
<M> round-robin scheduling
<M> weighted round-robin scheduling
<M> least-connection scheduling
<M> weighted least-connection scheduling
<M> locality-based least-connection scheduling
<M> locality-based least-connection with replication scheduling
<M> destination hashing scheduling
<M> source hashing scheduling
<M> shortest expected delay scheduling
<M> never queue scheduling
--- IPVS application helper
<M> FTP protocol helperUne fois votre nouveau noyau compilé, bootez dessus.
Vous n’êtes pas obligé de charger les modules au démarrage car ceux nécéssaires se chargeront automatiquement en utilisant la commande ipvsadm.
Pour la partie concernant iptables je vous laisse passer à cet article.
nous allons avoir besoin de quelques paquets :
# emerge -av sys-cluster/ipvsadm
Afin de configurer ipvsadm, je vous ai confectionné un petit script spécial pour les gentooistes :
# wget http://babykart.free.fr/scripts/virtualserver/virtualserver-rules.conf -P /etc
# wget http://babykart.free.fr/scripts/virtualserver/virtualserver-rules -P /usr/local/sbin
# chmod +x /usr/local/sbin/virtualserver-rules
Et un autre pour les non-gentooistes :
# wget http://babykart.free.fr/scripts/virtualserver/virtualserver-rules.conf -P /etc
# wget http://babykart.free.fr/scripts/virtualserver/virtualserver-rules_nogen -P /usr/local/sbin
# chmod +x /usr/local/sbin/virtualserver-rules_nogen
Passons donc à la configuration du fichier /etc/virtualserver-rules.conf :
activated_vs="vs0"
vs0() {
# choix de l'algorithme de load balancing
# Round-Robin Scheduling: Dans cette configuration, la repartition fonctionne de maniere cyclique,
# sans se preoccuper de la charge des serveurs. La premiere requete sera affectee au 1er serveur,
# la seconde au second serveur, ainsi de suite en boucle.
# --> rr
#
# Weighted Round-Robin Scheduling: Meme technique, mais les real-serveurs peuvent être affectes
# par des poids, pour tenir compte des differentes capacites de traitement.
# --> wrr
#
# Least-Connection Scheduling: Le load-balancer possede une table des connections actives. Il renverra
# toute nouvelle requete au serveur possedant le moins de connexions actives, dynamiquement.
# --> lc
#
# Weighted Least-Connection Scheduling: Meme idee que l'algorithme precedent, en ayant la possibilite
# d'attribuer des poids aux serveurs.
# --> wlc
#
# Locality-Based Least-Connection Scheduling: Le load balancer choisit un serveur reel dans un
# groupe en fonction de l'adresse IP de destination. Il est utilise dans les clusters de cache.
# --> lblc
#
# Locality-Based Least-Connection with Replication scheduling: Idem que le precedent, avec une
# fonctionnalite supplementaire : si tous les serveurs du groupe sont surcharges ou indisponibles,
# il choisit un serveur dans un autre groupe pour l'affecter au 1er groupe de serveurs.
# --> lblcr
#
# Destination Hashing Scheduling : Affecte la requete arrivant a un serveur d'un groupe fixe dans
# une table de hashage, en fonction de l'adresse IP de destination.
# --> dh
#
# Source Hashing Scheduling: Affecte la requete a un serveur reel en fonction de l'adresse source.
# --> sh
vs_algo="wlc"
# choix de la topologie
# Network address translation --> -m
# IP tunneling --> -i
# Direct Routing request dispatching technique --> -g
vs_net="-g"
# l'adresse virtuel ou bien le domaine du load balancer
vs_ip="192.168.0.1"
#vs_ip="gentoofr.org"
# le protocol
# UDP --> -u
# TCP --> -t
vs_protocol="TCP"
# le port ou le service du load balancer
# voir le fichier /etc/services
vs_serv="http"
# les IP des serveurs réels
vs_reals="192.168.0.2+2 192.168.0.3+2"
}
vs1() {
vs_algo="wlc"
vs_net="-g"
vs_ip="192.168.0.4"
vs_protocol="UDP"
vs_serv="ntp"
vs_reals="192.168.0.2+2"
}
ensuite éxecutez le script, lancez et installez le service ipvsadm :
# /usr/local/sbin/virtualserver-rules
* VirtualServer vs0 ...
* TCP VirtualServer IP: 192.168.0.4:http with wlc algorithm
* -> TCP RealServer IP: 192.168.0.2:http -g weight: 2
* -> TCP RealServer IP: 192.168.0.3:http -g weight: 2
# /etc/init.d/ipvsadm save && /etc/init.d/ipvsadm start
# rc-update -a ipvsadm default
La configuration du load balancer s’arrete là, passons aux serveurs réels.
Les serveurs réels ne nécéssitent que l’installation d’iptables dont nous nous servirons pour contrer les problèmes de cache ARP.
Il éxiste d’autres méthodes que vous pourrez trouver sur le site officiel de Linux Virtual Server pour contrer les problèmes de cache ARP, mais j’ai retenu la redirection sous iptables pour sa facilité de mise en oeuvre et sa flexibilité dans le cas d’un changement de load balancer.
L’installation et la configuration d’iptables.
Ensuite, il vous suffit d’ajouter ces lignes au fichier /etc/netfilter-rules.conf :
# configuration load balancing pour contrer le cache arp
iptables -t nat -A PREROUTING -p TCP -d 192.168.0.1 --dport 80 -j REDIRECT --to-port 80
# indispensable pour les real servers LVS
echo 1 > /proc/sys/net/ipv4/ip_forward
et de lancer la commande
# netfilter-rules
Il ne nous reste plus qu’à vérifier que cela fonctionne.
Assurez-vous que sur chacun des serveurs réels vous avez une page d’index différente, prenez votre navigateur préféré, et lancez plusieurs fois l’url http://192.168.0.1 : si vous voyez bien les deux index différents c’est gagné...
Par ailleurs, dans une console sur le load balancer tapez la commande suivante :
# ipvsadm -L
IP Virtual Server version 1.2.1 (size=1048576)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.0.1:http wlc
-> 192.168.0.2:http Route 2 1 1
-> 192.168.0.3:http Route 2 2 1Votre serveur virtuel est donc fonctionnel et vous permet par simple modification dans le fichier /etc/virtualserver-rules.conf (et en éxecutant la commande qui va avec) de rentrer ou sortir des serveurs réels ou de modifier leur poids.
RSS 2.0