Apprentissage des performances, surveillance en temps réel et contrôle d admission d un serveur Web utilisant les techniques neuronales

Transcription

1 SETIT th International Conference: Sciences of Electronic, Technologies of Information and Telecommunications March 25-29, 2007 TUNISIA Apprentissage des performances, surveillance en temps réel et contrôle d admission d un serveur Web utilisant les techniques neuronales R. Fontaine *, P. Laurencot ** et A. Aussem * * LIMOS, Université Blaise Pascal, France & PRISMa, Université Claude Bernard, France fontaine@isima.fr aaussem@bat701.univ-lyon1.fr ** LIMOS, Université Blaise Pascal, France patrice.laurencot@isima.fr Résumé: Nous présentons des modèles de réseaux de neurones (RNs) permettant la prédiction des performances d un serveur Web. Trois RNs sont entraînés pour prédire respectivement le temps moyen de réponse, le pourcentage de rejet et le débit d un serveur Web en fonction des paramètres d optimisation du noyau du système FreeBSD, du serveur Apache et le trafic d arrivée λ, en utilisant l algorithme de rétropropagation du gradient. Tous les trois sont utilisés pour la surveillance en temps réel des performances du serveur Web. Le premier RNs a également servi à contrôler l admission des requêtes sur la base du temps moyen de réponse estimé. Validé par des expérimentations, les RNs combinés avec les modules LIBPCAP et IPFIREWALL, permettent la surveillance en temps réel des métriques des performances et évitent l accroissement indésirable du temps de réponse du serveur Web. Mots-clés : Apprentissage des performances, contrôle d admission, réseaux de neurones, serveur Web, surveillance en temps réel. INTRODUCTION Les modèles d évaluation des performances sont utiles pour localiser les goulets d étranglement responsables de l accroissement indésirable des temps de réponse de certains serveurs Web. Plusieurs facteurs affectent les performances : la vitesse du Client, la bande passante Client-Serveur, et la capacité du serveur lui même. Ce dernier dépend considérablement de la configuration du serveur Apache 1 et de la stabilité du système d exploitation. L optimisation des performances peut se réaliser en modifiant les paramètres du noyau et du fichier de configuration d Apache. Certaines combinaisons de ces paramètres offrent une meilleure performance et affectent par conséquent les valeurs des métriques des performances d un serveur Web. Bien que les serveurs Web actuels sont capables de servir des milliers de requêtes par seconde, le temps moyen de réponse d un serveur peut être long durant la période de 1 pointe. Cette situation frustre les utilisateurs qui sont en interaction avec le serveur et déprécie ainsi la qualité de service du serveur Web. C'est pour cette raison que bon nombre de chercheurs s'intéressent à la qualité de service sur les serveurs Web [ADM 98] [BhF 99] [ChM 99] [EgH 99] [VTF 01]. Le principe de base consiste à mettre en place une différenciation par priorité basée sur la classification des requêtes vers le serveur et un traitement différencié à l intérieur. La classification est réalisée suivant le temps de service requis pour le traitement de la requête, l adresse IP du client, l adresse sous réseau de celui-ci, l URL (Uniform Resource Locator) ou le coockie pour identifier les requêtes comme appartenant à un niveau particulier de service différencié. La notion de priorité de l ordonnancement dans le serveur Web offre un temps de réponse acceptable pour les processus de priorité supérieure contrairement à ceux de priorité inférieure. Néanmoins, au cas où le serveur est surchargé, il est encore possible que des requêtes de priorité supérieure soient abandonnées et qu un temps de réponse acceptable par l'utilisateur ne

