LOAD-BALANCING AVEC LINUX VIRTUAL SERVER

LOAD-BALANCING AVEC LINUX VIRTUAL SERVER Projet CSII1 2008 encadré par M. Ozano Réalisé par : - Yann Garit - Yann Gilliot - Steve Lacroix - Dorian Lamandé - Maxime Panczak - Aymeric Vroomhout CSII1 Année 2008 Projet Load-Balancing

SOMMAIRE Introduction... 1 1 Le cluster... 1 2 Le load-balancing ou répartiteur de charge... 1 3 De quoi a-t-on besoin?(niveau matériel)... 2 I) A quoi servent ces technologies... 4 1 Le load-balancing... 4 A) Les avantages... 4 B) Les différents algorithmes de routage... 4 C) Comment se passe la connexion d un client... 6 2 Fonctionnement de LVS et algorithmes de LVS... 6 A) Fonctionnement de LVS... 6 B) Le NAT... 7 C) L IP tuneling... 7 D) Le routage direct... 8 3 Le clustering... 8 A) Les avantages... 8 B) Utilisation... 9 C) Heartbeart et Ldirector... 9 D) Comment mettre en place ces paquets... 9 E) Tests sur heartbeat... 10 II) Comment mettre en place un répartiteur de charge... 12 1 Mettre en IP fixe les serveurs... 12 2 Installer les paquets nécessaires... 14 3 Autoriser le routage... 14 4 Ajouter des machines dans le cluster... 15 III) Les tests à effectuer... 16 Conclusion... 17 CSII1 Année 2008 Projet Load-Balancing

INTRODUCTION Une des principales difficultés rencontrées par les administrateurs réseaux est la capacité à monter en charge, c'est-à-dire la faculté de répondre aux requêtes avec un temps de réponse acceptable, même en cas d'affluence massive. Le load-balancing va permettre de résoudre ce souci en équilibrant les charges en fonction du nombre de serveurs, de leurs capacités, et de l algorithme choisi. Nous allons vous expliquer tout ceci en commençant par quelques définitions indispensables pour avoir le même vocabulaire. 1 LE CLUSTER Un cluster serveur est un groupe de systèmes informatiques indépendants, appelés nœuds (node en anglais), qui exécutent un système d exploitation et fonctionnent ensemble comme s'il s'agissait d'un seul système pour garantir que des applications et des ressources stratégiques restent disponibles pour les clients. Chaque nœud est connecté à un ou plusieurs périphériques de stockage de cluster. Les clusters serveur permettent aux utilisateurs et aux administrateurs d'accéder aux nœuds et de les gérer, non comme des ordinateurs distincts, mais comme un seul système. 2 LE LOAD-BALANCING OU REPARTITEUR DE CHARGE La répartition de charge (load-balancing en anglais, littéralement équilibrage de charge) est une technique utilisée en informatique pour distribuer un travail entre plusieurs processus, ordinateurs, disques ou autres ressources. Le principe de base consiste à interposer entre les consommateurs de la ressource et le pool de ressources un dispositif (le répartiteur ou load-balancer en anglais) qui connaît l'état d'occupation de chaque ressource et qui est capable de diriger le consommateur vers la ressource la moins occupée, ou la plus facilement accessible. Les ressources peuvent ne pas avoir la même capacité à satisfaire les besoins du consommateur (en vitesse de traitement, en bande passante, etc.), ce qui influe sur le mode de calcul du répartiteur. Il existe différents types d algorithmes de répartition de charge. Ils seront expliqués dans la suite de ce rapport. CSII1 Année 2008 Projet Load-Balancing page 1

3 DE QUOI A-T-ON BESOIN? (NIVEAU MATÉRIEL) Pour faire du load-balancing, il faut au minimum un serveur qui sert de load-balancer et qui dispache les ressources, ainsi que d au moins deux serveurs réels qui traiteront les informations reçues. Cependant dans notre configuration, nous avons ajouté un second loadbalancer, pour ainsi pour étendre le sujet, et créer un répartiteur de charge de secours. (Celuici est facultatif, tout fonctionne parfaitement avec uniquement un load balancer) Voici donc notre architecture qui a été mise en place. Eth0 est la carte externe (pour internet) et eth1 est la carte LAN (qui reste dans le cluster) Loadb1 eth0 192.168.4.100 eth1 192.168.5.1 Real1 eth0 192.168.5.10 Real2 eth0 192.168.5.11 Pour avoir plus de détail sur les configurations, allez voir la partie II. CSII1 Année 2008 Projet Load-Balancing page 2

