SECURINETS CLUB DE LA SECURITE INFORMATIQUE INSAT SECURIDAY 2012 Pro Edition [LOAD BALANCING] Chef Atelier : Asma JERBI (rt5) Hajer MEHRZI(rt3) Rania FLISS (rt3) Ibtissem OMAR (rt3) Asma Tounsi (rt3la) 30/04/2011
1. Présentation de l atelier : 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 afin d obtenir un gain de performances. La répartition de charge consiste à mettre un système entre les clients (demandeurs de ressources) et les ressources. Ce système se chargera de désigner le fournisseur le moins occupé au moment de la demande pour servir le client. Les demandes seront alors réparties sur plusieurs fournisseurs de ressources au lieu d un seul. Dans une architecture classique, c'est-à-dire une connexion direct entres les clients et le serveur, lors de fortes activités, ce serveur ne pourra pas servir tout le monde et l accès aux ressources sera bloqué. C est ce qu on appel le déni de service (DOS : Deny of service). La répartition de charge permet d optimiser le trafic et de répartir les charges sur un ensemble de serveurs. La capacité totale de traitement est alors plus importante. Différents algorithmes de répartition de la charge sont implémentés dans LVS(linux virtual server). 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 1er 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. 2
3
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. La méthode qu on a choisi d utilisé dans notre atelier est round robin. Avantages et inconvénients : Comme on l a vu, la répartition de niveau DNS, quel qu en soit l outil, est pratiquement la seule qui permette de répartir sur différents datacenters, ce qui permet à la fois une meilleure tolérance aux pannes, et dans certains cas une moindre latence donc une meilleure qualité de service. Dans le mode Round-Robin, elle est très facile à mettre en place, et peu coûteuse, pour autant que l application soit compatible, c est à dire qu elle ne suppose aucune ressource partagée, un «share nothing» de niveau datacenter. Elle présente toutefois les limitations suivantes : La gestion de la détection de panne et du secours est laissée à la charge du navigateur. Si le serveur HTTP répond une erreur 500, par exemple, le navigateur ne passe pas sur la seconde adresse. L équilibrage de la charge n est pas géré de manière fine, typiquement avec des capacités d accueil différentes selon les plateformes, ou bien l affectation au datacenter le moins chargé. Elle ne permet pas de mettre en œuvre l affinité de serveur de manière satisfaisante. A la différence des solutions de répartition de charge réseau, que l on verra plus loin, la répartition de niveau DNS ne met pas en œuvre une surveillance des plateformes, et n adapte pas la répartition à la disponibilité ou à la charge. Notons qu il existe malgré tout quelques solutions gérant la haute-disponibilité au travers d une reconfiguration DNS : on met en œuvre un monitoring des différents serveurs, et si l un d entre eux ne répond pas, on met à jour les DNS pour exclure ce serveur. Tant qu on utilise les DNS de manière standard, c est le cas pour le mode round-robin, la tolérance aux pannes du dispositif de répartition lui-même est excellente. En revanche, pour les deux autres modes, qui demandent un DNS spécifique, c est à vous d assurer son secours et sa disponibilité. 2. Présentation des outils utilisés : On utilisera : 2 machines qui contiennent comme système d exploitation linux de distribution ubuntu 10.10. l une contient un serveur apache configuré dessus et 4
l autre le serveur apache et dns configuré dessus. 3. Topologie du réseau : 4. Configuration des outils : Serveur apache : installation et configuration Installation du paquet apache2 sous Linux : sudo apt-get install apache2 Création d'une page HTML de test Mkdir /ver/www/sdz Cd/var/ww/sdz Vi index.html -Code HTML au niveau de l index.html <html> <head> <title> securinets </title> </head> <body> <p> Voici la page d'accueil de votre serveur Apache! </p> </body> </html> Configuration du serveur Apache Configuration du serveur apache sans restrictions d accès c'est à dire sans mot de passe. Dans ce cas, tout le monde peut accéder à notre serveur. Les commandes : 5
cd /etc/apache2/sites-available vi sdz NameVirtualHost 192.168.21.6:80 <VirtualHost 192.168.21.6 :80> ServerName sdz.truc.tp DocumentRoot /var/www/sdz <Directory /var/www/sdz> Order allow,deny Allow from </Directory> </VirtualHost> sudo ln -s /etc/apache2/sites-available/sdz /etc/apache2/sites-enabled/sdz /etc/init.d/apache2 restart Serveur dns: installation et configuration Sudo apt-get install bind9 Configuration: vi /etc/network/interfaces Auto lo Iface lo inet loopback iface eth0 inet static address 192.168.30.140 netmask 255.255.255.0 broadcast 192.168.30.255 Vi /etc/resolv.conf Search sdz.tp Nameserver 192.168.30.1 cd /etc/bind Vi named.conf.local Zone «sdz.tp» { 6
Type master; File «/etc/bind/db.sdz.tp.hosts» ; }; Zone 30.168.192.in-addr.arpa { Type master; File /etc/bind/db.30.168.192.in-addr.arpa ; }; VI db.sdz.tp BIND data file for local loopback interface ; $TTL 604800 @ IN SOA ubuntu1.sdz.tp. root.sdz.tp. ( 1 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; @ IN NS ns.ubuntu-fr.lan. ns IN A 192.168.30.140 ns1 IN A 192.168.30.141 7
vi db.30.168.192.in-addr.arpa BIND reverse data file for local loopback interface ; $TTL 604800 @ IN SOA ns.sdz.tp. root.sdz.tp.( 2 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; @ IN NS ns. ns IN PTR sdz.tp. Sudo /etc/init.d/bind9 restart 5. Un scénario de test Exemple : site hotmail.com Chaque fois que le site est demandé par le client, la requêtes est dirigé vers un serveur dans l ordre. 6. 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 8
nouveau serveur plus puissant, et plus sécurisante, car si l un des serveurs tombe, les autres sont toujours là pour assurer le service. 9