jump to navigation

Cloud Computing, la fin de l’analyse réseau ? 30 mars 2010

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

Sauf si vous vivez sur une autre planète, vous avez sûrement entendu parlé du Cloud Computing* qui consiste pour les entreprises à outsourcer serveurs et applications.

Beaucoup d’entreprises ont déjà adopté cette technologie  : Pew Research Center rapporte que 69% des entreprises aux U.S.A. l’utiliseraient déjà.

L’adoption de cette technologie pourrait laisser penser que la supervision du réseau dans les entreprises est moins stratégique que par le passé puisque les applications et les problèmes sont, eux aussi, outsourcés !

Dès lors, la question se pose de savoir si le Could Computing annonce la fin de la supervision réseau ?

Nous pensons bien au contraire, qu’elle est plus nécessaire que jamais !

Même si la mise en place du Cloud Computing modifie la manière de superviser les réseaux, une infrastructure réseau robuste reste la clé de voûte pour permettre une communication fluide entre les utilisateurs et leurs applications.

En fait, la plus grande différence est que les administrateurs vont se concentrer sur la gestion (performances, disponibilité …) des services plutôt que sur celle des infrastructures.

D’un point de vue réseau, le Cloud Computing revient à gérer des flux accédant à des serveurs distants, comme cela est déjà le cas pour les entreprises multi-sites. De ce fait, la problématique réseau demeure : Goulets d’étranglements potentiels, mauvaise répartition de la bande passante, et utilisation de protocoles non autorisés subsistent et impactent directement la fluidité des communications.

Le contrôle des performances applicatives requiert dès lors une attention particulièrement aiguisée !

Il est essentiel de disposer d’un référentiel des performances applicatives AVANT de basculer en Cloud Computing ! Une attention particulière devra également être portée aux transactions cross-applications une fois le basculement réalisé.

Comme toujours, la sécurisation du réseau reste un point essentiel, la migration vers un nuage ne fait pas exception.

Ce contrôle de sécurité commence avec le choix du prestataire retenu. Confier la gestion et le traitement de données hautement sensibles à un prestataire nécessite une vigilance de chaque instant. L’étude et la compréhension de la politique de sécurité du prestataire ainsi que son contrôle lors de tests menés par vos soins est primordiale.

Les analyses réalisées avec OmniPeek lors des phases de tests vont permettre aux ingénieurs de disposer de données cruciales sur les performances et la sécurité pour assurer une migration en toute quiétude.

Si l’utilisation du Cloud-Computing sécurise l’hébergement physique des données, la disponibilité sans faille du réseau ne doit en aucun cas être négligée car il ne s’agit ni plus ni moins (d’un point de vue réseau) que d’un déplacement de serveurs ! Les processus d’analyse et de contrôle au fil de l’eau sont un point clé de la réussite d’une migration vers le Cloud Computing.

Ces procédures garantiront à l’entreprise un contrôle impartial et adapté des prestations en matière de performances, de disponibilité et de respect des procédures de sécurité indispensables.

Elles permettent de garantir une migration sous contrôle et un suivi dans le temps.

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

(*ou encore informatique dématérialisée ou informatique dans les nuages)

Publicités

Compass ou l’utilisation des statistiques pour accélérer le diagnostic 22 mars 2010

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

Le plus grand challenge du diagnostic de réseau est de cerner rapidement l’origine des problèmes pour les résoudre. Toutes les techniques afin d’optimiser le processus d’analyse rapide sont les bienvenues car elles permettent d’accroitre le taux de disponibilité du réseau et sa santé.

Partant de cette constatation, voici une suggestion : plutôt que de charger (et d’analyser) tous les paquets, gagnez du temps en utilisant les statistiques du trafic pour trouver des réponses aux questions comme « Que c’est il passé ?« , « Quand ?« , « Qui l’a fait ?« . En isolant la période précise grâce aux statistiques, vous pouvez alors focaliser toute votre expertise sur les paquets concernés.

Compass Forensics DashBoard

Exemple d'affichage de Compass

