OPNET Technologies:

Sondes Réseaux pour le Monitoring réseau  Temps réel et

la Surveillance des temps de réponse applicatifs

Le but de ce document est de présenter les principales fonctionnalités de la solution ACE Live en prenant comme exemple des données collectées dans un cadre d’utilisation typique.

Les sondes réseaux d'OPNET Technologies, de type appliance, permettent  de diagnostiquer les problèmes réseaux en prenant en compte une vue de bout en bout de l'application. Les problèmes traités sont plus particulièrement lié au temps de réponses réseaux et applicatifs, à la compréhension des baisses des performances dans le temps des applications et au suivi de la bande passante.

La sonde réseau est non intrusive et elle est placée sur un segment Ethernet cuivre ou fibres optiques. La gamme de sondes est adaptée à la taille des réseaux en se basant sur le nombre maximum de paquets par secondes à supporter. La sonde réseau possède deux interfaces d'acquisition et d'un port de management.

 Sonde réseau  

La sonde décode les flux et conserve les données statistiques sur son disque dur. Les résultats sont stockés sur la sonde sous forme de bases de données. Cette structure permet de forer dans les résultats de façon à avoir des indications pertinentes liées au métier de l'exploitant réseaux. Les histogrammes et rapports sont facilement accessibles. Pour afficher les tableaux de bord d'une sonde, il n'y a pas à installer de logiciel particulier sur la console, l'interface utilisateur est le Navigateur web en Java. 

Les appliances peuvent être installées dans les différentes architectures rencontrées. Chaque sonde peut être connectée sur un port de Miroring de switch ou sur un tap cuivre ou fibres. Ci-dessous la configuration avec TAP qui permet d'assurer la meilleure qualité possible sur les informations recueillis en évitant les écueils liés à la méthode de redirection dans un switch LAN.

Exemple d'installation de la solution sur le réseau

L'administration la sonde et la consultation des métriques est réalisée via une interface java. Il n’y pas de logiciel (client lourd) à installer sur le poste de l’utilisateur. La sécurité d'accès aux données est assurée par login et password.

Les fonctions principales sont un affichage temps réel des principaux métriques, l'édition de statistiques sur l'ensemble des métriques, la génération d'alarmes sur des seuils particuliers et la réalisation de captures (traces). Les principaux métriques sont la charge, le débit sur le site central et sur les sites distant, la volumétrie par application, les matrices de trafic, la ventilation par protocoles utilisé et la valeur de la latence.

ACE Live fait partie de la famille de sondes dites non intrusives (ou passives). Le trafic réseau passant sur un ou plusieurs liens est analysé en permanence afin de présenter différents tableaux de bords :

Ø     Volumétrique : qui parle avec qui.

Ø     Applicatifs : quels sont les applications utilisés et quels sont les temps de réponses associés.

Ø     Sécurité : détection automatique de comportement anormal pouvant suggérer la présence d’un virus sur une machine particulière.

Ø     Historique : visualisation des ressources consommées (par site distant, par applicatif, …) dans le temps et analyse des tendances

2.1.    Software ou Hardware :

La solution ACE Live peut être déployée soit dans une version purement software (appelée « rover ») qui sera parfaitement adaptée pour l’audit ponctuel de sites clients. Le « rover » peut tourner sur un PC portable classique et est capable de supporter un débit de 5000 pps (paquets par secondes). Avec une taille de paquet moyenne de 500 octets, cela donne donc un débit effectif de l’ordre de 20 Mbps. La majorité des copies d’écrans qui sont utilisées dans ce document ont été prises sur notre « rover » installé en coupure de l’accès WAN du bureau français d’OPNET situé à Paris (Boulogne Billancourt)

Si l’on désire supporter des débits plus importants ainsi que de disposer de capacités de stockages plus étendues, deux versions hardwares sont disponibles, à savoir ACE Live 2000 et ACE Live 3000. Ces « appliances » seront plus adaptées pour un monitoring sur des liens WAN de « Data lefts » ou bien pour monitorer des liens Gbps entre des serveurs.

