Blog ENI : Toute la veille numérique !
-25€ dès 75€ sur les livres en ligne, vidéos... avec le code FUSEE25. J'en profite !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. Les réseaux informatiques
  3. Métrologie et mesure de performances
Extrait - Les réseaux informatiques Guide pratique pour l'administration, la sécurité et la supervision (2e édition)
Extraits du livre
Les réseaux informatiques Guide pratique pour l'administration, la sécurité et la supervision (2e édition)
2 avis
Revenir à la page d'achat du livre

Métrologie et mesure de performances

Métrologie et métriques réseau

1. Définition de la métrologie

La métrologie fait partie intégrante de la supervision. Elle désigne globalement la science de la mesure qui s’applique dans de nombreux domaines et notamment dans les réseaux informatiques. Au-delà de la simple mesure, la métrologie s’applique à garantir la mesure et à l’interpréter.

Les utilisateurs se plaignent d’un réseau lent, d’un mauvais débit lors du téléchargement de fichiers sur le cloud, d’une application qui met trop de temps à répondre : Comment solutionner ces problématiques sans éléments quantifiables et comparables ? Comment mesurer le temps de réponse d’un applicatif ? Comment mesurer un débit ? Avec quelle(s) unité(s) ? Comment s’assurer qu’un prestataire assure un service selon les SLA contractuelles ?

Si on ne met pas en place des moyens pour mesurer les performances d’un réseau ou d’une application, il sera alors difficile d’en évaluer la qualité. Ainsi, la réflexion sur l’amélioration des performances actuelles ou futures est impossible sans les évaluer concrètement selon des métriques bien déterminées. On admet aisément que la perception de vitesse de l’accès à une application par un utilisateur est une donnée à prendre en compte, mais qui n’est pas mathématiquement comparable et reste assez subjective.

Il faut qualifier ce ressenti de lenteur par une mesure précise, qui pourrait être celle du temps d’affichage de la page d’accueil d’un site Intranet à la suite de l’identification d’un utilisateur par exemple, donc évaluable en secondes. Cette valeur pourrait être quantifiée à plusieurs moments de la journée afin d’évaluer le temps de réponse moyen en période de forte ou faible utilisation. Ce relevé de moyennes permettrait également d’évaluer les conséquences induites par la modification du code de l’application par l’équipe de développement, par une modification du système d’exploitation...

Mesure de débit et optimisation

1. Débit brut et débit applicatif

Les opérateurs ont l’habitude d’exprimer les débits d’une connexion de type xDSL en débit ATM. Ainsi, une connexion ADSL2 annoncée à 28 Mbits/s en téléchargement ne représente pas vraiment le débit réel mesuré, même en faisant abstraction d’une inévitable atténuation du signal qui est fonction de la distance de l’abonné. D’ailleurs, un test de débit nous fournira un résultat autour des 22 Mbits/s, c’est ce que les opérateurs appellent le débit IP, c’est-à-dire le débit disponible en omettant le débit supplémentaire utilisé par un ou plusieurs protocoles de niveau inférieur au protocole IP, comme justement ATM (cf. chapitre Évolution des métiers autour des réseaux - section L’évolution vers les réseaux ATM). En fait, il ne faut pas oublier que pour la transmission de données, ces dernières sont encapsulées dans différents protocoles qui utilisent des en-têtes de différentes tailles, potentiellement variables. Ces en-têtes utilisent donc du débit supplémentaire (puisque le nombre de bits à transmettre est augmenté).

Lorsque l’on parle de débit, il est nécessaire de préciser à quel niveau de la couche OSI on se place, par défaut on a pris l’habitude de faire référence au débit IP. Mais si l’application en question utilise TCP au lieu d’UDP, ainsi qu’IPv6 au lieu d’IPv4, la transmission d’un fichier sera plus longue, car les en-têtes TCP et IPv6 pour notre exemple ont une taille plus importante. Sachant qu’en plus il existe une taille maximum pour un paquet donné appelée MTU (Maximum Transfer Unit), nécessitant qu’au-delà de cette valeur, les données soient fragmentées et utilisent donc davantage de bits pour les en-têtes, puisqu’on utilise plus de paquets.

