Ce service web est lent, ou pas !

Nouvel article dans la série : surveillance des réseaux et services

Quand un utilisateur signale un problème avec un site web, il est toujours facile de lui dire que le problème ne touche que lui. Mais lorsque ce n’est pas le cas, on n’a fait que jeter de lui sur le feu !

Illustrons avec ce nouvel extrait de statistiques. Google (le moteur de recherche) est déjà en soi un bon baromètre des accès Internet. Mais lorsqu’on voit vers 9h50, que tous les temps de réponse de Google, Salesforce et Webex s’envolent tous, on peut facilement répondre à un utilisateur que son problème n’était pas unique.

Selon le cas, il reste à investiguer (en croisant avec d’autres indicateurs) quelle est la cause de ce ralentissement (proxy, lien d’accès). A suivre dans d’autres épisodes

140331_internet-access-events

QoS, sauvegardes et autres trafics sur un lien MAN / WAN

Premier article dans la série : surveillance des réseaux et services

C’est bien connu quand on a des liens MAN /WAN à 100Mbps, on n’a pas de souci de performances à se faire.

Perte paquets engendrée par une grosse sauvegarde / synchronisation

En fait, la réalité est souvent plus subtile. Ce graphique illustre un lien MAN suivi tout simplement par des tests ICMP. En général, les latences sont très bonnes variant entre 11ms et 15ms.

On voit tout de même samedi, que le backup / synchro à froid des clusters de stockage a duré un certain temps (24h !) et que les pertes de paquets correspondantes tournaient autour de 3%. Si le week-end offre des fenêtres de maintenance évidentes, il faut tout de même faire attention au fait que d’autres « épisodes » de même nature, mais plus brefs, se sont encore produits en semaine (nuit de mardi à mercredi, sur ce premier graphique) voire en journée (graphique ci-dessous sur une semaine antérieure). Autant annoncer de suite que la qualité des visio passant par le même chemin n’a pas été optimale.

140401_perte-paquets

L’apport d’une surveillance continue est d’identifier régulièrement ces trafics massifs mal gérés qui peuvent pourrir la vie des autres usages des réseaux. On peut les placer dans des fenêtres temporelles adéquates, on peut les configurer pour qu’ils n’estropient pas les autres trafics…

Les cas sont multiples et ne se présentent pas de façon toujours aussi évidente qu’un outil de backup (il suffit de penser au Patch Tuesday de Windows, via Windows Update ou WSUS)

 

Quelle est la qualité des réseaux dans vos agences et sites distants ?

Comme conseil spécialisé, nous sommes appelés à étudier & architecturer des réseaux IP, quotidiennement. Et certains constats se répètent.

  • Lorsqu’on interroge les utilisateurs, particulièrement sur sites distants ou en agences, ils se plaignent de lenteurs.
  • Lorsqu’on interviewe les administrateurs réseaux, ils montrent des graphes d’utilisations des liens. Parfois ils grommellent : si les tuyaux n’étaient pas remplis de flux YouTube, il y aurait moins d’incidents ; c’est par manque de budget si les liens sont insuffisamment dimensionnés…

Le problème est qu’il n’est pas facile de faire un lien entre les graphes et les plaintes. Le taux de remplissage est un mauvais indicateur parce qu’on se heurte facilement à des contre-exemples.

  • lorsque la QoS (DSCP) est correctement mise en œuvre (un gros si, il faut en convenir), la ToIP traverse sans peine un WAN, même saturé à ses accès.
  • inversement, si le tri entre flux n’est pas fait, ou l’application sur-réagit à de légers « défauts » du réseau (ils sont en partie intrinsèques puisque TCP détecte la saturation par les pertes de paquets, rappelons-le), on peut avoir des lenteurs majeures pour les utilisateurs avec des tuyaux peu remplis.
  • et pour finir, les lenteurs qu’on attribue au « réseau » – cet « éther » de l’informatique –  sont aussi causées par des limites des serveurs (processeurs, disques), des protocoles (verrous de base de données, non-streamlining des requêtes), voire des postes client (c’est incroyable comment on peut « accélérer » le réseau en remplaçant des PC équipés de disques durs traditionnels, par des PC équipés de SSD !). Il s’ensuit donc un jeu de ping-pong de responsabilité entre équipes ou prestataires qui pourrait être drôle si les utilisateurs n’attendaient pas…