Se référer à l’Annexe I pour obtenir les caractéristiques techniques des différentes solutions.

De plus, une « appliance » appelée « ACE Live Director » va permettre d’agréger les données collectées par les différentes sondes ACE Live déployées sur le réseau dans son ensemble.

Il est important de noter que l’interface graphique sera exactement la même quelle que soit la solution utilisée (« rover », « appliance », « director »).

En ce qui concerne les sondes passives (« rover » et « appliances » ACE Live 2000 et 3000), l’installation est on ne peut plus simple.

Soit on vient se mettre en coupure (via un « tap ») sur le lien à monitorer soit on utilise la technique dite de « port mirroring » pour rediriger un ou plusieurs liens vers les interfaces de monitoring de la solution.

La sonde pouvant commencer à récupérer les informations en analysant le contenu des trames à la volée. Il n’est donc pas nécessaire de s’appuyer sur des informations supplémentaires comme SNMP ou Netflow.

De même, la base de données utilisée pour stocker les données collectées est intégrée dans la solution et ne nécessite aucune configuration particulière.

L’accès à distance sur la sonde se fait via un applet Java téléchargé automatiquement si nécessaire sur un poste client quelconque.

ACE Live dispose de plus de soixante métriques (voir Annexe II pour la liste complète).

La plupart d’entre elles sont bidirectionnelles (entrant ou sortant, « inbound » ou « outbound »).

Si l’on utilise un « tap », la sonde va automatiquement déterminer le sens de communication.

Si technique de « port mirroring », alors il faudra configurer la sonde pour lui spécifier quelles sont les adresses internes du site sur lequel cette dernière a été placée. Par exemple, le site de Paris d’OPNET utilise la plage d’adresse 192.168.10.224 – 192.168.10.255 ce qui nous donne 192.168.10.224/27. La notion de trafic entrant ou sortant sera donc relative aux plages d’adresses spécifiées comme étant internes au site considéré.

Plusieurs tableaux de bords sont disponibles par défaut (appelés « Insights ») comme le nombre la figure 3 :

Figure 3

En haut, on peut voir que l’on a sélectionné une période temps spécifique, à savoir entre le 16 et le 26 Janvier 2008, ce qui va constituer la base de temps utilisée dans toutes les copies d’écrans de ce document.

Plusieurs onglets sont disponibles (« Audit », « Baseline », « Troubleshoot », « Security », « Optimize », « Custom »).

La figure 4 ci-dessous décrit les différents types de fonctionnalités disponibles :

Figure 4

Si l’on se concentre tout d’abord sur l’aspect audit, le tableau de bord « Total Traffic Dashboard » va nous donner une vue d’ensemble des données collectées par la sonde comme le montre la figure 5 page suivante:

Figure 5

Le débit total (entrant et sortant) est sélectionné comme métrique et l’on peut constater assez logiquement des périodes d’activité lors des jours de la semaine avec une pointe importante le Lundi 21 Janvier cependant.

En cliquant sur l’onglet « Top IP Addresses » on va obtenir la liste des adresses IP les plus bavardes comme le montre la figure 6 page suivante :

Figure 6

Deux adresses internes sont listées comme les plus bavardes : 192.168.10.232 et .231 suivies par deux adresses externes : 87.231.193.219 et 208.53.138.68.

Le prochain onglet « Top IP Conversations » va nous permettre de connaître quels sont les paires d’adresses IP qui ont consommé le plus de bande passante sur l’intervalle de temps considéré (on rappelle que celui-ci est de 10 jours ici) comme le montre la figure 7 page suivante :

Figure 7

Sans surprise, on retrouve les quatre adresses IP précitées mais maintenant on sait qui parlait avec qui.

