Comment identifier l’origine d’un ralentissement réseau?

Chaque administrateur réseau a déjà entendu cette plainte : « le réseau est lent, je ne peux même pas avoir accès à « mes applications » pour faire mon boulot ! »

Comment pouvez-vous identifier s’il y a un ralentissement réseau, ou bien si la dégradation vient d’un autre socle (serveur d’application, Base de données, poste de travail) ?

Quel outil de diagnostic réseau peut-on utiliser pour déterminer s’il y a un ralentissement réseau ? Vaste question… Votre première cible (en tant qu’administrateur réseau) sera de regarder les autres socles où il n’y a pas de congestion et où les temps de latence et taux retransmission sont corrects… et celui ou il y aurait matière à investiguer, dans d’autres parties de la chaine applicative. Comment procéder ?

Option 1: Capturer le traffic?

Vous avez Wireshark présent sur votre PC ; c’est parti !

Sélectionnons notre premier plaignant : nous allons le dénommer Bob. Suivons ces étapes :

1. Plaçons un point de capture soit en utilisant des TAPs ou un port mirroring – (voir notre article sur le sujet) –  sur la connexion réseau de Bob, mais aussi du coté serveurs. Cela signifie que vous aurez besoin de deux appliances pour capturer le trafic, une pour le stream to disk et une pour l’enregistrement des paquets.
2. Là, vous réalisez que les dégradations sont intermittentes : vous allez avoir besoin d’enregistrer le trafic sur un grand nombre de jours… et demander à Bob de noter soigneusement les horaires précis où arrive chaque dégradation (ce qu’il ne fera probablement pas ;).
3. Après 2 ou 3 jours de capture de trafic, arrive la bataille finale : analyser 2GB de fichiers de traces réseau avec Wireshark… Est-ce faisable ? Pas vraiment…
4. Découpons ces résultats en tronçons et procédons à des calculs manuels de temps de réponse.
5. Après une (longue…et relativement partielle) analyse des fichiers PCAP… vous avez passé 3 jours, vous n’avez trouvé aucun signe de problème réseau, de saturation de bande passante ou de perte de paquets…mais un grand nombre de transactions applicatives réalisées en dizaines de secondes !
6. Nous allons consigner ces informations dans un rapport et les envoyer à l’équipe en charge des applications tout en sachant que ce ne sont pas de grands fanatiques des lectures de traces réseaux et de surcroit qu’ils vont réceptionner ces informations avec un certain niveau de suspicion.

Soyez prêts toutefois, à envisager ces mêmes étapes pour chaque plainte utilisateur et pour chaque nouvel incident.

Pour apprendre comment, en 4 étapes simples, diagnostiquer les dégradations des performances des réseaux et des applications, téléchargez notre « Guide du Diagnostic des Performances ».

Option 2: Devriez-vous investiguer dans la supervision de vos éléments réseau au travers d’une solution SNMP?

En tant qu’administrateur réseau qualifié, vous avez implémenté des outils pour surveiller la disponibilité des ressources de vos éléments réseau (en utilisant soit une application éditeur comme Solarwinds NPM, OpManager, What’sUp Gold, etc…ou une solution Open source telle que Nagios, Cacti, PRTG, Centréon, etc..)

Avec un peu de chance, le travail de configuration sur les éléments réseau et la plate forme de surveillance a déjà été réalisé.

Jetons un œil sur les données : vous aurez des métriques sur les bandes passantes et les pertes de paquets, vous pourrez vérifier que vos ressources matérielles ne sont pas saturées (mémoire, CPU, …) mais vous ferez très vite face à des limites :

• Les 5 mn de granularité ne vous permettront pas de voir une dégradation instantanée
• Vous n’aurez aucune information sur les temps de réponse (réseau ou applicatifs)
• En aucun cas vous ne pourrez diagnostiquer des évènements qui seraient spécifiques à une destination ou une application.

Option 3: Installer des robots au travers de votre réseau?

Comme les dysfonctionnements deviennent récurrents, vous avez décidé d’installer des dispositifs afin de tester activement la disponibilité et les performances de vos réseaux et applications. Vous les installez sur des emplacements d’utilisateurs stratégiques et commencez à développer des scenarios qui représentent les activités les plus significatives de vos utilisateurs…et très vite vous serez confrontés aux limitations suivantes :

• Tester à intervalle de 5mn n’est pas pertinent lorsque vous faites face à des dégradations intermittentes
• La plainte de votre utilisateur…n’est jamais prévue dans votre scénario
• Cela vous informe à quel moment le temps de réponse se dégrade…mais cela n’en donne pas la cause !!!!

Ou prenez 1h et résolvez vos problèmes avec SkyLIGHT PVX!

SkyLIGHT PVX va enregistrer le trafic entre vos utilisateurs et vos serveurs (sans exception, et sans problème d’évolutivité) et mesure le ressenti utilisateur 24/24h, tous les jours. Avec un seul équipement par centre de données, vous pourrez :

• Visualiser l’évolution du ressenti utilisateur
• Revenir en arrière sur une échelle de temps, afin de déterminer quel utilisateur, application ou transaction est dégradé et à quel moment
• Identifier la cause d’un ralentissement (client, réseau, serveur, Base de données)
• Montrer les transactions applicatives sans avoir besoin d’analyser les paquets réseaux
• Sortir des rapports et les automatiser en un simple click de souris

Vous n’aurez pas à :

• Configurer et maintenir des scénarios
• Ajouter / mettre à jour des configurations SNMP sur les équipements
• Expliquer les données des paquets à vos collègues en charge des applications

Alors, non seulement vous pourrez dire que le réseau n’est pas en cause, mais vous pourrez aider vos collègues de façon constructive à identifier l’origine du problème.