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

Transcription

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

2 Table des matières I. Présentation de l atelier Équilibrage de charge Haute disponibilité... 2 II. Présentation des outils utilisés Répartition de charge... 3 a) DNS... 3 b) HaProxy... 3 c) LVS... 3 d) Apache - mod_proxy_balancer... 3 e) Pen Haute Disponibilité... 4 a) Drbd... 4 b) Heartbeat... 5 c) Ultramonkey Choix des outils utilisés... 6 a) Le DNS round-robin, le load-balancer du pauvre... 6 b) Load-balancer hardware/software... 6 III. Topologie du réseau... 7 IV. Configuration des outils... 8 V. Un scénario de test... 9 VI. Conclusion

3 I. Présentation de l atelier Load Balancing SECURILIGHT É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 afin d'éviter toute dégradation que ce soit en terme de performances ou de fiabilité lors d'affluences importantes. Le principe de base de l'équilibrage de charge (load balancing en anglais) consiste à effectuer une distribution des tâches à des machines de façon intelligente. 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. 2. 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 effectué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. 2

4 3 Load Balancing SECURILIGHT 2013 II. Présentation des outils utilisés 1. Répartition de charge a) DNS Dans cette solution le répartiteur de charge est le serveur DNS. Basé sur la configuration 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 diffé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 sufft d'ajouter quelques lignes à la configuration de bind 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. b) HaProxy HAProxy 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 : Il 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 : reconfiguration à chaud impossible, pas d'interface Web de configuration, pas de centralisation des configurations. c) LVS Linux Virtual Server 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 différents ports TCP. d) Apache - mod_proxy_balancer À partir de apache 2.1, en utilisant le module mod_proxy_balancer, il est possible de faire de l'équilibrage de charge pour les protocoles HTTP, FTP et AJP13 (Apache JServ Protocol utilisé principalement avec Tomcat pour rediriger les sessions vers le bon serveur et pour faire du monitoring simple). Il intègre trois algorithmes d'ordonnancement : Request Counting, Weighted Trafic Counting et Pending Request Counting. Le module mod_status permet de rajouter des possibilités de gestion dynamique des pondérations de chaque serveur.

5 Avantages : facilité de mise en oeuvre bien maintenu portabilité (toute architecture supportant apache) Inconvénients : protocoles HTTP, FTP et AJP13 uniquement. e) Pen Pen est un load balancer pour les protocoles basés sur TCP. Il permet de distribuer les requêtes de clients sur différents serveurs en gardant une trace de ceux-ci pour renvoyer chaque client vers le serveur qui lui avait été affecté 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 VRRP3 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, Récapitulatif des fonctionnalités 2. 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 afin de limiter les SPOF (Single Point of Failure). Il est ainsi systématique dans ce type de configuration de pratiquer de la réplication de données ainsi que de mettre en place des technologies telles que le RAID afin d'éviter les pertes de données. a) 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. 4

6 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écifique. En effet, 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 fichiers utilisé sur le serveur. b) 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 coeur. Il exécute des scripts d'initialisations lorsque une machine «tombe» (plus d'entente du battement de coeur) ou est à nouveau disponible (battement de coeur 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. c) Ultramonkey Ultramonkey fait partie des solutions tout-en-un permettant de mettre en oeuvre rapidement un équilibrage de charge. 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 différentes machines. 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é offerte par le protocole de Heartbeat, monitoring des services via ldirectord, offre une documentation assez complète sur le déploiement de solutions de haute disponibilité et/ou d'équilibrage de charge, open source, Inconvénients : n'est plus maintenu. 5

7 Récapitulatif des fonctionnalités 3. Choix des outils utilisés Pour l'élaboration d'une architecture de load balancing, nous avons choisi de tester le DNS round-robin et un load-balancer hardware/software. a) Le DNS round-robin, le load-balancer du pauvre Le principe est simple, on a un enregistrement DNS qui pointe vers plusieurs adresses IP. Chaque IP peut avoir un poid différent. A chaque fois qu'un nouveau client fait une requête DNS on lui retourne une IP différente du pool de serveurs. ; exemple de format d un fichier zone ftp IN A IN A IN A www IN A IN A L'inconvénient majeur de cette solution est le cache DNS côté client que l'on ne maîtrise pas. En effet, chaque système d'exploitation, chaque librairie DNS, chaque fournisseur d'accès peut mettre en cache à sa manière les requêtes DNS. Le deuxième problème important est que chaque serveur de notre pool devra avoir une adresse IP publique. Et donc il faut penser en terme de sécurité les conséquences (firewall...). L'utilisation de DNS ne permet malheureusement pas de prendre en compte les capacités ou disponibilités des machines, ainsi une autre solution utilisée est celle du load balancing. b) Load-balancer hardware/software Le concept est hyper connu, on place une machine devant un pool de serveurs et on distribue le trafic entre les différentes machines. 6

