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

22 2.3.2 Piranha : C est un outil de configuration LVS disponible avec Red Hat Cluster Suite Piranha Configuration Tool. Piranha est une interface utilisateur graphique (GUI) qui fournit une approche structurée de la création du fichier de configuration pour LVS (/etc/sysconfig/ha/lvs.cf) La connexion à la page d accueil donne accès aux quatre principaux écrans : - Contrôle/commande - Paramètres globaux - La redondance - Serveurs virtuels Ce logiciel est donc pratique pour configurer LVS de façon plus visuelle, et évite ainsi de se perdre dans les fichiers de configuration du serveur DRBD : DRBD «Distributed Replicated Block Device» est un module du noyau Linux qui constitue un système de stockage distribué. On peut utiliser DRBD pour partager des périphériques entre les serveurs Linux (disques durs, partitions des volumes logiques, etc). DRBD est un outil qui permet de synchroniser (par réplication) des périphériques de stockage (disque dur, partition, volume logique, etc.) entre deux ordinateurs via le réseau. Cette synchronisation se fait en temps réel, de manière transparente, de manière synchrone ou asynchrone. DRBD met en œuvre un périphérique (block device) qui peut être utilisé pour le stockage et qui est reproduit à l identique à partir d un serveur principal à un ou plusieurs serveurs secondaire. Le périphérique de distribution est géré par le service DRBD. Sur le serveur primaire, les données sont écrites sur le périphérique physique et distribuées vers les services secondaires de «DRBD». Le serveur secondaire, les données sont reçues et écrites sur le périphérique physique. L information est partagée entre le serveur principal et le serveur secondaire de manière synchrone. «DRBD» utilise des périphériques logiques (appelés /dev/drbx ou X est le nombre de périphérique) sur des périphériques physique existants de chacun des serveurs du cluster. Les écritures sont transférées du périphérique logique (/dev/drbx) au périphérique physique et simultanément vers le serveur secondaire. Le serveur secondaire transfère les données vers son périphérique. DRDB peut être associé à Heartbeat et vont ainsi se compléter, car Heartbeat vérifie l état d une ressource et DRDB synchronise plusieurs ressources entre elles (cf schémas dans la partie Heartbeat). Rapport de projet Répartition des charges sur serveurs web virtualisés 22

23 2.4 Architecture Plus complexe. Afin de prendre en compte l ensemble des éléments que nous avons présenté tout au long de ce rapport, nous avons testé une infrastructure intégrant les technologies de répartition, de redondance et de réplication (cf schéma ci-dessous). L infrastructure est donc composée de 2 serveurs Haproxy, intégrant le logiciel Heartbeat afin que si le premier serveur tombe, le second prenne le relai. Ces 2 serveurs vont répartir les charges au sein du cluster. Afin de surveiller les membres du cluster, les répartiteurs intègrent un serveur de supervision Zabbix. Le cluster est, quand à lui, composé de 3 serveurs Apache. Chacun des serveurs intègre un agent Zabbix permettant de surveiller les paramètres essentiels depuis le serveur de supervision. De plus les fichiers sont stockés sur le serveur NFS, pour centraliser les fichiers statiques. La base de données est également mise en place sur le serveur NFS et est répliquée sur un autre serveur qui est synchronisé en temps réel avec DRDB. Cette infrastructure a donc l avantage de répartir les charges, de mettre en place de la redondance ainsi que de la réplication pour assurer une sécurité des données ainsi qu une disponibilité en toute circonstances. Rapport de projet Répartition des charges sur serveurs web virtualisés 23

24 2.3.4 Unison Unison est un logiciel de synchronisation de dossiers. Il a l avantage d être multi plateforme et portable. Il existe en deux versions : l une avec une interface graphique, l autre en ligne de commande uniquement. Ce logiciel fonctionne par profil : une fois un nouveau profil créé, on indique la source et la destination de synchronisation, les règles de synchronisation. Par contre, il est peu souple : l interface est en anglais, un profil ne peut contenir que le nom de deux dossiers et sous-dossiers (la source et la destination), et il semble qu il soit impossible de modifier ou supprimer un profil créé via l interface graphique. Il est donc à utiliser principalement pour sa ligne de commande. Afin d automatiser ce processus, il est possible d utiliser le cron, qui automatise les tâches planifiées. Ainsi, on peut effectuer la synchronisation automatiquement tous les jours à 6h par exemple. Avec cette technique, on ne synchronise que des fichiers statiques. On ne peut pas synchroniser une base de donnée par exemple (nécessité de synchronisation en temps réel) comme avec DRDB qui peut être synchronisé en temps réel. Rapport de projet Répartition des charges sur serveurs web virtualisés 24