Pour éviter que les redimensionnements se pratiquent par crise, pour que les budgets se mobilisent (ou inversement ne se consument pas en sur-capacité pour rien, car c’est le versant le moins visible de la difficulté de dimensionner sans points de repère), il faut apporter des éléments factuels des performances observées depuis les sites distants. Techniquement des mesures de la latence des services.

Sur le papier, les capacités de métrologie ne manquent pas. Par exemple, les routeurs Cisco peuvent être activés comme sondes de tests. Les fonctions IP-SLA permettent de lancer des requêtes http depuis un site distant, des ping marqués DSCP, de mesure la gigue, etc. Mais je pense que si Cisco avait les moyens comme Microsoft avec Office de mesurer le taux d’usage par fonction embarquée, on ferait le constat qu’IP-SLA est mis en œuvre sur moins de 1% du parc.

Les PC aussi peuvent servir de sonde, comme nous l’avons fait en 2011 avec des scripts mais les déploiements sont malaisés :

  • Les laptops changement de point de connexion avec les réseaux, même les desktops ne sont pas allumés en permanence
  • Les utilisateurs n’ont pas envie d’avoir un agent de plus qui consomme CPU, mémoire, etc.
  • Windows remet à zéro les champs DSCP
  • Etc.

Nous avons donc essayé de réfléchir à un dispositif alternatif pour répondre simplement à ces questions simples :

  • Quelles sont les temps de réponse effectifs depuis mes sites distants pour mes principaux services réseaux ?
  • Est-ce le réseau qui est lent, les systèmes (serveurs, PC) ou mon fournisseur SaaS ?
  • Puis-je avoir un suivi sur la durée, car les problèmes difficiles sont intermittents et les retours utilisateurs ne sont pas immédiats ?

Pour ne pas connaître un aussi faible usage que les moyens précédents, l’idée est de faire aussi simple que le déploiement des box opérateurs. Avec des millions de clients, ils sont devenus extrêmement rodés :

  1. Demande de livraison d’un boîtier sur site et configuration de quelques éléments spécifiques de configuration sur un portail web
  2. A l’arrivée du boitier, connexion plug-and-play sur une prise LAN RJ45 et une prise électrique

Le portail permet ensuite le suivi via graphes et alertes sur performances.

Nous en sommes actuellement à l’état de quelques prototypes. Nous envisageons d’ouvrir une première expérimentation opérationnelle de services en juin et vous tiendrons informé sur ce blog. En attendant, vous pouvez nous contacter si vous voulez influencer le développement, nous indiquer quel serait le coût à ne pas dépasser ou toute autre remarque.

A bientôt.

Web QoS : l’acronyme manquant qui a de l’avenir

Il y a quelques semaines, lors d’une session de travail pour la réalisation d’un schéma directeur télécom, j’ai pu faire le constat que même si les acronymes sont nombreux dans notre domaine, il en manque encore parfois.

Nous faisions le constat partagé de problèmes de « qualité » au niveau des réseaux : lorsqu’au sein des flux http, les vidéos YouTube sont dans la même catégorie que les sessions d’e-learning via WebEx, fort logiquement, aux heures de pointe sur les sites contraints en bande passante, la qualité des visio avec cet outil de webconférences se dégrade rapidement au point d’être inutilisable.

Je me suis donc laissé aller à dire que le réseau nécessitait de la Web QoS, pour me faire interpeller par un DSI un peu surpris : il avait l’impression que cela faisait 3 ans que ses équipes mettaient en œuvre la QoS sur le WAN (l’organisation finissait un cycle d’équipements en ToIP) !