Les postes de travail sont des clients qui se connectent au cluster. Ils ne connaissent que l IP 192.168.4.100 et ne se rendent pas compte qu il y a en fait plusieurs serveurs capables de gérer leur demande. Voilà le schéma le plus simple que nous ayons réalisé. Cependant nous pouvons ajouter un second répartiteur de charge et ajouter un module heartbeat entre les deux load-balancer ce qui permet d ajouter de la sécurité à notre architecture. Ainsi si l un des répartiteurs de charge tombe en panne, le second sera automatiquement utilisé afin d allouer les ressources aux serveurs réels. Des explications sur heartbeat seront apportées dans le chapitre suivant. CSII1 Année 2008 Projet Load-Balancing page 3

I) A QUOI SERVENT CES TECHNOLOGIES 1 LE LOAD-BALANCING A) LES AVANTAGES La répartition de charge est une forme d'optimisation. Les avantages sont nombreux : - Augmentation de la qualité des services. - Amélioration des temps de réponse des services. - Capacité à palier la défaillance d'une ou de plusieurs machines. - Possibilité d'ajouter des serveurs sans interruption de service. B) LES DIFFERENTS ALGORITHMES DE ROUTAGE Différents algorithmes de répartition de la charge sont implémentés dans LVS. Ils définissent l'ordre dans lequel le load-balancer affectera les requêtes des clients aux différents serveurs réels proposant un service. Chaque service hébergé dans une ferme de serveurs LVS peut posséder son propre algorithme de répartition de charge. Voici ces algorithmes existants : - Le Round-Robin (RR) considère avec égalité tous les serveurs réels sans se soucier du nombre de connections entrantes ou du temps de réponse de chacun. Il est qualifié d'algorithme de répartition sans condition d'état. Par exemple, dans une configuration avec 2 serveurs réels, la première requête sera affectée au 1 er serveur, la seconde au second serveur, la 3 ème requête au 1 er serveur, et ainsi de suite en boucle. Note : Un exemple de répartition de charge de type Round-robin est effectué au niveau des serveurs DNS : ainsi, pour un nom de domaine précis, le serveur DNS possède plusieurs adresses IP. À chaque requête, le serveur DNS choisit l'adresse IP à inclure dans la réponse de manière à ce que chaque adresse IP soit présente dans les réponses de manière équitable. Les différents accès au nom de domaine sont par conséquent répartis équitablement entre les différentes adresses IP. Des tranches de temps sont donc accordées à chaque processus en proportion égale, sans leur accorder de priorité. Chaque processus reçoit du temps processeur appelé "quantum". Quand l'algorithme change de processus, cela prend du temps (de l'ordre de 1 ms). Il faut donc trouver le juste milieu entre : CSII1 Année 2008 Projet Load-Balancing page 4

o Un quantum court : changements de processus réguliers donc perte d'efficacité o Un quantum long : le temps de réponse sera allongé Les algorithmes suivant sont : - Le Weighted Round-Robin (WRR) ajoute à la boucle du RR la notion de poids. Ainsi, il est plus performant que ce dernier dans le cas ou les capacités de traitement sont différentes. Cependant, il peut mener à une mauvaise gestion de la charge lorsque les puissances varient beaucoup. Il est en effet fréquent que les grosses requêtes soient dirigées vers le même serveur, déséquilibrant ainsi la balance. - Le Least-Connection (LC) dirige les requêtes vers le serveur ayant le moins de connexions établies. Il est dit dynamique, comptant le nombre de connexion de chaque serveur pour estimer sa charge. Il garde un état du nombre de connexion, incrémentant le compteur lors de l'assignation ou le décrémentant lors d'une déconnexion ou d'un timeout. Le Least-Connection est idéal lorsque les serveurs ont une puissance de traitement similaire. Note: TCP produit un phénomène de cache. L'état TIME_WAIT, d'une durée d'environ 2 minutes par défaut, est un état durant lesquels les requêtes reçues sont conservées afin d'empêcher que les paquets non fiables ou avec des erreurs ne soient à nouveau traités. Cela surcharge ainsi virtuellement le serveur. Pendant une période d'attente de 2 minutes, un site surchargé peut recevoir des centaines de connexions. Ainsi, un serveur A (imaginons le, deux fois plus puissant qu'un serveur B) peut garder des requêtes déjà exécutées dans un état de TIME_WAIT alors que le serveur B aura du mal à se défaire de sa centaine de connexion en cours. - Le Weighted Least Connexion (WLC) gère bien mieux la répartition entre serveurs de puissances différentes. Les serveurs du cluster sont classés par rapport à leur poids, et un pourcentage leur est attribué. Le système de répartition du LC s'y ajoute ensuite. - Locality-Based Least-Connection : 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. CSII1 Année 2008 Projet Load-Balancing page 5