25 3. Tests de performance Nous avons donc vu les différentes architectures décrites, dont les 3 principales que nous avons mises en place. Cependant, afin de voir concrètement leur efficacité face à une demande importante entrainant des charges élevées sur les serveurs, nous avons utilisé divers outils pour tester ces infrastructures. Ces outils consistent à envoyer en boucle des requêtes sur les serveurs tout en rendant des statistiques à la fin pour connaître leur réaction face à une forte demande. Nous avons donc utilisé principalement 2 outils dans cette optique : httperf et siège. 3.1 Matériel Dans le cadre de ce projet, nous avons à notre disposition 5 PC : - 4 PC avec 2 cartes réseaux et disposant de 256Mo de mémoire RAM (les serveurs Apache) - 1 PC avec 4 cartes réseaux et disposant de 512Mo de mémoire RAM (le répartiteur) Cependant, nous avons également utilisé nos propres ordinateurs pour virtualiser les machines et nous permettre de nous échanger des configurations pour nos tests : - Un PC avec 4 Go de Ram et un processeur Intel Celeron à 1.2Ghz (1 cœur) - Un PC avec 4 Go de Ram et un processeur Intel Core I3 à 2.26Ghz (2 cœurs) - Un PC avec 4 Go de Ram et un processeur Intel Core I7 à 1.6Ghz (4 cœurs, 8 threads logiques) Les résultats les plus concrets ont été enregistrés sur machines virtuelles avec le PC le plus puissant des Solutions de test HTTPERF Httperf est donc un outil qui permet de tester les performances d un serveur web. Différentes options sont possibles afin d exploiter au maximum nos 4 serveurs web et en tirer des résultats significatifs. L'objectif de httperf n'est pas à mettre en œuvre une référence particulière, mais à fournir un outil fiable de haute performance. Les trois caractéristiques distinctives de httperf sont sa robustesse, ce qui comprend la capacité de générer et de maintenir la surcharge des serveurs, support pour les protocoles HTTP/1.1 et SSL, et son extensibilité à de nouveaux générateurs de charge de travail et les mesures du rendement. Rapport de projet Répartition des charges sur serveurs web virtualisés 25

26 Pour cela, nous avons utilisé une option qui modélise des sessions avec un nombre définit de requêtes par sessions et un laps de temps définit entre chaque requête. La commande est donc structurée de la manière suivante : Httperf --hog - -server :@server - -uri:/index.htm - -wsess N1,N2, X - -rate R - - timeout T --hog server: ici on spécifie l adresse du serveur web (dans notre cas on spécifie l adresse du répartiteur) -- uri : ici on spécifie l url que l on veut tester (dans notre cas on spécifie le fichier index.htm à la racine du dossier /var/www) --wsess : Le nombre N1 correspond au nombre de sessions à générer (cela peut être vu comme un nombre d utilisateurs). Le nombre N2 correspond au nombre d appels par session, c'est-à-dire le nombre de requêtes par session Le nombre X correspond au temps en secondes entre chaque appel --rate : R correspond au débit de création de sessions par seconde. Par défaut, le paramètre est à 0 et à chaque fin de session une autre est créée. Cet ensemble d options permet ainsi de générer de nombreuses requêtes simultanément afin de modéliser un grand nombre d utilisateurs sur le site web en question Siège C est un outil qui permet de faire des tests de montée en charge des applications web en simulant un grand nombre de connexions simultanées sur une ou plusieurs URLs données. Siege rapporte le nombre totale de hits enregistrés, de bytes transférés, le temps de réponse, les accès concurrents et retourne le statut du serveur. Siege supporte les protocoles HTTP/1.0 et 1.1, les méthodes GET & POST, les cookies, les transactions log, et l authentification basique Voici un exemple de commande avec siège : # siege c 380 r 50 d /index.php Ici on teste le serveur Haproxy d adresse don t l URL est /index.php avec les arguments suivants: - c qui représente le nombre d utilisateurs - r qui représente le nombre de requêtes par utilisateur - d qui représente le délai entre les requêtes Rapport de projet Répartition des charges sur serveurs web virtualisés 26

27 3.2.3 Autres outils de test Tsung : Outils de test de performances. Il est Multi-protocoles utilisant un système de plugin (HTTP, WebDAV, SOAP, PostgreSQL, MySQL, LDAP, SSL et XMPP/Jabber) Et chose très importante, il permet de faire des scénarios. Les scénarios permette de simuler de la montée en charge mais non sur une seule url, mais via une succession d action, par exemple, on arrive sur la page d accueil, on clique sur la catégorie «Administration», on choisi l article «Test de montée en charge avec des logiciels libres». L activité de l utilisateur et le taux d arrivée peut être aléatoire en utilisant une notion de probabilité. Clif : Permet de faire des tests de performances d applications web distribuées Plusieurs injecteurs réparties (permet de simuler d énormes charges) vont simuler des connections simultanées en mesurant les temps de réponse, des erreurs Des sondes déployées sur les serveurs hébergeant les applications à tester vont mesurer l activité RAM, CPU, Disque Clif gère les scénarios et fonctionne en multi-protocole (TCP, UDP, TCP, DNS, HTTP(S), JDBC, JMS, DHCP, LDAP, SIP) Rapport de projet Répartition des charges sur serveurs web virtualisés 27

