Load Balancing. Table des matières. Gatien, Julien, Rémi, Vincent. 2 mars Le projet 2. 2 L'équilibrage de charge 2.

Transcription

1 Load Balancing Gatien, Julien, Rémi, Vincent 2 mars 2009 Table des matières 1 Le projet 2 2 L'équilibrage de charge 2 3 Algorithmes 2 4 État de l'art LVS Apache - mod_proxy_balancer Pen HaProxy UltraMonkey Balance Nginx Autres solutions logicielles Récapitulatif des fonctionnalités Conclusion 8 1

2 1 Le projet Notre projet porte sur la mise en place de solutions assurant la haute disponibilité et la répartition de charge sur un service web. Les serveurs oriront un service Web basé sur Ruby on Rails couplé à un Système de Gestion de Base de Données. C'est pourquoi le projet va se dérouler en deux grandes parties. La première consistant à se documenter sur les solutions existantes et à choisir celles qui conviendront le mieux. La seconde sera plus pratique avec la mise en place de la solution choisie suivie d'une période de tests et benchmarking. 2 L'équilibrage de charge L'équilibrage de charge est un élément important lors de le mise en place de services amenés à croître. Il faut s'assurer que la capacité à monter en charge soit la plus optimum possible an d'éviter toute dégradation que ce soit en terme de performances ou de abilité lors d'auences importantes. Le principe de base de l'équilibrage de charge (ou load balancing) consiste à eectuer une distribution des tâches à des machines de façon intelligente. Pour cela il faut intégrer un dispositif entre les serveurs et les utilisateurs de la ressource. Ce dispositif aura pour tâche de rediriger les consommateurs de services en fonction de l'état d'occupation des serveurs. Il faut aussi prendre en compte le service distribué et adapter la méthode de redirection en fonction de celui-ci au travers de diérents algorithmes (Round Robin, Random, Least Resources...). Les gains sont non négligeables : augmentation de la qualité des services, amélioration des temps de réponse des services, capacité à pallier la défaillance d'une ou de plusieurs machines, ajout de nouveaux serveurs sans interruption de service. L'équilibrage de charge utilise essentiellement 2 techniques, le DNS et le reverse-proxy. 3 Algorithmes Les applications Web modernes utilisent le plus souvent un mécanisme de persistence (les fameuses sessions en PHP par exemple). HTTP étant un protocole non connecté, un répartiteur de charge doit pouvoir assurer qu'au cours d'une session limitée dans le temps, un utilisateur donné devra être reconnecté au serveur ayant eectué la transaction initiale. Plusieurs solutions possibles ont été mise en oeuvre. Algorithmes déterministes : Tables de hash : On construit une table de hash à partir de l'adresse IP du client. Cet algorithme suppose que le client ne passe pas au travers de diérents proxies (adresse IP variable), sinon il n'est valable qu'au cours d'une session limitée dans le temps. N'assure pas forcément une répartition homogène Redirection : Les clients sont envoyés vers un serveur de redirection, celui-ci les redirigeant vers un serveur selon un algorithme qui lui peut ne pas être déterministe. Le problème peut alors survenir si le serveur vers lequel le client a été redirigé est indisponnible. Peu able donc. Algorithmes non-déterministes Round Robin : ou 'tourniquet' est comme son nom l'indique un algorithme de le tournante : l'équilibrage choisit à chaque instant un serveur dans la le et boucle sur celle-ci. Certainement le plus performant. 2

