Tous les administrateurs réseaux ont entendu cette phrase au moins une fois dans leur carrière :

« Les lenteurs du réseau m’empêchent de travailler !! Je mets un temps fou à aller sur [application réseau de votre choix]!!!!! »

Mais comment savoir si c’est le réseau qui ne fonctionne pas correctement ou si c’est autre chose (l’application, les serveurs d’application, la base de donnée, le poste client, …) ?

Comment savoir si c’est vraiment une lenteur de mon réseau ?

Voilà la vraie question ! Car en tant qu’administrateur réseau ce qui m’intéresse c’est de prouver aux autres services que ce n’est pas un problème réseau et qu’ils devraient regarder un peu de leur coté. Seulement quels méthodes a-t-on à notre disposition pour fournir cette preuve ?

La capture de trace ?

C’est parti pour capturer le trafic.

Allons mettre 2 taps en coupure (les ports miroirs ne restituent pas exactement les temps réseau) 1 au plus près du poste de Roger¹  (notre râleur N°1) et un au plus près du serveur (en heures non ouvrées bien sûr pour ce dernier, car on ne peut pas couper l’accès au serveur d’application comme ça…). Ensuite, on lance les captures. On attend que l’utilisateur du poste client ait un problème de lenteur (et oui c’est pas en permanence), et qu’il note les heures où ça se produit (ce qu’un utilisateur ne fait JAMAIS).

Une fois qu’on a 2 à 3 jours de capture, on ouvre les 2 traces et on cherche les requêtes qui ont été lentes parmi les quelques milliers de transactions. On arrive enfin à dire que c’est le serveur d’application qui a mis 40 secondes à répondre…

Après une semaine, on peut dire que les « lenteurs réseau » de Roger sont en réalité des soucis au niveau du serveur d’application. Plus qu’à faire la même chose auprès des postes de Régis, Thomas et Alice (respectivement les râleurs N°2, 3 et 4 de l’entreprise).

Après plus d’un mois d’acharnement et de souffrances, on a notre preuve !! C’est l’application et/ou son serveur qui mettent du temps à répondre !!

Réponse du service application :

« Ça tombe bien, on a déployé une nouvelle version qui est plus rapide et corrige ces lenteurs. Maintenant si c’est long c’est qu’il y a des lenteurs du réseau !! ».

Le polling SNMP?

Essayons alors de voir au niveau de la santé des équipements réseau.

Pour cela commençons par autoriser la récupération des infos en SNMP sur les équipements qui le permettent (et sur lesquels on a des droits). Ensuite, on installe un poller SNMP dans lequel on ajoute nos équipements.

Une fois ce travail fait, on a une visibilité sur les équipements en terme de débit traité, de CPU, de mémoire et de paquets perdus.

Par contre pas d’informations sur les temps de réponse… Donc même si cela peut donner un état des lieux sur la santé des divers équipements, cette méthode ne nous garantit pas que le réseau n’est pas responsable des ralentissements de l’application utilisée.

Gagnons du temps avec Qual’IT

Une autre option est de déployer une solution Qual’IT pour vérifier de façon régulière si le réseau répond correctement.

Qual’IT va s’appuyer sur les Qual’ITBox qu’on va placer à des endroits stratégiques du réseau et qui vont tester le réseau situé entre elles. Ces boitiers étant dédiés aux tests, nous nous affranchissons ainsi de la charge d’un serveur d’application ou bien du poste client.

Pour être encore plus pointilleux sur les preuves qu’on va fournir, on crée un profil de test qui va simuler les mêmes communications que mon application à partir d’une capture.

On va placer au minimum une Qual’ITBox au plus près du serveur d’application et quelques unes au plus près des utilisateurs mécontents. Une fois que ces box sont en place, la console Qual’IT va nous permettre :

• d’organiser les Qual’ITBox (en zones géographiques ou bien en services),

• de définir des scripts de tests incluant les informations à surveiller (telles que le temps de réponse, le débit, le temps de latence, …), les seuils de réussite ou d’échec du test (par exemple le test est en échec si le temps de réponse réseau est supérieur à 2 secondes) et, éventuellement, les alarmes à remonter par e-mail ou par trap SNMP.

• de définir les profils de QoS TOS ou DSCP utilisés sur le réseau si besoin,
• de paramétrer les tests, entre les Qual’ITBox, lancés par Qual’IT à intervalles réguliers.

Une fois que Qual’IT aura fait quelques tests, nous n’aurons plus qu’à jeter un coup d’œil au tableau de bord.

Si tout est vert, c’est qu’il n’y a pas de problème réseau et que le problème de lenteur vient d’autre part. Si on a du rouge, nous allons pouvoir forer dans les résultats de test et voir ce qui pose problème (la latence dans un sens de communication, les pertes de paquets, …) et tout cela de manière continue.

Et voila! Maintenant on peut aller voir le DSI en lui assurant que la « lenteur réseau » n’en est pas une et lui présenter nos preuves.

En savoir plus sur Qual’IT