28 3.3 Résultats Dans le cadre de nos tests, afin d obtenir des résultats probants, nous avons effectué différentes requêtes avec le logiciel siège afin de générer différents nombres de requêtes. Nous avons donc généré entre 10 et 380 clients qui envoyaient 50 requêtes chacun. Le délai d envoi entre les requêtes est de 0.1 seconde. Nous avons donc relevé différentes informations à la fin de chaque test tel que le nombre de requêtes traitées par seconde (transactions/sec), le temps d exécution du test et le délai moyen de traitement d une requête. Ces tests ont été effectués sur différents fichiers hébergés sur nos 4 serveurs Web. Nous avons donc choisit un fichier HTML léger (1500 bytes), un fichier PHP (8000 bytes) et un fichier HTML lourd (300 Kbytes). Pour informations, notre serveur Haproxy possède 2048 Mo de mémoire RAM et chacun de nos serveurs Apache possède 256 Mo de RAM (en machine virtuelle) HTML : Voici le nombre de transactions par seconde en fonction du nombre de requêtes envoyées : Transactions /sec Serveur 2 Serveurs 3 Serveurs Nombre de transactions On remarque ainsi que pour 1 ou 3 serveurs actifs, le nombre de transactions moyens par seconde sature aux environs de 500 requêtes/seconde. Rapport de projet Répartition des charges sur serveurs web virtualisés 28

29 Voici le temps d exécution du test (en secondes) en fonction du nombre de requêtes émises Secondes Serveur 2 Serveurs 3 Serveurs Nombre de transactions On remarque que le temps d exécution des requêtes est quasiment identique pour 1 ou 3 serveurs actifs. Voici le délai de réponse en seconde en fonction du nombre de requêtes envoyées. Secondes 0,8 0,7 0,6 0,5 0,4 0,3 0,2 0, Serveur 2 Serveurs 3 Serveurs Nombre de transactions On remarque que le délai de réponse est identique pour 1 ou 3 serveurs actifs. On peut donc en déduire que c est Haproxy qui est bridé et qui limite le nombre de requêtes/seconde à 500. Rapport de projet Répartition des charges sur serveurs web virtualisés 29

30 3.3.2 PHP Voici le nombre de transactions par seconde en fonction du nombre de requêtes envoyées Transactions /sec Serveur 2 Serveurs 3 Serveurs 4 Serveurs Nombre de transactions On remarque sur cette courbe que pour 1 et 2 serveurs actifs, on atteint la saturation. Cependant pour 3 et 4 serveurs actifs, le système peut encore supporter de la charge, soit plus de 380 clients émettant 50 (soit transactions) requêtes chacun toutes les 0.1 seconde. Voici le temps d exécution du test en fonction du nombre de requêtes Secondes Serveur 2 Serveurs 3 Serveurs 4 Serveurs Nombre de transactions On peut remarquer que le temps d exécution s améliore nettement lorsque l on augmente le nombre de serveurs actifs. Rapport de projet Répartition des charges sur serveurs web virtualisés 30

31 Voici le délai de réponse en secondes en fonction du nombre de requêtes envoyées. Secondes 3,5 3 2,5 2 1,5 1 0, Serveur 2 Serveurs 3 Serveurs 4 Serveurs Nombre de transactions On remarque que le délai moyen de traitement d une requête et l on voit également que ce délai diminue avec le nombre de serveurs actifs HTTP lourd : Voici le nombre de transactions par seconde en fonction du nombre de requêtes envoyées Transactions /sec Serveur 2 Serveurs 3 Serveurs 4 Serveurs Nombre de transactions On remarque sur ce graphique que le nombre de serveurs influe vraiment sur les performances sur ce type de données. On peut également voir que les performances pour 1 et 2 serveurs actifs diminuent pour un nombre important de requêtes émises. Nous allons voir sur le graphique suivant la cause de cette baisse de performance. Rapport de projet Répartition des charges sur serveurs web virtualisés 31

32 Majid LAYOUNI Raphaël MAZOT Master 2 Alexandre TRAN 2010/2011 Voici le temps d exécution du test en fonction du nombre de requêtes Secondes Serveur 2 Serveurs 3 Serveurs 4 Serveurs Nombre de transactions On remarque sur ce graphique que pour 1 et 2 serveurs actifs, le temps d exécution du test augmente jusqu à un certain point pour retomber. Il s agit de la saturation des serveurs qui ne peuvent plus répondre à aucune requête. On voit ainsi les performances accrues avec 3 et 4 serveurs actifs. Voici le délai de réponse en secondes en fonction du nombre de requêtes envoyées. Secondes Serveur 2 Serveurs 3 Serveurs 4 Serveurs 0 Nombre de transactions On remarque que le délai de traitement d une requête est vraiment optimum avec 4 serveurs Web actifs. Rapport de projet Répartition des charges sur serveurs web virtualisés 32

