Architecture pour l hébergement web à fort trafic

Architecture pour l hébergement web à fort trafic Auteurs : Dupont Francois, Giroud Gabriel, Luc Aymeric, Nonet Guillaume Tuteur : Patrick Nourissier 18 mars 2015

Résumé Dans une entreprise, tous les services ne nécessitent pas une disponibilité ou accessibilité constante, cependant, certains services sont vitaux et il n est pas envisageable de les arrêter sans occasionner des pertes conséquentes pour l entreprise (un site e-commerce d envergure mondiale inaccessible). Notre projet a pour objectif d étudier et de proposer des solutions (une pile logicielle) permettant de répondre à ces besoins impitoyables de disponibilité, dans le cas de sites web engendrant un fort trafic.

Remerciements Nous remercions Patrick Nourissier, notre tuteur, pour sa disponibilité, son suivi, son aide et ses encouragements. Nous remercions openssh de nous permettre d optimiser nos horaires de travail. Page 1

Table des matières I Introduction 5 1 Définitions 6 1.1 La disponibilité..................................... 6 1.2 Qu est ce que la très haute disponibilité?...................... 7 1.3 Les architectures en couches.............................. 8 1.3.1 SPOF...................................... 10 2 Objectifs 11 2.1 Nos objectifs...................................... 11 2.2 La stack logicielle.................................... 11 2.2.1 Load balancing................................. 11 2.2.2 Reverse Proxy................................. 12 2.2.3 Cache...................................... 12 2.3 Complexification de la stack.............................. 12 3 Outils 13 3.1 Debian.......................................... 13 II Étude 14 4 LXC 15 4.1 Particularités...................................... 15 4.1.1 Cgroups..................................... 15 4.2 Avantages des conteneurs sur les machines virtuelles................ 15 4.3 Configuration de LXC................................. 16 4.3.1 Flockport.................................... 16 4.4 Fonctionnement de LXC................................ 16 5 HA-Proxy 18 5.1 Modes de fonctionnement............................... 18 5.2 Prendre la température de sa machine........................ 19 5.3 Les algorithmes de répartition............................. 19 5.3.1 Round Robin.................................. 20 5.3.2 Leastconn.................................... 20 5.3.3 First....................................... 21 5.3.4 Source...................................... 21 5.3.5 uri........................................ 22 2

5.4 Interface d administration............................... 22 5.5 Avantages sur Nginx.................................. 22 5.6 Avantages sur Varnish................................. 22 6 Collectd 23 6.1 Présentation...................................... 23 6.2 Principe du logiciel................................... 23 6.2.1 Pourquoi utiliser Collectd?.......................... 23 6.3 Exemple de plugins................................... 23 6.4 Les points forts de Collectd.............................. 24 6.5 Installation de Collectd................................ 24 6.6 Configuration de Collectd............................... 25 6.6.1 Configuration d un serveur.......................... 26 7 Munnin 29 7.1 Fonctionnement..................................... 29 8 Apache2 30 9 Nginx 31 9.1 Nginx en quelques points............................... 31 9.1.1 Un serveur asynchrone............................. 31 9.1.2 Modularité................................... 31 9.1.3 Optimisations.................................. 31 9.1.4 Nginx et ses extensions............................ 31 9.1.5 Nginx en quelques chiffres........................... 32 10 Joomla 33 11 Mysql et Percona 34 11.1 MySQL......................................... 34 11.1.1 Pourquoi utiliser le fork de Percona pour MySQL?............. 34 11.1.2 Etapes d installation de Percona XtraDB Cluster.............. 35 11.1.3 La configuration du cluster.......................... 36 11.1.4 Test de la réplication.............................. 38 12 Varnish 42 13 DRBD 43 14 Sécurité 44 14.1 Kalilinux........................................ 44 14.2 Firewall......................................... 44 14.2.1 naxsi....................................... 44 14.2.2 Netfilter..................................... 44 III Notre architecture haute diponibilité 45 15 Nos choix 46 15.1 Notre architecture................................... 46 Page 3

15.2 HA Proxy........................................ 47 15.3 LXC........................................... 47 15.4 Nginx.......................................... 47 15.5 Percona......................................... 47 15.6 Sécurité......................................... 47 15.7 Autres.......................................... 47 15.7.1 dnsmasq..................................... 47 15.7.2 Tuning...................................... 47 16 Conclusion 48 IV Annexes 49 16.1 Sources/Webographie/Bibliogrpahie......................... 50 16.2 Scripts et configurations................................ 50 Page 4

Première partie Introduction 5

Chapitre 1 Définitions Dans cette partie nous allons essayer d expliquer clairement les notions que nous allons aborder dans le reste du rapport. Cette partie fera également office de description des alternatives à la solution que nous proposons, nous en profiterons également pour faire le bilan de l état de l art actuel dans l industrie. 1.1 La disponibilité Ce mot n est pas présent dans l intitulé de notre sujet, il est pourtant sous-entendu et essentiel. Pouvoir gérer beaucoup de trafic (tenir la charge) ne doit pas être ponctuel, aujourd hui un service doit pouvoir être disponible en permanence ou à la demande. D où la nécessité de définir la disponibilité. La disponibilité d un équipement ou d un système est une mesure que l on obtient en divisant la durée durant laquelle l équipement est opérationnel et la durée pendant laquelle on aurait souhaité qu il le soit. Typiquement on calcule la disponibilité en divisant la durée effective de fonctionnement par la durée totale. Cependant en fonction du système considéré toutes les indisponibilités ne sont pas critiques. On peut penser aux arrêts planifiés, qui auront été anticipés et convenus entre client et fournisseur de service et dont l impact est souvent très faible. Ou les arrêts se produisant pendant les périodes de faible affluence (entre 2h et 4h du matin). On commence à considérer qu un système est très disponible à partir de 99,9% de disponibilité annuelle. Disponibilité en % Indisponibilité annuelle Indisponibilité mensuelle 95% 18,25 jours 36 heures 99,0% 3,65 jours 7,20 heures 99,9% 8,76 heures 43,2 minutes 99,99% 52,56 minutes 4,32 minutes 99,999% 5,26 minutes 25,9 secondes Table 1.1 Table d équivalence de disponibilité La formule généralement utilisé pour définir la disponibilité est la suivante : MT BF = MT T R + MT T F 6

