La QoS visible

Régulièrement, dans notre métier, nous sommes amenés à expliquer le fonctionnement de la QoS. Avec la nécessité de recadrer toutes les imprécisions laissées par des discours marketing trop approximatifs. Maintenant il faut bien dire que le concept est abstrait, tout comme ses manifestations. On a aussi connu des exemples d’entreprises qui pensaient que leur réseau supportait la QoS, pour finir par découvrir après incidents et analyses approfondies que certains « détails » faisaient que la QoS n’était pas maîtrisée de bout en bout.

D’où un besoin simple : comment démontrer visuellement et simplement que la QoS est bien implémentée ?

140428_impact-EF-3

Voici un graphique qui montre très clairement la différence effective. Les flux bleus ne sont pas taggés DSCP. Un backup est lancé vers 1h du matin et dure jusqu’à 4h. Les temps de latence du réseau (test ICMP) grimpent immédiatement à 200 ms. Inutile de préciser qu’une communication téléphonique ToIP supporterait mal ce choc.

Les flux de tests correspondants à la ligne rouge sont marqués prioritaires (DSCP = EF). Durant toute la période, la latence varie à peine. Pour information de contexte, la connexion WAN qui est le premier point de contention est un accès SDSL 2 Mbps.

A la vue du premier graphique, certains peuvent se dire que tous les efforts de mise en place de la QoS pour ne pas être impactés par des sauvegardes nocturnes n’en valent pas la chandelle. Pour ceux là, voici un deuxième graphique qui offre une fenêtre de temps plus grande.

140518-impact-EF

Sur la même destination, le graphique du haut – qui correspond aux flux non marqués – montre tous les impacts sur performances des différents traversants le lien. Celui du bas correspond au trafic prioritaire. Comme les échelles verticales sont cette fois différentes, on voit d’ailleurs que si la « protection » des flux prioritaires n’est pas absolue (dans certaines périodes, la latence atteint malgré tout le double de la valeur en heures creuses), elle remplit globalement son rôle. Cela tombe bien, le site est équipé en ToIP sans gateway locale…

 

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 exemples.

 

140519_VM-cluster

Dans cette première illustration, il s’agit d’un serveur applicatif Tomcat, sur une VM Linux. Il est en phase de tests, sans volume d’utilisateur. Sa performance de base en périodes creuses (la nuit, le week-end) se situe aux environs de 300ms. Ce n’est pas excellent mais acceptable si on remarque que ce temps de réponse inclut la négociation HTTPS.

Mais on note aussi les variations de performances durant les « heures ouvertes », avec des temps de réponse dépassant la seconde.

Comme il n’y a pas d’utilisateurs, toutes ces fluctuations sont uniquement dues à la capacité de réponse du cluster qui abrite les VM. A travers cet exemple, on voit clairement que virtualiser un datacenter conduit naturellement à la supervision des performances, fait bien connu des hébergeurs d’environnements mutualisés.

140516_2vCPU

Ce suivi contribue également à dimensionner ces VM, comme le montre ce nouvel exemple. Il s’agit d’une autre application dont les temps de réponse initiaux ne sont pas bons, à la fois parce qu’ils sont longs mais aussi parce qu’ils varient significativement. Ajouter un vCPU de plus dans les paramètres de la machine virtuelle apporte des temps de réponse nettement plus stables.

Un service SaaS qui a du mal à ternir la charge

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

Vous avez choisi de basculer vers une messagerie en mode SaaS. L’offre commerciale était alléchante et les performances bonnes lors de la phase de sourcing. Les mois passent avec les déploiements au siège puis sur site distants. Et les utilisateurs commencent à se plaindre. Le service est « lent », avec rapport de « déconnexion ».

Les sites distants étant les plus bruyants à se plaindre, le réseau est le premier accusé. Pas facile de faire le point.

140425_load-webmail

Graphiques en main, le constat devient plus clair : les autres trafics ne connaissent pas de ralentissements de même nature. Mais ce service est effectivement lent.

Explication : l’offre a rencontré un certain succès et le fournisseur a accumulé les utilisateurs sur les mêmes clusters. Si les performances (ici mesurées depuis le siège) sont excellentes la nuit ( !), dès que les utilisateurs se connectent en nombre, les temps de réponse se détériorent. Il est temps d’avoir une discussion avec le fournisseur.

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

SLA « 100% »

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

Dans les négociations commerciales, il y a toujours un décalage certain entre le discours des brochures

  • « Datacenter Tier-3 »
  • « architecture hautement redondante »
  • Etc.

Et le moment des engagements sur les chiffres de disponibilité, SLA et éventuellement pénalités.

Le problème est foncièrement difficile parce que :

  • Le client Entreprise n’a pas toujours de surveillance en propre
  • Les causes hardware sont rarement celles qui dominent comme le rappelle ce rapport du PTS , l’équivalent suédois de l’ARCEP autorité de régulation des télécoms (pour ceux qui lisent l’anglais mieux que le suédois, les causes sont par ordre décroissant 1. Software, 2. Overload, 3. Cable cut, 4. Hardware, 5. Power/electricity)
  • outre les gros incidents, francs et nets, il y a une myriade de micro-coupures d’origine diverses et souvent « logicielles », des reconfigurations.

140424_restart

Ce cas est illustré avec une cible de surveillance interne sur notre site web. Suite à une attaque de notre site, une règle un peu stricte d’autoprotection empêchait certaines fonctions (envoi de CV). Résultat : il a fallu redémarrer le proxy/WAF (apache/mod-security pour être précis), en pleine journée !

Evidemment le baromètre automatisé de suivi ne loupe rien… comme les utilisateurs.

Comment un nouveau logo peut ralentir un site web

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

Les équipes Opérations sont entièrement responsables de la performance du site web de l’entreprise… Ou pas.

Prenons un cas interne à Setec. Comme nous l’avons mentionné, le Groupe a changé de logo. Choix graphique à propager sur tous les supports de communication et évidemment les sites web. Pour celui de Setec IS, nous avons laissé la place à l’expérimentation en ne présentant plus le logo en tant qu’image bitmap mais en tant que dessin vectoriel. L’intérêt est que sur les écrans Retina, ou lorsqu’on zoom, le dessin reste parfait.

Pour être encore plus précis sur la réalisation, le bout de SVG est incorporé directement dans la page et non une ressource liée.

140331_latence-nouveau-logo

Le changement a été rendu effectif un dimanche en fin d’après-midi. Les temps de réponse lorsque le serveur est peu chargé qui tournaient aux environs de 55ms se situent maintenant aux alentours de 70ms.

Si votre site web change beaucoup, il est bon de garder un œil sur la performance délivrée au final de tous ces choix graphiques.

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.

140404-DoS

Comme souvent cela démarre un lundi matin. Les performances de bases sont déjà moyennes (temps de réponse supérieur à 0,5s car le service est hébergé aux US, et utilise https ce qui ralentit la latence à première connexion) mais les accès deviennent franchement lents ( >1s ) et surtout un certain nombre de requêtes ne trouvent pas de réponse. Rapidement le blog du fournisseur fait état d’une attaque par déni de service, attaque avec demande de rançon. Pour ne pas céder à ce chantage, il décide publiquement de ne pas céder (au prix d’une souffrance des utilisateurs pendant quelques jours).

Le bras de fer durera une semaine avant que la situation redeviendra complètement normale.

Intérêt de la surveillance continue : obliger chaque acteur à la transparence, à savoir rapidement si vous êtes les seuls touchés.

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.