33 3.3.4 Bilan des tests Après ces tests sur des fichiers différents tels que HTML léger, PHP et HTML lourd, les résultats se sont déterminés probants tout en montrant l efficacité de la répartition des charges (dans le cas de PHP et HTML lourd). Ces tests montrent également les limites de Haproxy et montrent qu il est tout de même important d avoir une machine puissante capable de supporter un grand nombre de requêtes par seconde pour ne pas limiter le système comme dans le cas du fichier HTML léger. Nous n avons cependant pas pu déterminer si la cause de ce blocage venait du logiciel en lui-même ou si cela venait du manque de ressources physiques. Sachant que 2Go de Ram lui était affectés ainsi qu un cœur du processeur I7 pour son bon fonctionnement. Vu que de grands sites Internet utilisent cette solution (voir chapitre suivant), nous pensons que cela vient des ressources de la machine. Nous allons maintenant voir quels types de solutions utilisent les grands sites Internet qui doivent supporter bien plus de 500 requêtes par secondes sur leurs serveurs. Rapport de projet Répartition des charges sur serveurs web virtualisés 33

34 4. Utilisations concrètes Au sein de l internet, de nombreux sites web sont extrêmement demandés et ont été obligé de mettre en place un système de répartition des charges pour garder une haute disponibilité vis-à-vis de leurs utilisateurs. Dans cette partie, nous allons vous montrer 2 architectures de sites très utilisées au sein de l Internet, à savoir les sites Dailymotion et Wikipedia. 4.1 Dailymotion L architecture de DailyMotion est assez impressionnante. Les volumes de données, le nombre de requêtes simultanées ainsi que les upload et download continuels sont un véritable défit en terme de disponibilité. Pour ce type de site les problématiques sont multiples : - Tout d abord la gestion d un trafic réseau colossal : avec un backbone interne à 10Gb et des routages dynamiques tout aussi impressionnants. La structure du réseau et la communication entre les data center sont déjà un challenge. Figure : Communication entre les serveurs - Les applicatifs : plusieurs serveurs, de l apache pour les proxys vidéo et du lighttpd pour les images, style et contenus statique. Le tout, comme d habitude, en cluster sous PHP et MySQL. La recherche est gérée sur des serveurs dédiés équipé de Sphinx (logiciel d enquête et d analyse de données). Les performances de ce moteur full text sont bien plus impressionnantes que le moteur de MySql ou encore qu un couple Lucene/Java. Mais même avec cette application ultra performante il faut 9 serveurs pour traiter le flot de recherche permanent (tout en indexant les nouveautés rapidement). - Le stockage est lui aussi gourmand, une vidéo c est quelques dizaines de Mo, même avec la baisse drastique des coûts des disques des volumétries de cet ordre sont très couteuses. - L encodage des vidéos qui arrivent sans cesse consomme également beaucoup de CPU. - Mais il y a aussi : Le load balancing sur le niveau réseau, le Round Robin DNS, les serveurs proxy, BDD, Search, etc. Rapport de projet Répartition des charges sur serveurs web virtualisés 34

35 Pour cette année cette architecture va devoir traiter la livraison de plusieurs dizaines de millions de vidéos par jour, soit quelques centaines de vidéos par seconde! Chez Google l architecture de YouTube est assez comparable. Mais l avantage pour YouTube c est que la gestion de la croissance est désormais gérée avec Google, qui avec une bonne trentaine de data center et son GFS peut mutualiser une bonne partie des dépenses d infrastructure. Mais dans les deux cas pour ce type de service la bande passante reste un élément clef. Car au delà des problèmes commerciaux la gestion de ces autoroutes représente des couts très important et l empilement des clusters de serveur n est efficace que si le trafic est correctement régulé (et cela jusque dans les couches les plus bases des réseaux). Dernier défit, et non des moindre pour DailyMotion atteindre les 20, voir 30 millions d euros de revenus en Car à ce rythme la levée de fond de 25 millions de l année dernière va vite se consumer. Il va donc falloir du chiffre pour lui permettre de payer de cette colossale infrastructure (en plus de la petite centaine de personnes qui compose la société). 4.2 Wikipedia Nous allons maintenant voir la structure d un site Internet très connu pour ses informations (parfois non vérifiées) et qui est souvent sollicité : Wikipédia. Il fonctionne grâce à un logiciel open source: MediaWiki. C est un logiciel PHP/MySQL. L architecture des sites Wikipédia est donc basée sur ce couple de logiciel et hébergée sur des configurations classiques de type LAMP (Linux Apache Mysql Php). Mais pour gérer des pics avec plusieurs dizaines de milliers de connections par seconde il faut booster cette architecture. L équipe du site a donc ajouté un certains nombre de composant pour absorber ce trafic colossal. Dans le désordre nous retrouvons : - Une répartition de charge par DNS - LVS pour le load balancing - Squid pour le cache - Memcached, Lucene, Lighttpd, - etc Rapport de projet Répartition des charges sur serveurs web virtualisés 35