Le piège serait donc d’effectuer le calcul suivant : une application transfère un fichier de 25 Mo, disposant d’un lien à 100 Mbits...

Mesurer les temps de réponse

1. Mesure de la latence et de la gigue

a. Ping

Le protocole ICMP, par la génération de messages Echo Request et des réponses correspondantes Echo Reply, permet de vérifier, d’une part, la connectivité réseau entre deux machines sur un réseau WAN ou LAN (par la commande ping), et d’autre part, indirectement, de remonter des valeurs de latence sur l’ensemble du ou des réseaux traversés. La latence correspond à l’un des métriques réseau défini dans ce chapitre à la section Les métriques réseau.

Le résultat d’une commande ping vers un destinataire joignable s’accompagne ainsi du temps écoulé entre l’envoi de la requête ICMP et la réponse correspondante, c’est-à-dire le temps de l’aller-retour sur le réseau ou RTT. On obtient la latence en divisant cette valeur par 2, en général elle reste symétrique bien que le trajet aller emprunté par un paquet IP peut différer du trajet retour.

La latence est fonction du support utilisé ainsi que de sa longueur. Les latences les plus faibles sont atteintes sur des supports fibrés, les latences les plus élevées se retrouvent souvent sur des connexions sans-fils type satellite ou 4G.

Voici un tableau représentant les valeurs de RTT « habituelles » sur une connexion WAN lors d’un test de ping entre deux machines en France, selon le type de connexion utilisé :

SUPPORT PHYSIQUE

RTT moyen attendu

ADSL/VDSL (cuivre)

Entre 30 ms et 80 ms

Fibre optique

Entre 2 ms et 25 ms

Connexion câblée (coaxial)

Entre 15 ms et 40 ms

4G

Entre 40 ms et 60 ms

3G

Entre 90 ms et 130 ms

Wimax

Entre 65 ms et 85 ms

Satellite

Entre 500 ms et 900 ms

images/07EI11.png

Obtention du RTT via le résultat de la commande ping. La latence étant donc de 7 ms sur cette capture pour un RTT de 14 ms

La latence peut être également évaluée par rapport à l’utilisation de protocoles de plus haut niveau qu’ICMP, concrètement au niveau transport via TCP ou UDP. Pour cela, on peut utiliser l’utilitaire echoping évoqué à la section Méthodologie...

Les outils de supervision spécialisés en métrologie

1. Stocker les mesures

a. Problématique de stockage des données de métrologie

Les besoins de performances et de stockage des données récoltées sont spécifiques dans le domaine de la métrologie. Les données doivent en effet être stockées rapidement, en temps réel et horodatées en utilisant un minimum d’espace disque pour une mesure donnée. En effet, les bases de données ou le système de fichiers utilisé doivent être adaptés à recevoir de nombreuses écritures séquentiellement voire simultanément à une fréquence élevée. En matière de lecture, d’interprétation et de présentation des données, un système de gestion de base de données (SGBD) traditionnel n’est pas forcément adapté. Ainsi, dans un souci d’optimisation, les éditeurs sont amenés à développer des structures de données, des SGBD spécifiques appelés TSDB (Time Serie Database), adaptés au stockage de données de métrologie en vue d’en accélérer a posteriori leur traitement. Une série de temps (« time serie ») est en fait une série de tuples temps (ou intervalle)/valeur mesurée.

Ces TSDB prennent en compte notamment le fait que les données n’arrivent jamais à intervalle de temps régulier, elles sont capables alors de lisser les données récoltées en les pondérant sur un intervalle de temps donné avant de les stocker véritablement et de les horodater. Bien sûr, on perd alors de la précision, mais a-t-on par exemple besoin de savoir qu’à t=0s, le débit enregistré sur une interface réseau est de 100 kbits/s, 102 kbits/s à t=1s et 101 kbits/s à t=2s ?

Ce qui intéresse l’administrateur c’est plutôt d’observer des tendances et des moyennes sur un laps de temps plus important : moyenne sur les dernières cinq minutes, le dernier quart d’heure, la dernière heure…

b. Outils répandus de stockage des données...