Le prochain onglet « Top Applications » va nous donner une ventilation par application utilisé. ACE Live utilise deux mécanismes pour « découvrir » les applications déployées sur le réseau. Une reconnaissance basée sur l’analyse de la « payload » au niveau 7 soit une reconnaissance suivant le port TCP ou UDP utilisé. La figure 8 page suivante va donc nous permettre de déterminer quelles sont les applications les plus souvent utilisées toujours sur la plage d’observation de 10 jours prise ici en tant que référence :

Figure 8

On remarque une majorité de FTP et de HTTP. La plupart des applications sont celles découvertes par défaut par la sonde. On note cependant en dernière position ici l’application « OPNET SCM » qui est une application définie par rapport à l’adresse IP du serveur. Cette application est l’application critique pour nous. Elle sert à entrer dans notre base de données tout contact ou action effectué par notre force commerciale. On verra par la suite que celle-ci a souffert de problème de performance durant la période d’observation.

Mais tout d’abord, intéressons nous aux deux conversations IP les plus importantes. Il est aisé d’obtenir des informations particulières par le biais des « tables ». Plusieurs types sont disponibles comme le montre la figure 9 page suivante :

Figure 9

Le nommage des tables est assez explicite. A noter cependant la notion de « Business Group ». Un BG est tout simplement un pool d’adresses IP pouvant donc définir un ensemble de clients particuliers (on pourrait définir un BG Marketing, un BG support, un BG Ventes, …, si l’on raisonne sur un seul site mais aussi on BG par site distant si l’on se place du côté « Data left »).

Si l’on revient sur les conversations IP, par défaut les 20 plus « bavardes » sont affichées automatiquement comme le montre la figure 10 :

Figure 10

On retrouve en tête les deux conversations IP vues précédemment et l’on peut maintenant s’apercevoir que 192.168.10.232 fait du FTP avec le tiers « chello.fr » tandis que 192.168.10.231 fait plutôt du HTTP avec le tiers « thextremehost.com ».

La figure 11 ci-dessous montre de manière graphique le débit utilisé pour ces deux conversations IP :

Figure 11

Les pointes en rouge pour 192.168.10.232 en FTP tandis que l’on observe un usage plus « régulier » pour 192.168.10.231 en HTTP. Il est possible de faire un « zoom » sur la journée du Lundi 21 Janvier uniquement comme le montre la figure 12 page suivante:

Figure 12

A gauche le débit entrant (« Inbound ») et à droite le débit sortant (« Outbound »).

On constate d’une part que le FTP (pour l’adresse 192.168.10.232) est entrant donc plutôt un « download » qu’un « upload » avec un débit légèrement inférieur à 4 Mpbs en moyenne. D’autre part, le trafic HTTP (pour l’adresse 192.168.10.231) est constant à 140 Kbps toute la journée entre 10h00 et 18h00, lui aussi dans le sens entrant, ce qui semble plutôt inhabituel.

Etant donné que le rédacteur de ce document utilise l’adresse 192.168.10.231, il n’est pas nécessaire de creuser plus loin et j’avoue que c’est le flux à 128 Kbps de charge utile de la radio live que j’écoute et dont je fais néanmoins profiter les autres membres du bureau, y compris mon collègue utilisant l’adresse 192.168.10.232 dont on connaît la fâcheuse habitude à  télécharger des images ISO de près de 700 MB entre midi et deux pendant sa pause déjeuner…

Dans le cadre d’un audit ponctuel, on se rend bien compte qu’il est assez simple et rapide d’obtenir des informations de type volumétrie sans configuration particulière et donc comment l’on peut surveiller l’utilisation de notre lien WAN que ce soit au niveau adresses IP ou bien applicatif.

4.1.    Contexte

Une de nos applications majeures s’appelle SCM (Sales Case Manager). Elle sert principalement à notre force commerciale afin de pouvoir enregistrer et suivre tout contact effectué avec un prospect ou client. Récemment, ces derniers sont venus se plaindre de très mauvais temps de réponse : « J’attends des fois plus d’une minute avant de voir la page se mettre à jour ». Pendant ce temps, ils ne peuvent pas faire grand-chose à par attendre que « ça finisse par passer ». D’où d’une part, un perte de temps et un certain énervement car cela ne pouvait pas leur permettre d’être aussi efficace que d’habitude.

