Rapport de projet. Répartition des charges sur serveurs web virtualisés. 1. Introduction

Transcription

1 Introduction Rapport de projet Répartition des charges sur serveurs web virtualisés La répartition des charges est un procédé extrêmement utilisé dans l infrastructure d Internet. Ce rapport va donc vous présenter les spécifications d un tel système ainsi que les travaux que nous avons effectués sur le sujet. Majid LAYOUNI Raphaël MAZOT Alexandre TRAN Centre d Etude et de Recherche en Informatique Master 2

2 Sommaire Préface... 4 Introduction Présentation Générale La haute disponibilité Principe de redondance : Sécurisation de données : Principe de répartition de charge : La répartition de charge Algorithmes : La persistance Solutions de répartition Le DNS Principe de fonctionnement Le DNS Round Robin GeoDNS Anycast Avantages et limites Redirection applicative Travaux Le Load Balancing Présentation Propriétés et principe de fonctionnement d HAproxy : Configuration Bilan du logiciel Logiciels complémentaires aux équilibreurs de charges Heartbeat : Piranha : DRBD : Architecture Plus complexe Unison Tests de performance Matériel Solutions de test Rapport de projet Répartition des charges sur serveurs web virtualisés 2

3 3.2.1 HTTPERF Siège Autres outils de test Résultats HTML : PHP HTTP lourd : Bilan des tests Utilisations concrètes Dailymotion Wikipedia Bilan des infrastructures Internet Conclusion Bibliographie Livre: Sources Internet: Récapitulatif des logiciels utilisés: Annexes : Annexe 1 : DNS Round Robin Annexe 2: HAProxy Annexe 3 : DRBD Annexe 4 : MySQL Annexe 5 : NFS Annexe 6 : Benchmark Rapport de projet Répartition des charges sur serveurs web virtualisés 3

4 Préface Nous sommes trois étudiants en deuxième année de master au Centre d Etude et de Recherches en informatique. Dans le cadre de notre cursus, nous devons étudier et mettre en place une solution en groupe de deux ou trois individus. Ce projet s inscrit donc dans le cadre scolaire et le sujet que nous avons choisit correspond à notre parcours qui est spécialisé dans les réseaux et télécommunications. Introduction Depuis le lancement d Internet, la demande en contenu web n a cessée d augmenter. Au commencement, les pages web étaient statiques, donc les abonnés consultaient seulement les sites sans interagir avec eux. Puis, le web est devenu dynamique, avec des contenus permettant d ajouter ses idées, ses travaux, de faire des jeux, de regarder des vidéos, Les sites de forum, de jeux en ligne, de streaming vidéo et même de réseaux sociaux ont donc explosé, entrainant avec eux une demande plus forte en termes de bande passante et de ressources physiques. Il était donc obligatoire de réfléchir à un nouveau moyen afin de répartir les charges sur les serveurs web qui devaient sans cesse être plus performants pour pouvoir répondre à la demande. Plusieurs solutions ont donc été étudiées et mises en place dans de nombreuses architectures de sites web au sein de l Internet. Dans ce rapport, nous allons donc présenter les solutions de répartition que nous avons étudiées et celles que nous avons testé. Rapport de projet Répartition des charges sur serveurs web virtualisés 4

5 1. Présentation Générale 1.1 La haute disponibilité La haute disponibilité correspond au fait de maintenir l accessibilité d un service suivant un taux de disponibilité élevé. Pour cela il faut mettre en place une architecture matérielle dédiée et donc de la redondance matériels, la sécurisation des données afin de garantir leurs intégrités (RAID, Sauvegarde ), la répartition de charge pour faire face à des pics d activités Principe de redondance : La redondance a pour but d augmenter les performances et/ou diminuer les risques de pannes. Il faut mettre en place des configurations matérielles et logiciels identiques afin de relayer des serveurs défaillants ou de partager les différentes tâches Sécurisation de données : La possibilité de réimplanter les données rapidement et sans corruption de celles-ci. On peut utiliser les technologies de RAID, le stockage des copies des données sur un NAS ou serveur de sauvegarde Principe de répartition de charge : La répartition de charge est de pouvoir distribuer un travail entre plusieurs ressources afin d obtenir un gain de performances La répartition de charge 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. Il est donc possible d augmenter la capacité de connexion et de traitement en augmentant le nombre de machines du pool (groupe) pour augmenter sa capacité. Dans une architecture classique, l augmentation de la capacité nécessite un changement matériel sur le serveur (RAM, Processeur ) et donc un arrêt temporaire du service et un coût important suivant les caractéristiques des serveurs. Rapport de projet Répartition des charges sur serveurs web virtualisés 5