2 soit plus assuré. D' où la nécessité d un système de contrôle d'admission pour assurer un débit et un temps de réponse acceptable du serveur Web. [CMC 01] propose un algorithme de contrôle d'admission appelé PACERS (Periodical Admission Control based on Estimation of Request rate and Service time) en utilisant deux files d'attente. La qualité de service a été assurée par une allocation périodique des ressources systèmes basée sur l'estimation du taux d'arrivée des requêtes et le temps de service requit pour les processus de priorité élevée. [ENT 04] préconise la priorité des contenus de sites Web dynamiques. Les auteurs proposent un algorithme simple mais efficace. En effet, le contrôleur d'admission appelé Gatekeeper identifie les différents types de requêtes (i.e servlets) et maintient en ligne le temps de service qui a été requis pour chaque requête à partir des mesures faites sur des exécutions précédentes. Connaissant la capacité du serveur web, le contrôleur d'admission peut maintenir la charge au dessus de cette capacité pour assurer un débit et un temps de réponse acceptables. Dans cet article, nous allons proposer un mécanisme de contrôle d'admission à partir de l'apprentissage des performances d'un serveur Web. Trois RNs seront utilisés pour prédire respectivement le temps moyen de réponse, le pourcentage de rejet et le débit du serveur Web en fonction des paramètres d optimisation du système FreeBSD 2, du serveur Apache et le trafic d arrivée λ, en utilisant l algorithme de rétropropagation du gradient. Notre Contrôle d Admission fonctionne à base du temps moyen de réponse estimé par le premier RNs. L'admission des requêtes est décidée en comparant le temps de réponse estimé par les RNs avec celui fixé d'avance comme étant acceptable. Par ailleurs, nous allons utiliser ces trois RNs pour la surveillance en temps réel du serveur web. L implémentation du contrôle d admission et de la surveillance en temps réel du serveur Web ont été réalisées sur un poste serveur FreeBSD. Ce document est organisé en 6 sections. Après un bref rappel du fonctionnement d un serveur Web, nous présenterons la procédure d obtention des données pour l apprentissage et la configuration de ce dernier. L estimation du trafic d arrivée est examinée dans la section 4. Les expérimentations menées avec LIBPCAP 3 et IPFIREWALL 4, la surveillance en temps réel et l implémentation du modèle pour le contrôle d admission seront présentées en fin d article Performance d un serveur Web Le WWW est une application client-serveur. Il est composé de navigateurs et de serveurs qui se communiquent en utilisant le protocole HTTP (HyperText Transfer Protocol) qui correspond à une couche la plus haute du protocole TCP/IP. Les navigateurs tels que Netscape, Mosaïc et Internet Explorer de Microsoft fournissent une interface graphique et conviviale pour visualiser des pages et des documents sur Internet. Un serveur Web, également appelé serveur HTTP renvoie les informations (pages, images, etc.) vers les clients en réponse à leurs requêtes HTTP. Il permet aussi l intégration de sources variées d informations par l intermédiaire des programmes Common Gateway Interface (CGI) qui se chargent de la gestion des réponses aux requêtes des clients. HTTP est un protocole statique rapide. La figure 1 montre une interaction client-serveur pour le protocole HTTP. Le client établit la connexion au serveur et interagit avec en utilisant différentes méthodes définies, par le protocole HTTP. A la base il envoie une requête pour un objet (exemple : document, image, recherche de base de donnée, etc.).un laps de temps variable est nécessaire au serveur pour traiter les requêtes et renvoyer l objet ou les résultats de ces requêtes. Les objets sont référencés par leur URL. Envoie d une connexion TCP Envoie d une requête HTTP au serveur Analyse de la requête et fermeture de la session Client Récupération des Informations Fermeture de la connexion Serveur Figure 1. Une interaction client-serveur simple. Un programme serveur Web est caractérisé par différents types de requêtes clients qui progressent en même temps, comme un système d exploitation multitâche. Certains serveurs implémentent cette sorte d exécution multitâche par création de processus ou de threads pour chaque connexion entrante. En fonction de l implémentation, la création de nouveaux processus peut s accroître et peut ainsi entraîner une surcharge du serveur caractérisée par des temps de traitement des requêtes rédhibitoires. Certains serveurs tentent de minimiser les problèmes de surcharge par l implémentation d un mécanisme connu sous le nom de pool processes, où un certain nombre de processus sont créés durant l initialisation. Le temps de traitement d une requête HTTP dépend de la vitesse du serveur et de la complexité de la requête. La composition est fonction de la configuration matérielle (fréquence du microprocesseur, architecture de la

