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.

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.

Analyse de performances de l’IT grâce au réseau

satelite observationEn ce début d’année 11111011110, il est bon de se souvenir que le transport de données sur les réseaux et l’encodage de toutes les informations que nous utilisons dans notre monde numérique se basent sur une simple suite de 0 et de 1. Finalement au niveau du transport des données on peut voir passer beaucoup de choses, l’affaire récente de la NSA nous l’a rappelé.

Lire la suite

Débarrassez-vous de vos derniers postes XP

no more windows xpLes résultats d’un projet visant à faciliter le travail  en équipe multi-sites confirment que l’utilisation depuis un poste Windows Seven d’un serveur de fichier Win2008 R2 ou plus est tout à fait acceptable même si ce serveur est hébergé à plusieurs milliers de kilomètres. Avec de telles performances,  pourquoi ne pas supprimer tous les serveurs de fichiers locaux pour centraliser les données sur les datacenters centraux ?

Lire la suite