disponibilité = MT T F MT BF MTBF pour Mean Time Before Failure, temps moyen avant la panne MTTR pour Mean Time To Repair, temps moyen pour réparer une panne MTTF pour Mean Time To Failure, temps moyen jusqu à la panne (aussi appelé fonctionnement normal) Table 1.2 Représentation disponibilité Où 0 représente un service indisponible, et 1 le service accessible. 1.2 Qu est ce que la très haute disponibilité? La haute disponibilité c est le principe qui consiste à rendre une application, un site web ou un service le plus disponible possible (en permanence si possible). Cela implique que le service web puisse répondre et se comporter conformément à ce qui est attendu dans un temps convenable, même si le trafic est important. On considère par exemple qu un site web ne doit jamais mettre plus de 3 secondes à répondre à une requête. Évidemment le ressenti pour l utilisateur sera grandement dépendant de la qualité de sa connexion à un internet, mais il faut rendre notre infrastructure suffisamment véloce pour que la latence induite devienne marginale. En fonction des moyens de l entreprise 1 et de l aspect critique ou non d un service et de la qualité de service que l on souhaite délivrer 2, il est évidemment possible de faire varier la tolérance de l indisponibilité. Pour réaliser cela, une infrastructure haute disponibilité doit être dimensionnée, pour pouvoir encaisser un trafic bien supérieur à son trafic nominal 3. 1. la disponibilité est pratiquement fonction des moyens investis dedans 2. Il est de notoriété publique que Free ne souhaite pas servir youtube.com de façon convenable, pour des raisons politiques et économiques 3. Dans notre rapport il ne sera pas question de résister à un DDOS sérieux, juste à un trafic inhabituellement élevé Page 7

L infrastructure doit également être conçue pour être le moins indisponible possible, cela sous-entend ajouter de la redondance partout où cela est nécessaire. Créer une infrastructure que l on puisse mettre à jour sans coupure de service (il n est même pas envisageable de pouvoir penser échapper aux mises à jour 4 ), répartir la charge autant que possible, prévoir la possibilité de passer à l échelle 5... Une infrastructure haute disponibilité nécessite des moyens matériels 6 importants, qui ne sont en pratique possible à mettre en œuvre que chez un hébergeur. Au niveau logiciel la mise en place doit être planifiée, car les technologies utilisées sont pointues et complexes à mettre en œuvre. Leurs configurations sont très liées aux machines sur lesquels elles se trouvent, cela nécessite une automatisation de l installation pour gagner du temps et éviter les erreurs. Dans ce projet nous n avons pas pour objectif de monter une infrastructure capable de contrer un gros DDOS. Nous verrons comment "mitiger", ce genre d attaque avec un firewall, mais pas comment arrêter les attaques les plus sérieuses, ce qui est à notre connaissance impossible 7. 1.3 Les architectures en couches L architecture en couche est un terme employé en architecture systèmes et réseaux. Ce terme désigne la forme que prend l implémentation d une architecture (l installation). Il existe plusieurs forme communes d architectures en couche, on choisira d en utiliser une plutôt en fonction de la complexité et de l isolation que l on souhaite donner à son infrastructure ainsi que la disponibilité potentielle. Avant même l architecture, le niveau 0 de l administration est de mettre tout sur un seul serveur : Ici toutes nos applications sont logées sur le même serveur ce qui présente pas mal d avantages. Facilité d administration (versions des logiciels, configuration etc...) car tout est sur la même machine, plus simple à sécuriser, une réduction exponentielle des points critiques. Cette architecture est souvent préférée par les toutes petites entreprises, les amateurs et plus globalement les gens disposant de peu de moyens. En revanche un de ses points faibles principaux c est bien évidemment l absence de redondance, et l impossibilité d en mettre. Architecture Monocouche L architecture monocouche est la plus simple des architectures sérieuses à mettre en place. La configuration est assez similaire à celle d un serveur seul mais avec une réplication, pour la sureté des données. On peut penser à l utilisation de pacemaker, pour répliquer l application métier. On voit dans l image la base de données externalisé ce n est pas forcément une nécessité, mais c est en général préférable. Un des inconvénients de l architecture monocouche est qu elle n est pas très scalable. Page 8

Table 1.3 Architecture Monocouche Table 1.4 Architecture à 2 couches Architecture à deux couches Ici on sépare différents composants de notre application dans le but d être encore plus scalable, (on peut dédier des machines à certains usages). Attention, toutes les applications ne sont pas forcément utilisables en mode cluster. Architecture multicouche Ici on a arrêté d essayer de compter les couches, on augmente le nombre de couche toujours dans le but de mieux répartir la charge. 4. il semble que de nombreuses banques ne possèdent pas vraiment d infrastructure haute disponibilité 5. scalabiliser 6. abordé de manière très parcellaire dans ce rapport, la description exhaustive d une infrastructure matérielle dépasse le cadre de notre étude 7. blackholing BGP en dernier recours Page 9

1.3.1 SPOF Table 1.5 Architecture multicouches SPOF est un terme anglais Single Point Of Failure signifiant point unique de défaillance. C est un terme courant servant à qualifier une faiblesse dans l architecture. L objectif est toujours d éviter d avoir un SPOF, c est malheureusement rarement possible, et extrêmement coûteux. La remonté du SPOF Il est possible d éliminer un point de défaillance, mais souvent, le problème est le même sur la couche supérieur. Un exemple pour mieux comprendre. Pour éviter une indisponibilité je décide de prévenir la panne de disque dur. Je mets en place un système de RAID1 qui préservera l intégrité de mes données et permettra une continuité de service. Cependant ce système se révèlera inopérant si un problème électrique survient, on peut imaginer que mon alimentation (pourtant gold) décide subitement de ne plus fonctionner. On peut anticiper le problème en mettant en place une alimentation redondante. Dans ce cas-ci nos précautions actuelles ne pourraient en revanche rien contre une défaillance de la distribution électrique (un arbre qui tombe sur une ligne électrique). Ce problème pourrait être réglé par la mise en place d un onduleur et d un générateur (diesel par exemple). On pourrait évidemment citer l exemple de la pelleteuse qui arrache notre fibre, etc.. la liste est sans fin. Mais on voit bien que plus on remonte la chaine moins les défaillance sont de notre ressort, certaines grandes entreprises avec des moyens quasiment illimités ont pris les devant en construisant leur propres centrales électriques (google par exemple). D autres problèmes rentrent également en ligne de compte les peerings, une requête BGP malencontreuse, une catastrophe naturelle etc.. La chasse au SPOF a de quoi rendre paranoïaque. À noter que dans notre architecture plusieurs points peuvent être défaillantes comme l alimentation électrique ou bien notre load balancer/reverse proxy, ou même notre DNS. Page 10