3 mémoire et des sous systèmes d entrée/sortie) et dépend également de la taille du document et du temps de calcul nécessaire pour l exécution d un programme CGI. Le temps et la vitesse sont les unités de mesure de base pour la performance d un serveur. La vitesse des requêtes HTTP servies représente le débit du système et le temps requis pour exécuter une requête est le temps de réponse du système. Comme les variations de la taille des objets sont significatives, le débit est généralement mesuré en terme d octets par seconde. 2. Les données de l apprentissage Les données utilisées pendant l apprentissage et la validation ont été obtenues à partir des expérimentations dont la configuration est illustrée par la figure 2. Client 1 Linux Redhat 8.0 commutateur Client 3 Serveur FreeBSD Figure 2. Configuration du labo Client 2 Client 4 Nous avons utilisé un serveur FreeBSD 5.1 connecté aux clients 9.2 via un commutateur. Pour que la latence causée par la liaison entre les clients et le serveur soit négligeable, nous avons utilisé 4 cartes NIC groupées reliant le commutateur avec le serveur. De même les 4 clients 9.2 sont nécessaires pour qu ils ne constituent pas un éventuel goulet d étranglement. Une machine Linux Redhat 8.0 aussi connectée au même commutateur a été utilisée pour le lancement, automatisation des mesures et la collecte des résultats. Le serveur est un PC pentium III de 800 Mhz avec 512 Mo de RAM, les quatre clients sont des PC pentium 4 de 2,4 GHz et avec 128 Mo de RAM. La machine qui s occupe de la synchronisation et de la collecte des résultats est un Céléron de 1,2 GHz avec 128 Mo de RAM et le commutateur est un CISCO CATALYST ports 10/100 Mbits. Nous avons utilisé un serveur HTTP Apache version 1.3. Les fichiers documents ont été stockés dans le disque dur local du serveur. Les effets des paramètres du noyau de FreeBSD et du serveur Apache sur les métriques des performances du serveur Web ont été examinés. Pour cela, nous avons fait varier les valeurs des trois paramètres kern.maxusers, kern.ipc.somaxconn du noyau et MaxClients de Apache. Ainsi, pour chaque combinaison des valeurs de kern.maxusers [ ], kern.ipc.somaxconn [ ] et MaxClients [ ], nous avons utilisé Autobenchadmin pour lancer les tests des performances. Autobenchadmin permet de lancer l outil de génération de trafic HTTP HTTPERF sur les 4 machines qui à leur tour émettent des requêtes suivant un processus de Poisson de paramètre λ. Nous avons fait varier λ de 20 à 520 avec un pas de 20. Pour chaque valeur de lambda, Autobenchadmin récupère les métriques des performances, le temps moyen de réponse, le débit et la probabilité du rejet après 5 minutes de test. Ceci nous a permis d avoir une base d apprentissage constituée de 5616 exemples.. 3. Configuration de l apprentissage Après normalisation dans l intervalle [0..1], les données obtenues à partir des expérimentations de la section précédente ont été entraînées en utilisant l algorithme de rétropropagation. Ainsi, l algorithme momentum et weight decay avec pas d apprentissage adaptif ont été utilisés pour éviter le local minima et l overfitting. Les performances des RNs ont été testées en utilisant la technique 10-fold cross-validation ; 80% des données ont été aléatoirement sélectionnées pour l apprentissage et le reste a été servi pour évaluer les performances du modèle. Nous avons utilisé trois RNs correspondant aux trois sorties à apprendre : débit, temps moyen de réponse et pourcentage de rejet. Le vecteur d entrée des RNs est caractérisé par les quatres paramètres qui sont kern.maxuser, kern.somaxconn, Maxclients, et λ. Les RNs utilisés pour l estimation du débit, du temps moyen de réponse et du pourcentage de rejet ont respectivement 8, 16 et 4 neurones cachés. Les performances des RNs ont été calculées en utilisant le NMSE (Normalized Mean Square Error) des données normalisées et sont rassemblées dans le tableau 1. NMSE Débit Temps moyen de réponse Pourcentage de rejet 2, , , Tableau 1. NMSE moyen des métriques des performances Le NMSE est défini comme étant le rapport entre le MSE (Mean Square Error) et la variance des données de l apprentissage.

