jump to navigation

Lenteurs, le réseau est il fautif ? réponse immédiate avec OmniPeek ! 1 mai 2012

Posted by frnetworker in OmniPeek.
Tags: , , , , , , , , ,
add a comment

En tant qu’administrateur réseau, nous sommes souvent confronté aux utilisateurs qui se plaignent, souvent à juste titre, des lenteurs du système d’information.

Habituellement c’est le réseau qui est montré du doigt par les utilisateurs, mais ce n’est pas toujours le cas !

C’est notre rôle de déterminer comment diminuer les temps de réponse, mais où doit on agir ? Quelle est l’origine des lenteurs ? s’agit t’il de lenteurs réseau ou de lenteurs liées au serveur et à ses applications ?

Les heureux propriétaires d’OmniPeek vont connaitre la réponse en quelques instant avec l’aide de l’utilisateur concerné !

Mettre en oeuvre une capture

  1. Positionnez OmniPeek pour capturer les données du réseau au niveau du poste utilisateur,
  2. Créez un filtre avec l’adresse IP de l’utilisateur pour vous concentrer sur son trafic et lancez la capture,
  3. Demandez à l’utilisateur d’utiliser ses applicatifs comme il le fait au quotidien.

Afficher les informations de diagnostique

OmniPeek affiche les informations permettant un diagnostique immédiat des lenteurs dans les fenêtres Event Summary et Visual Expert.

Event Summary

OmniPeek détecte pour vous les anomalies de fonctionnement du réseau grâce au système expert.

Le système expert d'OmniPeek lui permet de relever les erreurs réseau …

OmniPeek enregistre les anomalies réseau dans l'onglet Event Summary

Visual Expert

OmniPeek permet également de visualiser les temps de réponses des applications dans l’onglet Visual Expert.

La séquence des paquets et le délai de réponse permettent à l'administrateur de connaitre avec précision l'origine du problème.

OmniPeek trace les latences réseau ou applicatives dans le fenêtre Visual Expert

Dans le cas de cette seconde copie d’écran, les paquets d’accusés de réception (ACK) parviennent rapidement, vous avez donc la certitude que le problème provient du serveur ou de ses applications et que votre réseau est clean !

C’est des nombreuses raisons pour laquelle OmniPeek permet aux administrateurs de réaliser un travail de haute qualité.

Essayer Gratuitement OmniPeek Maintenant

OmniPeek est distribué en France par NetWalker.
Informations et Tarifs 

Publicités

Analyse de la VoFI : Mettre en place la supervision, l’analyse et le diagnostic 8 juin 2010

Posted by frnetworker in Diagnostic Réseau, OmniPeek.
Tags: , , , , , , , ,
add a comment

La VoIP mobile (ou VoFI) s’installe dans les entreprises. La société  In-Stat anticipe 171 millions d’utilisateurs aux alentours de 2013 avec des revenus estimés à 10 milliards de dollars. Concentrons-nous sur la supervision, l’analyse et le diagnostic de la VoIP sur Wifi. (VoFI)

Avant d’être effrayés, prenez une bonne respiration ! Analyser le trafic VoFI revient à peu de chose près à analyser le trafic VoIP. Souvenez-vous seulement que le WIFI rend plus sensible des problèmes comme la gigue, la latence et la perte de paquets.

Remontons à la source : les appels de vos utilisateurs !

Lorsque des problèmes surviennent avec des applications VoIP ou VoFI, le point de départ est toujours le même : Avant même de vous précipiter sur vos statistiques ou vos captures prenez le temps d’écouter les appels significatifs afin de vous rendre compte par vous-même de ce que les utilisateurs ont vécu.

Votre oreille vous indiquera les signes de latence excessive, gigue ou perte de paquets.

Le plus simple est de  vous assurer que votre solution d’analyse VoIP vous permet le playback des appels téléphoniques et plus spécialement des flux RTP individuellement ainsi que de l’ensemble d’une conversation.

Sans cette ré-écoute, vous perdrez probablement des heures à pister l’origine des problèmes sur le réseau ou dans l’application alors qu’il s’agissait d’un simple problème de casque défectueux sur le poste de l’utilisateur !


