Bufferbloat: Kossé ca??
Quand on utilise les valeurs par défaut des produits, on se bute quelques fois à des limitations. Dans un gros environnement ou je travaille, nous sommes au prise avec du « bufferbloat » ou plus précisément, des problèmes de latences sporadiques dues aux mauvaises valeurs par défaut.
Stockage
Si on regarde du coté du stockage, dans le cas qui nous intérrèsse, du NetAPP, on voit une latence très stable. Pas de gros pics ou de saturation.
Du coté des IO, la même remarque peut être faite et si on superposait la latence et les IOPS, les résultats suivraient les mêmes directions.
VMWARE
Par contre, lorsqu’on investigue sur une VM ou un host VMware, on voit des gros pics de performance, des lenteurs soudaines et soutenues, bref, rien n’est stable.
Que se passe-t-il donc alors?
Le bufferbloat est un probleme qui arrive lorsqu’on à assigné trop de cache à un endroit ou un autre d’un réseau switché. Ca pourrait etre du réseau SAN, du IP, du 3G, etc.
Voici une explication sommaire du problème : Nous prenons un cas ou il y’a un serveur ESX, un HBA 8Go, un Service Processor de stockage et un LUN.
Les valeurs qui nous interressent sont celles du queue length ou d’autres fois le « Execution Throttle ».
Dans notre exemple les valeurs sont les suivantes :
ESX : 64
HBA : 65535
SP : 64
LUN : 64
Tout ira bien dans un environnement normal mais dès qu’on tombe dans du gros load, les problemes arriveront.
Le HBA va remplir tranquillement sa cache avec 65535 commandes. Une fois que ca va arriver, le ESX, lui, va continuer a envoyer des demandes parce qu’il est 65471 commandes en retard.. Pour lui, il y a un bon moment que les 65471 autres commandes ont été lancées… Alors, là, il sera ralenti, la la tence de toutes la chaine va se déteriorer… ON est en probleme…
Le bufferbloat a un pattern distinctif, le voici :
Source : http://blog.malayter.com/2012/02/bufferbloat-on-3g-network.html
On fait quoi alors?
N’utilisons plus les valeurs par défaut.
Dans VMWare, il faut valider qu’on est bien a 64.
Dans les HBA des serveurs ESX, il faut aller forcer le Execution Throttle à 64 commandes…
Tout redémarrer et le problème devrait disparaitre. Au moins, s’il y’a de la latence ensuite, ca sera dans le moment présent. 🙂