4 4. Estimation du trafic d arrivée λ Le trafic d arrivée λ a été estimé en temps réel grâce au module LIBPCAP. C est un ensemble de bibliothèques de fonctions qui sert à intercepter des paquets au niveau de la couche 2 du modèle OSI. Il inclut les trois modules suivants: un filtre basé sur le BPF (Berkeley Packet Filter), un temporisateur et un compteur. Le premier module permet de sélectionner les paquets transitant le réseau selon les types de protocole, les flags dans les en-têtes des paquets ainsi que le numéro de port. Le deuxième module fixe la période durant laquelle on applique le filtre tandis que le dernier module permet de compter le nombre de paquets répondant au filtre durant la période définie par le temporisateur. Ces trois modules de LIBPCAP nous ont permis d estimer en temps réel le trafic d arrivée λ. En effet, nous avons écrit un programme en C qui estime λ en utilisant LIBPCAP selon l algorithme ci-après : 1. Initialiser le filtre à «dst port 80 and tcp[13]&2!=0 (Toute demande de connexion HTTP) 2. Initialiser le temporisateur à 1milliseconde 3. Initialiser la variable cumule à 0 4. Exécuter les séquences (5) et (6) mille fois 5. Récupérer le compteur 6. cumule=cumule+compteur 7. λ est égale à cumule (donne une estimation de λ/seconde) 8. Tant que vraie, exécuter la séquence (3) Pour ne pas surcharger le serveur Apache, notre programme a été implémenté dans une autre machine. Cette dernière communique avec la machine du serveur Apache grâce au même commutateur de la figure 2. Elle est dotée de deux cartes réseaux : la première carte lui permet de communiquer au serveur tandis que la seconde a été utilisée par notre programme grâce au module LIBPCAP pour l estimation du trafic d arrivée λ. Un port du commutateur a été configuré de telle sorte que tous les paquets des machines clientes passent à travers ce port avant d attaquer la seconde carte de la machine où LIBPCAP est installé. Nous avons validé notre algorithme en utilisant Apachetop 5. Il s agit d un outil qu on peut installer sur le serveur Apache permettant de visualiser en temps réel les activités de ce dernier en utilisant son fichier de log. En effet, nous avons installé Apachetop sur le serveur Apache et notre programme d estimation de λ sur le poste moniteur. Sur les quatre machines clientes de la figure 2, HTTPERF a été lancé pour générer le trafic Web suivant la loi déterministe de moyenne λ h [ ]. Débit (Connexion/seconde) La figure 3 montre que le nombre de requêtes par seconde fournit par Apachetop colle bien avec celui de notre programme. Figure 3. Apachetop en fonction de HTTPerf. L avantage de notre programme pour l estimation de λ par rapport à Apachetop est qu il ne nécessite aucune ressource au niveau du serveur. En effet, notre programme est implémenté dans une machine à part et n a pas besoin d exploiter le fichier de log du serveur. En outre, contrairement à Apachetop, les ressources du serveur telles que la mémoire, le disque et le CPU ne sont pas utilisées. 5. Surveillance et contrôle d admission du serveur Web. Cette section se divise en deux parties: la première concerne la surveillance en temps réel des performances du serveur Web et la seconde traite le contrôle d admission. Nous avons apporté quelques modifications sur la configuration de nos expérimentations (figure 2). En effet, nous avons utilisé une machine supplémentaire de Processeur Pentium III 800Mhz, 128 Mo de RAM équipé de 2 NIC. Cette machine tourne sous FreeBSD et joue le rôle d un moniteur. Elle est connectée au réseau de la section expérimentation via le même commutateur CISCO Catalyst Elle se charge de l interception en temps réel des requêtes HTTP des clients en utilisant le module LIBPCAP. La première carte réseau de cette machine est reliée au port de surveillance tandis que la seconde est connectée au port de contrôle du commutateur * Apachetop Notre programme Trafic généré par HTTPerf (Connexion/seconde) 5

5 Nous avons configuré le commutateur de telle sorte que tous les paquets circulants sur les quatre ports précédemment configurés en «Etherchannel» passent sur le port que nous avons appelé port de surveillance. Port de contrôle Port de surveillance MONITEUR CLIENTS Commutateur SERVEUR Figure 4. Configuration de l expérimentation. Le deuxième port que nous avons appelé port de contrôle n utilise aucune configuration particulière. Son appellation vient du fait qu il a été utilisé pour activer le contrôle d admission au niveau du serveur lorsque le temps moyen de réponse du serveur atteint un seuil fixé d avance par l administrateur système. La figure 4 montre la configuration de l expérimentation. Nous donnons dans ce qui suit deux extraits de fichiers de log traditionnel et celui obtenu à partir des réseaux de neurones. Extrait du fichier de log traditionnel : [03/Feb/2006 : 15 :28 : ] GET /favion.ico http/ Mozilla/5.0 (Windows;U;Windows NT 5.1;fr-FR;rv:1.7.5) [03/Feb/2006 : 15 :28 : ] GET /index.php http/ Mozilla/5.0 (Windows;U;Windows NT 5.1;fr- FR;rv:1.7.5) Extrait du fichier de log obtenu à partir des RNs : Feb 04 11:30:30 FreeBSD : Débit = Temps de réponse= (s) Rejet= Feb 04 11:30:35 FreeBSD : Débit = Temps de réponse= (s) Rejet= Contrôle d admission Notre contrôle d admission fonctionne à base du temps moyen de réponse estimé par les RNs. En effet, on fixe un temps de réponse acceptable (T a ). Toutes les secondes, le poste moniteur récupère λ et estime grâce aux RNs le temps moyen de réponse. Si ce dernier est supérieur à T a, le programme situé sur le poste moniteur cherche par itération λ a qui donne le premier temps moyen de réponse plus petit ou égal à T a. Ce λ a est ensuite envoyé au serveur. Ce dernier limite les connexions HTTP à λ a en utilisant IPFIREWALL Surveillance en temps réel et génération de fichier de trace Après les avoir convertis en fonctions C, les trois RNs obtenus de la section 3 ont été implémentés dans une machine connectée au serveur Apache à travers un commutateur. Le poste moniteur récupère les paramètres d entrées des réseaux de neurones par l intermédiaire de deux programmes. Le premier programme est situé sur le serveur et a comme rôle de récupérer périodiquement les paramètres du noyau et d Apache et de les envoyer au poste moniteur via des sockets. Le second programme utilise le module LIBPCAP pour estimer en temps réel le trafic d arrivée λ selon l algorithme de la section précédente. Moyennant ces paramètres, en utilisant les RNs, le poste moniteur peut estimer d une manière périodique les métriques des performances du serveur. Ces métriques seront ensuite enregistrées sous forme de fichier de trace. Contrairement au fichier de log Web traditionnel, ce dernier peut fournir d autres informations intéressantes telles que le débit accepté, le temps de réponse ainsi que le taux de rejet au niveau du serveur à un instant donné. Temps moyen de réponse (ms) * Sans contrôle d admiclient Avec contrôle d admission Taux d arrivée Figure 5. Temps moyen de réponse avec et sans contrôle d admission.