6 Voici donc un schéma d une infrastructure dédiée à la répartition des charges avec 3 serveurs Web : Schéma simple de load-balancing Algorithmes : Il faut savoir qu il existe différents algorithmes permettant de répartir les charges aux ressources qui sont disponibles. Voici les principaux : Round robin : Le round robin ou tourniquet est un algorithme pour sélectionner tous les éléments d un groupe équitablement en commençant par le premier élément de la liste jusqu à arriver à la fin et recommencer à nouveau depuis le premier élément. 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ées simultanément à tous les serveurs et le premier qui répond sera chargé de la connexion. (Rarement employé) 1.2 La persistance On définit la persistance comme le mécanisme responsable de la sauvegarde et la restauration de données afin qu un programme puisse se terminer sans que ses données ni son état ne soient perdus. Par exemple si un utilisateur démarre une session sur un des serveurs du groupe, il faut que ce serveur soit utilisé pendant toutes la durée de la session, pour ne pas perdre la connexion et les données qui y sont raccrochées. Rapport de projet Répartition des charges sur serveurs web virtualisés 6

7 Voici des méthodes de persistance sur les équilibreurs de charges : Cookies : Le serveur cible émet un «cookie» contenant un identifiant vers le client. L équilibreur de charge pourra ensuite retrouver le serveur initial lorsque le client lui présentera le «cookie». Espace disque commun en réseau : Dans le cas de load-balancing où plusieurs serveurs cohabitent sur le même réseau local, il est avantageux de leur permettre de partager des fichiers. C est ce que permettent les systèmes de fichiers en réseau tel que NFS (Network File System) pour les systèmes Unix. Stockage des sessions en base de données : Cette solution permet de garder les données de session dans une base de données. En général, cela est mauvais pour la performance, car la charge sur la base de données augmente. Pour éviter à une base de données de devenir un point de défaillance, il est possible d utiliser un load-balancer pour la base de donné. Equilibrage de charge sur les serveurs de bases de données. Rapport de projet Répartition des charges sur serveurs web virtualisés 7