Dans ce cas de figure, on a toujours tendance à contacter les gens qui s’occupent et/ou connaissent le réseau (en l’occurrence nous-mêmes, les ingénieurs avant vente, même si on en principe d’autres attributions mais c’est une autre histoire).

Comme justement nous étions sur des sujets « plus urgents » pour nous, la situation a perduré quelques jours avant de devoir s’y plonger car le niveau d’énervement de nos amis commerciaux augmentait au fur et à mesure que les jours passaient.

Bien évidemment, si l’application avait été utilisée par la direction, tout le monde aurait été sur le pont immédiatement (un cas de figure que l’on rencontre fréquemment chez nos clients) ce qui laisse sous entendre que la criticité de l’application est proportionnelle au niveau de l’utilisateur dans la hiérarchie dans l’entreprise.

Bref, constatant une agitation de plus en plus grande de la part de nos amis commerciaux, il a fallu se rendre à l’évidence qu’il y avait probablement un problème récurrent qu’il fallait résoudre.

De part notre expérience avec la solution de troublehooting applicatif ACE, nous savions que le comportement par défaut est d’incriminer le réseau quand le niveau de performance baisse.

Et qu’en pratique, on constate plus fréquemment des problèmes de code applicatif pas adapté à un déploiement sur un WAN ou bien des problèmes de performances serveurs.

4.2.    Problème réseau ou non ?

Comme expliqué précédemment, notre site de Paris est un site client avec un plan d’adressage en 192.168.10.224/27 (i.e. de .224 à .255). L’application SCM est une application « web based », donc accessible via un navigateur internet via l’URL « scm.opnet.com ».

Afin de tracer les échanges entre les clients et le serveur en frontal, nous avons donc défini une application appelée « SCM ».

La définition peut se faire sur une adresse IP (i.e. celle du serveur). Dans ce cas, on va pouvoir regarder tous les échanges effectués avec cette adresse. Dans notre cas, c’est amplement suffisant puisque ce serveur est dédié pour cette application.

La définition de l’application va s’effectuer via l’ « Application Manager » comme le montre la figure 13 :

Figure 13

L’application est basée sur le protocole de transport TCP et il serait possible de définir la plage de ports utilisés par cette application (non nécessaire ici puisque serveur dédié).

Comme le serveur est dédié, l’adresse IP (172.16.6.33) est suffisante pour définir l’application comme le montre la figure 14 :

Figure 14

Il aurait aussi été possible de définir l’application par rapport à une URL comme le montre la figure 15 ci-dessous pour une autre application appelée « OPNET product update »:

Figure 15

Une fois l’application « SCM » définie, on peut passer sur la table « Application » afin de visualiser les échanges entre nos postes clients et l’application « SCM » comme le montre la figure 16 ci dessous :

Figure 16

On note 9 adresses IP du site de Paris. La métrique qui nous intéresse ici est « User Response Time (clients) »

En double cliquant sur la valeur de la métrique pour par exemple l’adresse IP cliente 192.168.10.227, on obtient une décomposition du temps de réponse comme le montre la figure 17 :

image002

Figure 17

On constate des pointes jusqu’à 14 secondes. Il est important de noter que la métrique en question ne travaille pas sur le temps de réponse global de la transaction mais plutôt sur les différents éléments de celle-ci. Une page web est constitué de plusieurs objets que le client va réclamer en effectuant des « Get ». Ce sont ces « Get » qui sont calculés ici. Si la page est constituée de 10 objets alors on peut déduire que le temps de réponse total (si un « Get » prend 10 secondes) peut monter à 100 secondes (délai remonté par les clients). En quelque sorte, on peut dire que l’on obtient ici un « baromètre » de l’application, i.e. des tendances qui vont pouvoir indiquer la présence ou non d’un problème potentiel.

