a ne plus utiliser ce guide ne fonctionne plus avec nos nouvelles regles de securité au niveau de nos routeurs !


Ce guide est fait pour des personnes expérimentées, sachant recompiler un noyau et ayant des connaissances réseau. Ce guide aura pour but de créer un cluster avec un load balancer sous fedoracore. (Ce guide est réalisé avec une fedoracore 8)

Il y a aura 4 étapes :
Compilation du noyau
Installation et configuration du load balancer (ipvsadm et ldirectord)
Configuration des serveurs réels
installation et configuration du filer


Allez dans le dossier /usr/src/ et téléchargez les sources du noyau et le .config
exemple :



Configuration :
vous avez 3 possibilités pour reconfigurer un noyau :
♦ make xconfig (graphique) ou :
♦ make menuconfig (mode texte avec menus) ou encore :
♦ make config (mode texte intégral)

nous allons utiliser :


Ensuite on recompile le noyau avec le support de lvs :

on active les options suivantes :

Networking --->
* Networking support
Networking options --->
IP: Virtual Server Configuration --->
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
<*> round-robin scheduling
<*> weighted round-robin scheduling
<*> least-connection scheduling
<*> weighted least-connection scheduling
<*> locality-based least-connection scheduling
<*> locality-based least-connection with replication scheduling
<*> destination hashing scheduling
<*> source hashing scheduling
<*> shortest expected delay scheduling
<*> never queue scheduling
--- IPVS application helper
<*> FTP protocol helper

• Compilation :

on vérifie les dépendances :


on compile le noyau :



-Installation (les lignes suivantes sont à adapter à votre configuration, à la version du noyau...) :



ensuite on édite le fichier /etc/lilo.conf



modifiez la ligne :
default=linux par default=loadbalancer

et rajoutez un paragraphe par exemple :


root=/dev/md1 à remplacer par ce qui correspond a votre partition de boot.

on recharge la configuration par la commande :


ensuite on reboot le serveur et on croise les doigts !!


notre serveur reboot on passe à l'installation et configuration de notre repariteur de charge :




Voici a quoi va ressembler le trajet d'une requête vers le répartiteur de charge :




nous allons utiliser l'architecture tunneling IP pour ce guide.

-NAT (Network Adress Translation) : c’est de la translation d’adresse IP entre le répartiteur de charge et les serveurs réels.

-Le Direct Routing : le répartiteur de charge et les serveurs réels doivent se trouver sur le même segment réseau, les serveurs réels répondent directement au client

-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

Dans ce guide nous développerons la dernière architecture LVS.


Il vous faut choisir entre les différents algorithmes de balancing selon vos besoins et les différents services gérés par le répartiteur de charge :

- Round-robin Scheduling (rr) : 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 (wrr): 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 (lc) : 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 (wlc) : 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 (lblc) : 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 (lblcr) : 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 (dh) : 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 (sh) : Affecte la requête à un serveur réel en fonction de l’adresse source.



Pour gérer LVS que nous avons activé dans notre kernel, nous allons installé ipvsadm.
Pour faire une comparaison, ipvsadm est ce qu'est iptable a netfilter.

Pour l'installer utilisez les commandes :



modifiez le fichier /etc/sysctl.conf :



remplacer :
net.ipv4.ip_forward = 0 par net.ipv4.ip_forward = 1

ensuite rechargez sysctl :



on vérifie qu'il est installé correctement :


Il n'y a pas de message d'erreur donc on continue



Pour notre répartiteur de charge nous allons utiliser une ipfailover ce qui va nous permettre en plus de faire un répartiteur de secours en cas de probleme et de basculer l'ip failover d'un répartiteur à l'autre.

Dans la suite de notre guide nous allons appeler l'ip de notre loadbalancer : IPDIRECTOR
il vous faudra donc remplacer IPDIRECTOR par l'ip du loadbalancer.

Pour configurer l'ip failover nous vous invitons a suivre ce guide :
http://guide.ovh.com/ajouteraliasip

Nous allons prendre un exemple de configuration pour le serveur apache (port80)
nous aurons dans l'exemple 2 serveurs réels avec les ip : IPR1 et IPR2 pour la suite de notre guide.

nous avons choisit l'algorithmes wrr.
nous déclarons une répartitions pour le port 80 avec l'ip IPDIRECTOR :



on vérifie qu'elle est prise en compte :



on voit qu'il a pris en compte l'IPDIRECTOR pour le port 80 et l'algorithme wrr.

Maintenant nous ajoutons nos serveurs avec des poids différents.
-le serveur 1 aura le poids 2
-le serveur 2 aura le poids 1

Nous avons un total de 3 pour l'ensemble des poids:
le serveur 1 aura 2/3 des requêtes et le serveur 2 aura 1/3 des requêtes.