8 2. Solutions de répartition Avant toute chose, il faut savoir que nos travaux ont été réalisés sur machines virtuelles Vmware Workstation afin de faciliter notre travail. En effet, l avantage de travailler en machines virtuelles réside dans le fait de pouvoir sauvegarder l état des machines à des instants donnés. Cela permet ainsi de pouvoir revenir à une configuration stable en toute circonstance. L équilibrage de charge utilise essentiellement deux techniques qui sont le DNS et le load-balancing. Pour réaliser de l équilibrage de charge plusieurs solutions sont possibles, le plus simple est l utilisation d un DNS. Dans le cas du DNS, c est ce serveur qui va rediriger le client vers une adresse différente appartenant au même nom de domaine du site désiré. L utilisation de DNS ne permet pas de prendre en compte les capacités ou disponibilités des machines, ainsi une autre solution utilisée est celle du loadbalancing. Voici donc un descriptif des 2 méthodes. 2.1 Le DNS Principe de fonctionnement La répartition de charge de niveau DNS intervient dans l association d une adresse IP à un nom de serveur. Lorsque le navigateur doit accéder à un serveur dont il connaît le nom, par exemple il commence par rechercher l adresse IP correspondant à ce serveur www sur le domaine google.fr. Il adresse une requête à son serveur DNS, qui lui-même, s il ne dispose pas de l information, interrogera d autres serveurs DNS, de manière récursive. Une fois que le poste client a obtenu l adresse IP, il la conserve en cache selon différentes règles, généralement de l ordre d une demi-heure. C est dans cette phase d association entre un nom de serveur et une adresse IP, c est à dire un serveur Web, qu intervient la répartition de charge de niveau DNS, simplement en fournissant différentes adresses IP pour un même nom de serveur. On utilise assez peu cette technique pour répartir la charge entre serveurs d un même datacenter, simplement parce que les répartitions réseaux, que nous verrons plus loin, sont plus flexibles et plus réactives. La répartition de niveau DNS est donc plutôt utilisée pour répartir la charge entre plusieurs datacenters (centres de données). Quelle en est la finalité? La tolérance aux pannes : un datacenter peut se trouver globalement indisponible, pour différentes raisons, et toutes les mesures internes à la plateforme seront alors inopérantes. La proximité physique des internautes, dans une approche de type «Content Delivery Network» qui va délivrer le contenu depuis le serveur le plus proche de l utilisateur (inutile d envoyer une requête sur un serveur web à New York pour un utilisateur à Lyon si il y a un Rapport de projet Répartition des charges sur serveurs web virtualisés 8

9 serveur à Paris par exemple, les temps de réponse seront meilleurs et les coûts en terme d utilisation du réseau moindres). La recherche d un point d équilibre entre mesures de haute-disponibilité internes à une plateforme, et haute-disponibilité globale multi-plateformes, pour viser une hautedisponibilité globale au moindre coût. Nous passerons en revue trois types de solutions de répartition de niveau DNS : DNS Round-Robin, GeoDNS et Anycast. La première est la seule qui soit totalement standard, compatible avec n importe quel DNS ; les deux suivantes requièrent un serveur DNS spécifique et sont donc sensiblement plus complexes à mettre en œuvre. Durant notre projet, nous avons mis en place seulement la première solution. Mais pour montrer l étendue des possibilités, nous allons présenter également les deux autres solutions Le DNS Round Robin La technique de répartition DNS la plus simple et la plus couramment utilisée est celle du DNS Round-Robin, ou DNS-RR. Lorsqu un serveur DNS répond à un client, il peut fournir non pas une adresse IP, mais une liste d adresses IP, dans un certain ordre. La première adresse est celle qu il faut utiliser en premier lieu, les autres sont des adresses de secours. Si l on dispose de trois serveurs S1, S2, S3 capables de traiter les requêtes, alors le serveur DNS pourra répondre {S1, S2, S3}, dans cet ordre. Rappelons qu ici Si désigne l adresse IP d un serveur. Le principe du DNS-RR consiste à répondre en indiquant les serveurs en permutation circulaire : {S1, S2, S3}, puis {S2, S3, S1}, puis {S3, S1, S2} et ainsi de suite. Le premier client, s adressera donc à S1, le second à S2, le troisième à S3. Et si S1 ne répond pas, alors le premier s adressera à S2 en secours. Voici un schéma pour chacune des 3 phases qui constituent le processus de répartition dans le cas d un cluster de 3 serveurs Web. Quand la phase 3 est atteinte, on reprend à la phase 1. Rapport de projet Répartition des charges sur serveurs web virtualisés 9

10 Figure : Phase 1 Figure : Phase 2 Figure : Phase 3. Rapport de projet Répartition des charges sur serveurs web virtualisés 10

11 Cette technique a le mérite d être très simple à mettre en œuvre, et ne requiert pas un DNS spécifique, le Round-Robin est supporté par tous les serveurs DNS de l Internet. La solution peut convenir lorsqu on dispose de 2 ou 3 datacenters d une même région géographique, d un même continent. Elle convient beaucoup moins bien au niveau global, avec des datacenters sur différents continents, car elle peut amener l internaute européen sur un datacenter asiatique, l internaute américain sur un datacenter européen, et ainsi dégrader la qualité de service de tout le monde. Hors, à l échelle de la planète la proximité géographique a un impact important sur la qualité de service. La répartition par DNS-RR est assimilable au global à une répartition aléatoire. En particulier, elle ne s appuie sur aucune connaissance de la charge respective des serveurs. Néanmoins, avec un trafic important, l aléatoire procure une répartition tout à fait satisfaisante, avec des écarts en général de moins de 5% entre les serveurs. On met en œuvre également le DNS-RR lorsqu on vise un hébergement low-cost, qui ne permet pas d insérer de load-balancer GeoDNS Au lieu de répondre en permutation circulaire, le serveur DNS peut essayer de répondre intelligemment, en fournissant en premier le serveur le plus proche de l internaute, après avoir localisé l internaute, au moyen de son adresse IP. C est l objet de l extension GeoDNS, qui ajoute cette fonctionnalité au serveur BIND, le DNS plus utilisé sur l Internet. Bien entendu, cela suppose de gérer son propre DNS sur son domaine. L extension GeoDNS permet de définir, pays par pays, la réponse spécifique du DNS à une demande de l internaute, et donc de répondre { SFR, SUS, SKR } a un internaute européen, et { SKR, SUS, SEU } à un internaute chinois, où SFR, SUS, SKR sont les adresses des serveurs hébergés respectivement en France, Etats-Unis et Corée du Sud. C est donc une solution qui convient bien au niveau global. Rapport de projet Répartition des charges sur serveurs web virtualisés 11