Chapitre 2 Objectifs 2.1 Nos objectifs Dans ce projet nous avions pour objectif, de comprendre, tester et réaliser une architecture haute disponibilité orientée pour des besoins web. En concertation avec notre tuteur de projet nous avons décider d expérimenter plusieurs technologies et de choisir celle qui nous paraissait la meilleure. Pour réaliser nos choix nous nous sommes basés sur nos tests, les conseils de notre tuteur et la littérature disponible sur le sujet. Dans la mesure du possible nous avons essayé de réaliser nos installations sur les futurs standards : les versions testing/dev des logiciels. 2.2 La stack logicielle Une stack logicielle est un terme employé pour désigner un ensemble qui interagissent ensemble afin de réaliser un objectif. Un ensemble de logiciels acquière généralement le titre de stack lorsque ce groupe devient une sorte de standard utilisé de façon normalisé dans l industrie pour des besoins spécifiques. On peut par exemple penser à la célèbre stack LAMP : Linux Apache Mysql Php. Cette dernière bien qu éprouvée et très stable présente quelques problèmes de performances on lui préfèrera du LHANPP : Linux HAProxy Nginx Percona PHP (Percona utilisant Mysql nous aurions pu dire MySQL à la place). Il est à noter que dans une stack chaque composant réalise généralement une tâche spécifique, généralement celle qu il réalise la mieux. Nous verrons plus tard que Nginx peut faire load balancer, mais ses performances sont moins intéressantes que HaProxy, il ne sera donc pas utilisé dans ce cadre. 2.2.1 Load balancing L une des techniques de base pour permettre de la haute disponibilité est d avoir plusieurs serveurs et de répartir la charge sur ces machines. L idéal étant évidement d avoir un nombre de machines suffisant pour permettre de tenir la charge, malgré l indisponibilité de certaines. 11

2.2.2 Reverse Proxy Un serveur proxy sert généralement à un ou plusieurs utilisateurs à aller sur internet, le reverse proxy permet l inverse c est à dire aux clients/utilisateurs venant par exemple d internet d accéder à un service/contenu local. 2.2.3 Cache Le principe du cache est d enregistrer en mémoire une requête récurrente afin de pouvoir la servir lors d une demande ultérieur sans avoir à recalculer cette requête ou demande. Le cache peut physiquement, s enregistrer sur le disque dur ou bien s enregistrer sur la mémoire RAM. On choisira la meilleur solution en fonction de nos contraintes techniques et de nos besoins. Le cache peut se situer à plusieurs endroits, il est possible de faire un cache HTTP en cas de demandes nombreuses sur une page, on peut également faire du cache de requête SQL ou de code php compilé. 2.3 Complexification de la stack Nous avons dit ne pas vouloir utiliser la stack LAMP pour cause de manque de performances (et parce que ce n était pas notre sujet). Mais un des problèmes de ne pas utiliser une stack standard c est qu elle n est pas aussi éprouvée, qu il y a moins de support et donc généralement plus de problèmes. LAMP est également ce qu on peut appeler une stack simple, un système d exploitation un serveur web, une base de données, un langage interprété. Plus on ajoute des outils, des couches à notre stack plus les choses peuvent mal tourner. Pour avoir quelque chose de maintenable dans le temps il est important de garder quelque chose de relativement simple et si possible dont l entièreté est compréhensible par plusieurs personnes (documentation!). Mais comme expliqué quelques paragraphes au-dessus notre objectif est également d améliorer les performances. La difficulté dans ce genre d architecture est de maintenir l équilibre entre quelque chose de suffisamment performant et bleeding edge et quelque chose de stable et utilisé. Page 12

Chapitre 3 Outils Dans cette partie nous allons présenter les outils que nous avons choisi, testé et choisi d utiliser ou non. 3.1 Debian GNU/Linux Debian ce choix était un souhait de notre tuteur, c est une distribution robuste que nous utilisons quotidiennement dans notre formation. Aprécié en entreprise du fait de son excellence technique meme si on lui préfère souvent les RHEL-like du fait de leur support et ou proximité avec RHEL qui dispose d un support technique. PLEINS d outils tunning du noyau! mais pas que! 13

Deuxième partie Étude 14

Chapitre 4 LXC LXC pour Linux Containers, est un logiciel de virtualisation développé depuis les années 2008 en C, Python, lua, Go, Ruby et Haskell. LXC est aujourd hui en version 1.1.0 et est activement développé principalement par les entreprises Parallels, IBM, Google, et par les développeurs Eric Bierderman, Daniel Lezcano, Serge Hallyn et Stéphane Graber. Ce logiciel est parfois utilisé en tant qu interface pour le logiciel Docker pour pouvoir interagir avec les différents conteneurs sur le système. 4.1 Particularités Pour isoler les différents systèmes d exploitation, LXC utilise les fonctionnalités du kernel Linux introduites dans la version 2.6.24 - les cgroups Les machines virtuelles sont des conteneurs isolés du système d exploitation hôte et agissent comme une machine physique. Tous les conteneurs vont utiliser le kernel du système hôte, et donc ne peuvent s agir de distributions utilisant le kernel Linux. 4.1.1 Cgroups Cgroups ou Control Groups est une fonctionnalité du kernel Linux qui va permettre de limiter l accès au ressources d un groupes, de prioriser un groupe plutôt qu un autre à accéder aux ressources de la machine, mesurer combien de ressources utilise un groupe et le contrôler en manipulant les processus du groupe (freeze - unfreeze). Le développement de la fonctionnalité cgroups a débuté en 2006 principalement par les ingénieurs de Google Paul Menage et Rohit Seth sous le nom de process containers. Il a été renommé sous le nom de control groups à cause de la confusion lors de l utilisation du mot conteneur dans le kernel Linux. 4.2 Avantages des conteneurs sur les machines virtuelles Un conteneur ne va utiliser que les ressources qui lui sont nécessaires pour le fonctionnement de ses processus. Une machine virtuelle possède des ressources allouées par défaut et n utilise pas forcément toutes les ressources tout le temps. On va pouvoir contrôler les conteneurs depuis le système hôte : Un conteneur dont les services ne sont pas utilisés ne vont pas consommer de ressource jusqu à ce qu on lui demande une requête. 15