6 Temps moyen de réponse (ms) * Première combinaison des paramètres Deuxième combinaison des paramètres Troisième combinaison des paramètres λ a1 λ a2 λ a1 Taux d arrivée T a =100ms Figure 6. Temps moyen de réponse pour les trois combinaisons des paramètres prises aléatoirement avec contrôle d admission Afin de valider empiriquement notre modèle de contrôle d admission, nous avons lancé cinq simulations : la première et la seconde consistent à estimer le temps moyen de réponse avec et sans contrôle d admission tandis que les trois autres estiment la même métrique de performance pour trois combinaisons différentes des paramètres prises aléatoirement du noyau et Apache avec contrôle d admission. D après les figures 5 et 6, notre modèle limite le temps de réponse et évite une montée exponentielle de ce dernier. [ChM 99] Chen X., Mohapatra P.: Providing differentiated service from an internet server. In Proceedings of IEEE Internet Conference on Computer Communications and Networks (ICCCN 99), Boston, MA, October [CMC 01] Chen X., Mohapatra P., Chen H.: An Admission Control Scheme for Predictable Server Response Time for Web Accesses, In Proceedings of the International Worl Wide Web Conference (10), Hong-kong, [EgH 99] Eggert L., Heidemann J.: Application-level differentiated services for web servers. In World Wide Web Journal, 32(3): , [ENT 04] Elnikety S., Nahum E., Tracey J., Zwaenepoel W.: A Method for Transparent Admission Control and and Request Scheduling in E-Commerce Web Sites. In Proceedings of the 13 th International Conference on World Wide Web, [VTF 01] Voigt T., Tewari R., Freimuth D., Mehra A.: Kernel mechanisms for service differentiation in overloaded Web servers. In Proceedings of the USENIX Annual Technical Conference, Boston, MA, June Conclusion Nous avons présenté des modèles de réseaux de neurones permettant la prédiction des métriques de performance d un serveur Web. Deux paramètres d optimisation du noyau de FreeBSD, un paramètre d Apache et le trafic d arrivée λ ont été les entrées des RNs. Les sorties sont le débit, le temps moyen de réponse et le pourcentage de rejet. Trois RNs ont été entraînés pour estimer chacune de ces sorties. Les métriques des performances estimées à partir des RNs s accordent parfaitement aux résultats expérimentaux. Aussi, nous avons implémenté ce modèle sur une machine sous FreeBSD afin de réaliser une surveillance en temps réel des métriques de performance et un contrôle d admission du serveur Apache. Ce système garantit des temps de réponse raisonnables. REFERENCES [ADM 98] Aldemia J., Dadu M., Manikutty A., Cao P.: Providing differentiated quality-of-service in web hosting services, in 1998 Workshop on Internet Server Performance, June [BhF 99] Bhatti N., Friedrich R.: Web server support for tiered services. IEEE Network, pages 64-71, September/October 1999.