8 On peut utiliser du matériel vendu par les géants des réseaux (Cisco ou whatever), ça marche bien, c'est performant et fiable. Mais ça coûte très cher. Sinon, on peut se faire un load-balancer soit-même avec un serveur sous Linux et des logiciels comme HAProxy ou autre. Ces logiciels sont optimisés à mort et fonctionnent bien. Ces deux solutions permettent de détecter si une machine de votre pool est tombée (healthcheck) et d'arrêter de lui envoyer du trafic le temps de résoudre le problème. SE : Serveur Linux CentOS Serveurs/services : Apache2, PHP, Mysql-server installé et configuré à l'identique sur deux serveurs, HAProxy Clients : Windows ou autre système III. Topologie du réseau Une configuration relativement simple va nous permettre de mettre en œuvre la répartition de charge sur deux serveurs Web préalablement installés. La demande de connexion est adressée au serveur HAProxy d'adresse IP qui détermine, selon l'algorithme configuré, le serveur auquel il va affecter la connexion, parmi les serveurs disponibles. Une fois la connexion TCP établie, l équipement de répartition de charge devient pratiquement transparent : dans son rôle de base, il transfère les paquets IP du client vers le serveur sélectionné et vice versa jusqu à fermeture de la connexion. 7

9 IV. Configuration des outils Load Balancing SECURILIGHT 2013 HAProxy peut être utilisé comme un load-balancer, un proxy filtrant, ou les deux. Configuration de HAProxy: théorie La configuration se partage en plusieurs parties: global default frontend backend Options du service. Options par défaut. Elles s'appliqueront partout, sauf si elle sont reprises. Défini la partie publique de HAProxy. Les connexions arriveront donc ici. La partie "privée". Apparaîtront ici le ou les serveurs web qu'haproxy devra protéger. Dans ce cas précis, nous paramétrons différents timeout. Le but de tout cela est de limiter au maximum les effets d'une attaque: timeout client timeout server timeout queue Le temps durant lequel nous attendrons le client Le temps durant lequel nous attendrons le serveur web (backend) Si le backend n'est pas disponible, HAProxy va conserver les requètes en file d'attente. Au bout d'un certain temps, celles-ci seront détruites. timeout http-request Très intéressant pour contrer slowloris: si la requète HTTP n'est pas complètement envoyée en moins 5 secondes, la connexion est fermée car jugée invalide. Si vous avez plus d'un serveur web à protéger, il vous suffit de rajouter une ligne dans la partie backend. HAProxy se comportera alors également en load-balancer, avec tout un tas d'options supplémentaires qu'il vous faudra découvrir et maîtriser. 8

10 Configuration de HAProxy: protection anti-ddos Dans le cas d'une protection contre une attaque DDOS, la configuration peut ressembler à : /etc/haproxy/haproxy.cfg global daemon user haproxy group haproxy maxconn 5000 defaults mode http maxconn 4950 retries 2 timeout client 60s # Client and server timeout must match the longest timeout server 60s # time we may wait for a response from the server. timeout queue 60s # Don't queue requests too long if saturated. timeout connect 4s # There's no reason to change this one. timeout http-request 5s # A complete request may never take that long. option httpclose option abortonclose balance roundrobin option forwardfor # set the client's IP in X-Forwarded-For. retries 2 frontend public bind :80 default_backend webfarm backend webfarm cookie JSESSIONID prefix option httpchk HEAD /check.txt HTTP/1.0 server web :80 cookie W1 check server web :80 cookie W2 check V. Un scénario de test Pour vérifier que la syntaxe du fichier est correcte : haproxy -c pour -c -f /etc/haproxy/haproxy.cfg vérifier (check) le fichier -f pour spécifier le fichier de configuration root@haproxyar:~# haproxy -c -f /etc/haproxy/haproxy.cfg Configuration file is valid 9

11 Pour vérifier que le service fonctionne bien et écoute sur le port 80 avec la commande netstat, en n'affichant que la ligne correspondante à «haproxy» : root@haproxyar:~# netstat -tpnl grep haproxy tcp : :* LISTEN 8877/haproxy haproxy est bien lancé et attend des requêtes sur le port 80. Pour vérifier que le service a bien le comportement attendu, il suffit de se connecter à deux reprises à partir d'un navigateur. 10

12 Puis, on stoppe par exemple le serveur 1 : on aura toujours «server 2» qui répond. VI. Conclusion Comme nous l'avons démontré tout au long de ce rapport, nous pouvons maintenant affirmer que la haute disponibilité permet un gain de confort pour les utilisateurs finaux tout comme pour les administrateurs des systèmes. Quant à l'administration, nous avons vu que la solution HAProxy s'avère très efficace, permettant un déploiement rapide et flexible. De plus, c est un relais TCP/HTTP (il fonctionne donc aux niveau 4 et 7) offrant des facilités d'intégration en environnement hautement disponible. En outre, il requiert peu de ressources et son architecture événementielle mono-processus lui permet de gérer facilement plusieurs milliers de connexions simultanées sur plusieurs relais sans effondrer le système. La répartition de charge permet de résoudre des problématiques de gestion des ressources, de performances et de tolérance aux pannes. Pour garantir une disponibilité maximale, il est nécessaire d'implémenter des mécanismes permettant de synchroniser ou de centraliser les données et les sessions entre les différents serveurs réels et de mettre en place une réplication des bases de données. Pour finir, la répartition de charge à elle seule ne permet pas d'accomplir des miracles et de combler les carences d'une application mal écrite (lente, coûteuse en ressource) ou d'une architecture mal pensée qui générera invariablement des problèmes dans les flux réseaux. 11