3 Least Connection : Le serveur renvoie vers le serveur le moins chargé. Si en théorie il semble le plus adapté, en réalité dans le cadre du Web dynamique, un serveur peut ètre considéré comme chargé alors que les processus sont en attente d'une requête vers une base de données... First Response : Les requêtes clients sont envoyés simultanément à tous les serveurs et le premier qui répond sera chargé de la connexion. Dicile à mettre en oeuvre et rarement employé. 4 État de l'art 4.1 LVS Linux Virtual Server (LVS) est une solution de répartition de charge pour GNU/Linux. L'objectif principal est de construire un serveur de haute performance pour Linux utilisant la technologie du clustering. LVS est un logiciel basé sur les couches 3 et 4.Il fait des redirections sur les adresses IP ainsi que diérents ports TCP. L'algorithme se rapprochant le plus de celui utilisé par cette solution est Round Robin. 4.2 Apache - mod_proxy_balancer A partir de apache 2.1, en utilisant le module mod_proxy_balancer, il est possible de faire de l'équilibrage de charge pour les protocoles HTTP, FTP et AJP13 (Apache JServ Protocol - utilisé principalement avec Tomcat pour rediriger les sessions vers le bon serveur et pour faire du monitoring simple). Il intègre trois algorithmes d'"ordonnancement" : Request Counting, Weighted Trac Counting et Pending Request Counting. Request Counting : répartit les requètes de façon pondérée sur leur nombre vers les serveurs. Weighted Trac Counting : répartit les requètes de façon pondérée sur la taille (en octets) des réponses. Pending Request Counting : répartit les requètes de façon pondérée sur la taille de la liste d'attente des requètes sur chaque serveur. Le module mod_status permet de rajouter des possibilités management dynamique des pondérations de chaque serveur. facilité de mise en oeuvre, bien maintenu (apache), portabilité (toute architecture supportant apache). protocoles HTTP et FTP uniquement. 4.3 Pen Pen est un load balancer pour les protocoles basés sur tcp. Il permet de distribuer les requètes de clients sur diérents serveurs en essayant de garder une trace de ceux-ci pour renvoyer chaque client vers le serveur qui lui avait été aecté précédemment. Il intègre également un dispositif simple de haute disponibilité qui, si un serveur est hors service, envoie la requète vers un autre. Il est possible de faire de la redondance sur pen lui-même en le déployant sur plusieurs serveurs et en utilisant le protocole vrrp pour décider lequel est actif. Alors que le monitorage de pen se limite à la couche transport, il est possible de faire du monitorage au niveau applicatif en utilisant penbw. 3

4 tous les protocoles basés sur tcp (y-compris https), possibilité d'utiliser vrrp, bien maintenu (dernière version mai 2008), bonne portabilité (FreeBSD, Linux, HP-UX, Solaris et Windows), détection automatique des serveurs hors-service, garde en mémoire les traces des clients. un seul algorithme (round-robin + trace des connexions). 4.4 HaProxy HAProxy permet de répartir les connexions sur un port sur plusieurs serveurs. Il permet aussi de détecter l'indisponibilité d'un des serveurs. Il peut être utilisé pour les applications utilisant TCP ou HTTP. HAProxy sait gérer plusieurs "proxy" à la fois. Il est possible de faire du load balancing sur le port http et le port smtp en même temps. Il est aussi possible de faire du load balancing sur le port 80 pour plusieurs IP. Surtout utilisé pour les sites Web. très performant, peut tenir des charges très importantes comme plusieurs milliers de connexions par seconde, ressources matérielles nécessaires très faible, aucune vulnérabilité depuis plus de 6 ans. reconguration à chaud impossible, pas d'interface Web de conguration, pas de centralisation des congurations. 4.5 UltraMonkey Ultramonkey regroupe plusieurs solutions logicielles permettant de mettre en place un système assurant l'équilibrage de charge mais aussi la haute disponibilitée des services/données. Celui-ci est basé sur LVS pour l'équilibrage, heartbeat pour la disponibilité et ldirectord pour la supervision des diérentes machines. Ces logiciels sont réputés pour leur bon fonctionnement ainsi que leur ecacité. UltraMonkey convient aussi bien pour la mise en place sur de petits clusters que sur de grands systèmes. Ultramonkey ore des fonctionnalités non négligeables : switch sur la couche transport du modèle OSI avec LVS, facilement expensible pour un grand nombre d'ip basé sur des services virtuels, haut disponibilité oerte par le protocole Heartbeat, monitoring des services via ldirectord, ore une documentation assez complète sur le déploiement de solutions de haute disponibilité et/ou d'équilibrage de charge, open source, package Debian disponible. assez complexe. 4