Prendre le pouls de votre réseau !

Une fois que vous avez écouté l’appel, vous pouvez alors contrôler ce qui se passe sur le réseau.

Synthèse de la qualité VoIP sur votre réseau avec OmniPeek

Synthèse de la qualité VoIP sur votre réseau

Vous visualisez immédiatement ce que vous avez entendu ! La qualité de l’appel était déplorable (poor). (la barre orange sur le graphe).

Entrer dans les détails

Le système expert vous permet de vérifier ce que vos oreilles vous avaient littéralement ‘laissé entendre’ :

Synthèse des évènements réseau

Synthèse des évènements réseau

Durant cet appel, il y a eu une grande quantité d’erreurs physiques : paquets arrivés en retard, ré-émission, paquets dé-séquencés, pertes de paquets, trop de gigue …

La cause ayant été rapidement identifiée, vous allez être en mesure de régler le problème.

En visualisant l’appel dans sa globalité, vous constatez que l’appel s’est clôturé avec une fin ‘normale’ dans le sens ou l’appel n’a pas été coupé. Quel Codec a été utilisé, quelle longueur, quel était son score ?

Statistique des appels VoIP & VoFI

Statistique des appels VoIP & VoFI

Dans cet exemple, le score d’évaluation était de 2,5 ce qui confirme la mauvaise qualité de l’appel.

La vue par média (Media view) vous permettra de déterminer pourquoi la qualité était si déplorable.

Détails des appels, R-factor, Mean Opinion Score, Pourcentage de paquets perdus …

Détails des appels, R-factor, Mean Opinion Score, Pourcentage de paquets perdus …

Comprendre la différence entre les appels VoIP sur réseau physique et ceux sur réseau Wifi.

Les deux écrans suivants, montrent le déroulement, paquet par paquet, d’un appel VoIP sur un réseau filaire et sur un réseau Wifi. Vous remarquez qu’ils sont assez similaires. Si les protocoles utilisés sont différents, le VoFI comporte cependant une étape supplémentaire : l’authentification !

Anatomie d'un appel VoIP sur réseau filaire

Anatomie d'un appel VoIP sur réseau filaire

L’utilisation du wifi implique des interférences de signal et des authentifications.

Anatomie d'un appel VoIP sur un réseau wifi (VoFI)

Anatomie d'un appel VoIP sur un réseau wifi (VoFI)

Approfondir :

Il y a quelques temps, Joe Habib, Directeur des services professionnels a présenté « QoS en VoIP : Tordre le cou à la latence, à la gigue et aux pertes de paquets ». Si la VoFI ou si vous prévoyez de la déployer, un coup d’oeil sur ce document PDF vous permettra de mieux cerner les enjeux et d’éviter de nombreux écueils.

Dans cette présentation vous retrouverez :

  • Quels sont les 6 facteurs qui contribuent à une mauvaise qualité de la VoIP,
  • Comment évaluer la qualité des appels VoIP,
  • Comment faire la balance entre les besoins de vitesse des équipements et celui de qualité des appels VoIP,
  • Comment capturer les données VoFI et comment identifier l’apparition des problèmes,
  • Comment analyser les appels VoFI paquet par paquet et vérifier la qualité effective avec le play-back.

Cette présentation est disponible ici : QoS de la téléphonie sur IP

Librement inspiré du blog de l’éditeur WildPackets par NetWalker, distributeur pour la France.

Trois points clés pour déterminer si la latence est causée par le réseau ou par les applications. 11 mars 2010

Posted by frnetworker in Diagnostic Réseau, InterMapper, OmniPeek.
Tags: , , , ,
add a comment

Le réseau est le support d’un large spectre d’applications, depuis les plus simples hébergées en local comme l’email à des applications plus complexes utilisant de multiples serveurs ou encore des applications dépendantes des temps de réponses comme la VoIP. Lorsque le trafic de telles applications transite au travers de data centres, la tendance à atteindre les limites rend les latences du réseau encore plus pénalisantes. Identifier puis corriger les ralentissements devient rapidement une nécessité et peut parfois relever de l’exploit !