on vérifie que les serveur sont bien pris en compte ainsi que leur poids.



nos serveurs sont bien dans le cluster.

maintenant il nous faut configurer nos serveurs réels pour qu'ils puissent accepter les paquets.


pour que notre serveur réel accepte les requetes envoyées par le load-balancer, l'ip de notre répartiteur doit etre connue de chaque machine du cluster ,nous ajoutons cette ip de cette maniere :
(manipulation a faire sur chaque machine du cluster)



Faites attention dans certaines distributions le fait de le configurer avec ifconfig la configuration peut disparaitre avec un redémarrage du serveur.
attention: Dans ce cas, créez la en dur dans votre fichier de configuration réseau ou créer un fichier qui se lancera au démarrage du serveur avec les deux commande précédente.

Ensuite pour que le routeur ne reçoive plus de requetes arp indiquant que l'ip corresponde a cette adresse mac de serveur. nous desactivons l'arp.



Enfin on active les redirection d'ip :


Pour les services gérés par le répartiteur n'oubliez pas de lui indiquer d'écouter cette ip, dans le cas d'un virtualhost celui ci doit etre declarer avec l'ip IPDIRECTOR.

et voila si vous faites un test vous arriverez soit sur le serveur 1 ou le serveur 2 de maniere cyclique.

Pour avoir une synchronisation des données pour les serveurs dans le cluster , nous preconisons d'installer un filer ainsi tous les serveurs auront les meme données instantanéments.



Notre repartiteur de charge fonctionne mais si une machine dans le cluster tombe les clients auront des messages d'erreurs indiquant que le site n'est pas accessible. il faut la retirer du pool de serveur . Nous pouvons le faire automatiquement avec ldirectord.

Pour l'installer suivez ces instructions :



ensuite les modules suivant peuvent demander une installation en fonction de la configuration avec ldirectord.

on install cpan pour les differents modules suivants si necessaire.

pour verifier le protocole pop3

pour verifier un protocole utilisant le ssl

pour verifier le protocole imap

Pour verifier le service DNS

Nous allons maintenant créer un fichier de configuration pour ldirectord



Il y aura deux grandes parties pour le fichier de configuration :
-une partie globale
-une partie pour chaque service.

dans la partie global :




c'est le délai en secondes pour négocier les contrôles.



c'est le délai en secondes pour se connecter, des contrôles des services UP si le délai est dépassé alors le serveur réel est déclaré mort.



Définit le nombre de seconde entre chaque contrôle par défaut ldirectord met une valeur 10s. Pour notre guide nous l'avons réglé a 30s.



Le nombre de fois où un contrôle sera atteint avant qu'il ne soit considéré comme ayant échoué.



logfile = "/chemin/vers/fichierjournal" sinon ce sera le fichier syslog.
Un autre fichier journal peut être spécifié, Si le fichier journal ne possède pas un chef de file '/', il est supposé être syslog.



adresse de courriel valide pour l'envoi des alertes sur le changement de statut de connexion a un serveur réel défini dans le service virtuel.



Délai en secondes entre les alertes par e-mail, tandis que n'importe quel serveur réel dans le service virtuel reste inaccessible. Une valeur de zéro seconde empêche la répétition des alertes


quel type d'alertes allons nous suivre; ici toutes.


dans la partie par services :



c'est un service particulier il vous faut une persistance dans les connections vers les serveurs réel.
attention : la tabulation est tres importante dans le fichier de configuration (pas un espace mais bien une tabulation)



Il vous faut creer un fichier welcome.msg dans le repertoire de l'utilisateur que vous allez creer specialement pour ce test avec le contenu 200. Ldirector va faire une connection ftp et va verifier le contenu de welcome.msg et le comprarer a la valeur receive.







ldirector va verifier via le protocole http que la page test.html contient bien 200.
le fichier test.html devra etre dans repertoire correspondant au virtualhost de l'adresse de votre serveur.


Pour tester ce service vous pouvez creer une adresse qui sera utilisée pour le test uniquement.
l'exemple en dessous est a titre indicatif , à parametrer selon vos besoins.







si vous souhaitez faire juste avec un ping du service vous pouvez le faire en mettant de manière générale:



remplacez chaque valeur dans l'exemple ci dessus.

vous avez d'autres possibilités pour les services mais nous vous invitons verifier la documentation officielle de ldirectord


enfin nous lancons ldirectord en mode debug pour verifier que tout se passe bien :



vous verrez ainsi si il y a des messages d'erreurs.

ensuite pour lancer ldirectord :
nous allons modifier une ligne au fichier de lancement de ldirectord



et commentez la ligne suivante en mettant un # devant comme ceci :



pour le lancer utilisez la commande :



pour mettre ldirectord au demarrage :
chkconfig --level 35 ldirectord on


pour verifier votre cluster en temps réel :


et pour les connections :