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.

Et aussi

  • 2 mai 2014 DDoS sur un service SaaS Nouvel article dans la série : surveillance des réseaux et services Rien de tel que des exemples pour illustrer ce qu’apporte un système de suivi des performances comme celui que nous préparons [annonce]. Premier exemple, le fournisseur SaaS qui subit une attaque DDoS. Comme souvent cela démarre un lundi matin. Les performances de bases sont déjà moyennes (temps de réponse […]
  • 20 mai 2014 Performance d’une application dans un environnement mutualisé Les précédents articles de la catégorie ont permis de visualiser un certain nombre de cas figures liés aux réseaux (WAN + LAN). Mais les serveurs eux-mêmes sont la cause de différences de performances notables. D'où la nécessité de superviser ces performances, en particulier sur les environnements mutualisés comme les clusters de machines virtuelles. Voici quelques […]
  • 13 mai 2014 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 […]