12 2.1.4 Anycast La dernière solution, utilisée par les plus grands sites globaux, s appelle «Anycast». Elle consiste à utiliser la même adresse IP pour différents serveurs DNS en charge du domaine, chaque serveur étant hébergé sur le même datacenter que l une des plateformes web. Ainsi si l on dispose de trois plateformes dans trois datacenters, en Europe, Asie et Amérique, on mettra en place trois DNS pour mondomaine.com, sur ces mêmes plateformes. Comme ces trois serveurs DNS partagent la même adresse IP, on compte sur les algorithmes de routage IP pour trouver automatiquement le serveur DNS le plus proche de l internaute. Chaque DNS répond à la requête de nom de domaine de manière légèrement différente, en plaçant l IP de son propre datacenter en tête de liste. Le génie de cette solution, c est de trouver de manière naturelle le serveur le plus proche, au sens de la topologie de l Internet, et non au sens géographique, en utilisant les mécanismes standards du réseau. Partager une adresse IP est en général hasardeux, et effectivement, dans une connexion TCP/IP, il se pourrait que certains paquets arrivent à un serveur et d autres à un autre serveur, ce qui rendrait la communication impossible. Mais l interrogation DNS n utilise que le protocole UDP, qui est sans session, de sorte qu il est compatible avec le mode Anycast Avantages et limites 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. Rapport de projet Répartition des charges sur serveurs web virtualisés 12

13 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é Redirection applicative Il faut évoquer aussi la possibilité de redirection applicative, vers un serveur ou un datacenter proche de l internaute. C est une version très rustique du GeoDNS : l internaute se connecte à un premier serveur l application localise l internaute, en déduit le serveur le plus approprié, et adresse un redirect HTTP vers ce serveur, par exemple qui assurera la suite de la session Travaux De notre côté, nous avons mis en place un système de DNS round robin. Cependant, après quelques tests sur cette infrastructure, nous nous sommes rendu compte que le serveur DNS renvoyait toujours le même serveur Web à son client (nous avions personnalisé chaque page index.html sur les différents serveurs de notre cluster). Figure : Requêtes dirigées vers le serveur 1 Le ping quant à lui été bien redirigé vers chaque serveur Web chacun à la suite de l autre, mais ce n est pas le cas des requêtes HTTP. Cependant, si nous déconnectons le premier serveur Web, nous avons bien pu constater que les requêtes étaient ensuite redirigées vers le second serveur Web. Rapport de projet Répartition des charges sur serveurs web virtualisés 13

14 Figure : Requêtes dirigées vers le serveur 2 quand Serveur 1 HS Il est donc préférable d utiliser la technique du DNS round robin pour prévenir d une panne, et rediriger immédiatement les requêtes sur un autre serveur (ou autre datacenter) plutôt que d effectuer de la répartition des charges. Vous trouverez en annexes la procédure d installation du round robin DNS. Rapport de projet Répartition des charges sur serveurs web virtualisés 14