L’incompréhension (temporaire car c’était à moi de mieux m’expliquer) est que l’acronyme QoS (tout court) est généralement associé à la priorisation au niveau IP (aussi appelé niveau 3 dans le modèle en couche des réseaux). A ma connaissance, il n’y a pas de vocabulaire établi pour la priorisation au niveau applicatif (niveau 7), ou encore l’association de priorités entre couches (comment un trafic prioritaire au niveau http (niveau 7) est rendu prioritaire au niveau IP, puis Ethernet (niveau 2). Par exemple, l’excellente base documentaire de JANET (l’équivalent anglais de RENATER) aborde au plus la question du mapping entre niveaux 3 et 2 (on parle d’autoqos dans un environnement Cisco), met en garde sur la non transparence des firewalls / proxies mais guère plus

Il n’y a pas besoin d’avoir une boule de cristal pour voir que le centre de gravité des systèmes d’information se déplacent vers Internet et le Web. Google et consorts y travaillent ardemment au point d’avancer vers http 2.0. Dans ce nouveau standard basé sur SPDY déjà embarqué dans Chrome et Firefox, la principale innovation pour améliorer l’efficacité du protocole, et améliorer la latence perçue par l’utilisateur consiste à multiplexer au sein d’une même connexion TCP plusieurs requêtes et réponses (streams pipelining). Evidemment, cela impliquera d’être capable de prioriser les flux à l’intérieur d’une session http.

Ce qui me permet de prédire que l’acronyme Web QoS (ou un autre qui s’imposera pour désigner la même chose) a l’avenir pour lui.

Revue de l’actualité Télécom, IT & Lean

Tout d’abord meilleurs voeux pour 2014 à tous les professionnels des Réseaux & Télécoms.

La trêve des confiseurs offrent de nombreuses opportunités de lectures. Ce billet est donc particulièrement fourni :

Perspectives et prospectives

Lire la suite

Où l’on parle de Dropbox, d’accès Internet…

Au fil des réunions, je note dans mon cahier des citations marquantes ou qui interpellent, selon l’expression consacrée. Deux exemples récents.

 

« on recherche une sorte de Dropbox pour l’entreprise… »

C’est la troisième fois en peu de temps que j’entends cette expression dans la bouche d’un DSI ou d’un responsable de solutions de collaboration chez des grands comptes. Force est de constater que, d’une façon ou d’une autre, toutes les solutions de gestion électronique de documents (Sharepoint, Alfresco…) ont été un jour ou l’autre contraintes de développer une interface type arborescence. C’est un magnifique testament à la lente conduite du changement réussie collectivement en une décennie, car je suis déjà assez ancien pour me souvenir de longues explications auprès des premiers utilisateurs de la bureautique pour appréhender le concept de dossiers.

Dropbox a su proposer un service simple, facile à appréhender à ce stade de développement des utilisateurs. Mais si j’apprécie l’outil pour un usage personnel, il est souvent intéressant de remarquer que la demande d’un Dropbox pour l’entreprise signale généralement une autre problématique d’accompagnement des utilisateurs. Nous l’avons encore démontré cette année, la plupart des entreprises sont déjà équipées des briques techniques pour offrir un service similaire. Encore faut-il les agencer, et le faire savoir.

 

« au fait, comment se fait-il que l’accès Internet soit moins bon que celui installé par mon mari à la maison ? »

Cette question posée par une responsable fraichement arrivée, alors qu’elle passe en revue la renégociation d’un contrat WAN de 2 millions d’euros annuels, a le mérite de poser franchement la question de la capacité d’une DSI à offrir des accès à Internet fiables, performants (au point de supporter des flux temps réels). Comme souvent, répondre à ce défi réclame une analyse saine, et de l’expérience pratique.

Une première dans les salles de marchés

stock_trading_screens_277277_h

Cela fait maintenant une bonne dizaine d’année que les entreprises migrent petit à petit vers la téléphonie sur IP. Les salles de marché s’y sont mis mais bien plus tard. En effet, les obligations techniques, fonctionnelles et réglementaires spécifiques au métier du trading ont ralenti la donne. On observe depuis quelques années la volonté de ces dernières de passer au tout IP pour se voir offrir de nouveaux services et remplacer les solutions devenues obsolètes.

Lire la suite

Revue de l’actualité Telecom, IT & Lean

Repenser les modes de travail

How can we get people more engaged, more productive, and happier at work? Is technology part of the problem – and could it also be part of the solution?  RSA Animate

Les limites du télé-travail – Phil Simon

Why Face-To-Face Meetings Are Overrated – Jason Fried interview by Inc

Visio

WebRTC, premières plateformes publiques –  LifeSize, OpenVRI, Tawk.com

Open H.264, une solution Open Source se débarrassant des problèmes de licence - Cisco et Mozilla

Virtualisation

Le creux de la « Hype Curve » se manifeste quand on se rend compte que la « solution » sert souvent à résoudre des problèmes qu’on peut adresser autrement, Forrester.

Sécurité

Infection rates and end of support for Windows XP – Microsoft la peur poussera-t-elle plus que les progrès techniques pour faire migrer les entreprises vers Win 7-8 ?

Une foultitude de détails techniques

Queueing in the Linux Network Stack – Dan Siemon

Why IPSec is so complex? – Ivan Pepelnjak

Do you have a sleepy NIC? – Microsoft TechNet

Optimizing TLS Record Size & Buffering Latency - Ilya Grigorik

Object Storage on Ethernet – Seagate

Estimating the Number of TCP Sessions per Host - Ivan Pepelnjak

Captures de paquets à la source

La semaine dernière, nous avions à analyser un problème d’interopérabilité de systèmes visio. La séance qui réunissait des personnes basées aux US, en France, à l’Ile Maurice et en Roumanie a tourné au show INTEROP avec des équipements de nombreux constructeurs :

  • Radvision (MCU et client mobile)
  • Polycom (HDX 4000 et 9000)
  • LifeSize
  • Tanberg (Edge 55) et Cisco (Jabber Video)
  • ACME Packets
  • Vidyo

L’avenir va à la multiplication d’équipements, équipements achetés par des acteurs divers (interne / externe, DSI / métiers / BYOD). Dans un tel paysage, l’existence de quelques hics n’a rien d’étonnant.

L’objet de ce message est que, dans cet environnement, la résolution de problème vire au cauchemar si on ne dispose pas des informations de bases, quels sont les messages échangés par les machines. Nous avons découvert à cette occasion que les équipements Vidyo disposaient nativement de la capacité de faire des captures de packets. Un test et quelques minutes plus tard, un fichier de 80 Mo(compressé) était sur le bureau de mon PC. Nous ne pouvons qu’engager les autres constructeurs à faire de même et à nous le signaler (cette facilité aurait été bien utile dans une autre affaire au début 2013 ; nous ne citerons pas de nom).

 

 

Déménagement IT : démonstration par l’absurbe

Dans nos activités liées aux déménagements (sièges d’entreprises, datacenters), il arrive quelquefois de rencontrer des entreprises qui ont du mal à en voir l’utilité de l’assistance, à comprendre notre rôle sur ces projets, allant jusqu’à nous confondre avec des entreprises manutentionnaires, preuve du décalage des points de vue de référence.

Pour briser la glace d’incompréhension, il m’arrive parfois de faire la démonstration suivante, par l’absurde. Je demande à mon interlocuteur d’imaginer qu’il déménage son PC de son bureau à son domicile, pour y faire du télétravail durable. Il a besoin d’un véhicule certes (le déménageur). Mais s’il ne prend aucune autre mesure, beaucoup d’applications ne fonctionneront pas sur son PC une fois connecté chez lui. Bien sûr ! est la réaction habituelle. Pourtant, vous y avez déjà accès à Internet, WiFi…

Pour faire court, nous sommes des ingénieurs qui menons les projets nécessaires pour que les postes de travail ou serveurs informatiques fonctionnent dans leur nouvel environnement (à votre domicile dans notre analogie). Dans le même temps, nous définissons / sélectionnons / faisons les recettes des installations et équipements du nouveau site.

Il est possible de faire ce travail par soi-même. Mais c’est faire peu de cas de l’expérience accumulée par la répétition des chantiers. A ce compte là, chacun peut être maçon pour construire sa maison.