- Locality-Based Least-Connection with Replication : 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 1 er groupe de serveurs. - Destination Hashing : affecte la requête arrivant à un serveur d'un groupe fixé dans une table de hachage, en fonction de l'adresse IP de destination. - Source Hashing : affecte la requête à un serveur réel en fonction de l'adresse source. C) COMMENT SE PASSE LA CONNEXION D UN CLIENT Le client se connecte via la seule IP qu il connait : c'est-à-dire l IP principale du loadbalancer. Celui-ci via l algorithme de routage choisi, va renvoyer le client sur le serveur réel le plus adapté à l instant t. Ainsi le client pourra utiliser le service apache, et ne se rendra même pas compte qu il y a plusieurs serveurs qui pouvaient traiter sa demande. 2 FONCTIONNEMENT DE LVS ET ALGORITHMES DE LVS A) FONCTIONNEMENT DE LVS Mettre en place une solution de clustering et de load-balancing permet d accroître la disponibilité de votre application tel qu un serveur web ou encore un serveur ftp. Pour effectuer cela, il existe plusieurs techniques : - Disposer d un routeur de couche 4 - De mettre en place l option Round Robin sur votre serveur DNS - A l aide de logiciel tel que Linux Virtual Server (LVS) LVS est un logiciel qui travaille sur les couches 3 et 4. Il fait des redirections sur différentes adresses IP et sur différents ports TCP. Nous pourrions dire que c est un Round Robin évolué. En effet, si l on fait une symétrie entre LVS et Round Robin, dans le rôle du serveur ce sera le load-balancer, et pour le reste cela reste la même chose. CSII1 Année 2008 Projet Load-Balancing page 6

Ainsi, lorsque l on effectue une requête au load-balancer c est lui qui va déterminer quel serveur va répondre, en fonction de sa table répertoriant les serveurs réels et les services du serveur. Il se peut que ce load-balancer peut tomber en panne alors vous pouvez mettre un second load-balancer pour plus de sécurité. Ces deux répartiteurs de charge sont reliés par heartbeat. Les répartiteurs de charge forment un cluster, et chaque machine du cluster s appelle un node. Quel est l intérêt par rapport à l option Round Robin d un serveur DNS? Cela permet une meilleure adaptation au réseau et aux pannes car si un serveur réel tombe en panne, la table du load-balancer est directement mise à jour par l intermédiaire d un logiciel nommé mon. De plus il existe beaucoup de logiciel de surveillance pour que l application soit disponible à 99,9%. LVS peut fonctionner sur tous les systèmes, du moment que celui-ci puisse fournir le service adéquat (comme http) car la répartition de charge se paramètre avec IPVS. Il existe trois manières de faire du load-balancing avec LVS : - En utilisant le NAT - En utilisant l IP tuneling - En utilisant le routage direct B) LE NAT On dit qu'un routeur fait du Network Address Translation (NAT) (ce qu'on peut traduire de l'anglais en «traduction d'adresse réseau») lorsqu'il fait correspondre les adresses IP internes non-uniques et souvent non routables d'un intranet à un ensemble d'adresses externes uniques et routables. Ce mécanisme permet notamment de faire correspondre une seule adresse externe publique visible sur Internet à toutes les adresses d'un réseau privé, et pallie ainsi la carence d'adresses IPv4 d'internet. Pour le cache ARP la solution la plus simple est en LVS- NAT. Ainsi pas besoin de gérer le cache ARP. Mais elle est limité car le serveur de répartition est durement mis à l épreuve étant donné qu il traite les paquets entrants, les réécrit et les transmet aux serveurs réels, puis reçoit leur réponse, la réécrit à nouveau avant de la renvoyer au client. C) L IP TUNELING ITP (Internet Tunneling Protocol) est un protocole (couche 3 du modèle OSI) permettant le transport de données sécurisées sur un réseau IP. CSII1 Année 2008 Projet Load-Balancing page 7