Pour vous simplifier la tâche, WildPackets rend disponible gratuitement* ‘Compass‘, un tableau de bord interactif pour OmniPeek. Ce tableau de synthèse (voir graphique) permet aux ingénieurs de sélectionner un intervalle de temps pour l’analyse. Ils peuvent alors afficher soit masquer des nœuds ou des protocoles à ce graphe afin de permettre comparaisons et corrélations sur différentes périodes.

Dans certains cas, la consultation du graphe de Compass permettra directement de résoudre le problème. D’autres fois, après avoir borné une plage horaire, les paquets concernés pourront directement être chargés grâce au bouton « Load Packets » pour une analyse complémentaire détaillée.

*Compass est téléchargeable gratuitement sur le site MyPeek pour les licences ayant un contrat de maintenance en cours.

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

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

Votre nouvelle application est elle une tueuse de réseau ? 9 mars 2010

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

Lorsqu’une nouvelle application est déployée sur votre réseau, les ingénieurs doivent être en mesure de prédire avec précision comment elle va se comporter et surtout garantir que les autres applications critiques ne seront pas pénalisées.

OmniPeek avec les fonctionnalités d’Analyse des performances du réseau (Network Performance Analysis) vous permet de déterminer immédiatement le comportement de nouvelles applications sur le réseau et l’impact éventuel sur les applications existantes.

Il existe trois signaux d’alerte indiquant qu’une nouvelle application ne fonctionne pas aussi bien qu’elle le devrait sur le réseau ou qu’elle dégrade les performances d’autres applications critiques.

  1. Les performances en production diffèrent de celles obtenues lors des tests préliminaires
    Les tests préliminaires peuvent prendre des formes diverses, depuis quelques simulations basiques à la simulation grandeur nature d’une session de travail réel. Mais la seconde approche peut être complexe à mettre en oeuvre et consommatrice de temps ! Il est pourtant simple d’obtenir une estimation précise grâce à OmniPeek. En installant l’application et en capturant les transactions représentatives d’une utilisation standard de l’application, la fonction ‘What If’ (Que se passerait il si …) permet de connaitre l’impact réseau réel en fonction du nombre d’utilisateurs prévus en production. Qui plus est, cela permet d’étalonner la charge induite, le comportement de l’application et de traquer toute variation lors de la mise en route finale de l’application.
  2. Les fondamentaux du réseau changent dramatiquement après le déploiement
    Sans étalonnage préalable des performances et du comportement ‘usuel’ du réseau les équipes travaillent à  l’aveugle à la fois lors du déploiement d’une nouvelle application mais aussi au jour le jour. Un échantillonnage doit inclure des statistiques sur une période suffisamment longue (une semaine par exemple) des points clés du réseau : nœuds, protocoles,  applications au cours du temps et une estimation du seuil de décrochage du réseau, typiquement le nombre de paquets perdus, de retransmissions, les temps de réponse des applications clés. Après le déploiement d’une nouvelle application (et comme pré-requis lors des phases préliminaires) un nouvel échantillonnage doit être réalisé et comparé point par point afin de détecter et de remédier à toute variation inattendue. Cette fonction est disponible en natif dans OmniPeek afin de faciliter la comparaison.
  3. Une modification du « pouls » du réseau
    La bonne santé du réseau tient à son seuil de tolérance au « bruit », mais les modifications de sa santé doivent être perçues au plus vite. OmniPeek analyse en permanence tous les signes vitaux en réalisant une expertise en tâche de fond et prévient quand ces indicateurs commencent à varier. Par exemple, lors de l’installation d’une nouvelle application, si OmniPeek détecte trop de retransmission TCP (‘Too many TCP retransmissions’) c’est un signe fort indiquant que cette nouvelle application a rompu l’équilibre du réseau.

Quelque soit la méthode retenue pour analyser les répercussions d’une nouvelle application sur le réseau, l’applicatif permettant de mesure et contrôler les performances devrait au minimum :

  1. Fournir des informations détaillées sur les sept niveaux du modèle OSI.
  2. Permettre la capture de données sur une période relativement longue (une semaine par exemple) pour établir un échantillonnage de référence.
  3. Identifier rapidement et localiser les points de stress réseau.
  4. Permettre de modéliser l’impact du trafic en fonction des données collectées lors d’une simulation.

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

%d blogueurs aiment cette page :