Maintenant, travailler sur une seule adresse IP est dommage car comme on le constate ici, il n’y a pas de données pour le week end (assez normal) et certains jours de la semaine entre le 21 et le 26 Janvier (pas de présence au bureau de la personne concernée).

Il serait plus intéressant de travailler sur un graphe comportant toutes les adresses IP concernées afin d’obtenir plus d’informations. C’est ici qu’apparaît le concept de « Business Groups (BG)». Un BG est tout simplement un pool d’adresses IPs. Par exemple, le BG « Paris Office » que l’on va utiliser par la suite est tout simplement l’ensemble des adresses IP allouées à notre site de Paris.

La figure 18 page suivante utilise maintenant la table « Business Group » pour visualiser les données collectées entre le BG « Paris Office » et l’application « SCM » :

Figure 18

La figure 19 ci-dessous quant à elle est similaire à la figure 17 mais va agréger les résultats pour les 9 adresses IP vu précédemment :

Figure 19

La première constatation que l’on peut faire visuellement est que les temps de réponses sont mauvais pour le début de l’intervalle (Mercredi 16 jusqu’au Samedi 19 Janvier) quand le problème était présent puis s’améliorent grandement par la suite (une fois le problème résolu). Le code couleur pour décomposer le temps de réponse est le suivant :

·        Bleu :               temps d’établissement de la connexion TCP

·        Orange :           temps de réponse serveur

·        Vert :               temps réseau pour transmettre les données

·        Rose :              temps dus aux retransmissions TCP => pertes de paquets

On constate clairement une corrélation entre la dégradation du temps de réponse et la présence de retransmissions TCP en rose. Cela revient à incriminer le WAN et soit le fournisseur d’accès Français (côté site Paris Office) soit américain (côté « Data left »).

Outre la visibilité que permet de ramener ACE Live comme vu dans la première partie du document, l’autre grande valeur ajoutée est de pouvoir fournir ce type d’information dans un cadre de troubleshooting et de faire un premier niveau de triage en cas de problème. Dans le cas présent, ce n’est visiblement pas un problème applicatif ou serveur mais bel et bien un problème réseau.

Mais est-ce un problème opérateur français ou américain ?

4.3.    Isolation de la source des retransmissions

Ici, il est intéressant de se placer du point de vue « Data left » (ce qui serait  la place « normale » à utiliser si l’on utilise une seule appliance). Côté US, le « Data left » est équipé d’une appliance ACE Live hardware accessible à distance également.

Le concept de « Business Group » est de nouveau utile afin de comparer par exemple les temps de réponse de la même application (appelée CRM maintenant) entre deux sites distants, à savoir Paris et Londres. La figure 20 ci-dessous provient donc de la sonde placée en entrée du « Data left » US :

Figure 20

En haut, le BG « Paris office » et en bas le BG « London Office »

Concernant la période qui nous intéresse (Mercredi 16 à Lundi 21 Janvier), il semble clair que le problème touche uniquement le site de Paris donc plutôt l’opérateur français.

Mais en analysant plus finement la journée du Vendredi 18 Janvier pour le site de Paris, on constate un phénomène intéressant (figure 21 page suivante) :

Figure 21

Premièrement, il est nécessaire d’indiquer que chaque bureau d’OPNET est équipé d’un robot SLA Commander qui rejoue de manière régulière une transaction sur l’application « SCM ».

C’est pour cela que le trafic n’était pas nul durant le week end sur les graphes précédents et c’est aussi pourquoi on voit des petits pics durant la nuit pour la journée du Vendredi 18 Janvier. L’avantage d’un robot étant que l’on va monitorer de manière active (une véritable transaction est effectuée, ici un recherche sur la base de données) le temps de réponse même quand aucun utilisateur n’est présent.