ITP prend en charge la notion de NAT, il a été réalisé dans le but de fonctionner avec le protocole IPv6 tout en étant adapté pour l'actuel protocole IP : IPv4. Son but est d'assurer l'intégrité et la confidentialité des données : le flux ne pourra être compréhensible que par le destinataire final (chiffrement) et la modification des données par des intermédiaires ne pourra être possible (intégrité). ITP peut être un composant de VPN pour sa sécurité ou peut-être utilisé pour la répartition des charges. L intérêt est que l IP Tuneling évite le point de congestion, c'est-à-dire que toutes les requêtes n ont pas besoin de passer par le serveur de répartition aussi souvent qu en mode LVS-NAT. D) LE ROUTAGE DIRECT Cette technique est la même que l IP tuneling sauf que les serveurs réels se trouvent dans un même réseau local. L intérêt est le même que l IP tuneling (évite le point de congestion) et l encapsulation IP avec adressage IP virtuelle. La solution LVS-DR (Direct Routing) est plus compliqué car il faut gérer le cache ARP, mais est beaucoup plus performante car elle ne monopolise pas le serveur de répartition dans les deux sens. Les requêtes ne sont pas retraduites lors des réponses des serveurs réels vers le client. 3 LE CLUSTERING A) LES AVANTAGES Les clusters serveur garantissent une haute disponibilité des applications grâce au basculement des ressources situées sur les serveurs. Le service de cluster permet le fonctionnement des clusters serveur. Un autre avantage est que lorsqu une machine tombe en panne, toutes les applications du cluster restent fonctionnelles. Les autres machines prennent en charge ce que la machine en panne ne peut plus faire. CSII1 Année 2008 Projet Load-Balancing page 8

Enfin ceci permet aussi de retirer une machine du cluster afin de pouvoir l administrer en y ajoutant des applications, des mises à jour etc. B) UTILISATION Le clustering est principalement utilisé sur des applications critiques comme les bases de données, les systèmes de gestion de la connaissance, les progiciels de gestion intégrés et les services de fichiers et d'impression. C) HEARTBEART ET LDIRECTOR Il y a d'autres outils comme Heartbeat et Ldirector qui peuvent renforcer le LVS : - Heartbeat permet d'avoir plus de deux load-balancers; si le load-balancer primaire tombe en panne, le secondaire prend le relais automatiquement sans interruption de service - Ldirector permet de vérifier si les serveurs réels sont disponibles; si un des serveurs réels tombe en panne, il est automatiquement retiré du LVS. D) COMMENT METTRE EN PLACE CES PAQUETS Dans le fichier /etc/ha.d/ha.cf sur tous les load-balancer. (Ici je n en ai que deux : On le voit avec les node qui sont le nombre de serveurs contenus dans le cluster) Eth0 est l interface c'est-à-dire la carte réseau. Le port utilisé pour heartbeat est le port 694 en UDP. L auto_failback est à off ce qui signifie que lorsqu un serveur est coupé, pour le remettre dans le cluster, il faut redémarrer le service heartbeat avec cette commande : /etc/init.d/heartbeat restart bcast eth0 debugfile /var/log/ha-debug logfile /var/log/ha-log logfacility local0 keepalive 2 deadtime 10 CSII1 Année 2008 Projet Load-Balancing page 9

warntime 6 initdead 60 udpport 694 node loadb1 node loadb2 auto_failback off Dans le fichier /etc/ha.d/haresources sur tous les load-balancer écrire cette ligne pour considérer loadb1 comme étant le load-balancer maître : loadb1 IPaddr::192.168.5.1 Dans le fichier /etc/ha.d/authkeys sur tous les load-balancer : auth 2 1 md5 "cluster test" 2 crc La phrase de cryptage doit évidemment être changée. Ici «cluster test» n est qu un exemple. Nous pouvons augmenter la sécurité en y ajoutant davantage de caractères alphanumériques et de caractères spéciaux. Ne pas oublier de faire un chmod 600 /etc/ha.d/authkeys pour protéger le fichier. Note : Les fichiers haresources et authkeys doivent être strictement identique sur tous les load-balancer. E) TESTS SUR HEARTBEAT Vérifiez si les connexions SSH à chacun des nodes via leur adresse IP (192.168.5.1 et 192.168.5.2 dans notre exemple) fonctionnent. Si tel est le cas, nous pouvons faire un test. Sinon il faut installer ssh sur les serveurs réels: apt-get install openssh-server Pour se connecter, suffit de prendre un client ssh (Putty sous Windows, ou la console sous Linux) et de marquer ssh root@192.168.5.1 (faire entrée) puis rentrer le mot de passe. Vous verrez ainsi root@loadb1# ou alors root@loadb2# en fonction du serveur sur lequel vous êtes. CSII1 Année 2008 Projet Load-Balancing page 10