36 Voici un schéma pour expliciter l infrastructure du site : Concernant les volumétries, les 3 datacenters de Wikipédia utilisent quelques 400 serveurs (du P4 au double Xeon Quad Core avec 16Gb de RAM). Mais le plus impressionnant reste Squid car il gère ici des pointes à 2500 requêtes/sec sur UN SERVEUR! Rapport de projet Répartition des charges sur serveurs web virtualisés 36

37 A noter également l utilisation astucieuse de CARP (Common Address Redundancy Protocol), protocole qui autorise sur un même segment réseau de partager une adresse IP, dans le but de répartir les requêtes sur les différents datacenter. 4.3 Bilan des infrastructures Internet On peut donc voir que les grands sites internet utilisent des infrastructures complexes qui intègrent des outils comme LVS, le load balancing, le DNS round robin ainsi que des solutions de réplication pour répondre à la demande de leurs clients. Ils n utilisent donc pas seulement une, mais un ensemble de solutions afin de gérer au mieux la haute disponibilité de leur site internet. Ces solutions sont également différentes car les deux sites ne proposent pas les mêmes services et ne demandent donc pas les mêmes types de ressources (bande passante, disque dur, indexation, ). Il est cependant intéressant de remarquer que les grands sites de l Internet utilisent des solutions libres. Que ce soit avec Apache pour les serveurs Web, avec LVS et Haproxy pour la répartition des tâches, les logiciels libres sont bien utilisés sur de grosses infrastructures. Rapport de projet Répartition des charges sur serveurs web virtualisés 37

38 Conclusion Ce projet fut fort intéressant car il pose une vraie problématique pour les gestionnaires de grands sites internet. De plus, cela correspond à un besoin qui va probablement s accentuer dans les prochaines années vu le nombre croissant d internautes, sans compter ceux provenant des pays émergeant dont les connexions vont augmenter à l avenir. Cependant, nous aurions aimé approfondir le sujet, mais les machines virtuelles ainsi que les pc qui nous avaient été fournis ne permettent pas d exploiter correctement les performances des architectures que nous avons étudiées et ne peut donc pas être comparée à une grosse infrastructure. De plus, nous nous sommes rendu comte que des solutions de répartition peuvent être utilisées dans différents cas. EN effet il est préférable d utiliser le DNS round robin pour répartir des datacenters alors que les solutions de load balancing sont plus adaptées à l équilibrage de charges au sein du datacenter. Cela nous a tout de même permis de voir et de comprendre des solutions de répartition des charges et ainsi avoir une vue plus générale sur les infrastructures des sites Internet qui nécessitent une haute disponibilité. Nous pouvons maintenant comprendre la complexité de mettre en place et de maintenir des sites très demandés tels que Google ou facebook qui sont les sites les plus demandés à ce jour. Rapport de projet Répartition des charges sur serveurs web virtualisés 38

39 Bibliographie Livre: Tony Bourke Server Load Balancing O Reilly 2001 Sources Internet: Description des techniques de répartition des charges DNS : Mise en place du DNS round robin : Mise en place d Haproxy : Etude de cas des architectures de Youtube et Wikipedia : Récapitulatif des logiciels utilisés: Système d exploitation: Serveur de base de données: ServeurWeb : Serveur de stockage de données : Logiciels de monitoring : Solutions d équilibrage de charges : Outils de benchmark et de génération de graphiques : Debian, CentOS MySQL/DRBD Apache2 NFS Zabbix HAProxy, LVS siège, httperf, Zabbix, Excel Rapport de projet Répartition des charges sur serveurs web virtualisés 39

