Soutenance mémoire
Les métriques de la performance
Les métriques de la performance des réseaux sont des informations décrivant les conditions de transmission de paquets. Le délai (Angrisani et autres, 2006), la gigue (Matta et Takeshita, 2002), le taux de perte de paquets (Boulos, 2009), le débit effectif (Matta et Takeshita, 2002), le taux d’utilisation de lien (Papagiannaki et autres, 2003b) et le taux de consommation des ressources physiques (Papagiannaki, Cruz et Diot, 2003a), sont les métriques de la performance des réseaux les plus utilisées. Le délai de paquet est le composant le plus significatif du délai de bout-en-bout du paquet, qui est le plus important paramètre de la qualité de service. Le délai de paquet est le temps pour les paquets à traverser un des éléments de transfert dans leurs chemins. Il consiste en trois composants : le délai de transmission, le délai de traitement et le délai de la file d’attente. Le délai de transmission est le temps nécessaire, pour le commutateur, pour placer le paquet sur le lien de sortie. Le délai de traitement est le temps nécessaire pour déterminer le port de sortie, et lui transférer le paquet.
Le délai de la file d’attente est le temps passé par le paquet à l’entrée et/ou la sortie du commutateur. Alors que le délai de transmission est relié à la capacité des liens et la taille des paquets, le délai de traitement et le délai de la file d’attente décrivent quantitativement la performance du commutateur (Angrisani et autres, 2006). Le délai de la file d’attente est un paramètre dynamique qui est proportionnel au nombre de paquets qui sont déjà en attente à la file d’attente de sortie à un instant donné (Salehin et Rojas-Cessa, 2014). Autrement dit, la mesure de délai de la file d’attente du commutateur est clé pour déterminer le niveau de congestion dans le réseau. Un calcul précis du délai de la file d’attente permet à un fournisseur de service de terminer et maintenir, respectivement, la qualité de service et le Service Level Agreement, pour les applications sensibles au délai (Salehin et Rojas-Cessa, 2014). La variation de la qualité de service est directement liée la variation du délai de la file d’attente. Le délai de traitement de paquets est le temps entre l’arrivée du paquet à la file d’attente d’entrée de l’interface réseau (niveau liaison de données), et le temps de traitement de paquet au niveau application (Salehin et Rojas-Cessa, 2013).
C’est le seul délai, lié à la performance du commutateur, qui est toujours présent, puisque le délai de la file d’attente n’existe qu’au cas de congestion. La gigue est la variation en délai de transmission de bout en bout des paquets d’un même flux. Cela se traduit par le décalage temporel entre les paquets à la réception. La gigue est une métrique importante pour les applications sensibles à la latence, comme la voix sur IP. Le taux de perte de paquets est la métrique décrivant la fiabilité du réseau. Il est souvent utilisé pour superviser la qualité de service. C’est une métrique clé pour les services de temps réel. Si un faible taux de perte de paquets est tolérable pour les services de la voix sur IP, la perte 1.1% de paquets en IPTV génère un taux de mal satisfaction de 80% des clients du service (Boulos, 2009). Le débit effectif est le nombre de bits par unité de temps qu’une source peut émettre sur le réseau. Cela varie en fonction du temps passé par le paquet dans la file d’attente. Ce qui fait de la bande passante disponible et le délai de la file d’attente deux faces d’une même métrique. Le taux d’utilisation de lien est la capacité du lien consommée par le flux émis par la source. C’est commun de collecter le taux d’utilisation de lien pour en déduire le délai de paquet. En effet, un seuil d’utilisation de lien est établi, souvent de 50%. Si un lien est utilisé à moins de 50%, alors, il est capable de transporter n’importe quel flux de la même capacité de lien, dans 20 les autres liens voisins, en cas de panne (Papagiannaki, Cruz et Diot, 2003a). Aussi, il avait été prouvé dans une étude, que les liens utilisés à moins de 50%, introduisent un délai de la file d’attente minimum (Papagiannaki, Cruz et Diot, 2003a). La consommation du CPU représente la limitation physique du réseau. Elle est nécessaire pour le dimensionnement et la conception de réseaux. Une consommation élevée du CPU peut produire des lenteurs dans la performance et échec de réponse de certains services.
Analyse de la performance dans les réseaux de centres de données Alors que les applications et les services sont en massive migration vers les centres de données, les administrateurs réseaux sont mis au défi de superviser leurs réseaux de noeuds virtuels avec les outils existants. Cela a relevé une éventuelle nécessité aux nouveaux outils. Les solutions développées pour la supervision des réseaux d’interconnexion des centres de données, s’intéressent plutôt sur la disponibilité des ressources physiques, en relevant les utilisations de CPU, du stockage, de la mémoire et la bande passante des interfaces réseaux (GroundWork, 2015) (Hyperic, 2015). Une vue limitée du trafic est offerte par les outils d’aujourd’hui (Clayman, Galis et Mamatas, 2010). Pourtant, plusieurs études ont relevé l’importance de la supervision de la performance des réseaux virtuels. Ciuffoletti (2010) fait le point sur l’hétérogénéité de l’infrastructure dans les centres de données, et argumente qu’une hétérogénéité de la performance du réseau rend le load balancing ineffective, le streaming avec des variations de délais et le calcul parallèle impossible. Le travail de Fabienne (2013) traite l’influence de l’hyperviseur sur le débit effectif des commutateurs virtuels. Les expérimentations ont été faites sur des commutateurs virtuels à base de Linux.
L’hyperviseur de la couche au-dessous changeait durant l’expérimentation. Figure 2.13 montre la couche hyperviseur, sous expérimentation. Le débit effectif du commutateur virtuel, dans chaque cas d’hyperviseurs expérimentés, a été comparé avec celui d’un commutateur Linux natif. Les résultats montrent que l’hyperviseur a une influence sur la performance des commutateurs virtuels. Le débit effectif ne peut pas dépasser les 25% du débit effectif d’un commutateur natif. Cette efficacité de 25% peut même ne pas être atteinte dans le cas de trafique à petits paquets (Fabienne, 2013). Dans Martinovic, Balen et Rimac-Drlje (2013), l’impact du système d’exploitation hébergeur est étudié. Un serveur, d’un pool de serveurs identiques, a été déployé pour chaque système d’exploitation hébergeur différent. Sur ces serveurs, des machines virtuelles identiques, ainsi que le même hyperviseur ont été utilisées. Figure 2.14 montre la couche système d’exploitation hébergeur, sous expérimentation. Les résultats montrent que le choix de système d’exploitation hébergeur affecte la performance du commutateur virtuel, en termes de performance graphique, l’utilisation de la mémoire physique et de l’espace disque de stockage. Cependant, le choix de système d’exploitation hébergeur n’a pas d’impact sur l’utilisation de CPU (Martinovic, Balen et Rimac-Drlje, 2013). Alors que Fabienne (2013) traite l’impact de l’hyperviseur, et Martinovic, Balen et Rimac- Drlje (2013) traite l’impact du système d’exploitation hébergeur; Sundling (2010) traite l’impact de la couche physique sur la performance des machines virtuelles. Dans cette expérimentation, les ressources physiques des machines virtuelles ont été variées et la réponse des applications, sur ces machines virtuelles, a été observée.
L’expérimentation montre qu’au changement de nombre de CPU alloués à une machine virtuelle, le comportement des applications, l’exécution parallèle et la charge de CPU peuvent changer. Cela relève un impact du CPU sur la performance des applications exécutées sur les machines virtuelles (Sundling, 2010). En termes de mémoire, l’expérimentation à relever une dégradation de performance dans le cas d’affectation d’un espace mémoire trop petit, par exemple de 4G, pour une machine virtuelle hébergeant une application demandant un espace mémoire plus grand, par exemple 16G. Cette dégradation au swapping intensif pour cause de manque de mémoire (Sundling, 2010). Cette expérimentation met le point sur l’option de limite de mémoire. Cette option, s’elle est activée, limite l’allocation de mémoire, par l’hyperviseur, à une valeur autre que celle réellement assignée (Sundling, 2010). Comme explication, si une mémoire de 2G est allouée à une machine virtuelle, et il y a une limite de 512M, le système d’exploitation verra une mémoire physique de 2G, mais l’hyperviseur ne va permettre l’accès qu’à 512M (Sundling, 2010). Si une application a besoin de plus de 512M, il y aura une dégradation de la performance, comme expliquée précédemment.
|
Table des matières
CHAPITRE 1 INTRODUCTION GÉNÉRALE
1.1 Contexte
1.2 Problématique
1.3 Objectifs du mémoire
1.4 Plan du mémoire
CHAPITRE 2 REVUE DE LITTÉRATURE
2.1 Introduction
2.2 Les réseaux d’interconnexion des centres de données
2.2.1 La virtualisation
2.2.1.1 Définition de concept
2.2.1.2 L’hyperviseur
2.2.1.3 Réseaux virtuels
2.2.1.4 Commutateurs virtuels
2.2.2 Les réseaux de centres de données
2.2.2.1 Architectures conventionnelles
2.2.2.2 Tendances futures
2.3 L’analyse de la performance des réseaux
2.3.1 Les métriques de la performance
2.3.2 Les outils de l’analyse de la performance
2.3.3 Analyse de la performance dans les réseaux de centres de données
2.4 Conclusion
CHAPITRE 3 MÉTHODOLOGIE DE RECHERCHE
3.1 Introduction
3.2 Collecte de données
3.2.1 Les métriques à superviser
3.2.2 L’outil de la collecte de données
3.2.3 Automatisation de la collecte des données
3.2.3.1 Algorithme de l’automatisation de la collecte des données
3.2.3.2 Enregistrement des données dans une base de données
3.3 Analyse de la performance
3.3.1 Effet de la couche physique sur la performance
3.3.2 Comparaison de la performance
3.4 Conclusion
CHAPITRE 4 EXPÉRIMENTATIONS ET RÉSULTATS
4.1 Introduction
4.2 Environnement expérimental
4.2.1 Métrique supervisée
4.2.2 Commutateurs du banc d’essai
4.2.3 Déploiement du banc d’essai
4.2.4 Scénarios des expérimentations
4.2.4.1 Scénario 1 : mesure de la performance d’un commutateur virtuel
4.2.4.2 Scénario 2 : influence de la couche physique sur la performance du commutateur virtuel
4.2.4.3 Scénario 3 : comparaison d’un commutateur virtuel et un commutateur physique
4.3 Relevé des données
4.3.1 Données brutes
4.3.1.1 Mesures par SNMP
4.3.1.2 Mesures par le plugin MRTG de Nagios
4.3.2 Données calculées
4.3.2.1 Base de données
4.3.2.2 Débit effectif de l’interface
4.3.2.3 Latence d’un lien
4.3.2.4 Vérification de l’exactitude des mesures
4.4 Analyse de la performance des commutateurs virtuels
4.4.1 Mesure de la performance d’un commutateur virtuel
4.4.2 Influence de la couche physique sur la performance du commutateur virtuel
4.4.2.1 Influence du CPU
4.4.2.2 Influence de la mémoire
4.4.3 Comparaison d’un commutateur virtuel et un commutateur physique
4.5 Conclusion
CHAPITRE 5 CONCLUSION GÉNÉRALE
ANNEXE I INSTALLATION DE L’HYPERVISEUR KVM
ANNEXE II DÉPLOIEMENT D’UN RÉSEAU D’INTERCONNEXION DE CENTRES DE DONNÉES
ANNEXE III DÉPLOIEMENT DE NAGIOS
ANNEXE IV CONFIGURATION DE L’ENVIRONEMENT POUR LA SUPERVISION DE LA PERFORMANCE
ANNEXE V PLUGIN MRTG POUR NAGIOS
ANNEXE VI ENREGISTREMENT DES DONNÉES NAGIOS DANS UNE BASE DE DONNÉES
ANNEXE VII TEMPS DE LATENCE AVEC PING
LISTE DE RÉFÉRENCES BIBLIOGRAPHIQUE
Télécharger le rapport complet