Les premiers problèmes surviennent vers 9h30 (heure française) mais sont amplifiées durant la journée de travail. Mais surtout, après 19h00 (heure française), on constate que le robot (étant le seul à travailler) a des temps de réponses qui continuent à être mauvais pendant la soirée, ce qui est plus étrange. Le « Data left » US est sur la côté EST des US donc il existe un décalage horaire de 6 heures :

9h00 – 18h00 (heure française) = 3h00 – 12h00 (heure côte EST US).

12h00 – minuit (heure française) = 6h00 – 18h00 (heure côte EST US).

On constate donc que la plus grande partie des retransmissions se produit pour les heures de travail US et non pas françaises ce qui revient à incriminer maintenant le fournisseur d’accès US d’OPNET.

C’est pour cette raison que l’on a d’abord contacté l’opérateur américain afin de lui demander de regarder s’il n’y avait pas de problème avec son trafic destiné vers la France.

Le contact a été fait Dimanche 20 Janvier. Dès le Lundi 21, le problème avait disparu comme le montre encore plus clairement le temps de réponse entre notre robot français (192.168.10.249) et le serveur « SCM » sur la figure 22 page suivante :

Figure 22

Dans cet exemple réel, on voit l’intérêt de mettre en place en plus de la solution de monitoring passive ACE Live une solution de monitoring active comme SLA Commander afin de pouvoir obtenir des informations même sans aucun utilisateur présent.

A supposer que le problème ait été plutôt côté « serveurs », i.e. plutôt des temps d’attentes côté « Data left », ACE Plus aurait été utile afin de pouvoir analyse en détail les trames capturées afin de détecter des requêtes applicatives mal codée, un serveur trop lent à répondre voire des problèmes relatifs aux paramètres de la couche TCP (taille de fenêtre non optimale, utilisation de l’algorithme de « Nagle », phénomènes de fenêtres TCP « gelées »)…

La figure 23 montre l’intégration possible entre ACE Live (sur les accès WAN) et ACE avec ses agents gratuits que l’on peut donc potentiellement installer sur tous les postes de l’entreprise :

Figure 23

ACE Live utilise le concept d’ « Insights » afin de fournir des tableaux de bords customisés et accessibles en un seul clic de souris.

Plutôt que de refaire plusieurs fois la même manipulation pour atteindre des données (par exemple, avoir la décomposition du temps de réponse pour l’application « SCM » ou vérifier l’utilisation du lien WAN du site de Paris), on va pouvoir se créer un tableau de bord spécifique qui sera accessible immédiatement.

Pour ce faire, on utilise le « Insight Development Kit » comme le montre la figure 24 :

Figure 24

Par la suite, on pourra en un seul clic obtenir la vue présentée figure 25 ci dessous:

Figure 25

OPNET propose toute une gamme de solution dans la sphère dite de l’APM (Application Performance Management).

Ø     ACE Plus : Troubleshooting applicatif et validation des applications avant déploiement sur le WAN.

Ø     ACE Live : Monitoring temps réel en mode passif et de troubleshooting rapide (notion de triage) afin de déterminer si un problème est plutôt réseau ou applicatif

Ø     SLA Commander : Générateur de transaction synthétique pour monitoring actif de temps de réponse applicatif

Ø     Panorama : Solution de monitoring et d’analyse des performances de chaînes applicatives complexes (web, J2EE/.NET, DBs)

Ce document portait sur ACE Live en particulier sachant qu’un descriptif similaire est disponible pour les autres solutions de la gamme APM sur demande.

Concernant ACE Live, le taux de clients ayant testé puis acheté la solution dans leur environnement est de plus de 80%.

Ce document n’est pas une description fonctionnelle complète de la solution ACE Live mais plutôt une présentation de la façon dont on utilise la solution au jour le jour. D’autres fonctionnalités sont disponibles (analyse sécurité, reporting, alertes, création de tableaux de bords customisés, monitoring VoIP,..) mais ne sont pas décrites ici.

Solution ACE Live possible avec agrégation via un boitier vers une seule sonde.