Le problème de cet ordonnanceur est qu'il est nécessaire de gérer les files d'attente
et que cela peut aboutir à des dépassements de capacités et donc à des pertes.
De plus, les paquets favorisés le sont de manières excessives, rien ne peut être envoyé dans une classe
tant qu'une classe de priorité plus haute a des paquets à émettre.
Limitation en entrée
Grâce à Ingress, on peut limitercertains
trafics entrant
en bande
passante.
Il faut tout d’abord attacher une "Queuing displine" au périphérique que l’on souhaite controler.
| tc qdisc add dev ppp0 handle ffff : ingress |
Il est alors possible de spécifier qu’elle doit être l’attitude à adopter face à certains flux.
Ici, on limite à 200kbit le flux marqué 5 par netfilter sur l’interface ppp0.
tc filter add dev ppp0 parent ffff : \
protocol ip handle 5 fw \
police rate 200kbit burst 10k drop \
flowid :1 |
La variable burst permet de réaliser un flux de type tocken bucket. Un seau de 10ko est
créé avec un taux de remplissage de 200kbit/s.
Les paquets doivent être marqués dans la chaine PREROUTING puisque le rejet des paquets est fait
au plus près de l’interface.
Manuel DERA a écrit une nouvelle implémentation de CBQ.
Le fonctionnement est globalement similaire à celui de CBQ (voir le manuel).
La différence notable est que cette implémentation utilise la notion de
Token Bucket.
On affecte une discipline htb au périphérique eth0.
| tcqdiscadddev eth0 root handle 1 : htb default 12 |
Les paquets non affectés dansles flux sont mis dans la classe
1:12
grâce au mot clé default.
Mais, il faut aussi déclarer une classe racine sinon il n’est
pas possible d’emprunter de la bande passante. Ici, on veut englober
toute la bande passante afin de filtrer l’ensemble du trafic.
tc class add dev eth0 parent 1 : classid 1:1 htb \
rate 10mbit ceil 10mbit burst 20k |
On définit ensuite des classes :
1:1 : Classe pour TCP, limité à 2mbit/s.
1:2 : Classe pour UDP, limité à 6mbit/s.
1:12 : Classe pour les autres, limité à 1mbit/s.
Ce qui donne :
tc class add dev eth0 parent 1 : classid 1:1 htb \
rate 1mbit ceil 10mbit burst 20k
tc class add dev eth0 parent 1 : classid 1:2 htb \
rate 8mbit ceil 10mbit burst 20k
tc class add dev eth0 parent 1 : classid 1:12 htb \
rate 1mbit ceil 1mbit burst 20k |
Ensuite, on n’affecte les flux marqués 1 et 2 à leur file respective :
tcfilter add dev eth0 protocol ip handle 1 fw flowid 1:1
tc filter add dev eth0 protocol ip handle 2 fw flowid 1:2 |
Les mots clés ont les significations suivantes :
rate : Débit à l’équilibre
ceil : Débit maximal autorisé pour la classe
burst : Taille du seau, elle est égale à la quantité maximale de données pouvant
être envoyée d’une classe avant de servir une autre classe.
Prise en charge des trafics par bouffée
Le but de la manoeuvre est de limiter le trafic utilisé par un flux donné.
Dans cet exemple, on va autoriser le flux smtp à prendre une grande partie de la
bande passante, mais ceux que pendant un bref moment.
Le flux permanent smtp est limité à 500kbit/s pour une bande passante de 10mbit/s.
On désire de plus que la bande passante maximale utilisée soit 1mbit/s.
Tout d’abord, définissons une discipline HTB sur eth0 après avoir remis à zéro
le périphérique :
tc qdisc del dev eth0 root
tc qdisc add dev eth0 root handle 1 : htb default 2 |
Ensuite, on définit, outre la classe racine englobant la bande passante totale, deux sous-classes.
La première est destinée à recevoir le flux soumis au tocken bucket.
La seconde est mise en place pour recevoir le trafic restant (la classe
1:2
est la classe par défaut
comme on l’a défini auparavant).
tc class add dev eth0 parent 1 : classid 1:1 htb \
rate 10mbit ceil 10mbit burst 20k
tc class add dev eth0 parent 1:1 classid 1:2 htb \
rate 1mbit ceil 1mbit burst 20k
tc class add dev eth0 parent 1:1 classid 1:3 htb \
rate 8mbit ceil 10mbit burst 20k |
La classe
10:2
se voit ensuite affectée une discipline TBF :
tc qdisc add dev eth0 parent 1:2 handle 2:
tbf rate 0.5mbit burst 20kb latency 70ms
peakrate 1mbit minburst 1540
rate : Taux de remplissage du seau
peakrate : Bande passante utilisée maximale
burst : Taille du seau en bytes.
latency : Temps de conservation des paquets dans la discipline.
minburst : Doit être égal au MTU.
Ensuite, on se contente de mettre les paquets dans leur files respectives :
tc filter add dev eth0 protocol ip handle 2 fw flowid 1:3
tc filter add dev eth0 protocol ip handle 1 fw flowid 1:2
C’est une discipline sans classes qui se met sur une feuille
de l’arbre des flux :
tc qdisc add dev eth0 parent 10:2 handle 2 : \
red limit 10kb min 2kb max 4kb avpkt 1000 \
burst 20 ecn probability 0.02
Lorsque la taille de la queue est en dessous de min, les paquets sont acceptés ; entre min et
max, la probabilité de rejet d’un paquet croit.
Au dessus de max la probabilité de rejet est maximale, égale à
probability. Lorsque la taille de la queue est supérieure à limit,
tous les paquets sont rejetés.
Si le flag exn est positionné, les machines, signalant dans
leurs paquets qu’elles sont respectueuses du protocole ECN, sont prévenues par
un paquet ICMP et non par un rejet de leurs paquets.
CBQ a parfois du mal à approximer la bande passante.
C’est particulièrement le cas pour les faibles bande passante
et pour les périphériques de type PPP.
HTB semble être à l’abri de ce genre de comportement.
Le paramètre burst exprime une quantité de tokens disponibles.
Cette notion est utilisée par TBF et HTB qui en
retirent un effet de bord assez original.
En effet, le remplissage du seau au débit rate est fait à intervalles réguliers,
toutes les secondes.
Par conséquent, le débit est limité à burst/s ; il y a donc une limitation
implicite qui oblige à augmenter la taille du burst lorsque la bande passante
maximale désirée, fixée par rate, est plus importante que burst/s.
L’outil bench permet de tester la répartition
des flux en période de congestion.
La syntaxe et la mise en oeuvre de la qualité de service sous Linux sont complexes.
La définition d’une stratégie cohérente est nécessaire avant toute chose.
Il faut donc déterminer précisément les besoins et arriver à la structure
la plus simple possible.
Les deux versions de CBQ ont chacune leur avantage. La simplicité
et la précision de HTB sont très souvent un gros avantage.
On ne trouve malheureusement pas les combinaisons possibles grâce
à l’utilisation des mots bounded et isolated.
Cependant, l’utilisation du mot bounded est à proscrire dans
la plupart des cas.
Pour la mise en oeuvre, HTB représente donc le meilleur
compromis, et ce, malgré le patch nécessaire du noyau et de tc.
Répondre à cet article
Introduction à la qualité de service sous Linux