Mais dans ces conditions, qui est responsable de ces temps de réponses déplorables pour les utilisateurs  ? L’application elle-même ou le réseau ?

En premier lieu, nous devons définir les deux types de latence possibles réseau ou applicatif.

La latence réseau est le temps nécessaire à l’application pour envoyer une requête et à l’applicatif (sur le serveur) pour renvoyer l’accusé de réception de la requête. (Un message est renvoyé au travers TCP pour accuser la bonne réception du paquet de requête).

La latence applicative est le temps nécessaire de l’application pour traiter la requête et renvoyer les données de la réponse. C’est cette latence, mesurée par l’indice Apdex, qui permet une estimation du taux de satisfaction des utilisateurs applicatif par applicatif.

La plupart des logiciels d’analyse réseau proposent quelques outils de mesure des temps de latence mais dans la plupart du temps et à la différence d’OmniPeek, ils ne permettent pas de différencier l’origine des latences.

Voici les trois points qui vous permettront de connaitre la source de la latence : Réseau ou Applicatif et parfois même les deux à la fois.

  1. Faire la part des choses : latence réseau versus latence applicatif
    C’est bien connu, tous les problèmes des applications sont dus à des dysfonctionnements du réseau!  « Coupable tant que pas prouvé innocent ! »

    Dès lors, mesurer avec précision la latence réseau et celle des applicatifs est la preuve de la compétence et de l’impartialité des ingénieurs réseau. L’analyse des paquets est idéale pour se rendre à l’évidence. L’échange de paquets lors d’une conversation entre un poste client et une application (sur un serveur) permet de visualiser si le réseau est la source des latences constatées ou si l’application est le point de congestion. Pour cela, il suffit de comparer le temps de réponse nécessaire à l’envoi du paquet d’accusé de réception de la requête (latence réseau) et le temps de réponse nécessaire à l’envoi des informations résultant de la requête (latence applicative). Le plus souvent, l’accusé de réception est renvoyé très rapidement (quelques millisecondes) tandis que la réponse de l’application elle-même nécessite plusieurs secondes. Si c’est ce que vous constatez vous aussi, c’est que l’application  est la cause de la latence.
  2. Evaluer périodiquement les applications clés et la réactivité du réseau
    Investir dans une analyse régulière préventive des éléments clés est le meilleur outil pour détecter rapidement toute dégradation de performances. Même si cette technique ne contrôle que le temps de réponse (de latence) réseau, elle fournit des informations indispensables pour déterminer l’origine d’une dégradation des temps de réponse. Par exemple, lancer une série de Ping à intervalles réguliers à votre application de CRM peut fournir une base de mesures de référence objective des variations de performances pour les utilisateurs. (NDLR : il est évidement plus simple d’utiliser un logiciel comme InterMapper pour réaliser cet étalonnage de manière permanente et automatique). Si les valeurs commencent à augmenter, c’est que le temps de réponse du réseau est en passe de devenir problématique rapidement. Si les utilisateurs se plaignent des temps de réponse sans que votre échantillon ne montre de modification de la latence des pings, alors c’est l’applicatif lui-même (ou le serveur qui l’héberge) qui est à incriminer.
  3. Conserver des graphes de l’évolution des temps de réponse dans le temps
    Grapher le temps de réponse dans le temps, c’est disposer d’un référentiel indispensable pour détecter les variations qui nécessitent votre attention.La supervision des temps de latence vous permet de corréler  les variations avec d’autres statistiques comme par exemple la charge réseau au même moment. Ce type de monitoring (d’analyse préventive) est essentiel pour détecter au plus tôt les problèmes afin de se focaliser sur leur origine.Dans l’idéal, les temps de latence du réseau et des applications devraient être graphés en parallèle au fil du temps. La fluctuation des courbes (relative et absolue) sera toujours riche d’enseignement.Le monitoring des temps de réponse peut inclure la mise en place de seuils d’alertes automatisés. Cela permet aux ingénieurs d’intervenir sur un problème de latence réseau avant même que les performances de l’applicatif  n’en souffre, au plus grand bénéfice des utilisateurs.

Cet article est librement inspiré du blog de l’éditeur WildPackets par NetWalker

%d blogueurs aiment cette page :