Lancez le service HeartBeat sur le node maître; à savoir loadb1 via la commande suivante : /etc/init.d/heartbeat start (ou restart) Puis faire de même sur loadb2. Si ca fonctionne vous pouvez maintenant tenter une connexion SSH sur l'adresse du cluster ; à savoir : 192.168.4.100 dans notre exemple. Une fois identifié, vous vous rendez compte que l'invite de ligne de commande vous dit que vous êtes sur loadb1 (root@loadb1#). Maintenant, éteignez loadb1. Votre console SSH va vous signaler une erreur (normal loadb1 n est plus allumé). Relancez une connexion SSH sur l'adresse du cluster. Le service répond! Or, loadb1 est arrêté. Une fois identifié, vous vous rendez compte que l'invite de ligne de commande indique qu on se trouve sur loadb2 (root@loadb2#). En rallumant loadb1 ssh reste sur load2, même si ce premier est maitre. Pour qu il reprenne la main, il faut relancer le service sur loadb2 de cette manière /etc/init.d/heartbeat restart CSII1 Année 2008 Projet Load-Balancing page 11

II) COMMENT METTRE EN PLACE UN REPARTITEUR DE CHARGE 1 METTRE EN IP FIXE LES SERVEURS Modifications sur fichier /etc/network/interfaces pour mettre en IP statique (mieux pour un serveur) Taper /etc/init.d/networking restart pour relancer le service réseau avec les nouvelles configurations. Eth0 est la carte externe (pour internet) et eth1 est la carte LAN (qui reste dans le cluster). Prenez note que tout ce qui se trouve à l intérieur du cluster appartient au sous réseau 192.168.5.0 et donc les seules adresses IP en 192.168.4.x sont sur le load-balancer. Celui-ci possède deux cartes Ethernet pour faire la liaison entre le WAN, et le LAN. Et enfin les passerelles de serveurs réels sont l adresse IP du coté LAN du load-balancer, c'est-à-dire 192.168.5.1 root@loadb1:~#cat /etc/network/interfaces auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 192.168.4.100 netmask 255.255.255.0 gateway 192.168.4.254 auto eth1 iface eth1 inet static address 192.168.5.1 netmask 255.255.255.0 root@real1:~#cat /etc/network/interfaces auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 192.168.5.10 netmask 255.255.255.0 CSII1 Année 2008 Projet Load-Balancing page 12

gateway 192.168.5.1 root@real2:~#cat /etc/network/interfaces auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 192.168.5.11 netmask 255.255.255.0 gateway 192.168.5.1 Avec un ifconfig, on constate bien que l'on a désormais 3 interfaces réseaux : lo qui est la boucle locale, eth0 qui est la carte externe pour Internet et enfin eth1 qui est la carte interne pour le LAN. CSII1 Année 2008 Projet Load-Balancing page 13

2 INSTALLER LES PAQUETS NECESSAIRES Sur le load-balancer, les paquets nécessaires sont ipvsadm, heartbeat, ldirectord que l on installe facilement grâce à apt-get install ipvsadm heartbeat ldirectord Sur les serveurs réels, nous aurons besoin d apache2 : apt-get install apache2 Le système de paquets apt gère toutes les dépendances. Il se peut donc qu il vous propose d installer des paquets supplémentaires. Acceptez alors en faisant «o» ou «y» selon que vous soyez en Français ou en Anglais. 3 AUTORISER LE ROUTAGE Ensuite, il faut éditer le fichier /etc/sysctl.conf et décommenter la ligne "net/ipv4/ip_forward=1" pour autoriser le routage. Ou alors taper echo "1" > /proc/sys/net/ipv4/conf/all/forwarding Ou enfin allez dans cd /proc/sys/net/ipv4/conf/all/ puis faite un vi forwarding puis modifier la valeur et enregistrer. Sur le load-balancer tapez les commandes suivantes pour activer la translation d adresses IP sur votre serveur. Dans notre exemple la carte externe (c est à dire Internet) du répartiteur de charge correspond à eth0 et donc la carte interne (c est à dire LAN) correspond à eth1 : Iptables t nat P POSTROUTING DROP Iptables t nat -A POSTROUTING o eth0 j MASQUERADE Modifier les paramètres ARP pour que l IP LAN renvoie toujours l'adresse MAC du Load-Balancer afin que les paquets provenant du serveur LVS vers les serveurs réels soient renvoyés vers le load-balancer. Cela impose une propriété aux serveurs réels : l'interface possédant l'adresse l IP LAN ne doit pas résoudre au niveau ARP. Il faut donc modifier ces fichiers sur le load-balancer grâce à ces commandes : CSII1 Année 2008 Projet Load-Balancing page 14