En revanche, une machine virtuelle, même si ses ressources ne sont pas sollicités, lui sont toujours réservées et ne peuvent pas être réquisitionnées par un autre service qui aurait besoin de ces ressources. 4.3 Configuration de LXC Sur Debian Jessie (8), l installation se réalise par la commande apt-get install lxc. LXC ne peut s utiliser par défaut que par l utilisateur root. Les dossiers des conteneurs se trouvent dans /var/lib/lxc. Un lxc-ls affichera également le contenu du dossier, n affichant que les conteneurs. Pour installer un nouveau conteneur, on va utiliser un template stocké dans /usr/share/lxc/- templates. Les templates vont nous permettre d installer la distribution de notre choix parmis les choix disponible dans la liste. Table 4.1 Représentation disponibilité Il ne s agit pas du seul moyen d installer un nouveau conteneur. Il existe des conteneurs déja prêt à l utilisation sur le site http ://www.flockport.com. Le site nous propose des conteneurs avec des services pré-installés directement prêt à l utilisation. Les templates vont se charger de télécharger les paquets nécessaires s ils n ont pas déjà été téléchargés sur le système. Dans le cas où on veut faire une modification sur le template utilisé, il faudra supprimer le cache du template afin de récupérer le nouveau. Par défaut, le template debian ne contient pas de logiciel d édition de texte, on pourra rajouter un éditeur dans la liste des paquets à télécharger. Le dossier contenant le cache est /var/cache/lxc. Lorsqu un conteneur est créé, on va pouvoir accéder à son fichier de configuration via le chemin /var/lib/lxc/nomconteneur/config 4.3.1 Flockport Flockport est un site communautaire qui propose librement des conteneurs prêt- à-l emploi. Il suffit juste de télécharger le conteneur, décompresser l archive sur le système hôte et de lancer le conteneur via la commande lxc-start -n conteneur. 4.4 Fonctionnement de LXC Pour créer un conteneur, on va utiliser la commande lxc-create avec les arguments -t pour choisir la distribution à installer sur le conteneur et -n pour choisir le nom du conteneur. Une fois le template exécuté, on va pouvoir lancer le conteneur avec la commande lxc-start avec les arguments -d pour dispatch, c est à dire que le conteneur ne sera pas lié à la console avec laquelle on démarre notre conteneur, et -n pour spécifier le nom du conteneur que l on veut démarrer. Pour se connecter au conteneur, on va utiliser la commande lxc-console avec l argument -n pour spécifier le nom. Page 16

Table 4.2 Représentation disponibilité Pour revenir au système hôte lorsque que l on s est connecté au conteneur via lxc-console, on utilisera la combinaison de touches Ctrl+A Q. Pour arrêter un conteneur depuis le système hôte on utilisera la commande lxc-stop avec -n pour le nom. Pour supprimer un conteneur on utilisera la commande lxc-destroy -n. Page 17

Chapitre 5 HA-Proxy HAProxy pour High Availabitlity Proxy, est un reverse proxy développé depuis les années 2000 en C "événementielle". Son auteur est le français Willy Tarreau également développeur du noyau Linux. HA Proxy est réputé extrêmement stable, c est une qualité très appréciable pour un logiciel de production, ça l est d autant plus lorsque le dit logiciel est votre tête de pont. Celui qu il est potentiellement visible et coûteux de mettre à jour, dans la mesure où cela est simplement envisageable. Ce logiciel est actuellement en version 1.5.11 et toujours activement développé. La principale utilité d un reverse proxy est évidemment de faire office de load balancer. Dans ce domaine les performances de HAProxy font références tant par leurs résultats impressionnants, que la modestie du matériel nécessaire pour les obtenir 1. C est donc logique qu il soit abondamment utilisé par les grands consommateurs de bande passante que sont les géants du web 2.0 2. 5.1 Modes de fonctionnement HAProxy dispose de deux modes de fonctionnement, un mode fonctionnant sur la couche 4 du modèle OSI, la couche transport, agissant donc au niveau du protocole TCP. Et un mode fonctionnant au niveau applicatif sur la couche 7 du modèle OSI, sur le protocole HTTP. Comme on peut s en douter, gérer le trafic au niveau TCP est bien moins coûteux en temps processeur que de le faire au niveau HTTP. Une estimation grossière envisage à environ 50% le coût de l overhead, ce qui est relativement acceptable. De plus utiliser HAProxy en mode TCP pourrait poser des problèmes de traduction d adresse IP. Mais ces problèmes ont été résolu de façon élégante par les ingénieurs développant HAProxy 3. L utilisation du mode TCP nous permet également d éviter des soucis de sécurité et de répartition de charge avec les sessions SSL/TLS. Nous avons parlé quelques lignes auparavant de l overhead de HTTP qui est loin d être négligeable en cas de fort trafic. Il parait donc logique de faire les choses bien, dès le début et d utiliser le mode TCP. Mais un lecteur éclairé s interrogera cependant sur le comportement de certaines applications qui ont besoin de communiquer directement, avec leurs clients. Ce problème, classique aux infrastructures disposant de proxys, a été résolu depuis longtemps par l introduction d un en-tête dans le protocole HTTP "X-Forwarded-For". 1. Saturer un lien 10Gbps avec < 20% d utilisation d un CPU de bureau, AVEC jumbo frames 2. Reddit, Twitter, GitHub etc... 3. création d un protocole spécifique, on en parle juste après 18