15 2.2 Le Load Balancing Présentation Le load balancing est une solution de répartition des charges qui a été implémentée dans plusieurs logiciels tels que LVS (Linux Virtual Server) et HAproxy. Nous allons vous présenter ces deux logiciels libres que nous avons mis en place au sein de notre infrastructure de haute disponibilité. Nous nous attarderons cependant plus sur Ha Proxy, qui possède beaucoup de similitudes avec LVS, dans cette partie du rapport. Linux Virtual Server (LVS) est une solution de répartition de charge pour GNU/Linux. C est un logiciel libre créé par Wenson Zhang en mai Le projet était de construire un serveur de haute performance pour Linux qui puisse avoir une bonne évolutivité, fiabilité et robustesse tout en utilisant la technologie du cluster. De, plus, LVS est une des solutions les plus utilisées. Un autre élément qui nous a fait choisir cette solution est le fait qu il est activement soutenu par des entreprises et notamment par RedHat, qui a repris la solution LVS en l améliorant pour son système d exploitation. Les outils de l éditeur RedHat sont très répandus dans le monde professionnel et sont réputés pour leur fiabilité, leur flexibilité et leurs performances. HA Proxy, quant-à lui, est un serveur http développé par le français Willy Tarreau en C est un serveur haute performance, léger et à consommation de ressources minimale. C est une solution gratuite, très rapide et fiable, offrant une haute disponibilité, Load balancing, et le proxy pour les applications TCP et HTTP Il est particulièrement adapté pour les sites web assaillis sous des charges très élevées tout en ayant besoin de persistance ou du traitement de la couche 7. Soutenir des dizaines de milliers de connexions est clairement réaliste avec le matériel d'aujourd'hui. Son mode de fonctionnement permet son intégration dans des architectures existantes très facile et sans risque, tout en offrant la possibilité de ne pas exposer les serveurs web fragiles sur le Net, comme ci-dessous: Rapport de projet Répartition des charges sur serveurs web virtualisés 15

16 2.2.2 Propriétés et principe de fonctionnement d HAproxy : A Propriétés HAProxy est un relais TCP/HTTP offrant des facilités d'intégration en environnement hautement disponible. En effet, il est capable : D'effectuer un aiguillage statique défini par des cookies ; D'effectuer une répartition de charge avec création de cookies pour assurer la persistance de session ; De fournir une visibilité externe de son état de santé (statistiques); De s'arrêter en douceur sans perte brutale de service ; De modifier/ajouter/supprimer des en-têtes dans la requête et la réponse ; D'interdire des requêtes qui vérifient certaines conditions ; D'utiliser des serveurs de secours lorsque les serveurs principaux sont hors d'usage. De maintenir des clients sur le bon serveur d'application en fonction de cookies applicatifs. Fournir des rapports d'état en HTML à des utilisateurs authentifiés, à travers des URI de l'application interceptées. Il requiert peu de ressources, et son architecture événementielle mono-processus lui permet facilement de gérer plusieurs milliers de connexions simultanées sur plusieurs relais sans effondrer le système. En mode load balancer, il utilise l algorithme round robin pour la répartition de charge et les «cookies» pour assurer la persistance de la session entre le client et le serveur. B Principe de fonctionnement : Nous parlions précédemment de la persistance des sessions. Voici un exemple qui illustre le fonctionnement du logiciel avec ce mode : L internaute demande une page web, la requête est donc à destination du serveur HAproxy. Ce dernier agit en «load balancer» et le dirige vers le «Serveur WEB 1» Rapport de projet Répartition des charges sur serveurs web virtualisés 16

17 Le serveur WEB 1 répond, HAproxy transmet la page à l internaute et met en place un «cookie» identifiant sur le serveur. L internaute demande une autre page web, HAproxy recherche un éventuel «cookie» et le redirige. Le serveur WEB 1 répond, HAproxy transmet mais ne rajoute pas de nouveau un «cookie». Dans le cas où le premier serveur tombe en panne pour une raison quelconque, le serveur HA Proxy va donc rediriger directement les requêtes vers les autres serveurs du cluster : Rapport de projet Répartition des charges sur serveurs web virtualisés 17

18 Pour l utilisateur, si un serveur tombe en panne, les requêtes sont redirigées vers un autre et cela lui parait donc complètement transparent Configuration Afin de comprendre plus aisément le fonctionnement du logiciel, nous allons détailler quelque peu la configuration de ce dernier. Modes de fonctionnement Le service peut fonctionner dans plusieurs modes : - avant- / arrière-plan - silencieux / normal / debug Le mode par défaut est normal, avant-plan, c'est à dire que le programme ne rend pas la main une fois lancé. Il ne faut surtout pas le lancer comme ceci dans un script de démarrage du système, sinon le système ne finirait pas son initialisation. Il faut le mettre en arrière-plan, de sorte qu'il rende la main au processus appelant. C'est ce que fait l'option 'daemon' de la section 'global'. Par ailleurs, certains messages d'alerte sont toujours envoyés sur la sortie standard, même en mode 'daemon'. Pour ne plus les voir ailleurs que dans les logs, il suffit de passer en mode silencieux par l'ajout de l'option 'quiet'. Cette option n'a pas d'équivalent en ligne de commande. Enfin, le mode 'debug' permet de diagnostiquer les origines de certains problèmes en affichant les connexions, déconnexions et échanges d'en-têtes http entre les clients et les serveurs. Ce mode est incompatible avec les options 'daemon' et 'quiet' pour des raisons de bon sens. Rapport de projet Répartition des charges sur serveurs web virtualisés 18