echo "0" > /proc/sys/net/ipv4/conf/all/send_redirects echo "0" > /proc/sys/net/ipv4/conf/default/send_redirects echo "0" > /proc/sys/net/ipv4/conf/eth0/send_redirects Et on ajoute aussi celles-ci : echo "1" > /proc/sys/net/ipv4/conf/all/arp_ignore echo "2" > /proc/sys/net/ipv4/conf/all/arp_announce echo "1" > /proc/sys/net/ipv4/conf/lo/arp_ignore echo "2" > /proc/sys/net/ipv4/conf/lo/arp_announce Taper la commande sysctl -p /etc/sysctl.conf pour activer les modifications. 4 AJOUTER DES MACHINES DANS LE CLUSTER Puis ajoutez ces lignes aussi sur le load-balancer : Ipvsadm A t 192.168.4.100 :80 s wlc Ipvsadm a t 192.168.4.100 :80 r 192.168.5.10:80 -m Ipvsadm a t 192.168.4.100 :80 r 192.168.5.11:80 m w 2 192.168.4.100 : IP internet du Load-Balancer. 192.168.5.10 : IP du serveur réel1 avec apache 192.168.5.11 : IP du serveur réel2 avec apache La première commande sert à définir le service. Il s agit d un service TCP (-t) sur le port 80 (http) avec l adresse 192.168.4.100. L option "-s wls" sert à choisir l algorithme de répartition de charge, c'est-à-dire ici le Le Weighted Least Connexion (WLC) qui pour rappel gère bien la répartition entre serveurs de puissances différentes. Les serveurs du cluster sont classés par rapport à leur poids, et un pourcentage leur est attribué. Les 2 lignes suivantes servent à rajouter nos deux serveurs réels dans la liste des machines qui font partie du cluster afin de répondre aux requêtes clientes. -r pour dire que c est un serveur réel -m pour dire qu il s agit d une machine -w pour donner un poids. Plus celui-ci est important, et plus le serveur recevra de demandes. (Par défaut c est w 1) CSII1 Année 2008 Projet Load-Balancing page 15

III) LES TESTS A EFFECTUER Lorsque toutes les machines sont lancées, un test simple et de prendre un client d ouvrir dans un navigateur, et de rentrer dans cet explorer l adresse IP du load-balancing. (Dans notre exemple écrire http://192.168.4.100 ) Normalement vous devriez voir des fichiers qui se trouvent dans /var/www/ En fait nous sommes dans le /var/www d un des serveurs réels. En actualisant la page il se peut que vous voyez d autres fichiers ou encore les mêmes. Ca dépend si on reste sur le même serveur réel ou non, et ceci dépend du choix de l algorithme. Comme premier test je vous conseille l algorithme round robin, ainsi une fois vous serrez sur le serveur 1 et la seconde fois, sur le second serveur. Créez des fichiers différents dans les /var/www/ vous verrez qu avec la même IP dans le navigateur, vous aurez accès à tous les serveurs réels. CSII1 Année 2008 Projet Load-Balancing page 16

CONCLUSION Le load-balancing accroit donc considérablement la vitesse de réponse lorsque la montée en charge devient importante. C est une solution plus économique que l achat d un nouveau serveur plus puissant, et plus sécurisante, car si l un des serveurs tombe, les autres sont toujours là pour assurer le service. Cependant la répartition de charge pose un autre problème. En effet les serveurs réels travaillent l un à la suite de l autre, et l utilisateur ne sait pas qu il travaille sur plusieurs serveurs, et il sait encore moins sur quel serveur il se trouve. Le problème se trouve ici : Lorsqu il enregistre des données sur le serveur numéro 1, les autres serveurs n ont pas ces informations, il n y a pas de réplication. Donc une fois que le load-balancing est installé, il faut ensuite mettre en place une solution de réplication, afin d avoir instantanément une même base de données, et une même arborescence sur tous les serveurs. On peut utiliser le module de noyau DRBD "Distributed Replicated Block Device" qui permet d'écrire des informations sur un disque physique et de les transmettre sur un homologue miroir qui se trouve sur une machine secondaire via le réseau Ethernet (et ceci de manière totalement fiable et automatisée). CSII1 Année 2008 Projet Load-Balancing page 17