Catastrophe, pensez vous? Et bien non. HAProxy à mis en place son propre protocole, originalement nommé PROXY protocol. Ce dernier ajoute une "adresse distante" aux paquet TCP adressé à une machine. Cependant pour être utilisé il faut que PROXY protocol soit supporté par le serveur HTTP, c est heureusement le cas de Nginx, de plus cela se configure assez aisément, ce sera expliqué plus bas. Il n y a donc pas de raison de ce coté-ci pour ne pas gagner des performances en utilisant le mode TCP. Deuxièmement il y a le problème des sessions SSL/TLS. De nos jours il est extrêmement rare de pouvoir se passer de négociation SSL/TLS. Elles sont indispensables à la confidentialité des échanges sur internet, que ce soit pour protéger les conversations, les mots de passe, ou bien les transactions. Si on utilisait un reverse proxy de niveau 7 il faudrait que toutes les négociations SSL 4 soient gérer en un même point (techniquement pas forcément, on peut et on doit avoir plusieurs reverse proxy de front, notion expliquée auparavant). La machine finira fatalement par être surchargée, alors qu on peut faire participer toute les machines du cluster à l effort. De plus cela devrait poser un problème majeur de confidentialité et de sécurité aux clients/utilisateurs soucieux de leur vie privée/secret industriels. En effet si la négociation SSL se termine à la porte du/des Proxy, cela signifie que tout ce qui se passe derrière se passe en clair. Cela permet à une personne mal intentionné dans l entreprise d espionner les trafic des clients. Dans le cas où un intrus aurait réussi à pénétrer notre infrastructure il lui suffirait d espionner le trafic à la sortie du reverse proxy, en utilisant par exemple wireshark ou autres. En résumé, NOUS n avons pas de raison d utiliser autre chose que le reverse proxy de niveau 4 de HAProxy. 5.2 Prendre la température de sa machine Pour savoir comment répartir la charge, avant même de parler d algorithme de répartition de charge il faut d abord vérifier que nos serveurs sont à même de pouvoir répondre. Ce procédé s appelle le health check, qu on pourrait traduire grossièrement par vérification de santé, mais qui en faite devrait plutôt être traduit par preuve de vie. Contrairement à plein d autres load balancer, HAProxy permet de faire des vérification au niveau applicatif, en vérifiant qu une valeur de retour 200 est bien reçu après envoi d une requête. Ce test, bien que simple est en général suffisant pour vérifier que le serveur HTTP ne déraille pas complètement et est bien plus probant qu un simple ping qui par exemple ne détecterait pas une erreur 50X. 5.3 Les algorithmes de répartition HAProxy dispose de plusieurs algorithmes de répartition de charge. Tous ne seront pas utiles à notre utilisation mais il est intéressant de savoir que HAProxy est très généraliste et qu il ne gère donc pas que des algorithmes pour la répartition de charge pour l hébergement web. Les deux premiers algorithmes sont sans doute ceux que nous seront les plus susceptibles d utiliser, ce sont aussi les plus simples à comprendre. 4. on va dire SSL pour toutes mentions faites de SSL/TLS, sauf indication contraire Page 19

