Équilibrage de Charge et Haute Disponibilité

Dimension: px
Commencer à balayer dès la page:

Download "Équilibrage de Charge et Haute Disponibilité"

Transcription

1 LP ASRALL Équilibrage de Charge et Haute Disponibilité pour applications Web Ruby On Rails Auteurs : Gatien Gaspard, Rémi Jachniewicz, Julien Lacava, Vincent Meslard 22 avril 2009

2 Table des matières 1 Étude Le projet Équilibrage de charge et haute disponibilité Équilibrage de charge Haute disponibilité État de l'art Répartition de charge Haute Disponibilité Serveur Web Monitoring Conclusion Principe et fonctionnement de LVS Présentation de LVS Méthodes de transmission pour la répartition de charge Conclusion Algorithmes des équilibreurs de charge Conclusion Protocoles de tests Inventaire Outils de test montée en charge Apache Bench HTTPerf Siege Tsung Conclusion Mise en Pratique Environnement d'expérimentation Environnement matériel Environnement logiciel Mise en uvre des Équilibreurs LVS Nat Heartbeat Monitoring Mise en uvre des serveurs Web Développement d'une application ROR simple Installation d'un serveur Web Apache + Mongrel Mise en uvre des Bases Mysql Installation de Tsung

3 3.5 Tests et relevés Conguration du test de charge Point de vue du Client Point de vue de l'administrateur Conclusion Divers Bibliographie Compte rendu projet Tutoré Nous Statistiques Remerciements