19 Accroissement de la capacité de traitement Sur des machines multi-processeurs, il peut sembler gâché de n'utiliser qu'un processeur pour effectuer les tâches de relayage, même si les charges nécessaires à saturer un processeur actuel sont bien au-delà des ordres de grandeur couramment rencontrés. Cependant, pour des besoins particuliers, le programme sait démarrer plusieurs processus se répartissant la charge de travail. Ce nombre de processus est spécifié par le paramètre 'nbproc' de la section 'global'. Sa valeur par défaut est naturellement 1. Ceci ne fonctionne qu'en mode 'daemon' Bilan du logiciel HaProxy répond donc bien à la problématique principale qui consiste à gérer dynamiquement les clusters de serveurs Web (nommés aussi Backends). De plus c est un système fiable et qui supporte de forts trafics lors de la mise en production. C est donc une solution simple à mettre en œuvre, qui permet de gérer les paramètres de bases tels que le poids des backends ainsi que le type d algorithme de répartition des charges, mais cependant essentiels au sein d une infrastructure à haute disponibilité. Un des aspects pratiques de cette solution est qu il détecte automatiquement les serveurs défaillants et redirige donc sur d autres serveurs qui sont actifs. De plus, lors d une maintenance, il est possible d arrêter progressivement les redirections vers un backend particulier sans coupure des connexions établies. Cependant, il n existe pas de partage de mémoire entre les serveurs d applications et, quand un serveur Web tombe en panne, les sessions applicatives associées sont perdues. Bien entendu, si le serveur Haproxy tombe en panne, tout le système est inutile car le Haproxy sert de routeur. De notre côté, nous avons trouvé qu Haproxy été un logiciel fiable, il ne plante jamais, et est performant pour des requêtes sur des fichiers volumineux. Rapport de projet Répartition des charges sur serveurs web virtualisés 19

20 2.3 Logiciels complémentaires aux équilibreurs de charges Afin de répondre aux inconvénients du logiciel que nous avons vu dans la partie précédente, on peut faire évoluer l architecture et utiliser des outils permettant de mieux la gérer et prévenir des pannes totales Heartbeat : Heartbeat (ou Pulse) est un système de gestion de la haute disponibilité open source. Il met en place un système de clustering basé sur des «battements de cœur». Il exécute des scripts d initialisations lorsqu une machine tombe ou est à nouveau disponible. Il permet aussi de changer d adresse IP entre les machines à l aide de mécanisme ARP «avancés». Pour résumer, Heartbeat permet le partage d une adresse IP «virtuelle» aux différentes machines du cluster. La notion de maître et d esclave est utilisée ici. Une des machines est déclarée «maître» qui répond au trafic sur l IP virtuelle, les autres sont «esclaves» et selon la priorité qui leur est attribué prennent la main en cas de défaillance du «maître». Pour résumer, voici les principales fonctionnalités du logiciel : - Gestion de cluster jusqu à 16 nœuds. - Gestion de différents modes : Actif/Passif, Actif/Actif. - Gestion intégrée des ressources (depuis la version 2). Schéma global en temps normal Un client passe par l adresse IP du cluster qui le redirige vers le serveur MySQL01. Une réplication du disque dur est faite de MySQL01 à MySQL02. Rapport de projet Répartition des charges sur serveurs web virtualisés 20

21 Schéma global, panne du serveur principale MySQL01, cluster dégradé Heartbeat détecte que le service MySQL du 1 er serveur ne répond plus, le cluster fonctionne en mode dégradé et donc les requêtes sont redirigées sur le serveur MySQL02. Schéma global, retour à une situation normale Heartbeat détecte que le service MySQL du 1 er serveur est redémarré, il redevient maître. Une réplication est effectuée du serveur MySQL02 à MySQL01 pour les mises à jour de sa base de données. Rapport de projet Répartition des charges sur serveurs web virtualisés 21