5.3.1 Round Robin Table 5.1 Fonctionnement avec mode TCP Aussi appelé l algorithme tourniquet. C est le moins consommateur en CPU et le plus simple, ici on a une liste de serveurs web (ou d IP), à chaque nouvelle requête, on prend le suivant. (remarque : l algorithme est en faite un peu plus complexe et il est possible de pondérer l importance des serveurs, afin que les plus gros servent le plus de requêtes. Il est possible de modifier la pondération en cours d utilisation (on the fly) cependant cette fonctionnalité implique une limite au nombre de serveurs que peut comporter la ferme (2 12-1 d après la documentation) La répartition se fait donc naturellement de façon très efficace, cet algorithme peut cependant montrer ses limites notamment dans le cas de temps de connexion très hétérogènes. Il existe une variante à cet algorithme appelé static-rr, ici la pondération existe mais n est pas modifiable à la volée. En revanche il n y a plus de limitation du nombre de serveurs que peut contenir notre ferme. L algorithme est aussi très légèrement plus efficace. 5.3.2 Leastconn Comme son nom l indique, le serveur avec le moins de connexions reçoit la connexion. Pour garantir que tous les serveurs seront utilisés, les serveurs sont automatiquement regroupés en fonction de leur charge. Un round robin est effectué dans ces groupes présentant des charges similaires. Cet algorithme s adresse particulièrement pour les applications ayant de très longues (en temps) requêtes : LDAP, SQL (certaines requêtes SQL, ou création d index peuvent durer des heures). Il est en général moins indiqué Page 20

Table 5.2 Fonctionnement avec mode HTTP pour les requêtes courtes comme HTTP. Cet algorithme est également dynamique, on peut donc faire varier la pondération des serveurs à la volée. 5.3.3 First Cet algorithme répartit la charge d une façon originale, puisque ici l objectif est de saturer les serveurs de connexions. Plus exactement vous définissez un nombre maximum de connexion possible sur le serveur, lorsque ce nombre est atteint on passe au serveur suivant. Les connexions sont adressées en fonction de l id du serveur. Cet algorithme, qui semble être l antithèse de notre objectif, a une utilité bien spécifique. Économiser de l énergie pendant les périodes non critiques, par exemple la nuit il peut être envisageable d éteindre une partie de notre ferme de serveur. Pour utiliser cet algorithme efficacement, il est conseillé de monitorer les serveurs non utilisés pour les éteindre lorsqu ils ne sont pas nécessaire et au contraire d en rallumer lorsque le temps de traitement des requêtes commence à s allonger ou n importe quel autre signe extérieur. 5.3.4 Source Cet algorithme essayera de toujours fournir le même serveur à un IP donnée, cela peut être utile pour effectuer des tests (de charge, de fonctionnalité, etc...) sur la ferme de serveurs. Cela peut aussi être utilisé pour permettre aux clients ne souhaitant pas utiliser de cookies de réutiliser leur session sur un serveur particulier. Cet algorithme est statique, pas de changement de pondération à la volée. Page 21

5.3.5 uri Cet algorithme est plus complexe, il hash l uri (ou un partie, c est paramétrable), la même requête (hash) sera toujours aiguillé vers le même serveur (si ce dernier reste allumé). Ce procédé est utilisé pour permettre des analyses antivirus (ça doit également être utile pour éviter les injections SQL) Ou encore optimiser le cache. Cet algorithme est statique, on peut également paramétrer la longueur du hash et la profondeur maximum jusqu à laquelle on hashera l uri (le nombre de slash). Et de nombreux autres dont nous ne feront pas la liste exhaustive ici. 5.4 Interface d administration HAProxy dispose de deux interfaces d administration communes : une interface web, une interface CLI, les deux proposent grossièrement les mêmes informations. État des serveurs front-end, taux d utilisation, disponibilité, nombre de sessions etc... L interface CLI, hatop permet également ajouter ou de retirer des serveurs à notre pool de load balancer. ajout de deux images 5.5 Avantages sur Nginx TODO Nginx peut faire office de reverse proxy, cependant n étant pas dédié à cela 5.6 Avantages sur Varnish TODO Page 22

Chapitre 6 Collectd 6.1 Présentation Collectd est un démon qui permet de récupérer les statistiques de performance périodique d un système et qui prévoit aussi des mécanismes qui permettent de stocker les valeurs en format de fichier RRD. Il a été écrit en juillet 2005 par Florian Forster, à l heure actuelle, Collectd est toujours en développement et la dernière version stable sortie est la version 5.4.1 (26 janvier 2014). De plus il est écrit dans le langage de programmation C et il est sous la licence GNU (GPL v2). 6.2 Principe du logiciel Collectd permet de recueillir plusieurs statistiques sur le système. Les utilités de ces informations est de pouvoir déceler des goulots d étranglements actuels, de prévenir les charges systèmes et de maintenir une vue d ensemble sur les ressources disponibles. Nous pouvons voir ici en exemple un graphique qui montre l utilisation du processeur par l utilisateur et les différents services. Cette image illustre les ressources du CPU 1 en utilisation par l utilisateur. 6.2.1 Pourquoi utiliser Collectd? Tout d abord il est important de souligner, comme d autres projets Collectd est un logiciel open source et gratuit, mais pourquoi choisir Collectd plutôt qu un autre logiciel du même type? C est ce que nous allons essayer de démontrer. De plus Collectd est développé avec le langage C pour un souci de performance et de portabilité, en effet cela lui permet de fonctionner sous tous les systèmes Unix sans à avoir à installer de scripts. L une des forces de collectd est qu il est "livré" avec un peu plus de 90 plugins ce qui permet d avoir une utilisation et des graphiques standard ou alors au contraire des graphiques très spécialisé pour une utilisation avancé. 6.3 Exemple de plugins CPU : Calcule le pourcentage d utilisation des CPU Network : Calcule le pourcentage d utilisation du réseau Memory : Calcule le pourcentage d utilisation de mémoire par l utilisateur De plus, il fournit de puissantes fonctions pour "surveiller" le réseau et de plus, extensibles de bien des façons. Il est très facile de choisir les plugins que l on veut utiliser ou non. 23

Table 6.1 Représentation disponibilité Pour finir il est important de souligner que Collectd a une communauté active et bien soutenue avec en plus une documentation importante et surtout de qualité. 6.4 Les points forts de Collectd La portabilité : Collectd peut être en effet installé sur une multitude de systèmes comme Solaris, Mac OS X ou encore sur FreeBSD (il est même possible d avoir une prise en charge de Collectd sur Windows qui est fourni par SSC Serv ). Une configuration facile : Collectd est facilement configurable, en outre les modules à charger il n est pas nécessaire de configurer quoi que ce soit d autre. Une grande aide : les administrateurs systèmes peuvent utiliser Collectd sur n importe quel nombre d ordinateurs (de un à plusieurs centaines ). Extensions personnalisées : il existe plusieurs moyens pour étendre les fonctionnalités de Collectd pour répondre à des besoins précis, il y a comme C-plugins qui permet de charger le daemons directement. 6.5 Installation de Collectd Après la présentation, il est temps de passer à l installation du logiciel : Tout d abord il faut installer les paquets essentiels sur le système où on se trouve. Pour cela : apt-get install build-essential. Si lors de l installation groupement de paquets, on peut choisir d installer les librairies unes à unes : Par exemple : apt-get install librrd2-dev libsensors-dev libsnmp-dev... Bien sûr l installation de Collectd est très facile : apt-get install collectd Un des nombreux avantages de Collectd est qu il permet d installer des utilitaires pour améliorer son utilisation. Par exemple Kcollectd. Il reprend les résultats de Collectd mais utilise une interface KDE, Nous allons voir son installation (simple un peu plus tard). Page 24

6.6 Configuration de Collectd Nous allons à présent voir comment configurer Collectd en fonction des besoins de l utilisateur. Mais avant voici un petit exemple sur le nombre de plugins de Collectd. Table 6.2 Représentation disponibilité Page 25

L administrateur système a à sa disposition un grand nombre de plugins pour pouvoir répondre à ces attentes. L administrateur système peut aller à tout moment changer le nombre de plugins utilisés c est l une des forces de Collectd car il est simple d utilisation et surtout de configuration. Pour configurer les plugins il faut éditer le fichier.conf de Collectd avec la commande suivante : vi etc/collectd/collectd.conf Suite à cette commande l administrateur doit avoir ce résultat ci : Table 6.3 Représentation disponibilité L administrateur peut alors choisir les plugins qu il veut utiliser. Pour cela il n a qu à décommenter la ligne avec le plugin voulu, par exemple sur l image ci-dessus l option LoadPlugin cpu et LoadPlugin disk sont décommentés, donc lors de la prochaine collecte d informations et de statistiques Collectd prendra l utilisation du CPU et des Disques Durs en compte. Pour que les changements soient pris en compte il faut pour cela relancer le service de Collectd avec la commande suivante : collectd restart. 6.6.1 Configuration d un serveur Il est en effet possible pour l administrateur de configurer Collectd pour que celui-ci "écoute" une machine en particulier pour pouvoir voir les ressources utilisées par les noeuds. Pour le serveur, il faut nous assurer que ces modules sont bien activés (donc décommentés) : Comme pour la configuration de la machine au dessus il faut éditer le fichier de configuration qui se trouve dans /etc/collectd/collectd.conf. Page 26

Pour le serveur on décommente donc les plugins pour le réseau : LoadPlugin "logfile" LoadPlugin "network" LoadPlugin "rrdtool" Ensuite nous allons (sur la machine qui va servir de serveur) entrer son adresse IP dans le fichier de configuration de Collectd : Table 6.4 Représentation disponibilité Après avoir fait cela il faut entrer pour les noeuds l adresse du serveur. Page 27

Table 6.5 Représentation disponibilité Page 28

Chapitre 7 Munnin Munin est un outil de surveillance système et réseau open source sous licence publique générale GNU. Il s appuie sur l outil RRDTool. Il présente ses résultats sous forme de graphiques disponibles via une interface web. Il possède une structure de plugins particulièrement simple qui permet d enrichir rapidement l outil. Des plugins sont actuellement disponibles pour les systèmes d exploitation suivants : GNU/Linux, FreeBSD, NetBSD ou encore Solaris. 7.1 Fonctionnement L architecture du système Munin est constituée d un serveur principal appelé Munin-master, récupérant les informations à intervalle régulier et de plusieurs nœuds appelés Munin-node. Le nœud doit être installé sur le ou les serveurs à surveiller. En effet, munin permet de générer une série de graphes à partir des informations reçues par les autres machines par exemple l utilisation de la mémoire vive, l usage CPU, réseau,... De plus il permet même d envoyer des alertes par mail ou d envoyer ses alertes vers Nagios. Munin fonctionne sur le modèle client-serveur. En effet, un petit démon tourne sur chacune des machines devant être surveillée (ici munin-node). Ce démon fournit les informations concernant la machine dès que le grapheur (la machine maitre munin) les lui demande. Par exemple avec Munin il est possible de surveiller plusieurs types de composantes d une ou plusieurs machines : Les disques durs : accès, usage, latence, uptime. Les processus : nombre, activité. Le réseau : nombre d erreurs, trafic, requêtes. Les capteurs : températures des composants (Disque dur, processeur...). A COMPLETER 29

Chapitre 8 Apache2 30

Chapitre 9 Nginx Nginx [engine x] est un logiciel libre de serveur Web (ou HTTP) ainsi qu un proxy inverse écrit par Igor Sysoev, dont le développement a débuté en 2002 pour les besoins d un site russe à très fort trafic. Nginx est écrit en C et la dernière version stable de cette solution est la version 1.6.2 9.1 Nginx en quelques points 9.1.1 Un serveur asynchrone Nginx est un serveur asynchrone par opposition aux serveurs synchrones où chaque requête est traitée par un processus dédié.en effet Nginx utilise les changements d état pour gérer plusieurs connexions en même temps, de plus pour tirer parti des ordinateurs multiprocesseurs, plusieurs processus peuvent être démarrés. Ce choix d architecture se traduit par des performances très élevées, mais également par une charge et une consommation de mémoire particulièrement faibles comparativement aux serveurs HTTP classiques, comme Apache. 9.1.2 Modularité En effet, Nginx est très modulaire : un noyau minimal et des modules, nombreux, venant compléter les fonctions de base. Chaque module peut agir comme un filtre sur le contenu en entrée, en sortie ou intermédiaire (proxy) par le biais de nombreuses callbacks. Ces modules sont liés au serveur lors de la compilation. 9.1.3 Optimisations Le noyau d Nginx s appuie sur des structures de données minimales, mais celle-ci sont optimales, visant à réduire le nombre d appels système, en particulier pour tout ce qui a trait à l allocation de mémoire. De différents mécanismes de signalisation peuvent être utilisés afin d exploiter au mieux le système d exploitation. L architecture asynchrone soulage l ordonnanceur du système d exploitation et favorise l utilisation des caches du ou des processeurs. A noter que si vous ne souhaitez pas migrer entièrement votre architecture web, il est également possible d utiliser Nginx en complément d Apache comme simple proxy de cache. 9.1.4 Nginx et ses extensions Dépourvu de surplus Nginx regorge néanmoins de modules et d addons qu il est possible d intégrer (ou d enlever) lors de la l installation de votre serveur web. Au total une cinquantaine d extensions, 31

officielles ou non, qui permettent de configurer Nginx à vos besoins comme par exemple : Le support SSL indispensable si vous êtes dans l e-commerce Stub Status pour se connecter avec des outils de monitoring comme Munin Perftools pour le support du service Google Performance Tools La pré compression gzip, les etags pour contenus statiques et dynamiques Une ribambelle de modules pour profiter au mieux de Memcached 9.1.5 Nginx en quelques chiffres Pour bien comprendre l évolution de l utilisation de Nginx en dans le monde voici quelques chiffres sur le nombre de domaines gérés par Nginx, de plus il est important de noter que ce chiffre en question est en constante augmentation. En juin 2007, Google le considérait comme le 3e serveur (4% d utilisation) parmi les serveurs web les plus fréquentés, après Apache (66%) et IIS de Microsoft (23%). En novembre 2010, Nginx est d après Netcraft le troisième serveur le plus utilisé sur les sites web mondiaux avec 6,04% de part de marché, derrière les 22,70% d IIS et les 59,36% d Apache. En juillet 2011, ces chiffres restent globalement stables : 64,66% pour Apache, 16,82% pour IIS, 6,55% pour Nginx, 4,61% pour Google Web Server. En janvier 2012, Nginx dépasse légèrement IIS, avec 12,18% contre 12,14%. En avril 2013, Nginx continue sa progression, avec 12,91% des sites actifs. Alors que Apache passe à 54,37%. IIS reste stable à 12,13% et Google Web Server passe à 8,12% PARTIE À REPRENDRE ENTIÈREMENT Page 32

Chapitre 10 Joomla PARTIE SUR JOOMLA à faire 33

Chapitre 11 Mysql et Percona 11.1 MySQL MySQL est un système de gestion de bases de données relationnelles (ou SGBDR). De plus cette solution est distribuée sous une double licence GPL et propriétaire. Il fait partie des logiciels de gestion de base de données les plus utilisés au monde, que ce soit par le grand public (applications web par exemple) que par des professionnels, MySQL est en concurrence avec Oracle, Informix et Microsoft SQL Server. MySQL AB a été acheté le 16 janvier 2008 par Sun Microsystems pour un milliard de dollars américains. En 2009, Sun Microsystems a été acquis par Oracle Corporation, mettant entre les mains d une même société les deux produits concurrents que sont Oracle Database et MySQL. MySQL peut donc s utiliser seul, mais est la plupart du temps combiné à un autre langage de programmation : PHP par exemple pour de nombreux sites web, mais aussi Java, Python, C++, et beaucoup, beaucoup d autres. De plus MySQL bénéficie d un large public, car : Il est facile à comprendre : Sa syntaxe simple en fait un langage facile à comprendre pour les programmeurs et des débutants. Le Langage est fonctionnel : MySQL fonctionne sur de nombreuses plates-formes différentes. Dispose d une vaste bibliothèque de fonctions et d API : API pour C, C++, Eiffel, Java, Perl, PHP, Python, Ruby et Tcl sont disponibles. Les fonctions SQL sont mises en place en utilisant une bibliothèque de classes optimisées. Multi Thread : complètement multi-thread utilisant un noyau de threads. Haute capacité de storage : pour vous donner une idée, de grosses entreprises actuelles utilisent le serveur MySQL avec plus de 100 000 tables et 1 000 000 000 d enregistrements. 11.1.1 Pourquoi utiliser le fork de Percona pour MySQL? Tout d abord un peux d histoire, Percona est une société de logiciels spécialisée dans MySQL, Consulting, Managed Services, et de la formation. La société a été fondée en 2006 par Peter Zaitsev et Vadim Tkachenko et est basée à Durham, Caroline du Nord. La société a lancé un service de sauvegarde MySQL en Juin 2014 comme partie de ses Managed Services. La société contribue à la communauté MySQL par le biais de son site de blog, le blog de performance MySQL. La société accueille également des conférences annuelles de l utilisation MySQL nommé "Percona Live" dans la Silicon Valley et à Londres. Les fondateurs de l entreprise ont également publié le livre O Reilly "High Performance MySQL". Mais que rajoute ce fork pour MySQL? Pour commencer sans "tunning" du fork aprés son installation nous avons : 40% de performance (en rapidité). Plus de cohérence et de performance générale que les serveurs MySQL seuls. 34

Percona inclue XtraDB qui est un fork de InnoDB, celui-ci offre une meilleures utilisation de la mémoire. Percona offre aussi plus d options de réglage ce qui donne encore plus de contrôle. Table 11.1 Comparatif de MySQL et Percona Dans ce projet nous avons utilisé cette technologie, en effet nous avons utilisé Percona XtraDB Cluster pour le clustering des serveurs MySQL et donc par ce biais la réplication des bases de données. En effet avec Percona XtraDB Cluster nous avons réussis à mettre en place un cluster de 3 serveurs de bases de données avec la réplication des données. de ce fait même si un ou deux serveurs sont amener à "tomber", les bases de données seront toujours disponibles, ainsi les applications seront toujours disponibles. 11.1.2 Etapes d installation de Percona XtraDB Cluster Quelques points avant l installation de Percona, Percona prend en supporte les architectures suivantes : x86-64 (amd64) x86 Ce logiciel est compatible avec les systèmes suivants : Debian : 6.0 squeeze 7.0 wheezy Ubuntu : 10.04 LTS lucid 12.04LTS precise 13.10 saucy 14.04 LTS trusty Pour commencer l installation, il faut en premier lieu ajouter les clés pour cela il faut faire : apt-key adv keyserver keys.gnupg.net recv-keys 1C4CBDCDCD2EFD2A Page 35

Ou bien alors ajouter les sources à la main dans /etc/apt/sources.list deb http ://repo.percona.com/apt VERSION main deb-src http ://repo.percona.com/apt VERSION main Ensuite il faut faire la commande suivante : apt-get update Suite à ces commandes nous pouvons passer à l installation de Percona XtraDB Cluster, pour se faire rien de plus simple : sudo apt-get install percona-xtradb-cluster-55 Pour Ubuntu 14.04 ce sera : sudo apt-get install percona-xtradb-cluster-55 percona-xtradb-cluster-galera-2.x 11.1.3 La configuration du cluster Suite à l installation de Percona XtraDB Cluster il faut faire la configuration des noeuds, pour se faire il faut configurer chaque noeud un à un. Voici les noeuds pour notre configuration : Table 11.2 Machines utilisées pour notre cluster Pour la configuration des noeuds il faut modifier le fichier suivant : /etc/mysql/my.cnf Donc ensuite avec votre éditeur de texte préféré il faut modifier my.cnf. Pour commencer voici un exemple de configuration pour notre noeud N 1 : Après avoir modifié my.cnf il faut redémarrer le service avec la commande suivante : /etc/init.d/mysql bootstrap-pxc en plus de redémarrer le service, cette commande initialise le cluster. Ensuite nous allons vérifier le statut du cluster dans MySQL avec la commande suivante : show status like wsrep% ;. Nous devons avoir Page 36

Table 11.3 Configuration du noeud 1 Page 37 un résultat comme celui-ci : Puis

ensuite il faut ajouter des droits pour que les prochains noeuds puissent avoir les mêmes droits que le premier noeud. Pour cela il faut créer un user, ici nous allons prendre pour exemple les commandes utilisées lors de cette création de user. Donc nous avons : 1. CREATE USER root @ giroud4.asrall.iutnc.univ-lorraine.fr IDENTIFIED BY pomme ; 2. ensuite il faut attribuer les droits et la réplication : GRANT RELOAD, LOCK TABLES, REPLICATION CLIENT ON *.* TO root @ giroud4.asrall.iutnc.univ-lorraine.fr ; 3. Et maintenant il lui faut tous les prévilèges : FLUSH PRIVILEGES ; Ensuite, après avoir attribué les droits au nouvel utilisateur, il faut maintenant configurer le noeud 2. Comme le premier noeud il faut modifier le fichier my.conf. Voici la configuration du noeud 2 : Après avoir configuré le noeud 2 il faut relancer le service comme ceci : /etc/init.d/mysql start. Puis Table 11.4 Configuration du noeud 2 comme le noeud 1 nous allons vérifier le statut du cluster toujours avec la commande : show status like wsrep% ; (dans MySQL).Et nous avons donc Nous pouvons donc voir que le noeud N 2 fait maintenant parti du cluster! Ensuite pour le dernier noeud (le N 3) nous allons une nouvelle fois modifier le fichier de configuration my.conf. Notre configuration pour le noeud 3 est la suivante : Puis comme pour le noeud précédent il faut relancer le service avec une nouvelle fois la commande /etc/init.d/mysql start Puis après nous allons faire une ultime vérification pour voir si la noeud N 3 est bien intégré dans le cluster avec la commande show status like wsrep% ; Après cette dernière vérification nous pouvons constater que le noeud 3 et bien intégré dans le cluster! 11.1.4 Test de la réplication On va faire quelquechose pour les images ;) Page 38

Table 11.5 Vérification de l intégration dans le cluster via MySQL Page 39

Table 11.6 Configuration du noeud 3 Page 40

Table 11.7 Vérification de l intégration dans le cluster via MySQL Page 41