4 Chapitre 1 Étude 1.1 Le projet Notre projet porte sur la mise en place de solutions assurant la haute disponibilité et la répartition de charge sur un service Web. Les serveurs oriront un service Web basé sur Ruby on Rails couplé à un Système de Gestion de Base de Données. Le projet se déroule en deux grandes parties. La première consiste à se documenter sur les solutions existantes et à choisir celles qui conviendront le mieux. La seconde est plus pratique avec la mise en place de l'une des solutions choisies suivie d'une période de tests et benchmarking. Le developpement d'une petite application Ruby on Rails sera donc indispensable pour ce projet. Ruby est un langage de script orienté objet. L'une de ses plus importantes caractéristiques est d'être entièrement orienté objet. Mais malgré ses nombreuses qualités, il manquait au langage Ruby un framework puissant, exploitant au mieux ses nombreuses facettes. Ruby on Rails est donc apparu. Celui-ci permet de construire des sites Internet de manière fonctionnelle, rapide et fournissant tous les outils nécessaires pour les sites que l'on trouve aujourd'hui. Il propose aux développeurs d'améliorer considérablement leur productivité grâce à : un code plus concis, plus évolutif et produit plus rapidement, une conguration minimale, favorisant certaines conventions, des technologies déjà intégrées comme Ajax permettant d'orir aux utilisateurs naux une interface riche et plus ergonomique. Il en résulte des sites qui proposent des interfaces riches en fonctionnalités, pourvues d'une forte interactivité, illustrant bien les services Web 2.0. De plus, tout a été conçu pour minimiser la partie développement d'un projet et maximiser la partie créativité et originalité du projet. Ainsi, il est possible de produire des petits sites web sans écrire une seule ligne de code! Un certain nombre d'outils sont disponibles à l'installation et permettent d'automatiser les tâches les plus classiques (création d'un formulaire, gestion de la base de données, gestion des erreurs, etc.). Dans sa phase de développement, une application Ruby on Rails peut se permettre de travailler avec le serveur web écrit en Ruby : WEBrick. Par une simple ligne de commande, le développeur exécute sur son ordinateur un serveur web. Le serveur est tout de suite opérationnel et est entièrement dédiée au développement de l'application. En ce qui concerne la base de données, plusieurs systèmes de gestion de base de données sont supportés : SQLite, MySQL, PostgreSQL, DB2, Oracle et Microsoft SQL Server. Pour les serveurs Web, on peut utiliser apache ou lighttpd ou encore Nginx avec Mongrel. 3

5 1.2 Équilibrage de charge et haute disponibilité Équilibrage de charge L'équilibrage de charge est un élément important lors de la mise en place de services amenés à croître. Il faut s'assurer que la capacité à monter en charge soit la plus optimale possible an d'éviter toute dégradation que ce soit en terme de performances ou de abilité lors d'auences importantes. Le principe de base de l'équilibrage de charge (load balancing en anglais) consiste à eectuer une distribution des tâches à des machines de façon intelligente. Pour cela il faut intégrer un dispositif entre les serveurs et les utilisateurs de la ressource. Ce dispositif aura pour tâche de rediriger les consommateurs de services en fonction de l'état d'occupation des serveurs. Il faut aussi prendre en compte le service distribué et adapter la méthode de redirection en fonction de celui-ci au travers de diérents algorithmes (Round Robin, Random, Least Resources...). Les gains sont non négligeables : amélioration des temps de réponse des services, capacité à pallier la défaillance d'une ou de plusieurs machines, ajout de nouveaux serveurs sans interruption de service. L'équilibrage de charge utilise essentiellement 2 techniques qui sont le DNS et le reverseproxy Haute disponibilité La haute disponibilité est l'ensemble des moyens mis en uvre dans le but de garantir la disponibilité d'un service de part son bon fonctionnement. Ces dispositions sont eectuées dans le but de prévenir toutes les pannes informatiques qui peuvent, en fonction de leur gravité, provoquer une perte de productivité et par conséquent une perte d'argent. Cette disponibilité est exprimée en pourcentage avec temps de disponibilité sur temps total. Quelques exemples sur une année : 97% 11 jours 98% 7 jours 99% 3 jours et 15 heures 99,9% 8 heures et 48 minutes 99,99% 53 minutes 99,999% 5 minutes 99,9999% 32 secondes Pour prévenir les défaillances, il est nécessaire de mettre en place des mécanismes de redondance sur les éléments critiques. 1.3 État de l'art Répartition de charge Il existe plusieurs solutions pour faire de la répartition de charge, la plus basique étant l'utilisation de DNS. Dans cette solution le répartiteur de charge est le serveur DNS. Basé sur la conguration de bind (démon le plus utilisé sous Linux pour le DNS), le serveur DNS permet de résoudre les noms d'hôtes de manière diérente à chaque requête. Un nom de domaine est associé à plusieurs adresses IP correspondant à chaque serveur du cluster. Bind, utilise alors un algorithme round-robin pour choisir le serveur destinataire de la requète. L'avantage de ce système est sa grande simplicité, il sut d'ajouter quelques lignes à la conguration de bind 4

6 sur le serveur DNS. Par contre il ne permet pas de prendre en compte les performances d'un serveur, ou bien son taux d'occupation, puisque qu'il n'utilise qu'un algorithme round-robin. D'autres solutions permettent de prendre en compte ces problèmes de performance ou de défaillance de serveurs du cluster. Voici quelques unes de ces solutions. LVS Linux Virtual Server 1 est une solution de répartition de charge pour GNU/Linux. L'objectif principal est de construire un serveur de haute performance pour Linux utilisant la technologie du clustering. LVS est un logiciel basé sur les couches 3 et 4 de la représentation OSI. Il fait des redirections sur les adresses IP ainsi que diérents ports TCP. LVS est plus détaillé par la suite (en 1.4). Apache - mod_proxy_balancer À partir de apache 2.1 2, en utilisant le module mod_proxy_balancer, il est possible de faire de l'équilibrage de charge pour les protocoles HTTP, FTP et AJP13 (Apache JServ Protocol - utilisé principalement avec Tomcat pour rediriger les sessions vers le bon serveur et pour faire du monitoring simple). Il intègre trois algorithmes d'ordonnancement : Request Counting, Weighted Trac Counting et Pending Request Counting. Request Counting : répartit les requêtes de façon pondérée vers les serveurs. Weighted Trac Counting : répartit les requêtes de façon pondérée sur la taille (en octets) des réponses. Pending Request Counting : répartit les requêtes de façon pondérée sur la taille de la liste d'attente des requêtes sur chaque serveur. Le module mod_status permet de rajouter des possibilités de gestion dynamique des pondérations de chaque serveur. Avantages : facilité de mise en uvre, bien maintenu, portabilité (toute architecture supportant apache). Inconvénients : protocoles HTTP, FTP et AJP13 uniquement. Pen Pen est un load balancer pour les protocoles basés sur TCP. Il permet de distribuer les requêtes de clients sur diérents serveurs en gardant une trace de ceux-ci pour renvoyer chaque client vers le serveur qui lui avait été aecté précédemment. Il intègre également un dispositif simple de haute disponibilité qui, si un serveur est hors service, envoie la requête vers un autre. Il est possible de faire de la redondance sur pen lui-même en le déployant sur plusieurs serveurs et en utilisant le protocole VRRP 3 pour décider lequel est actif. Alors que le monitorage de pen se limite à la couche transport, il est possible de faire du monitorage au niveau applicatif en utilisant penbw. Avantages : tous les protocoles basés sur TCP (y compris HTTPS), possibilité d'utiliser VRRP, Virtual Router Redundancy Protocol - RFC

7 bien maintenu (dernière version : mai 2008), bonne portabilité (FreeBSD, Linux, HP-UX, Solaris et Windows), détection automatique des serveurs hors-services, garde en mémoire les traces des clients. Inconvénients : un seul algorithme (round-robin + trace des connexions). HaProxy HAProxy 4 permet de répartir les connexions reçues d'un protocole sur plusieurs serveurs. Il permet aussi de détecter l'indisponibilité d'un des serveurs. Il peut être utilisé pour les applications utilisant TCP. HAProxy sait gérer plusieurs proxy à la fois. C'est un Reverse- Proxy, surtout utilisé pour les sites Web. Avantages : peut tenir des charges très importantes comme plusieurs milliers de connexions par seconde, ressources matérielles nécessaires très faibles, aucune vulnérabilité depuis plus de 6 ans. Inconvénients : reconguration à chaud impossible, pas d'interface Web de conguration, pas de centralisation des congurations. Balance Balance 5 est une solution simple basée sur le niveau utilisateur de la couche OSI, il ne touche pas au kernel. Il ore une solution d'équilibrage de charge mais aussi de proxy TCP. Son Load Balancing est basé sur plusieurs algorithmes (RoundRobin, random, hash, least resources). Il ore une gestion totale via la ligne de commande en plus d'être très léger. Il existe en deux versions, une gratuite (balance) et une commerciale (balanceng 6 ). Avantages : gestion totale via ligne de commande possible, diérents algorithmes de Load Balancing, mise en place rapide. Inconvénients : basé sur niveau utilisateur, pas OpenSource, version payante plus souvent mise à jour. Nginx Nginx 7 est un serveur et proxy web haute performance, il peut également servir de proxy mail et surtout en mode reverse proxy avec load balancer. Il a été programmé an d'obtenir les meilleurs performances possibles. Ainsi, il ne nécessite pas d'avoir autant de processus que de connexions, un par processeur sut. Les requêtes sont découpées en mini-tâches, ordonnancées par chacun des processus. Ceci et le fait qu'il soit développé en C lui confèrent une empreinte mémoire vraiment faible et une excellente rapidité d'exécution

8 Nginx est un front-end populaire pour les applications Rails et PHP. Aussi, l'équilibrage de charge mis en place est de type Round-Robin pondéré. Avantages : très facile à mettre en uvre, bien maintenu (dernière version : Janvier 2009), bonne portabilité GNU/Linux, BSD, Mac OS X, Solaris, Windows (non maintenu ociellement), protocoles HTTP et HTTPS. Inconvénients : pas de monitoring intégré. Autres solutions logicielles Voici une liste non exhaustive d'autres solutions disponibles : 1. OSCAR (Open Source Cluster Application Ressources) 8 Cette solution contient un ensemble d'applications pour l'installation, l'administration et l'utilisation de clusters. Avantages : projet open source, apres la version 5.0 en 2006, reprise de l'activité en 2009 avec la version 6.0, packagé pour de nombreuses distributions, multi-architecture. Inconvénients : peu de documentation, plutôt orienté calcul distribué. 2. CLIC 9 C'est une application permettant la gestion de cluster développée par Mandrake Soft. Avantages : projet open-source. Inconvénients : peu de documentation, ne semble plus maintenu, n'a pas évolué depuis 2003, plutôt orienté calcul distribué. 3. POUND 10 POUND est un reverse-proxy. Avantages : projet open-source sous licence GPL, pas d'accès direct au disque dur, wrapper ssl. Inconvénients : utilisable uniquement pour la répartition de charge sur serveurs web. Implication de la couche du modèle OSI utilisée. Parmi toutes ces solutions, certaines sont basées sur la couche réseau/transport du modèle OSI (Niveau 3/4) tandis que d'autres sont basées sur la couche applicative (Niveau 7). Cela

9 implique que les premiers prennent en considération l'ensemble des protocoles 11 utilisant TCP, tels que HTTP(S), FTP, SMTP / POP3 / IMAP,... Ceux basés sur la couche applicative en revanche sont beaucoup plus restrictifs puisqu'ils sont spécialisés, ils ne s'occupent par exemple que de HTTP. 11 TCP (RFC 793), HTTP (RFC 2616), FTP (RFC 959), SMTP (RFC 1870), POP3 (RFC 1939), IMAP (RFC 2595). 8

10 Récapitulatif des fonctionnalités TLS/SSL Sessions Cache Type Licence Couche OSI Portabilité Maintenu Apache Serveur web, apache X X X Application Unix, Windows décembre 2008 reverse proxy HAProxy Load Balancer GPL X X X Application Unix Novembre 08 Pen Load Balancer GPL X Application Unix, Windows Mai 2008 Balance GPL?? Application Unix Avril 08 BalanceNG shareware X X Application Unix Février 09 UltraMonkey? GPL Réseau/Transport Unix 2005 Nginx Serveur web, Reverse Proxy type BSD X X X Application 12 Unix janv-2009 reverse proxy Oscar GPL??? Réseau/Transport Unix 2009 Clic GPL - - Réseau/Transport Unix 2003 Pound Reverse Proxy GPL X X X Application Unix 2009 LVS(IPVS) Load Balancer GPL X X - Réseau/Transport Unix 2004 KeepAlived HealthCheck/Failover GPL??? Application Unix

11 Synthèse : répartition de charge Si l'on s'en tient aux données présentées précédemment, il existe 2 méthodes principalement utilisées pour faire de l'équilibrage de charge de serveurs Web, il y a les applications basées sur LVS et les reverse-proxies. Nous pouvons ainsi retenir dans le cadre de notre projet, POUND qui est un reverse-proxy et LVS puisque ceux-ci sont maintenus, stables et éprouvés Haute Disponibilité La haute disponibilité permet d'obtenir un temps d'indisponibilité minimal grâce à des principes simples tels que la redondance de l'ensemble du matériel et des services an de limiter les SPOF (Single Point of Failure). Il est ainsi systématique dans ce type de conguration de pratiquer de la réplication de données ainsi que de mettre en place des technologies telles que le RAID an d'éviter les pertes de données. Drbd DRBD (Distributed Replicated Block Device) est un mécanisme de réplication de données localisées sur deux serveurs distincts par voie réseau. Quand une écriture a lieu sur le disque du serveur maître, l'écriture est simultanément réalisée sur le serveur esclave. La synchronisation est faite au niveau de la partition. Le mécanisme DRBD fournit une approche du périphérique partagé, mais ne nécessite aucun matériel spécique. En eet, il utilise simplement le protocole IP pour le transport des données, ce qui s'avère moins coûteux en matériels que les périphériques de stockage réseau (NAS, SAN). Avantages : maintenance des serveurs sans coupure de services, indépendant du type de système de chiers utilisé sur le serveur. Heartbeat Heartbeat est un système de gestion de la haute disponibilité. Heartbeat met en place un système de clustering en haute disponibilité basé sur le principe des battements de c ur. Il exécute des scripts d'initialisations lorsque une machine tombe (plus d'entente du battement de c ur) ou est à nouveau disponible (battement de c ur retrouvé). Il permet aussi de changer d'adresse IP entre plusieurs machines à l'aide de mécanismes ARP avancés. Heartbeat fonctionne à partir de deux machines et peut être mis en place pour des architectures réseaux plus complexes. Ldirectord Ldirectord, écrit en Perl, a pour rôle la surveillance applicative des machines et modie, en temps réel, les règles de redirection, à l'aide de la commande ipvsadm. Ldirectord va permettre, si une machine devient indisponible, de la retirer du pool de serveurs, an que les utilisateurs n'aient pas de messages d'erreurs. KeepAlived Keepalived est utilisé pour surveiller les serveurs au sein d'un cluster en utilisant LVS. Keepalived peut être conguré pour supprimer un serveur appartenant au cluster (grappe de machines) s'il ne répond plus. Il peut aussi envoyer une notication par courriel pour que l'administrateur soit prévenu de la perte du service. 10

12 UltraMonkey Il existe également des solutions tout-en-un permettant de mettre en uvre rapidement un équilibrage de charge. Ultramonkey fait partie de celles-ci. Ultramonkey regroupe plusieurs solutions logicielles permettant de mettre en place un système assurant l'équilibrage de charge mais aussi la haute disponibilité des services/données. Celui-ci est basé sur LVS pour l'équilibrage, heartbeat pour la disponibilité et ldirectord pour la supervision des diérentes machines. Ces logiciels sont réputés pour leur bon fonctionnement ainsi que leur ecacité. Ultramonkey convient aussi bien pour la mise en place sur de petits clusters que sur de grands systèmes. Avantages : travaille sur la couche transport du modèle OSI avec LVS, facilement extensible pour un grand nombre d'ip basées sur des services virtuels, haute disponibilité oerte par le protocole de Heartbeat, monitoring des services via ldirectord, ore une documentation assez complète sur le déploiement de solutions de haute disponibilité et/ou d'équilibrage de charge, open source, package Debian disponible. Inconvénients : n'est plus maintenu. Mon Mon est un outil de surveillance applicative qui permet de surveiller l'état des ressources logicielles et de déclencher des actions paramétrables. C'est un composant essentiel pour déclencher un basculement dans le cadre d'un cluster avec migration de services (Heartbeat) si l'application ne tourne plus sur la machine active. Mysql Replication MySQL supporte la réplication unidirectionnelle interne. Un serveur sert de maître, et les autres serveurs servent d'esclaves. Le serveur entretient des logs binaires de toutes les modications qui surviennent. Il entretient aussi un chier d'index des chiers de logs binaires, pour garder la trace de la rotation des logs. Chaque esclave, après connexion réussie au serveur maître, indique au maître le point qu'il avait atteint depuis la n de la dernière réplication, puis rattrape les dernières modications qui ont eu lieu, puis se met en attente des prochains événements en provenance du maître. Ce sera donc une solution de haute disponibilité, l'équilibrage de charge ne sera pas mis en place sur les bases de données. 11

13 Récapitulatif des fonctionnalités Type Portabilité Maintenu UltraMonkey Package de solution Unix Juillet 2007 Drdb Outil de replication réseau Unix Février 2009 HeartBeat Outil de monitoring Unix Février 2009 Ldirectord Système de clustering Unix Février 2009 KeepAlived Système de clustering Unix Mars 2009 Mon Outil de monitoring Unix Juin 2007 MySQL Replication Outil de replication réseau Multiplateforme Janvier

14 Synthèse : haute disponibilité Comme cela est visible dans le tableau précédant, chacune de ces applications est destinée à un traitement particulier lié à la haute disponibilité hormis Ultramonkey qui est un package regroupant certaines des solutions présentées an de fournir un outil clé en main. Dans le cadre de notre projet, ces solutions peuvent toutes convenir. Ainsi, un choix devait être fait (Heart- Beat + Ldirectord ou Keepalived pour la gestion du cluster, DRBD ou MySQL Replication pour les bases de données). Les solutions choisies au nal sont : HeartBeat + Ldirectord ainsi que MySQL Replication Serveur Web An de mettre en place une application ruby, il nous faut un serveur web capable d'exécuter du code ruby. Nous allons présenter ici une liste des serveurs susceptibles de nous intéresser. Apache Apache HTTP Server, souvent appelé Apache, est un serveur HTTP produit par l'apache Software Foundation. C'est le serveur HTTP le plus populaire du Web. C'est un logiciel libre avec un type spécique de licence, nommée licence Apache. Apache est conçu pour prendre en charge de nombreux modules lui donnant des fonctionnalités supplémentaires : interprétation des langage Perl, PHP, Python et Ruby, serveur proxy, Common Gateway Interface, réécriture d'url, etc. Nginx Nginx est un serveur HTTP et Reverse proxy. Il est désormais utilisé par de plus en plus de site internet au niveau mondial. Nginx reprend un certain nombre de principes d'apache, comme la notion de chiers de conguration modulaires (via des include), des virtual hosts... Cependant dans Nginx, il n'y a pas de notion de ServerName ni de ServerAlias. Tout est au même niveau. Lighttpd Lighttp est un serveur web qui supporte un grand nombre de fonctionnalités comparables à celles d'apache, comme les rewrite, fast-cgi, proxy, pour des performances aussi bonnes. Gros inconvénient par rapport à Apache : il ne supporte pas les chiers.htaccess. Il est dans le Top 5 des serveurs les plus utilisés dans le monde. Mongrel Mongrel est un serveur HTTP écrit en Ruby et en C. Il a été conçu pour être léger, rapide et sécurisé et optimisé pour le délivrement de contenu dynamique Ruby On Rails. C'est un logiciel libre distribué selon les termes de la licence Ruby, compatible avec la licence GNU GPL. 13

15 FastCGI ou Mongrel? Fig. 1.1 Source : http ://blog.kovyrin.net/ D'après ce graphique, on s'aperçoit que les performances de Nginx et Apache sont sensiblement les mêmes, l'un en utilisant Mongrel, l'autre en utilisant FastCGI, d'autre part, la conguration d'apache est plus simple que celle ne Nginx. Nous avons donc décidé de tester Apache avec Mongrel pour voir les performances avec cette conguration Monitoring En vue d'eectuer des tests sur notre cluster il est indispensable de s'équiper d'outils nous permettant de surveiller les ressources utilisées sur les machines. De nombreuses solutions existent c'est pourquoi le choix est très important. Nous allons en premier lieu utiliser les outils fournis par Linux avec top, uptime, ps, free... Nagios Nagios (anciennement appelé Netsaint) est une application permettant la surveillance système et réseau. Plutôt axé supervision celui-ci permet d'être conguré de telle façon à récupérer 14

16 des informations système au travers de scripts. La récupération des informations se fait en partie via SNMP. RRDtool Outils de création de graphiques ultra polyvalent, celui-ci permet de créer des graphiques à partir d'informations de tout type. RRDtool ne gère pas la récupération automatique des ressources systèmes, il faut pour cela déployer une solution qui lui enverra les informations désirées. Munin Munin est un outil de surveillance système et réseau basé 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. L'architecture du système Munin est constituée d'un serveur principal, récupérant les informations à intervalle régulier et de plusieurs n uds, souvent un par serveur à surveiller. Ganglia De fonctionnalités équivalentes à Munin, Ganglia est lui plus axé pour la surveillance de cluster ou grid (ensemble de cluster). On bénécie aussi d'une présentation par interface web et d'un système client-serveur pour la récupération des informations Conclusion Notre choix principal est Ganglia car conçu spécialement pour le monitoring de cluster. De plus il procure un nombre important d'informations et une précision plus grande (détails sur l'heure, la journée,...). En eet sous ganglia la précision des statistiques est plus importante (regraphage sur de plus grands graphiques, changement de base de temps, etc.) 1.4 Principe et fonctionnement de LVS Présentation de LVS LVS permet de mettre en uvre un cluster d'un nombre important de machines avec un répartiteur de charge fonctionnant sous Linux. Celui-ci permet d'assurer la répartition de charge pour la plupart des services existants tout en permettant une haute disponibilité (via des logiciels comme heartbeat). LVS est constitué d'un logiciel appelé IPVS. IPVS implémente la répartition de charge au niveau de la couche transport (TCP). Celui-ci est inclus dans le noyau de Linux depuis sa version 2.0. C'est lui qui met en uvre les diérents algorithmes et s'occupe de router les paquets vers les serveurs. La commande ipvsadm permet d'administrer IPVS sur le répartiteur. C'est par son intermédiaire qu'on communique l'architecture du cluster (le répartiteur et les serveurs), ainsi que les services disponibles, les algorithmes à utiliser et les diérents paramètres globaux (timeouts, log, etc.). 15

17 1.4.2 Méthodes de transmission pour la répartition de charge La partie forwarding de IPVS se charge d'envoyer les paquets vers un serveur particulier. Il change les en-tête des paquets pour pouvoir les transmettre au serveur élu. Plusieurs méthodes de répartition existent, la grande diérence se situe au niveau de l'architecture du cluster. Avec LVS NAT le cluster est dans un réseau privé, alors que dans les deux autres méthodes les serveurs réels font partie du même réseau que le routeur. Il y a deux grands principes que le processus de transmission doit respecter : Le répartiteur doit modier le paquet pour l'envoyer au serveur réel. L'adresse source du paquet répondant à la requête doit être celle du répartiteur. LVS NAT C'est la méthode la plus simple à mettre en uvre, on n'a pas besoin de recongurer les serveurs réels, hormis leur indiquer l'équilibreur de charge comme passerelle par défaut. Seul le répartiteur a besoin d'être conguré. Les serveurs sont à l'intérieur d'un réseau privé et leur passerelle, pour leur permettre d'accéder aux réseaux externes, est un répartiteur déni. Donc tous les paquets en provenance ou à destination d'un serveur réel passent par le répartiteur. Le principe du NAT (Network Adress Translator) est basé sur la modication des adresses IP de destination. Lorsqu'un paquet arrive sur le répartiteur, l'adresse IP de destination est substituée par celle du serveur choisi. Le client n'étant pas dans le réseau privé, le paquet de réponse du serveur est envoyé au répartiteur (conguré en tant que passerelle sur le client), qui remplace l'adresse IP source par son adresse. Donc le client recevra un paquet dont l'adresse IP source est le répartiteur et non le serveur réel. On assure ainsi une totale transparence de la grappe (répartiteur + serveurs). LVS NAT a pour avantage l'utilisation d'adresses privées (10.x.x.x, x.x) pour les serveurs réels, il est donc économe en adresse IP publiques et plus simple à administrer. En contrepartie, la translation d'adresses demande des ressources de calculs plus importantes que les autres méthodes. Un autre problème est l'accès d'un serveur à une machine externe au réseau privé, tout le trac doit passer obligatoirement par le répartiteur. Ce qui constitue un goulet d'étranglement. 16

18 LVS DR Fig. 1.2 Chemin des paquets via LVS-NAT. LVS Direct Routing modie les tables ARP des serveurs pour transmettre les paquets. Lors de l'arrivée d'un paquet sur le répartiteur, celui-ci change l'adresse MAC de destination par celle du serveur élu puis modie la table ARP de ce serveur pour pouvoir résoudre l'adresse MAC de destination avec l'ip du répartiteur. À la suite de cette opération, le serveur va renvoyer directement (sans passer par le répartiteur) sa réponse au client avec comme adresse IP source celle du répartiteur. Cette méthode est contraignante car l'ensemble des machines du cluster doit partager la même table ARP. 17

19 LVS Tun Fig. 1.3 Chemin des paquets via LVS-DR. Cette méthode utilise l'encapsulation IPIP (Tunnelling). Un paquet arrivant sur le répartiteur sera encapsulé dans un nouveau paquet, puis envoyé au serveur élu. L'adresse IP de destination de ce paquet sera alors celle du serveur. Par suite le serveur désencapsule ce paquet pour récupérer le paquet original. Il répond ensuite en envoyant sa réponse directement au client. Cette méthode à l'avantage de pouvoir construire une grappe avec des machines très éloignées (réparties sur plusieurs réseaux), pour faire des miroirs FTP par exemple. Cette interface est associée à l'adresse IP du répartiteur pour que les paquets partant du serveur puissent avoir comme adresse source celle du répartiteur. Ainsi il faut faire en sorte que les serveurs réels ne répondent pas aux requêtes ARP, sous peine que le client se connecte directement à un des serveurs. 18

20 1.4.3 Conclusion Fig. 1.4 Chemin des paquets via LVS-Tun. Parmi ces 3 types d'infrastructure, celle qui semble la plus ecace dans le cadre d'un équilibrage de charge avec haute disponibilité est la méthode de routage direct (LVS - Direct Routing). En eet, cette méthode permet d'éviter le goulet d'étranglement au niveau du répartiteur lié à la structure LVS NAT sans pour autant utiliser d'adresses IP publiques et sans rendre possible la connexion directe à l'un des serveurs. 1.5 Algorithmes des équilibreurs de charge Les applications Web modernes utilisent le plus souvent un mécanisme de persistance (les fameuses sessions en PHP par exemple). HTTP étant un protocole non connecté, un répartiteur de charge doit pouvoir assurer qu'au cours d'une session limitée dans le temps, un utilisateur donné devra être reconnecté au serveur ayant eectué la transaction initiale. Plusieurs solutions possibles ont été mise en uvre. Il existe deux grands types de gestion de la répartition des charges : les algorithmes déterministes et non-déterministes. Les algorithmes déterministes se basent sur un cycle déni tandis que les algorithmes non-déterministes peuvent router en se basant sur plusieurs paramètres. La redirection peut donc ne jamais être la même. Par exemple, Least Connection est non-déterministe car il va rediriger le client en fonction de la dernière connexion. 19

21 Algorithmes déterministes Tables de hash : On construit une table de hash à partir de l'adresse IP du client. Cet algorithme suppose que le client ne passe pas au travers de diérents proxies (adresse IP variable), sinon il n'est valable qu'au cours d'une session limitée dans le temps. N'assure pas forcément une répartition homogène. Redirection : Les clients sont envoyés vers un serveur de redirection, celui-ci les redirigeant vers un serveur selon un algorithme qui lui peut ne pas être déterministe. Le problème peut alors survenir si le serveur vers lequel le client a été redirigé est indisponible. Peu able donc. Algorithmes non-déterministes Round Robin : ou 'tourniquet' est comme son nom l'indique un algorithme de le tournante : l'équilibrage choisit à chaque instant un serveur dans la le et boucle sur celle-ci. Certainement le plus performant. Least connection : Le répartiteur renvoi les requêtes 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. Dicile à mettre en uvre et rarement employé. Least-Load Scheduling : C'est un algorithme qui distribue les requêtes au serveur dont la charge CPU est la plus faible. Le Load Balancer interroge à intervalles réguliers la charge de chacun des serveurs, il y a donc une vraie répartition de charge, mais ce procédé est lent et gourmand en ressources 1.6 Conclusion Au travers de toutes ces solutions nous avons sélectionné les applications que l'on a mises en place. Concernant les équilibreurs : Il nous faut un système d'équilibrage de charge prenant en compte le fait que les diérentes machines sont sur un même réseau et n'utilisent que le protocole http. C'est pourquoi nous avons choisi une solution basé sur LVS car il répond à ces attentes. Pour un déploiement rapide, une automatisation et une surveillance des serveurs nous avons mis en place Ldirectord. An d'assurer la haute disponibilité des équilibreurs, Heartbeat a été choisi car il supporte Ldirectord et reste plus léger que Mon vis-à-vis de nos besoins. En eet la surveillance des ressources systèmes en vue de prévention de défaillance n'est pas déployée. On notera que ces logiciels font partie intégrante du projet Linux HA (High Availibility). Linux HA est un projet de clustering visant à fournir un système à haute disponibilité. Ce projet a pour objectif de réaliser une solution de redondance système et de clustering sous Linux. De plus en plus de personnes s'intéressent à ce type de système, et Linux HA est vu comme une solution des plus adéquates. C'est pourquoi les développeurs du projet se sont attelés à essayer de rendre leur système le plus portable et le plus compatible avec les autres systèmes existants. Ce projet comprend entre autre Ldirectord et HeartBeart ce qui nous assure une compatibilité totale entre ceux-ci. 20

22 Concernant les serveurs : Pour le contenu statique, la gestion est assurée par Apache de part sa polyvalence, sa documentation et le fait que nous avons déjà utilisé ce logiciel durant notre formation. Le contenu dynamique Ruby on Rails est assuré par Mongrel qui est conçu spécialement pour la gestion de contenu généré par les frameworks basés sur le langage Ruby. Concernant la base de données : La réplication de la base de donnée est eectuée par MySQL lui même. La diérence entre la réplication MySQL et DRBD est que la réplication MySQL est asynchrone alors que DRBD est synchrone. Une réplication synchrone, comme DRBD, signie que la copie des informations se fait en temps réel, les performances des serveurs sont donc aectées. De plus DRBD n'a pas été créée spéciquement pour faire de la réplication de base de données contrairement à MySQL réplication. En choisissant cette méthode nous nous assurons donc un fonctionnement garanti et pleinement compatible car conçu par les créateurs du SGBD. Heartbeat est de nouveau utilisé pour assurer la haute disponibilité des bases. Nous avons donc pour la suite du projet mis en place l'architecture suivante : Fig. 1.5 Schéma général d'équilibrage de charge. La structure mise en place est constituée d'un équilibreur (Equ1) qui se charge de la répartition de charge. Un deuxième équilibreur de secours (Equ2) est aussi installé et se charge de prendre le relais en cas de panne du premier. Ces équilibreurs se partagent une ip virtuelle qui est utilisée par les clients pour accéder aux serveurs Web. Sont aussi déployés deux serveurs Web 21

23 (Serv1 et Serv2) partageant une base de données MySQL commune (BD1). La base contenue sur BD1 est répliquée sur BD2. 22

24 Chapitre 2 Protocoles de tests 2.1 Inventaire Les protocoles de mesure de performances sont nombreux sur ce type de déploiement, cette partie parle donc des diérents tests possibles et ceux que nous avons sélectionnés. Certains éléments sont indispensables pour eectuer des statistiques dans de bonnes conditions : Même matériels et même systèmes d'exploitation pour les tests. Conguration des cartes réseaux identiques, ici 100 Megabits. On enregistre la charge des serveurs avant toute manipulation via top ou uptime. Eectuer plusieurs tests et garder les meilleurs résultats. Redémarrer la machine après chaque test. Revérication de load. Tests en statique sur des chiers HTML/PHP ainsi que chiers dynamiques. Test avec ou sans KeepAlive. Le KeepAlive fait partie intégrante du protocole HTTP1.1 et permet de maintenir une connexion ouverte après un échange en vue d'un éventuel nouveau transfert. Cela permet d'éviter des déconnexions/reconnexions multiples ayant pour incidence de ralentir l'accès aux données. Le benchmark de solutions est axé sur plusieurs points qui sont les serveurs Web, l'équilibrage, le SGBD. Les tests possibles sont très nombreux, il est donc important de sélectionner ceux qui sont les plus intéressants vis-à-vis de l'implémentation de la plate-forme Ruby On Rails. Il faut aussi savoir qu'il existe deux approches de montée en charge : Montée en charge brusque : il s'agit ici de tester la capacité du serveur à gérer une rapide montée en charge. Un test consiste donc à envoyer plusieurs requêtes simultanément. Ce genre de test peut être eectué avec des outils comme Apache Benchmark et nécessite un nombre de machines permettant de générer un maximum de connexions en un minimum de temps. Simulation réaliste : cette fois-ci la montée en charge se fait progressivement et plus longtemps. L'utilisation de scénarios de navigations peut être ici très utile. Nous travaillons sur ce point avec Tsung qui supporte nativement ce type de simulation. Le test de charge peut être vu de deux façons diérentes : Utilisateur et Administrateur. Le côté Utilisateur est plus axé sur la livraison rapide du contenu tandis que le côté Administrateur se préoccupe plus des ressources générales utilisées sur les diérentes machines. Pour résumer, notre procédure de test est donc : Temps de réponse sur des pages statiques. Temps de réponse sur des pages PHP. 23

25 Temps de réponse sur des pages PHP + MySQL. Temps de réponse sur des pages Ruby On Rails. Temps de réponse sur des pages Ruby On Rails + MySQL. Temps de réponse sur une utilisation intensive de la base de données et surveillance de la base de sauvegarde. Ressources utilisées sur les diérents éléments (Équilibreurs, Serveurs, etc.). Les éléments ci-dessus ayant un comportement diérent en fonction de l'état du système. Ces tests peuvent donc être eectués avec plusieurs machines hors lignes (déconnectées du cluster) an d'évaluer concrètement les gains procurés par la mise en place d'une solution d'équilibrage de charge et de haute disponibilité. Les premiers tests nous permettront d'avoir une référence en vue de les comparer avec les résultats obtenus sur le temps de réponse de pages Ruby On Rails. 2.2 Outils de test montée en charge Le meilleur moyen de voir comment vont se comporter nos applications Web et nos serveurs sous une charge importante est de les tester avec une charge simulée. Il existe plusieurs outils gratuits sous Linux dédiés à cela. Nous nous sommes interessés uniquement à des outils maintenus et libres Apache Bench Apache Bench (AB) est un outil conçu pour benchmarker des serveurs Apache. Il est conçu pour donner des statistiques sur la réponse des serveurs à un test de charge ainsi que le nombre de requêtes par secondes que celui-ci peut traiter. AB gère également la concurrence (simultanéité des requêtes) HTTPerf HTTPerf est un testeur de charge en ligne de commande développé par les laboratoires HP. Outil similaire à Apache Bench, celui-ci permet en plus de dénir des sessions. Chaque session correspondant à un utilisateur et son comportement de navigation associé. Dans le même esprit mais simplié il existe aussi HTTP_Load Siege Siege est similaire à HTTPerf de part sa conguration quasi intégrale via des arguments passés en ligne de commande. Siege peut lui utiliser des processus concurrents pour envoyer ses requêtes. Il possède des options un peu plus bas niveau qu'httperf et gère des listes d'url. Il est aussi plus simple d'utilisation qu'httperf grâce à ses options plus claires. L'enregistrement de scénarios de navigation est aussi possible Tsung Tsung marche de manière similaire à Siege mais ore des fonctionnalités supplémentaires comme la gestion d'utilisateurs diérents (navigateurs, Os,...), la simulation de sessions et le retour d'informations dynamiques. De plus celui-ci est basé sur le langage Erlang qui est un langage orienté concurrentiel. Tsung supporte aussi de nombreux autres protocoles tels que WebDAV, SOAP, PostgreSQL, MySQL, LDAP et Jabber/XMPP. Tsung possède de plus une fonctionnalité permettant de créer un cluster de test de charge, un système de génération de graphiques et rapports en HTML. 24

26 2.3 Conclusion Pour nos tests nous avons besoin d'un support HTTP, de la gestion de scénarios mais aussi d'outils permettant d'obtenir des graphiques exploitables en sortie. De plus le support du clustering nous permettra de gagner du temps tout en augmentant la abilité de nos mesures. C'est pourquoi nous allons utiliser en majorité Tsung. Fig. 2.1 Schéma du cluster de test de charge. Ci-dessus un exemple de structure envisagée pour l'utilisation de Tsung. Le maître répartira les tâches sur lui-même ainsi que deux esclaves qui auront pour but de mettre à l'épreuve la solution d'équilibrage via diérentes requêtes HTTP. Les machines utilisées pour ces tests vont être nos machines car plus puissantes que les machines mises en place dans la solution d'équilibrage an de pouvoir saturer les serveurs Web. 25

27 Chapitre 3 Mise en Pratique 3.1 Environnement d'expérimentation Environnement matériel Voici un inventaire des ressources utilisées pour la suite de l'expérimentation. Équilibreurs Nombre de machines : 2 Processeur : Intel Pentium D (2,8GHz) (dual-core) Ram : 1024 Mb Disque Dur : 80 Gb Serveurs Web Nombre de machines : 2 Processeur : Intel Pentium 4 (2,4GHz) Ram : = 768 Mb Disque Dur : 80 Gb Serveurs de Base de données Nombre de machines : 2 Processeur : Intel Pentium 4 (2,8GHz) Ram : 512 Mb Disque Dur : 80 Gb Environnement logiciel Équilibreurs Système d'exploitation : Debian Lenny ( ) Ipvsadm (v1.24) Heartbeat (2.1.3) Ganglia Apache (2.2.9) Ldirectord (v1.186-ha-2.1.3) Openssh (1 :5.1) 26

28 Serveurs Web Système d'exploitation : Debian Lenny ( ) Apache2 (2.2.9) Mongrel (1.1.5) Openssh (1 :5.1) Serveurs de Base de données Système d'exploitation : Debian Etch ( ) MySQL (5.0.32) Openssh (1 :5.1) 3.2 Mise en uvre des Équilibreurs LVS Nat L'équilibrage de type NAT via LVS que nous allons mettre en place s'appuie essentiellement sur ipvsadm qui est l'outil d'administration de LVS mais aussi de Ldirectord qui va s'occuper de la conguration et la détection de serveurs web down. Sur le/les équilibreur(s) : Tout d'abord on installe Ldirectord : sudo apt-get install ldirectord Ensuite on crée une interface virtuelle, qui sera utilisée par le client désirant visiter le site web : sudo ifconfig eth0 :virt Conguration de Ldirectord : Les chiers de conguration portent l'extension.cf et se trouvent dans /etc/ha.d/. Dans ce chier il faut renseigner plusieurs éléments : virtual= :80 protocol=tcp scheduler=rr real= :90 masq 1 real= :80 masq 1 request="test.html" receive="200" Virtual renseigne sur l'adresse ip virtuelle qui sera accédée par le client. Protocol permettant de dénir le type de protocole utilisé, ici tcp car http est basé sur celui-ci. Scheduler correspond à l'agorithme utilisé pour l'équilibrage, rr signiant Round Robin. real liste les serveurs constituant le pool avec l'adresse ip de chacun d'eux, son type de forward et le poids. Le type masq (pour masquerade) correspond au LVS de type NAT et le poids permet de dénir une priorité de l'aiguillage. Request déni le nom de la ressource qui sera accedée pour vérier que les serveurs web sont toujours disponibles. 27

29 Receive contient la valeur que devra contenir la ressource pour être considérée comme disponible. Sur les serveurs web : Il y a deux petits points à mettre en place sur les serveurs : La première consiste à changer la passerelle par defaut actuelle par l'ip de l'équilibreur : /sbin/route add default gw Ensuite il faut créer à la racine le chier test.html et y mettre comme contenu 200, valeur dénie dans le chier de conguration. Lancement : En mode débug : En mode normal : Heartbeat /usr/sbin/ldirectord -d /etc/ha.d/www.cf start /etc/init.d/ldirectord start La haute disponibilité va être assurée par Heartbeat, celui-ci doit être installé sur chacun des équilibreurs. On installe Heartbeat : sudo apt-get install heartbeat Conguration : Il y a 3 chiers à congurer pour qu'heartbeat fonctionne comme désiré : /etc/ha.d/ha.cf : bcast eth0 <= Interface utilisée pour le battement debugfile /var/log/ha-debug <= fichier de débug logfile /var/log/ha-log <= fichier de log logfacility local0 <= Log utilisant syslog-ng keepalive 2 <= temps (en s) entre chaque battement deadtime 10 <= temps au bout du quel on considère une machine morte warntime 6 <= on considère que la machine met du temps à répondre après 6s initdead 60 <= temps avant de lancer le premier battement au démarrage udpport 694 <= port utilisé pour l'envoi du battement node equ1 <= déclaration des machines devant être surveillées node equ2 auto_failback on <= réintègre une machine qui repasse en état de marche /etc/had.d/haresources : /etc/ha.d/authkeys : equ1 Ipaddr :: } {{ } } {{ } Node Ip virt à attribuer 28

30 auth 1 <= on utilise la méthode d'authentification 1 1 sha1 CleSecrete <= Numéro de méthode, Type de cryptage et clé Ensuite il ne nous reste plus qu'à lancer Heartbeat sur les machines : Monitoring /etc/init.d/heartbeat start An d'exploiter les résultats, il nous est nécessaire de surveiller et tracer des graphiques. MRTG et RRDTOOL sont les leaders dans ce domaine. Néanmoins la mise en place/conguration n'est pas rapide. C'est pourquoi des outils plus spéciques doivent être utilisés. Après plusieurs recherches Ganglia semble tout indiqué. Après quelques tests il a été décidé de choisir Ganglia de part ses nombreux graphiques fournis mais aussi le détail des événements par heure (sur munin on ne peut zoomer au delà des jours). Installation/Conguration Ganglia se décompose en deux parties, un serveur et un client. Le serveur est à installer sur chaque machine à surveiller au travers de la commande : apt-get install gmetad Puis il faut congurer divers éléments dans le chier /etc/gmetad.conf : Les serveurs à questionner : data_source "Mon Cluster" localhost Le nom de la grid : gridname ASRALL Il est ensuite nécessaire d'installer un client qui va s'occuper de récupérer toutes les informations sur les diérents serveurs : apt-get install ganglia-monitor On attribue le nom de la grid via le chier de conguration /etc/gmond.conf : Name ASRALL Ganglia est packagé par défaut mais ne contient pas le frontend Web, pour cela il sut de télécharger le tar.gz sur le site ociel et copier le répertoire web à l'emplacement du serveur web. 3.3 Mise en uvre des serveurs Web Pour la suite, nous allons installer sur chaque serveur, Apache et Mongrel. Dans cette conguration, Mongrel ne sera chargé que du contenu dynamique Ruby On Rails, le contenu statique étant mieux géré par des serveurs Web tels que Apache, Nginx ou Lighttpd. 29

31 3.3.1 Développement d'une application ROR simple Installer Ruby : sudo apt-get install ruby-full build-essential Ruby sudo apt-get install rails Ruby on Rails sudo apt-get install mysqlclient15-dev Rails/Mysql sudo gem install mysql Rails/Mysql Se placer dans le répertoire où l'on souhaite développer l'application. rails myrailsapp -d mysql Démarrage du serveur de développement (Webrick) : myrailsapp/script/server À ce stade, on se retrouve avec la page par défaut de ROR si l'on saisit l'url suivante dans un navigateur Installation d'un serveur Web Apache + Mongrel Installation : sudo apt-get install apache2 mongrel mongrel_cluster Activation des modules nécessaires pour Apache : sudo a2enmod proxy deflate proxy_balancer rewrite mem_cache proxy_http Création du VirtualHost : Contenu du VirtualHost : nano /etc/apache2/sites-available/001-railstest <VirtualHost *:80> ServerName railstest.com DocumentRoot /var/www/rails/apps/public/ ProxyPass / ProxyPassReverse / ProxyPreserveHost on #Fix for Apache bug SetEnv force-proxy-request SetEnv proxy-nokeepalive 1 # Ne pas rediriger les images, les CSS # et les Javascripts vers Mongrel ProxyPass /images! ProxyPass /stylesheets! ProxyPass /javascripts! # Et précisons le path où se trouve # les images, les CSS et les javascripts Alias /images /var/www/rails/apps/public/images Alias /stylesheets /var/www/rails/apps/public/stylesheets Alias /javascripts /var/www/rails/apps/public/javascripts CustomLog /var/www/rails/apps/log/access "%h %l %u %t \"%r\" %s %b \"%{Referer}i\" \"%{User-Agent}i\"" ErrorLog /var/www/rails/apps/log/error </VirtualHost> Activation du VirtualHost créé et désactivation de celui présent par défaut : 30

32 Conguration du module proxy d'apache : sudo a2ensite 001-railstest sudo a2dissite 000-default sudo nano /etc/apache2/mods-enabled/proxy.conf Il faut commenter la ligne Deny from all pour la remplacer par Allow from Relancer Apache : sudo /etc/init.d/apache2 restart Lancer Mongrel : Se placer dans le répertoire de l'application (ici /var/www/rails) puis exécuter les commandes suivantes : mongrel_rails cluster : :configure -e production -p N 3 -c /var/www/rails/ mongrel_rails cluster::start Mise en uvre des Bases Mysql Conguration du maître : Il faut tout d'abord éditer le chier /etc/mysql/my.cnf. La première chose à congurer est l'écoute sur le réseau en plus de l'hôte local : #skip-networking #bind-address = Maintenant il est nécessaire d'indiquer à MySQL pour quelle base les logs seront écrits (ces logs seront utilisés par le serveur esclave an de détecter des changements). On lui indique le chemin des log et nous spécions que le serveur jouera le rôle de maître : log-bin = /var/log/mysql/mysql-bin.log binlog-do-db=example server-id=1 Ensuite on redémarre MySQL : /etc/init.d/mysql restart Nous allons maintenant créer un utilisateur avec les droits de réplications via MySQL On attribue les droits : mysql -u root -p GRANT REPLICATION SLAVE ON *.* TO IDENTIFIED BY '<motdepass>' ;FLUSH PRIVILEGES ; Nous allons maintenant bloquer la table qui nous intéresse : 31

33 USE example; FLUSH TABLES WITH READ LOCK; SHOW MASTER STATUS; Ce qui devrait nous acher : File Position Binlog_do_db Binlog_ignore_db mysql-bin example row in set (0.00 sec) Il est nécessaire de garder ces informations pour le serveur esclave. On crée maintenant un dump de la table : mysqldump -u root -p opt example > example.sql Une fois le dump établi nous pouvons débloquer la base : mysql -u root -p Enter password: UNLOCK TABLES; quit; La conguration du maître est désormais terminée. Conguration de l'esclave : On crée tout d'abord la base à répliquer : mysql -u root -p Enter password: CREATE DATABASE example; quit; On importe ensuite la base précédemment copiée : mysql -u root -p example < example.sql Il faut maintenant indiquer à MySQL qu'il sera l'esclave, que le maître est et que la base se nomme example. Pour cela on modie le chier /etc/mysql/my.cnf : server-id=2 master-host= master-user=esclave master-password=motdepasse master-connect-retry=60 replicate-do-db=example On redémarre MySQL : /etc/init.d/mysql restart Ensuite on lance MySQL pour les derniers réglages : mysql -u root -p 32

34 On stoppe le mode esclave : SLAVE STOP ; CHANGE MASTER TO MASTER_HOST=' ', MASTER_USER='esclave', MASTER_PASSWORD='motdepass', MASTER_LOG_FILE='mysql-bin.006', MASTER_LOG_POS=183 ; MASTER_HOST Ip du maître MASTER_USER nom de l'utilisateur avec les droits de réplication. MASTER_PASSWORD mot de passe de l'utilisateur. MASTER_LOG_FILE nom du chier de log récupéré précédement. MASTER_LOG_POS position dans le log actuel. On relance le mode esclave : La réplication est désormais eective. 3.4 Installation de Tsung SLAVE START ; Tsung est directement packagé sous Debian, l'installation s'eectue donc très simplement : sudo apt-get install tsung La conguration de Tsung est mise en place au travers d'un chier xml que nous verrons lors des tests. 3.5 Tests et relevés Conguration du test de charge Nous allons durant ces tests mettre en avant les bénéces d'un équilibrage de charge. La montée en charge se fera progressivement et non brutalement dû au manque de matériels et le manque d'intérêt réel vis à vis des tests que nous voulons eectuer. Les tests de charges vont être fait avec Tsung et certains paramètres doivent être dénis. La conguration se fait entièrement dans le chier tsung.xml. La première étape consiste à ajouter les hôtes qui vont envoyer les requêtes : <clients> <client host="localhost"> <ip value=" "></ip></client> <client host="jul"> <ip value=" "></ip></client> <client host="gat"><ip value=" "></ip></client> </clients> On renseigne ensuite l'adresse du serveur à benchmarker : <servers> <server host=" " port="80" type="tcp"></server> </servers> 33

35 C'est cette adresse qu'il faudra changer pour les tests avec/sans équilibreurs. Il faut maintenant indiquer la fréquence d'arrivée des utilisateurs et la durée du test : <load> <arrivalphase phase="1" duration="3" unit="minute"> <users interarrival="0.05" unit="second"></users> </arrivalphase> </load> Notre test va durer 3 minutes avec 20 nouveaux arrivants toutes les secondes et un maintient de connexion de 8 secondes. Il nous faut maintenant dénir l'url de test : <request> <http url="/" method="get" version="1.1"></http> </request> <thinktime value="8"/> Le thinktime présent ici correspond au temps passé sur la page, impliquant un maintient de connexion. Maintenant que tout est conguré il sut de lancer tsung : tsung start Une fois le test généré il sut d'utiliser le script fourni par Tsung pour générer un rapport : /usr/lib/tsung/bin/tsung_stats.pl Toutes les valeurs dénies précedemment ont été choisies suite à de nombreux test et un étalonnage via la réaction de l'application ROR mise en place sur les serveurs Web Point de vue du Client Toutes les données présentées ici sont issues d'un seul des 2 serveurs du cluster, toujours le même an de bien remarquer les eets de l'équilibrage. Deux grands points vont être relevés : le nombre de connexions simultanées et le taux de réponses correctes (code HTTP 200). HTML Pour commencer nos tests, nous allons utiliser Tsung sur un serveur sans équilibreur avec une page statique HTML ("It works."). 34

36 Fig. 3.1 Nombre d'utilisateurs connectés simultanément Ce graphique montre que le nombre d'utilisateurs connectés simultanément est constant, on en déduit donc que sur une page statique, le serveur répond très bien. Fig. 3.2 Temps de réponse Ce graphique montre que le temps de réponse du serveur Web pour chaque requête est lui aussi constant. Il y a un pic au début, c'est le temps qu'apache fork les processus an de répondre aux requêtes. Au travers de ces deux graphiques on se rend compte que le serveur n'éprouve aucune dicultés à répondre aux requêtes qui lui sont adressées. PHP sans BDD Nous étudions maintenant la réaction d'un des 2 serveurs du cluster sans/avec équilibrage sur une page dynamique. Pour ce faire, nous utilisons sur les serveurs Web, un simple phpinfo. 35

37 Fig. 3.3 Nombre d'utilisateurs connectés simultanément Fig. 3.4 Temps de réponse Les performances relevés ci-dessus ont été obtenues sans équilibrage. Celles-ci étant très similaires avec l'équilibrage, il n'est pas nécessaire de nous y attarder. On constate que comme avec les tests de page HTML statique le serveur n'éprouve pas de problème pour gérer les requêtes. PHP avec BDD Nous passons maintenant à un test de charge sur une page PHP ayant un accès à une base de données MySQL. Nous utilisons ici un CMS déployé sur ces serveurs an d'obtenir un point de comparaison pour l'application ROR. Voici donc côte-à-côte les résultats sans et avec équilibrage de charge : 36

38 Fig. 3.5 Nombre d'utilisateurs connectés simultanément sans eq. Fig. 3.6 Nombre d'utilisateurs connectés simultanément avec eq. On remarque qu'avec un équilibreur les connexions sont gérées de façon plus souple que sans. 37

39 Fig. 3.7 Temps de réponse sans eq. Fig. 3.8 Temps de réponse avec eq. La diérence est ici beaucoup plus agrante qu'avec le nombre d'utilisateurs simultanés. En eet, la moyenne du temps de réponse est beaucoup plus faible avec l'équilibreur. Ici le gain est donc considérable et favorisera une navigation plus rapide pour le client. 38

40 Ruby Maintenant que nous disposons de notre point de comparaison en PHP, passons au test de charge de l'application ROR. Voici donc toujours dans le même ordre, les résultats du test sans puis avec équilibrage de charge. Fig. 3.9 Nombre d'utilisateurs connectés simultanément sans eq. Fig Nombre d'utilisateurs connectés simultanément avec eq. Ici, on s'aperçoit que lorsque l'équilibreur n'est pas mis en place, le nombre d'utilisateurs grimpe à 350, le serveur n'arrive pas à gérer toutes les connexions et les mets en attente. Dans le cas où l'équilibrage est mis en place, le serveur arrive facilement à gérer les utilisateurs connectés avec une constante de 200 utilisateurs simultanés. 39

41 Fig Temps de réponse sans eq. Fig Temps de réponse avec eq. Nous pouvons voir, d'après les résultats présentés précedemment et notamment pour le test de charge de l'application ROR, que notre équilibrage de charge fonctionne et permet des gains de performance non négligeables Point de vue de l'administrateur Du côté de l'administrateur, ce qui nous intéresse, ce sont les réactions des serveurs lors de ces diérents tests. Voici donc les diverses caractéristiques que nous avons relevés. 40

42 41 Fig Évolution de la charge CPU du serveur surveillé

43 42 Fig Évolution de l'utilisation mémoire du serveur surveillé

44 En ce qui concerne le premier graphique, on voit bien par exemple que lors des tests de montées de charges sur une page dynamique en PHP sans équilibrage (3), la charge CPU est montée jusqu'à 85%. Si l'équilibrage est actif, la charge CPU est 25% moins importante. Le test est encore plus représentatif avec l'application ROR car on passe d'une charge de pratiquement 100% a à peine 45% de charge. Le gain apporté ici par l'équilibrage est non négligeable. Le dernier graphique représente l'utilisation de la mémoire. Ici par exemple avec l'application PHP (3) sans équilibrage, il y a 500Mo d'utilisé pour répondre aux requêtes alors que lorsque l'équilibrage est mis en place, on gagne environ 250Mo en passant à 250Mo. En ce qui concerne l'application ROR (5), on passe d'environ 180Mo sans équilibrage à 140Mo avec la mise en place de l'équilibrage (6). Nous pouvons voir sur ces résultats que les ressources nécessaires sans équilibrage de charge peuvent vite surcharger le serveur tandis qu'avec l'équilibrage, celles-ci restent tout à fait disponible. 3.6 Conclusion Étant donné les diérents résultats présentés dans cette partie, nous pouvons en conclure que notre équilibrage fonctionne parfaitement puisqu'il permet aux clients d'accéder au site plus rapidement en cas d'encombrement tout en réduisant les ressources nécessaires sur les diverses machines du cluster. De plus la solution de haute disponibilité nous assure une sécurité supplémentaire en cas de défaillance au niveau de l'équilibreur, d'un serveur ou de la base de données. 43

45 Chapitre 4 Divers 4.1 Bibliographie LVS et Haute-disponibilité : http ://www.linuxvirtualserver.org/ Exemples de Haute-disponibilité : http ://www.haute-disponibilite.net/ Tsung : http ://www.process-one.net/en/tsung/ Linux Magazine 97 : Cluster haute-disponibilité avec équilibrage de charge Ruby On Rails : http ://rubyonrails.org/ Diérents tests d'apache, mongrel : http ://blog.kovyrin.net/ Réplication DRBD : http ://2005.jres.org/paper/91.pdf Réplication MySQL : http ://dev.mysql.com/doc/refman/5.0/fr/replication.html 4.2 Compte rendu projet Tutoré Une bonne conduite de projet n'est rien sans un planning et une bonne répartition des tâches. Bien qu'une très grande partie ait été faite entièrement en commun, certains éléments ont été attribués séparément Nous Jachniewicz Rémi Durée approximative de travail : Environ 140 heures. Tâches : Mise en place SVN Recherches sur équilibrage de charge et Haute Disponibilité. Recherches/Déploiement LVS simple. Recherches/Déploiement LVS + Ldirectord. Recherches/Déploiement Heartbeat. Recherches d'outils de monitoring. 44

46 Recherches/Déploiement Munin. Recherches/Déploiement Ganglia. Protocoles de tests. Gestion des Tests avec Tsung. Rapport (en parallèle avec le reste). Gaspard Gatien Ces tâches sont répertoriés par groupe et non chronologiquement et représentent un travail total d'environ 140 heures. Recherche de documentation concernant la haute disponibilité et l'équilibrage de charge sous Linux. Étude des divers documents trouvés et isolation des éléments intéressants. Recherches sur la mise en oeuvre de Mongrel sur diérents serveurs Web (Apache, Nginx,...) Développement d'une application ROR simple an de tester le déploiement sur un serveur avec Mongrel. Interfaçage de Mongrel avec Apache. Recherche d'outils de test de charge pour serveurs Web. Rédaction du rapport : Introductions et liens entre diverses parties. Liste non exhaustive de logiciel pour l'équilibrage de charge. Principe et fonctionnement de LVS. Conclusion des diverses parties de l'état de l'art. Rédaction de la mise en oeuvre de Mongrel et du déploiement d'une application ROR. Correction orthographique. Lacava Julien Durée approximative de travail : Environ 125 heures. Recherche de documentation concernant la haute disponibilité et l'équilibrage de charge sous Linux. Recherche et comparatif des diérents serveurs Web. Installation de base des serveurs (Debian, MySQL, Apache) avec Gatien. Recherche et début de déploiement de DRBD au vue d'une éventuelle mise en place (abandonné au prot de MysqlReplication). Recherche et déploiement de la réplication de la base de données avec l'aide de Rémi. Déploiement de l'application PHP. Correction orthographique. Meslard Vincent Durée approximative de travail : 132 heures. Recherche de documentation concernant la haute disponibilité et l'équilibrage de charge sous Linux. Tests de solutions non retenues : serveur web nginx, communication entre le serveur et Rails via fastcgi, utilisation de la virtualisation. 45

47 Application Rails de test. Recherche et déploiement d'applications ROR. Correction orthographique et syntaxique. Uniformisation du rapport Statistiques Tout le travail a été eectué sur un SVN, c'est pourquoi il peut être intéressant de regarder quelques statistiques. Fig. 4.1 Nombre de lignes Rapport On remarque que la progression a été plutôt lente au départ car notre travail portait en grande partie sur la recherche d'informations et d'avis avant toute rédaction. Fig. 4.2 Activité dans la semaine 46

48 On remarque que la plupart des modications se font le vendredi et le lundi en eet les réunions avec notre tuteur se tenaient en partie ces jours. De plus ces journées étaient entièrement dédiées au projet. Fig. 4.3 Activité dans la journée Les modications se font très souvent le matin au vu de ces statistiques. En eet la théorie a souvent été étudiée le matin et appliquée dans l'après-midi Remerciements Philippe Dosch pour nous avoir encadré tout au long du projet. 47

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

Load Balancing. Table des matières. Gatien, Julien, Rémi, Vincent. 2 mars 2009. 1 Le projet 2. 2 L'équilibrage de charge 2. Load Balancing Gatien, Julien, Rémi, Vincent 2 mars 2009 Table des matières 1 Le projet 2 2 L'équilibrage de charge 2 3 Algorithmes 2 4 État de l'art 3 4.1 LVS..........................................

Plus en détail

Load Balancing MASSAOUDI MOHAMED CHAHINEZ HACHAICHI AMENI DHAWEFI ERIJ MAIJED EMNA BOUGHANMI

Load Balancing MASSAOUDI MOHAMED CHAHINEZ HACHAICHI AMENI DHAWEFI ERIJ MAIJED EMNA BOUGHANMI Load Balancing MASSAOUDI MOHAMED CHAHINEZ HACHAICHI AMENI DHAWEFI ERIJ MAIJED EMNA BOUGHANMI Table des matières I. Présentation de l atelier... 2 1. Équilibrage de charge... 2 2. Haute disponibilité...

Plus en détail

Outils Logiciels Libres

Outils Logiciels Libres LP ASRALL Outils Logiciels Libres LDAP, CMS et Haute Disponibilitée Auteurs : Rémi Jachniewicz, Julien Lacava, Gatien Gaspard, Romain Gegout, Benoit Henryon 17 mars 2009 Table des matières I LDAP 3 0.1

Plus en détail

Outils Logiciels Libres

Outils Logiciels Libres LP ASRALL Outils Logiciels Libres LDAP, CMS et Haute Disponibilitée Auteurs : Rémi Jachniewicz, Julien Lacava, Gatien Gaspard, Romain Gegout, Benoit Henryon 20 mars 2009 Table des matières I LDAP 3 0.1

Plus en détail

«clustering» et «load balancing» avec Zope et ZEO

«clustering» et «load balancing» avec Zope et ZEO IN53 Printemps 2003 «clustering» et «load balancing» avec Zope et ZEO Professeur : M. Mignot Etudiants : Boureliou Sylvain et Meyer Pierre Sommaire Introduction...3 1. Présentation générale de ZEO...4

Plus en détail

Service WEB, BDD MySQL, PHP et réplication Heartbeat. Conditions requises : Dans ce TP, il est nécessaire d'avoir une machine Debian sous ProxMox

Service WEB, BDD MySQL, PHP et réplication Heartbeat. Conditions requises : Dans ce TP, il est nécessaire d'avoir une machine Debian sous ProxMox Version utilisée pour la Debian : 7.7 Conditions requises : Dans ce TP, il est nécessaire d'avoir une machine Debian sous ProxMox Caractéristiques de bases : Un service web (ou service de la toile) est

Plus en détail

SERVEUR WEB HAUTE DISPONIBILITÉ

SERVEUR WEB HAUTE DISPONIBILITÉ SERVEUR WEB HAUTE DISPONIBILITÉ Page 1 Table des matières I. Sujet... 3 II. Caractéristiques du projet... 2 A. Contexte... 2 B. Configuration... 2 C. Étapes et gestion du projet et travail en groupe...

Plus en détail

Synthèse sur la protection informatique

Synthèse sur la protection informatique Synthèse sur la protection informatique I. Problématique de la sécurité... 2 II.Introduction à la sûreté de fonctionnement... 6 Notion de haute disponibilité... 6 Évaluation des risques... 7 Tolérance

Plus en détail

Contexte InfoRéseau50. Charles SAINT-LÔ SIO2 Lycée Notre Dame de la Providence Année 2014-2015

Contexte InfoRéseau50. Charles SAINT-LÔ SIO2 Lycée Notre Dame de la Providence Année 2014-2015 Contexte InfoRéseau50 Charles SAINT-LÔ SIO2 Lycée Notre Dame de la Providence Année 2014-2015 1 Présentation du contexte : Je travaille chez InfoRéseau50, qui est une société spécialisée dans la gestion

Plus en détail

Redondance de service

Redondance de service BTS S.I.O. 2 nd Année Option SISR TP 15 Redondance de service 1 Objectifs Mettre en œuvre différentes techniques de haute disponibilité de services et de serveurs. 2 Présentation du déroulement Ce TP se

Plus en détail

Équilibrage de charge

Équilibrage de charge Équilibrage de charge Linux virtual server Un directeur réparti les requêtes Les serveurs ne le savent pas forcément Agit comme un répartiteur de couche 4 Cluster beowulf La charge est répatie de façon

Plus en détail

LOAD-BALANCING AVEC LINUX VIRTUAL SERVER

LOAD-BALANCING AVEC LINUX VIRTUAL SERVER LOAD-BALANCING AVEC LINUX VIRTUAL SERVER Projet CSII1 2008 encadré par M. Ozano Réalisé par : - Yann Garit - Yann Gilliot - Steve Lacroix - Dorian Lamandé - Maxime Panczak - Aymeric Vroomhout CSII1 Année

Plus en détail

Cahier de charges Projet 24

Cahier de charges Projet 24 Cahier de charges Projet 24 Répartition automatique de surcharge sur serveur web virtualisé Etudiants : KAOUACHI Youssef ELFELLAH Amine Encadré par : M. HAYEL Yezekael Année universitaire : 2008/2009 I-

Plus en détail

TP n 2: Mise en place d'un serveur Web avec PHP et MySQL

TP n 2: Mise en place d'un serveur Web avec PHP et MySQL TP n 2: Mise en place d'un serveur Web avec PHP et MySQL Le but de ce TP est de vous apprendre comment installer et congurer un serveur Web avec PHP et MySQL sous Linux. Cela requiert plusieurs étapes

Plus en détail

Architectures en couches pour applications web Rappel : Architecture en couches

Architectures en couches pour applications web Rappel : Architecture en couches Rappel : Architecture en couches Une architecture en couches aide à gérer la complexité : 7 Application 6 Presentation 5 Session Application Les couches hautes dépendent des couches basses 4 Transport

Plus en détail

Proxy et reverse proxy. Serveurs mandataires et relais inverses

Proxy et reverse proxy. Serveurs mandataires et relais inverses Serveurs mandataires et relais inverses Qu'est-ce qu'un proxy? Proxy = mandataire (traduction) Un proxy est un service mandataire pour une application donnée. C'est à dire qu'il sert d'intermédiaire dans

Plus en détail

Solution Haute Disponibilité pour Linux

Solution Haute Disponibilité pour Linux Solution Haute Disponibilité pour Linux Nicolas Schmitz Ecole Centrale de Nantes Nicolas.Schmitz@ec-nantes.fr Introduction La haute disponibilité c'est notamment : Doubler au maximum le matériel Mettre

Plus en détail

Heartbeat - cluster de haute disponibilité

Heartbeat - cluster de haute disponibilité Page 1 sur 7 L'idée générale pour assurer la disponibilité d'un service est de faire fonctionner plusieurs machines (deux au minimum) en même temps. Ces machines forment ce qu'on appelle un cluster et

Plus en détail

SECURIDAY 2012 Pro Edition

SECURIDAY 2012 Pro Edition SECURINETS CLUB DE LA SECURITE INFORMATIQUE INSAT SECURIDAY 2012 Pro Edition [LOAD BALANCING] Chef Atelier : Asma JERBI (rt5) Hajer MEHRZI(rt3) Rania FLISS (rt3) Ibtissem OMAR (rt3) Asma Tounsi (rt3la)

Plus en détail

Maintenance et gestion approfondie des Systèmes d exploitation Master 2 SILI. Année universitaire 2014-2015 David Genest

Maintenance et gestion approfondie des Systèmes d exploitation Master 2 SILI. Année universitaire 2014-2015 David Genest Maintenance et gestion approfondie des Systèmes d exploitation Master 2 SILI Année universitaire 2014-2015 David Genest Systèmes d exploitation Master 2 SILI 2014-2015 1 Chapitre I Virtualisation 1 Présentation

Plus en détail

Infrastructure Exemple

Infrastructure Exemple Infrastructure Exemple Table des matières 1. Serveurs...2 1.1 Serveurs physiques...2 1.2 Serveurs Virtuels...2 2. Services...3 2.1 Service mail...3 2.2 Service MySQL...3 2.3 Service Web...4 2.4 Cas particulier

Plus en détail

Architecture de la plateforme SBC

Architecture de la plateforme SBC Simple Business Connector Architecture de la plateforme SBC Titre Projet Description Architecture de la plateforme SBC Plateforme SBC Ce document reprend toutes les étapes de l'installation du serveur

Plus en détail

Parcours IT Projet réseaux informatiques Christophe DOIGNON

Parcours IT Projet réseaux informatiques Christophe DOIGNON FORMATION INGENIEURS ENSPS EN PARTENARIAT (2008-2009) MODULE MI6 DU PARCOURS INFORMATIQUE ET TELECOMMUNICATIONS MISE EN OEUVRE D'UN RESEAU INFORMATIQUE LOCAL EMULE ROUTAGE SOUS LINUX 1. Introduction La

Plus en détail

Serveur Web Apache2. un beau message va s'afficher dans votre navigateur it work, c'est le contenu du fichier /var/www/index.html

Serveur Web Apache2. un beau message va s'afficher dans votre navigateur it work, c'est le contenu du fichier /var/www/index.html Wilson Leclercq Serveur Web Apache2 BTS SIO - E6 La Mise en Place du Serveur Apache 1 Présentation Apache est le plus populaire des serveurs HTTP ('HyperText Transfer Protocole') Libre, c'est un Protocole

Plus en détail

Afin d'éviter un message d'erreur au démarrage du service Apache du type :

Afin d'éviter un message d'erreur au démarrage du service Apache du type : I. INTRODUCTION GLPI (Gestionnaire libre de parc informatique) est une solution open-source de gestion de parc informatique et de gestion des services d assistance aux utilisateurs distribué sous licence

Plus en détail

PHP. Performances. Audit et optimisation LAMP. Julien Pauli. Cyril Pierre de Geyer. Guillaume Plessis. Préface d Armel Fauveau

PHP. Performances. Audit et optimisation LAMP. Julien Pauli. Cyril Pierre de Geyer. Guillaume Plessis. Préface d Armel Fauveau Performances PHP Julien Pauli Cyril Pierre de Geyer Guillaume Plessis Préface d Armel Fauveau Groupe Eyrolles, 2012, ISBN : 978-2-212-12800-0 Table des matières Avant-propos... 1 Pourquoi ce livre?.....................................................

Plus en détail

Synchronisation Mysql (Replication)

Synchronisation Mysql (Replication) Synchronisation Mysql (Replication) [Petit avertissement : Bon, après relecture, je constate que c'est l'un des plus mauvais document que j'ai écrit. Mais bon, il est quand même utile ce torchon.] Nous

Plus en détail

TP PLACO. Journées Mathrice d'amiens Mars 2010

TP PLACO. Journées Mathrice d'amiens Mars 2010 TP PLACO Journées Mathrice d'amiens Mars 2010 Nicolas Vuilmet, Jacquelin Charbonnel, Jacques Foury, Damien Ferney, Benoit Métrot Introduction PLACO est un générateur de plates-formes collaboratives. Il

Plus en détail

Installation et configuration d un serveur Web Sauvegarde et restauration

Installation et configuration d un serveur Web Sauvegarde et restauration Installation et configuration d un serveur Web Sauvegarde et restauration Serveur Web Page 1 Sommaire Présentation 3 Configuration d une machine virtuelle 3 Création d une machine virtuelle 3 Configuration

Plus en détail

ZABBIX est distribué sous licence GNU General Public License Version 2 (GPL v.2).

ZABBIX est distribué sous licence GNU General Public License Version 2 (GPL v.2). Nom du projet : Zabbix Description : ZABBIX est un logiciel open source créé par Alexei Vladishev. Zabbix permet de surveiller le statut de divers services réseau, serveurs et autres matériels réseau.

Plus en détail

Serveur de partage de documents. Étude et proposition d'une solution afin de mettre en place un serveur de partage de documents.

Serveur de partage de documents. Étude et proposition d'une solution afin de mettre en place un serveur de partage de documents. Serveur de partage de documents Étude et proposition d'une solution afin de mettre en place un serveur de partage de documents. Table des matières Création de la machine virtuelle Debian... 3 Présentation

Plus en détail

Utilisation du Rôle IIS :

Utilisation du Rôle IIS : Utilisation du Rôle IIS : I. Installation du Rôle "Serveur Web" Dans la console de gestion du serveur Windows 2008, ajouter un rôle : Sélectionner le rôle "Serveur Web" : Ajouter "CGI" afin de permettre

Plus en détail

HAPROXY 1- CREATION DES DEUX SERVEUR WEB

HAPROXY 1- CREATION DES DEUX SERVEUR WEB HAPROXY 1- CREATION DES DEUX SERVEUR WEB Tout d abord je me connecte à VM Ware afin d utiliser la machine virtuelle Linux qui faisant office de serveur web et ayant pour adresse IP : 192.168.3.10 Sur cette

Plus en détail

Réf. 2402 Implémentation et gestion de Microsoft Exchange Server 2003

Réf. 2402 Implémentation et gestion de Microsoft Exchange Server 2003 Public Ce cours est destiné aux informaticiens qui gèrent une messagerie électronique dans un environnement comprenant entre 250 et 5000 utilisateurs, réparti sur de nombreux sites, utilisant divers protocoles

Plus en détail

Un serveur FTP chez soi Tutoriel pour Filezilla FTP server

Un serveur FTP chez soi Tutoriel pour Filezilla FTP server Space-OperaRécitsLogicielsCréationsBlogForum Un serveur FTP chez soi Tutoriel pour Filezilla FTP server DynDNS : Pourquoi et comment? Téléchargement et installation de Filezilla Server Configuration réseau

Plus en détail

eth0 10.254.52.1/24 eth1 10.52.1.1/24 Sn Serveur Apache

eth0 10.254.52.1/24 eth1 10.52.1.1/24 Sn Serveur Apache APACHE Configuration et administration d un serveur 1 : Mise en place du réseau Schéma logique stp 10.254.0.254 eth0 10.254.52.1/24 eth0 10.52.1.3/24 eth1 10.52.1.1/24 Sn Serveur Apache eth2 10.52.2.1/24

Plus en détail

«Clustering» et «Load balancing» avec Zope et ZEO

«Clustering» et «Load balancing» avec Zope et ZEO «Clustering» et «Load balancing» avec Zope et ZEO IN53 Printemps 2003 1 Python : généralités 1989 : Guido Van Rossum, le «Python Benevolent Dictator for Life» Orienté objet, interprété, écrit en C Mêle

Plus en détail

Le client/serveur repose sur une communication d égal à égal entre les applications.

Le client/serveur repose sur une communication d égal à égal entre les applications. Table des matières LES PRINCIPES DE BASE... 1 Présentation distribuée-revamping...2 Présentation distante...3 Traitements distribués...3 données distantes-rd...4 données distribuées-rda distribué...4 L'ARCHITECTURE

Plus en détail

Téléchargement d OCS Inventory Serveur et Agent. Sommaire

Téléchargement d OCS Inventory Serveur et Agent. Sommaire Téléchargement d OCS Inventory Serveur et Agent Tout d abord, Connectez-vous sur le site suivant : http://www.ocsinventory-ng.org/ Sélectionner le langage Français en cliquant sur le drapeau France Cliquer

Plus en détail

Architectures haute disponibilité avec MySQL. Olivier Olivier DASINI DASINI - - http://dasini.net/blog

Architectures haute disponibilité avec MySQL. Olivier Olivier DASINI DASINI - - http://dasini.net/blog Architectures haute disponibilité avec MySQL Architectures Architectures haute disponibilité haute disponibilité avec MySQL avec MySQL Olivier Olivier DASINI DASINI - - http://dasini.net/blog Forum PHP

Plus en détail

La continuité de service

La continuité de service La continuité de service I INTRODUCTION Si la performance est un élément important de satisfaction de l'utilisateur de réseau, la permanence de la disponibilité des ressources l'est encore davantage. Ici

Plus en détail

Publication d'application

Publication d'application Publication d'application Vue d'ensemble JetClouding supporte 3 types de publication d'application: Microsoft Remote Desktop: L'utilisateur verra le Bureau à distance Windows dans la session. Le contrôle

Plus en détail

Tutoriel compte-rendu Mission 1

Tutoriel compte-rendu Mission 1 Mission 1 : Inventaire de l ensemble du matériel BTS SIO 2 2012/2013 MUNIER Julien Tutoriel compte-rendu Mission 1 Sommaire I - OCS Inventory Agent a) Installation et configuration Agent b) Installation

Plus en détail

SQUID P r o x y L i b r e p o u r U n i x e t L i n u x

SQUID P r o x y L i b r e p o u r U n i x e t L i n u x SQUID P r o x y L i b r e p o u r U n i x e t L i n u x 1. P r é s e n t a t i o n : SQUID est un proxy (serveur mandataire en français) cache sous linux. De ce fait il permet de partager un accès Internet

Plus en détail

Installation d'un serveur DHCP sous Windows 2000 Serveur

Installation d'un serveur DHCP sous Windows 2000 Serveur Installation d'un serveur DHCP sous Windows 2000 Serveur Un serveur DHCP permet d'assigner des adresses IP à des ordinateurs clients du réseau. Grâce à un protocole DHCP (Dynamic Host Configuration Protocol),

Plus en détail

BTS SIO SISR3 TP 1-I Le service Web [1] Le service Web [1]

BTS SIO SISR3 TP 1-I Le service Web [1] Le service Web [1] SISR3 TP 1-I Le service Web [1] Objectifs Comprendre la configuration d'un service Web Définir les principaux paramètres d'exécution du serveur Gérer les accès aux pages distribuées Mettre à disposition

Plus en détail

Cosnefroy Thibaut Mars 2015 BTS 2 SIO Répartition de charge serveur web (debian wheezy) Version 1.0 (03/03/2015)

Cosnefroy Thibaut Mars 2015 BTS 2 SIO Répartition de charge serveur web (debian wheezy) Version 1.0 (03/03/2015) Conditions requises: Avoir deux machines déja configurés et prêtes pour faire de la répartition de charge entre machines. La première machine à pour adresse 10.0.0.2 et aura juste apache 2 d'installé.

Plus en détail

DOCUMENTATION TECHNIQUE

DOCUMENTATION TECHNIQUE DOCUMENTATION TECHNIQUE Installation et configuration d un serveur OCS Inventory et GLPI Active Directory et DHCP Benjamin Dupuy BTS Services Informatiques aux Organisations Option : Solutions d infrastructures,

Plus en détail

E-mail : contact@nqicorp.com - Web : http://www.nqicorp.com

E-mail : contact@nqicorp.com - Web : http://www.nqicorp.com - 5, rue Soutrane - 06560 Valbonne Sophia-Antipolis E-mail : contact@nqicorp.com - Web : http://www.nqicorp.com NQI Orchestra 3.3 - Guide d'installation Windows.................................................................

Plus en détail

Introduction aux Systèmes Distribués. Introduction générale

Introduction aux Systèmes Distribués. Introduction générale Introduction aux Systèmes Distribués Licence Informatique 3 ème année Introduction générale Eric Cariou Université de Pau et des Pays de l'adour Département Informatique Eric.Cariou@univ-pau.fr 1 Plan

Plus en détail

Linux Solutions de Haute Disponibilité (2ième édition)

Linux Solutions de Haute Disponibilité (2ième édition) Introduction 1. Introduction 19 2. Remerciements 22 Disponibilité du stockage 1. Introduction au SAN 23 1.1 Mutualiser le stockage 23 1.2 Avantages 24 1.3 Protocoles 25 1.4 Infrastructure 26 1.5 Accès

Plus en détail

Tests de montée en charge & Haute disponibilité

Tests de montée en charge & Haute disponibilité V1.7 Tests de montée en charge & Haute disponibilité Appliqués à l ENT de Paris Descartes ESUP-Days 13 8 Fév 2012 Sommaire Contexte et enjeux à Paris Descartes Une architecture Apache/Tomcat en «load balancing»

Plus en détail

OpenMediaVault installation

OpenMediaVault installation OpenMediaVault installation 2013-01-13/YM: version initiale 1 Introduction L'installation de OpenMediaVault, basé sur Debian, présente quelques difficultés pour l'utilisateur de Windows. Cette procédure

Plus en détail

[Serveur de déploiement FOG]

[Serveur de déploiement FOG] 2012 Yann VANDENBERGHE TAI @ AFPA Lomme [Serveur de déploiement FOG] Procédure d'installation d'un serveur FOG pour la création et le déploiement d'images disques. 1.1 Introduction : Malgré le développement

Plus en détail

TARDITI Richard Mise en place d une Haute Disponibilité

TARDITI Richard Mise en place d une Haute Disponibilité TARDITI Richard Mise en place d une Haute Disponibilité Dans le cadre du projet GSB j ai mis en place un cluster de deux machines virtuelles Apache sous Linux, avec une haute disponibilité produite grâce

Plus en détail

GOUTEYRON ALEXIS. SIO2 N candidat: 0110692972. UEpreuve E4. USituation professionnelle 2. serveurs de fichiers. Uen haute disponibilité

GOUTEYRON ALEXIS. SIO2 N candidat: 0110692972. UEpreuve E4. USituation professionnelle 2. serveurs de fichiers. Uen haute disponibilité GOUTEYRON ALEXIS SIO2 N candidat: 0110692972 UEpreuve E4 USituation professionnelle 2 serveurs de fichiers Uen haute disponibilité Session 2014 2015 I- Présentation a) Utilité Aujourd hui, dans le monde

Plus en détail

Documentation UpdatEngine Installation et migration version 2.1.1 stable

Documentation UpdatEngine Installation et migration version 2.1.1 stable Documentation UpdatEngine Installation et migration version 2.1.1 stable Version de la documentation : doc-2.1.1-stable-1 Auteur: Yves Guimard Référence internet : http://www.updatengine.com Licence Creative

Plus en détail

DOCUMENTATION PROJET SERVEURS WEB APACHE2. Voiset Nicolas BASINFORMATIQUE CARPENTRAS

DOCUMENTATION PROJET SERVEURS WEB APACHE2. Voiset Nicolas BASINFORMATIQUE CARPENTRAS DOCUMENTATION PROJET SERVEURS WEB APACHE2 Voiset Nicolas BASINFORMATIQUE CARPENTRAS SUIVI DU DOCUMENT MISES A JOUR Version Date Auteurs Objet de la mise à jour 1.0 10/02/2015 Nicolas Voiset Version initiale.

Plus en détail

FACILITER LES COMMUNICATIONS. Le gestionnaire de réseau VPN global de Saima Sistemas

FACILITER LES COMMUNICATIONS. Le gestionnaire de réseau VPN global de Saima Sistemas FACILITER LES COMMUNICATIONS Le gestionnaire de réseau global de Saima Sistemas Afin d'améliorer le service proposé à ses clients, SAIMA SISTEMAS met à leur disposition le SAIWALL, gestionnaire de réseau

Plus en détail

DESCRIPTION DU CONTEXTE INFORMATIQUE ET MISE EN PLACE DU CONTEXTE

DESCRIPTION DU CONTEXTE INFORMATIQUE ET MISE EN PLACE DU CONTEXTE DESCRIPTION DU CONTEXTE INFORMATIQUE ET MISE EN PLACE DU CONTEXTE Sommaire Description du réseau GSB... 2 Réseau GSB original... 2 Réseau GSB utilisé en PPE... 2 Liste des s de l'infrastructure... 3 Implémentation

Plus en détail

Principes de DHCP. Le mécanisme de délivrance d'une adresse IP à un client DHCP s'effectue en 4 étapes : COMMUTATEUR 1. DHCP DISCOVER 2.

Principes de DHCP. Le mécanisme de délivrance d'une adresse IP à un client DHCP s'effectue en 4 étapes : COMMUTATEUR 1. DHCP DISCOVER 2. DHCP ET TOPOLOGIES Principes de DHCP Présentation du protocole Sur un réseau TCP/IP, DHCP (Dynamic Host Configuration Protocol) permet d'attribuer automatiquement une adresse IP aux éléments qui en font

Plus en détail

Configuration matériel. Tâche 2 : Installation proprement dite de l application sur un serveur de test virtualisé sous VmWare Workstation.

Configuration matériel. Tâche 2 : Installation proprement dite de l application sur un serveur de test virtualisé sous VmWare Workstation. PPE 1 MISSION 1 Tâche 1 : Se renseigner sur les exigences logicielles et matérielles de l utilisation de MRBS sur une distribution Linux (Debian). Proposer une configuration matérielle suffisante pour

Plus en détail

TP : installation de services

TP : installation de services TP : installation de services Ce TP a été rédigé rapidement. Il ne donne certainement pas toutes les explications nécessaires à la compréhension des manipulations. Assurez vous de bien comprendre ce que

Plus en détail

BTS SIO 2. Projet GSB. Apache 2. Voiset Nicolas

BTS SIO 2. Projet GSB. Apache 2. Voiset Nicolas BTS SIO 2 Projet GSB Apache 2 Voiset Nicolas 1 Table des matières 1-Contexte d utilisation... 3 2-Informations d utilisation... 5 3-Comparaison... 5 4-Problèmes et solutions... 6 5-Phase de test... 6 Annexe1-Configuration

Plus en détail

Projet «Get Host In»

Projet «Get Host In» oui Projet «Get Host In» Equipe Projet Sebastien Duthil Johann Camus Alexandre Adjévi Koudossou Historique des révisions Date Version Description Auteurs 10 10 2006 16 10 2006 18 10 2006 23 10 2006 24

Plus en détail

INSTALLATION ET CONFIGURATION SERVEUR RSYSLOG

INSTALLATION ET CONFIGURATION SERVEUR RSYSLOG INSTALLATION ET CONFIGURATION SERVEUR RSYSLOG Table des matières 1. Préambule... 2 2. Pré-requis... 2 3. Installation et configuration du serveur... 3 3.1. Installation... 3 3.1.1. Rsyslog... 3 3.1.2.

Plus en détail

VMWare Infrastructure 3

VMWare Infrastructure 3 Ingénieurs 2000 Filière Informatique et réseaux Université de Marne-la-Vallée VMWare Infrastructure 3 Exposé système et nouvelles technologies réseau. Christophe KELLER Sommaire Sommaire... 2 Introduction...

Plus en détail

Guide d utilisation. Manuel d utilisation et d installation du système d exploitation UBUNTU 10.04.3 et d'installation d'un serveur LAMP.

Guide d utilisation. Manuel d utilisation et d installation du système d exploitation UBUNTU 10.04.3 et d'installation d'un serveur LAMP. Manuel d utilisation et d installation du système d exploitation UBUNTU 10.04.3 et d'installation d'un serveur LAMP. -- 1 -- Lycée Bahuet Table des matières Avant propos... - 5 - Démarrage d Ubuntu...

Plus en détail

Installation d'un Serveur AMPP sous Gnu/Linux. (Apache Mysql Php Phymyadmin)

Installation d'un Serveur AMPP sous Gnu/Linux. (Apache Mysql Php Phymyadmin) Installation d'un Serveur AMPP sous Gnu/Linux (Apache Mysql Php Phymyadmin) AMPP : Sommaire Introduction Prérequis Installation d'apache Installation de mysql Installation de php4 et phpmyadmin Configuration

Plus en détail

Le laboratoire Galaxy Swiss Bourdin (GSB)

Le laboratoire Galaxy Swiss Bourdin (GSB) Le laboratoire Galaxy Swiss Bourdin (GSB) Page 0 PROJET D ETUDE SUR LA MISE EN PLACE D UN Travail effectué par : LARANT Wilfried LEMAITRE Florian COMOTTI Arnaud Page 1 Table des matières I. Objectif...

Plus en détail

Prise de contrôle à distance de PC

Prise de contrôle à distance de PC Prise de contrôle à distance de PC VNC = Virtual Network Computing Il sagit de prendre très facilement le contrôle d'un PC à distance en utilisant un programme performant. Par exemple, si vous souhaitez

Plus en détail

Technologies du Web. Créer et héberger un site Web. Pierre Senellart. Page 1 / 26 Licence de droits d usage

Technologies du Web. Créer et héberger un site Web. Pierre Senellart. Page 1 / 26 Licence de droits d usage Technologies du Web Créer et héberger un site Web Page 1 / 26 Plan Planification Choisir une solution d hébergement Administration Développement du site Page 2 / 26 Cahier des charges Objectifs du site

Plus en détail

MySQL - Réplication. Fichiers de relais et de statut de la réplication. Mise en place de la réplication

MySQL - Réplication. Fichiers de relais et de statut de la réplication. Mise en place de la réplication MySQL - Réplication Réplication MySQL MySQL supporte la réplication unidirectionnelle interne. Un serveur sert de maître, et les autres servent d esclaves. Le serveur entretient des logs binaires, ainsi

Plus en détail

Cluster High Availability. Holger Hennig, HA-Cluster Specialist

Cluster High Availability. Holger Hennig, HA-Cluster Specialist Cluster High Availability Holger Hennig, HA-Cluster Specialist TABLE DES MATIÈRES 1. RÉSUMÉ...3 2. INTRODUCTION...4 2.1 GÉNÉRALITÉS...4 2.2 LE CONCEPT DES CLUSTERS HA...4 2.3 AVANTAGES D UNE SOLUTION DE

Plus en détail

Introduction. 1 P a g e. Khalid BOURICHE

Introduction. 1 P a g e. Khalid BOURICHE Introduction Basé sur FreeBSD, pfsense est un logiciel de filtrage de flux (Firewall). Comme iptables sur GNU/Linux, il est réputé pour sa fiabilité. Nous y retrouvons la plupart des fonctionnalités incluses

Plus en détail

Fonctionnement et mise en place d un reverse proxy sécurisé avec Apache. Dimitri ségard 8 mai 2011

Fonctionnement et mise en place d un reverse proxy sécurisé avec Apache. Dimitri ségard 8 mai 2011 Fonctionnement et mise en place d un reverse proxy sécurisé avec Apache. Dimitri ségard 8 mai 2011 Sommaire 1 Un peu de théorie 3 1.1 Qu est-ce qu un reverse proxy?................. 3 1.1.1 Généralités........................

Plus en détail

Documentation UpdatEngine Installation et migration version 2.1.0 stable

Documentation UpdatEngine Installation et migration version 2.1.0 stable Documentation UpdatEngine Installation et migration version 2.1.0 stable Version de la documentation : doc-2.1.0-stable-4 Auteur: Yves Guimard Référence internet : http://www.updatengine.com Licence Creative

Plus en détail

Bénéfices de Citrix NetScaler pour les architectures Citrix

Bénéfices de Citrix NetScaler pour les architectures Citrix Bénéfices de Citrix NetScaler pour les architectures Citrix 15 novembre 2007 Auteurs: Mahmoud EL GHOMARI E-mail: mahmoud.elghomari@eu.citrix.com Stéphane CAUNES E-mail: stephane.caunes@eu.citrix.com Riad

Plus en détail

Contribution à la mise en service d'une ferme de serveurs connectée à une grille de calcul pour la physique des hautes énergies

Contribution à la mise en service d'une ferme de serveurs connectée à une grille de calcul pour la physique des hautes énergies Contribution à la mise en service d'une ferme de serveurs connectée à une grille de calcul pour la physique des hautes énergies Charlier Fabrice 2è licence en informatique Année Académique 2005-2006 Plan

Plus en détail

NSY107 - Intégration des systèmes client-serveur

NSY107 - Intégration des systèmes client-serveur NSY107 - Intégration des systèmes client-serveur Cours du 13/05/2006 (4 heures) Emmanuel DESVIGNE Document sous licence libre (FDL) Plan du cours Introduction Historique Les différentes

Plus en détail

Solution d inventaire automatisé d un parc informatique et de télédistribution OCS INVENTORY NG. EHRHARD Eric - Gestionnaire Parc Informatique

Solution d inventaire automatisé d un parc informatique et de télédistribution OCS INVENTORY NG. EHRHARD Eric - Gestionnaire Parc Informatique Solution d inventaire automatisé d un parc informatique et de télédistribution OCS INVENTORY NG EHRHARD Eric - Gestionnaire Parc Informatique 1 Possibilités d OCS Inventory. Informations d'inventaire pertinentes.

Plus en détail

ARTICLE : élément de «base» contenant texte et ressources diverses. Peut avoir plusieurs statuts (visible ou non publiquement, entre autres),

ARTICLE : élément de «base» contenant texte et ressources diverses. Peut avoir plusieurs statuts (visible ou non publiquement, entre autres), Terminologie ARTICLE : élément de «base» contenant texte et ressources diverses. Peut avoir plusieurs statuts (visible ou non publiquement, entre autres), RUBRIQUE : contenant d'articles et/ou de rubriques

Plus en détail

INTRODUCTION. Mysql-server est un serveur de bases de données. Cest un logiciel libre.

INTRODUCTION. Mysql-server est un serveur de bases de données. Cest un logiciel libre. INTRODUCTION Mysql-server est un serveur de bases de données. Cest un logiciel libre. Une base de données informatique est un ensemble de données qui ont été stockées sur un support informatique, organisées

Plus en détail

Master d'informatique. Réseaux. Proxies et filtrage applicatif

Master d'informatique. Réseaux. Proxies et filtrage applicatif Master d'informatique Réseaux Proxies et filtrage applicatif Bureau S3-354 mailto:jean.saquet@info.unicaen.fr http://www.info.unicaen.fr/~jean/radis Proxy applicatif Un proxy, ou serveur mandataire, relaie

Plus en détail

Configuration de plusieurs serveurs en Load Balancing

Configuration de plusieurs serveurs en Load Balancing Le serveur de communication IceWarp Configuration de plusieurs serveurs en Load Balancing Version 10.4 27 février 2013 Icewarp France / DARNIS Informatique i Sommaire Configuration de plusieurs serveurs

Plus en détail

1 LE L S S ERV R EURS Si 5

1 LE L S S ERV R EURS Si 5 1 LES SERVEURS Si 5 Introduction 2 Un serveur réseau est un ordinateur spécifique partageant ses ressources avec d'autres ordinateurs appelés clients. Il fournit un service en réponse à une demande d un

Plus en détail

ARCHITECTURE CLIENT / SERVEUR

ARCHITECTURE CLIENT / SERVEUR ARCHITECTURE CLIENT / SERVEUR ARCHITECTURE CLIENT/SERVEUR Définition : L'architecture client serveur s'appuie sur un poste central, le serveur, qui envoit des données aux machines clientes. Des programmes

Plus en détail

Architecture Constellio

Architecture Constellio Architecture Constellio Date : 12 novembre 2013 Version 3.0 Contact : Nicolas Bélisle nicolas.belisle@doculibre.com 5146555185 1 Table des matières Table des matières... 2 Présentation générale... 4 Couche

Plus en détail

Installation d OwnCloud 8.0 sous Debian Avec connexion des utilisateurs active directory et mise en place de HTTPS

Installation d OwnCloud 8.0 sous Debian Avec connexion des utilisateurs active directory et mise en place de HTTPS Installation d OwnCloud 8.0 sous Debian Avec connexion des utilisateurs active directory et mise en place de HTTPS FOURNIER VINCENT 29/04/2015 1.2 Ce tutoriel est réalisé sous debian 7.7 avec une synchronisation

Plus en détail

Exchange Server 2013 Préparation à la certification MCSE Messaging - Examen 70-341

Exchange Server 2013 Préparation à la certification MCSE Messaging - Examen 70-341 Chapitre 1 Introduction à Exchange A. Présentation d'exchange 16 1. Public visé 16 2. La messagerie au sein de l entreprise 16 3. L évolution des plateformes Exchange 17 B. Introduction à Exchange 2O13

Plus en détail

LOSLIER Mathieu IR1 31 Mai 2011. Rapport TP Firewall

LOSLIER Mathieu IR1 31 Mai 2011. Rapport TP Firewall Rapport TP Firewall 1 Table des matières Rapport TP Firewall... 1 Introduction... 3 1. Plate-forme de sécurité étudiée... 3 2. Routage classique... 3 2.1 Mise en œuvre du routage classique... 4 2.2 Configuration

Plus en détail

Les messages d erreur d'applidis Client

Les messages d erreur d'applidis Client Fiche technique AppliDis Les messages d erreur d'applidis Client Fiche IS00313 Version document : 1.00 Diffusion limitée : Systancia, membres du programme Partenaires AppliDis et clients ou prospects de

Plus en détail

Exchange Server 2013 Configuration et gestion de votre environnement de messagerie

Exchange Server 2013 Configuration et gestion de votre environnement de messagerie Introduction à Exchange 1. Présentation d'exchange 17 1.1 La messagerie au sein de l entreprise 17 1.2 L évolution des plateformes Exchange 18 2. Introduction à Exchange 2O13 23 2.1 Contribution aux métiers

Plus en détail

BTS SIO 2012-2014. Dossier BTS. PURCHLA Romain

BTS SIO 2012-2014. Dossier BTS. PURCHLA Romain BTS SIO 2012-2014 Dossier BTS PURCHLA Romain 2012-2014 Lors d une création de serveur web plusieurs solution nous son proposé en voici quelques une. - LAMP (Linux, Apache, MySql, Php) La mise en place

Plus en détail

Hébergement de site web Damien Nouvel

Hébergement de site web Damien Nouvel Hébergement de site web Plan L'hébergeur Le serveur web Apache Sites dynamiques 2 / 27 Plan L'hébergeur Le serveur web Apache Sites dynamiques 3 / 27 L'hébergeur L'hébergeur sous-traite l'architecture

Plus en détail

ALOHA Load Balancer 2.5. Guide de démarrage rapide. EXCELIANCE ALOHA 2.5 Guide de démarrage rapide 30/01/2008 1/17

ALOHA Load Balancer 2.5. Guide de démarrage rapide. EXCELIANCE ALOHA 2.5 Guide de démarrage rapide 30/01/2008 1/17 ALOHA Load Balancer 2.5 Guide de démarrage rapide 1/17 Table des matières 1 - Contenu de l'emballage... 3 2 - Phase préparatoire... 3 3 - Configuration d'usine... 3 4 - Branchement du boîtier (ALOHA load

Plus en détail

Programmation d applications pour le Web

Programmation d applications pour le Web Programmation d applications pour le Web Cours 2 ème année ING ISI-Tunis Elaboré par: Hela LIMAM Chapitre 1 Architectures et applications du Web Année universitaire 2011/2012 Semestre 2 1 Plan Internet,

Plus en détail

Cluster. Une introduction aux architectures systèmes distribuées. Université de Haute Alsace Octobre 2003

Cluster. Une introduction aux architectures systèmes distribuées. Université de Haute Alsace Octobre 2003 Cluster Une introduction aux architectures systèmes distribuées Université de Haute Alsace Octobre 2003 Plan Généralisation Technique Introduction Applications $$$ Définition Questions? Idées Plan Plan

Plus en détail

La sécurité. Chapitre 6. 1. Introduction. 2. La sécurité des accès

La sécurité. Chapitre 6. 1. Introduction. 2. La sécurité des accès 259 Chapitre 6 La sécurité 1. Introduction La sécurité La sécurité des données est un enjeu capital. Une base de données peut être amenée à stocker des données très sensibles, confidentielles. L'implémentation

Plus en détail