5 4.6 Balance Solution simple basée sur le niveau utilisateur de la couche OSI, il ne touche pas au kernel. Ore une solution d'équilibrage de charge mais aussi de proxy tcp. Load Balancing basé sur plusieurs algorithmes (RoundRobin, random, hash, least resources). Ore une gestion totale via la ligne de commande en plus d'être très léger. Deux versions, une gratuite (balance) et une commerciale (balanceng). gestion totale via ligne de commande possible, diérents algorithmes de Load Balancing, mise en place rapide. basé sur niveau utilisateur, pas OpenSource, limitations sur la version gratuite, BalanceNG pour version commerciale et plus poussée. 4.7 Nginx Nginx est un serveur et proxy web haute performance, il peut également servir de proxy mail et surtout en mode reverse proxy avec load balancer. Il a été programmé an d'obtenir les meilleurs performances possibles. Ainsi, il ne nécessite pas d'avoir autant de processus que de connexions, un par processeur sut. Les requètes sont découpées en mini-tâches, ordonnancées par chacun des processus. Ceci et le fait qu'il soit développé en C lui confèrent une empreinte mémoire vraiment faible et une excellente rapidité d'exécution. Nginx est un front-end populaire pour les applications Rails et PHP, soit via FastCGI soit via HTTP. Aussi, l'équilibrage de charge mis en place est de type Round-Robin pondéré. très facile à mettre en oeuvre, bien maintenu (01/2009), bonne portabilité GNU/Linux, BSD, Mac OS X, Solaris, Windows (non maintenue ociellement), protocoles HTTP et HTTPS. pas de monitoring intégré. 4.8 Autres solutions logicielles Voici une liste non exhaustive d'autres solutions disponibles : 1. KIMBERLITE C'est un projet développé par Mission Critical Linux ayant pour but de fournir une solution simple d'équilibrage de charge pour les entreprises. projet opensource projet abandonné en 2001 limitée à 2 noeuds et nécessite un matériel adéquat, à savoir une baie de disques partagée, soit SCSI ou FC. 2. OSCAR (Open Source Cluster Application Ressources) Cette solution contient un ensemble d'applications pour l'installation, l'administration 5

6 et l'utilisation de clusters. http ://svn.oscar.openclustergroup.org/trac/oscar projet open source apres la version 5.0 en 2006, reprise de l'activite en 2009 avec la version 6.0 packagé pour de nombreuses distributions multi-architecture peu de documentation 3. CLIC C'est une application permettant la gestion de cluster développée par Mandrake Soft. Cette solution est orientée vers le calcul distribué. projet open-source peu de documentation ne semble plus maintenu, n'a pas évolué depuis POUND POUND est un reverse-proxy projet open-source sous licence GPL pas d'acces direct au disque dur wrapper ssl utilisable uniquement pour la repartition de charge sur serveurs web 6

7 4.9 Récapitulatif des fonctionnalités Type Licence Protocoles Couche OSI Mise en uvre Portabilité Maintenu Apache Serveur web, apache HTTP, TCP Application facile idem apache idem apache reverse proxy HAProxy Load Balancer GPL HTTP, TCP Application facile Linux, Solaris Novembre 08 Pen Load Balancer GPL HTTP, TCP? Application FreeBSD, Linux, Solaris, Mai 2008 MacOS X, Windows Balance GPL HTTP, TCP Application rapide Linux,FreeBSD,Solaris,MacOS X Avril 08 BalanceNG shareware HTTP, TCP Application rapide Linux,FreeBSD,Solaris,MacOS X Février 09 UltraMonkey? GPL HTTP, TCP Réseau/Transport +/- complexe RedHat, Debian 2005 Nginx Serveur Web type BSD HTTP, HTTPS Application 1 facile Linux, BSD, Mac OS X, janv-2009 reverse proxy Kimberlite GPL HTTP, TCP?? +/- complexe 2001 Oscar GPL HTTP, TCP Réseau/Transport +/- complexe unix 2009 Clic GPL HTTP, TCP Réseau/Transport +/- complexe unix 2003 Pound Reverse Proxy GPL HTTP, HTTPS, TCP Application rapide unix 2009 LVS(IPVS) Load Balancer GPL Multiprotocole reseau Réseau/Transport +/- complexe unix 2004 KeepAlived HealthCheck and Failover GPL? Application rapide unix

8 5 Conclusion Au vu des divers éléments présentés précedemment, nous avons choisi d'utiliser UltraMonkey puisqu'il s'agit de la solution disposant de la meilleure documentation et reposant sur des technologies éprouvées telles que LVS, ldirectord et Hearthbeat. Nginx nous semble aussi tout indiqué comme "remplaçant" d'apache de part sa légereté mais aussi de son support des applications Ruby. Il est de plus complétement compatible avec la structure que nous souhaitons mettre en place. Nous allons donc pour la suite du projet mettre en place l'architecture suivante : 8