40 Annexes : Nous avons dans un premier temps testé la solution du round robin sur un DNS qui est la solution la plus simple à mettre en place mais comporte certaine limite dans sa configuration (impossibilité de définir des «poids» pour les serveurs, le poids permet de définir la répartition de charge selon leur puissance). Voici la procédure d installation d une architecture DNS round robin : Annexe 1 : DNS Round Robin Cette approche de travail fonctionne pour BIND 4 serveurs de nom, où on ne considère pas les multiples CNAMES comme une erreur de configuration. Supposons qu il y ait 4 serveurs Web dans le groupe, configurés avec des adresses IP [1-4]. Dans un premier temps, ajoutez tous au DNS avec des adresses (des Noms) comme ci-dessous. Fichier «named.conf.local» : zone "domain.com" { type master; file "/etc/bind/db.charge.iup"; }; zone " in-addr.arpa" { type master; file "/etc/bind/db "; } ; Fichier «db.charge.iup»: server1 IN A server2 IN A server3 IN A server4 IN A Fichier db : 60 IN A www. charge.iup 60 IN A www. charge.iup 60 IN A www. charge.iup. 60.IN A Ici, sur cette infrastructure, nous pouvons voir qu il y a plusieurs serveurs web nommés «www» sur le domaine «charge.iup». Le paramètre «60» permet de rafraîchir le cache DNS plus rapidement. Ainsi lorsque le serveur DNS va recevoir la première requête pour un service web (port 80), il va la rediriger sur le premier serveur, la deuxième requête sur le deuxième serveur, et ainsi de suite. Rapport de projet Répartition des charges sur serveurs web virtualisés 40

41 Installation de HAProxy : # apt-get install haproxy Il faut activer le service : # nano /etc/default/haproxy ENABLED=1 Annexe 2: HAProxy Configuration de HAProxy : Dans le fichier de configuration on définit des paramètres tels que le mode «http», le nombre de connexions maximum, le temps de réponse d un serveur avant que celle-ci soit définit comme arrêté # nano /etc/haproxy/haproxy.cfg global log local0 log local1 notice #log loghost local0 info maxconn 4096 #debug #quiet user haproxy group haproxy defaults log global mode http option httplog option dontlognull retries 3 redispatch maxconn 2000 contimeout 5000 clitimeout srvtimeout listen ClusterWEB :80 mode http stats enable stats auth user:password balance roundrobin cookie SERVID prefix option httpclose Rapport de projet Répartition des charges sur serveurs web virtualisés 41

42 option forwardfor option httpchk HEAD / HTTP/1.0 server web1-cloud :80 weight 1 cookie A check server web2-cloud :80 weight 1 cookie B check server web3-cloud :80 weight 1 cookie C check Dans la partie «listen», on définit un nom que portera notre cluster «ClusterWEB» et l adresse IP auxquelles on pourra se connecter sur nos serveurs réel « :80». «stats enable» permet d activer les statistiques de nos serveurs du cluster, accessible à l adresse dont le login est user et le mot de passe password. On utilise l algorithme roundrobin et les cookies sont activés pour la persistance des données. server web1-cloud :80 weight 1 cookie A check server web2-cloud :80 weight 1 cookie B check server web3-cloud :80 weight 1 cookie C check On définit nos trois serveurs WEB par un nom webx-cloud suivi de son adresse IP et de son port puis de son poids, dans notre cas ils ont tous un poids de 1 car les serveurs ont une configuration identique. Trois serveurs active dans HAProxy Rapport de projet Répartition des charges sur serveurs web virtualisés 42

43 Annexe 3 : DRBD On fait une installation normale de deux serveurs avec la distribution CentOS, la seule différence réside dans le fait qu on va laisser un espace non partitionné pour l utilisation de DRBD. Nous avons laissé 2Go (il contiendra les bases de données de notre site Web). Nous avons configuré notre disque dur en trois partitions : Périphérique Point de montage Capacité /dev/sda1 / 15Go /dev/sda2 swap 4Go /dev/sda3 Linux LVM 2Go Serveur 1 Serveur 2 Nom du serveur mysql01 Mysql02 IP eth / /16 IP eth / /24 Il est important de nommer les serveurs pour que DRBD puissent se synchroniser entre les deux disques durs. # hostname mysql01 serveur 1 (NFS & DRBD) # hostname mysql02 serveur 2 (DRBD) La communication entre les deux serveurs s effectue sur les ports suivants : Service Port MySQL 3306 DRBD 8888 Nous avons décidé d utiliser DRBD, car c est l une des méthodes conseillé sur le site officiel de MySQL pour la réplication, les avantages de cette solutions sont les suivants : Réplication des données en temps réel La réplication se produit pendant même que des applications sont en train de modifier les données sur le périphérique. Réplication transparente Les applications qui stockent leurs données sur le périphérique ne sont pas «consciente» que leur donné sont répliqués sur plusieurs ordinateurs. Le principal inconvénient de DRBD est qu il est incapable de détecter la corruption du système de fichiers. Rapport de projet Répartition des charges sur serveurs web virtualisés 43

44 Les commandes sont à effectué sur les deux serveurs «DRBD», sauf indication contraire. Installation de DRBD: # yum install kmod-drbd IL faut ensuite copier le fichier de configuration de DRBD vers le répertoire /etc, sachant que la version de DRBD peut changer en fonction de la version du système d exploitation. # cp /usr/share/doc/drbd /drbd.conf /etc/drbd.conf Après avoir copié le fichier de configuration, il faut enlever les commentaires des lignes suivantes dans le fichier /etc/drbd.conf pour utiliser une authentification simple avec mot de passe crypté par «sha1», ce qui assure que seuls les serveurs avec le même mot de passe sont capables de se joindre au groupe. cram-hmac-alg sha1 ; shared-secret projet06 ; Le fichier de configuration de DRBD (/etc/drbd.conf) doit être le même sur les deux serveurs, sachant que l on a respecté les contraintes d installation : - On utilise le port 8888 sur les IP : et pour la communication réseau - Les ressources sont configurées pour une réplication synchrone (Protocol C) - On utilise la ressource appelée «r0» laquelle utilise /dev/sda3 comme périphérique de stockage de bas niveau, et est configuré comme méta-donnée interne. Rapport de projet Répartition des charges sur serveurs web virtualisés 44

45 Fichier de configuration «DRBD» global { usage-count no; } common { syncer { rate 100M; } } resource r0 { procotcol C; handlers { pri-on-incon-degr "echo o > /proc/sysrq-trigger ; halt -f" pri-lost-after-sb "echo o > /proc/sysrq-trigger ; halt -f" local-io-error "echo o > /proc/sysrq-trigger ; halt -f" outdate-peer "/usr/lib/heartbeat/drbd-peer-outdater"; } startup { degr-wfc-timeout 120; #2 minutes } disk { } net { } on-io-error detach; fencing resource-only; cram-hmac-alg "sha1"; shared-secret "projet06"; after-sb-0pri disconnect; after-sb-1pri disconnect; after-sb-2pri disconnect; rr-conflict disconnect; syncer { rate 10M; al-extents 257; } on mysql01 { device /dev/drbd0; disk /dev/sda3; address :8888; meta-disk internal; } } on mysql02 { device /dev/drbd0; disk /dev/sda3; address :8888; meta-disk internal; } Rapport de projet Répartition des charges sur serveurs web virtualisés 45

46 La section «global» Cette section est permise une seule fois dans le fichier de configuration, l option usage-count est utilisée pour stocker des statistiques sur l usage des plusieurs versions de DRBD, en contactant un serveur http chaque fois qu une nouvelle version de DRBD est installé sur le système. On peut le désactiver en utilisant «usage-count no ;», l utilisation par défaut est «usage-count ask ;» lequel vous invite à chaque fois de mettre à jour «DRBD». La section «common» Cette section fournit une méthode plus rapide pour définir une configuration à travers de l héritage, pour chaque ressource on peut définir n importe quelle option, mais aussi définir ou redéfinir des ressources de base (remplacer les commandes standard par des commandes prenant déjà en compte des options). La section «ressource» Tout type de ressource que l on définit devrait être appelée avec «ressource nom» dans le fichier de configuration. On peut utiliser un identifiant arbitraire, le nom d une ressource ne peut pas contenir d espaces. Chaque ressource doit avoir au moins deux sous sections «host» (une pour chaque serveur du cluster). Il faut ensuite créer les méta-données pour les périphériques. # drbdadm create-md all Il faut charger le module dans le noyau. # modprobe drbd On démarre le service DRBD et on définit le serveur primaire. # /etc/init.d/drbd start # drbdadm -- --overwrite-data-of-peer primary all Commande a effectué seulement pour le serveur primaire Pour pouvoir utiliser la partition, il faut formater le périphérique «DRBD», dans notre cas /dev/drbd0 # mkfs.ext3 /dev/drbd0 serveur primaire seulement Une fois le périphérique formaté, on va le monter dans /mnt/drbd # mkdir /mnt/drbd serveur primaire seulement #mount /dev/drbd0 /mnt/drbd serveur primaire seulement Rapport de projet Répartition des charges sur serveurs web virtualisés 46

47 Installation du serveur MySQL. # apt-get install mysql-server Annexe 4 : MySQL On va créer un répertoire pour les bases de données de MySQL # mkdir /mnt/drbd/mysql Puis, il faut copier le répertoire où sont stockées les bases de données vers un répertoire monté du périphérique «DRBD». # mkdir /mnt/drbd/mysql/data # cp R /var/lib/mysql /mnt/drbd/mysql/data Il nous reste plus qu a configuré notre serveur primaire, il faut éditer le fichier /etc/my.cnf pour changer le répertoire des bases de données et on active le journal binaire, avec l option «log-bin». #nano /etc/my.cnf datadir = /drbd/mysql/data log-bin = mysql-bin On peut maintenant démarrer le serveur «MySQL» et vérifier que le serveur fonctionne et stocke bien les données dans /mnt/drbd/mysql/data/ # /etc/init.d/mysql start On obtient donc une réplication de la base de données en temps réel entre le serveur MySQL et le serveur de réplication Nos serveurs Web et nos serveurs MySQL étant branchés sur le même commutateur, nous avons donc eu besoin de deux cartes réseau sur nos deux serveurs pour permettre l utilisation de «DRBD». Ainsi le trafic qu entraîne la réplication de la base ne perturbe en rien le reste du réseau. La partition sda3 (LVM) du serveur de réplication se synchronise avec le serveur Principale MySQL, Synchronisation en cours 89,7% Rapport de projet Répartition des charges sur serveurs web virtualisés 47

48 Annexe 5 : NFS Nous avons utilisé un serveur NFS pour centraliser le contenu et la configuration des serveurs Web. Cela offre plusieurs avantages : - Uniformisation de la configuration des serveurs Apache - Partage des fichiers du site Web entre les différents serveurs Web, ce qui simplifie les mises à jour Nous utilisons la version 4 du protocole NFS car cette version apporte des évolutions majeures : - Chiffrement et sécurisation (support de Kerberos5, ) - Support accru de la montée en charge (réduction du trafic par groupement de requêtes, délégation) - Reprise sur incidents - Utilisation du protocole TCP au lieu d UDP Mise en place du serveur NFS Installation de NFS : # yum install nfs-utils nfs-utils-lib On crée un répertoire /nfs qui contiendra les fichiers partagés avec nos serveurs web. On monte ce même répertoire sur lui-même en ajoutant cette ligne au fichier /etc/fstab : /nfs /nfs none bind 0 0 none : indique qu il n y a pas de système de gestion de fichier, /nfs étant un répertoire local. bind : option de montage permettant de monter plusieurs fois le même répertoire. 0 0 : indiquent respectivement la fréquence de sauvegarde de la partition et l ordre dans lequel l utilitaire fsck vérifie les partitions. Il ne reste plus qu a appliquer le montage à l aide de la commande : # mount -a Rapport de projet Répartition des charges sur serveurs web virtualisés 48

49 On partage le répertoire /nfs avec les serveurs web en ajoutant cette ligne dans le fichier /etc/exports : Point de montage IP Options /nfs /16 (rw,fsid=0,insecure,sync) /www /16 (rw,fsid=0,insecure,sync) /apache /16 (rw,fsid=0,insecure,sync) /php /16 (rw,fsid=0,insecure,sync) # nano /etc/exports /nfs /16(rw,fsid=0,insecure,sync) /www /16(rw,fsid=0,insecure,sync) /apache /16(rw,fsid=0,insecure,sync) /php /16(rw,fsid=0,insecure,sync) On lance le service nfs # /etc/init.d/nfs start On va partager sur le réseau les répertoires /nfs/* en lecture/écriture. -rw : lecture/écriture -fsid=0 : identifie l utilisateur du système de fichier en tant que root. -insecure : permet de désactiver l obligation de l utilisation d un port inférieur à 1024 pour l émission de la requête. -sync : la réponse aux demandes de ressources se fera après l application des changements sur le support (écriture sur le disque). Cela permet d éviter la corruption des données lors d un arrêt inopiné du serveur. Rapport de projet Répartition des charges sur serveurs web virtualisés 49

50 Mise en place du NFS sur les serveurs Web Nous allons monter les partitions dans le dossier /mnt Fichier /etc/fstab : Périphérique Point de montage SGF Option de montage Fréquence de sauvegarde de la partition :/ /mnt nfs4 _netdev,auto 0 0 Ordre de vérification de la partition Périphérique : on spécifie l adresse IP du serveur NFS SGF (système de gestion de fichier): protocole nfs en version 4 Point de montage : on va monter localement les répertoires partagés du nfs dans /mnt Option de montage : - _netdev : le montage de la partition s effectue seulement si le service réseau est démarré - auto : le montage est automatiquement effectué au démarrage de la machine Il ne reste plus qu a monter les partitions sur chaque serveur réel avec la commande : # mount -a Les serveurs web sont au préalable déjà installés via la commande : # aptitude install apache2 php5 mysql-server php5-mysql libapache2-mod-php5 Il ne nous reste plus qu à copier les fichiers de configuration de notre serveur web et les pages de notre site internet dans le serveur NFS puis de déployer les liens symboliques : # cp Rf /var/www /mnt # cp Rf /etc/apache2 /mnt # cp Rf /etc/php5 /mnt # rm Rf /var/www # rm Rf /etc/apache2 # rm Rf /etc/php5 # ln s /mnt/www/ /var # ln s /mnt/apache2 /etc # ln s /mnt/php5 /etc Rapport de projet Répartition des charges sur serveurs web virtualisés 50

51 Annexe 6 : Benchmark En effectuant des tests sous siège avec comme paramètre un grand nombre de clients, certains serveurs réel ayant des performances faible (peu de RAM, fréquence du processeur bas) tombe (down) puis remonte (up), tombe à nouveau et ainsi de suite. Web1 down ; Web2 up ; Web3 phase de transition du up à down Rapport de projet Répartition des charges sur serveurs web virtualisés 51