Qualité de Service sur Linux

Qualité de Service sur Linux
Malik GUILLAUD
Nicolas COUTANT
Plan
2

Problématique

La théorie

L’état de l’art

Notre Solution

Conclusion
Problématique
CONTEXTE
INTERNET
Passerelle Linux
Sous-réseau 1
Sous-réseau 2
4
Vue générale

Monopolisation de la bande passante
–
–

Flux multimédia
–
–

–
–
ssh, telnet, …
http, https, …
Garder une bonne réactivité dans tous les cas
Applications spécifiques
–
5
VoIP, vidéoconférence, radio, vocal
Débit assuré et faible latence
Protocoles interactifs légers
–

Exemple: upload/download ftp
Handicape fortement tout autre flux
Favoriser / handicaper
Vue réseau

Flux parasites
–
p2p


–

Spywares, mises à jour intempestives,…
Partage de la bande passante
–
–
6
Gourmand en ressources (nombre de connexions)
Gourmand en bande passante
Équitablement (connexion partagée en résidence)
Selon une stratégie définie
Qualité de Service – La Théorie
La Théorie

Définition

Les principaux ordonnanceurs

8
Les architectures d’ordonnancement
Définition

Qualité de service :
L'ensemble des technologies permettant
d'assurer la qualité du service réseau, de contrôler la
bande passante ou encore d'assigner des priorités
aux flux réseau.
La qualité de service désigne avant tout un
transfert à débit garanti entre l'émetteur et le
récepteur des données, et ce avec des temps
d'attente (de latence) réduits au minimum.
9
Définition

Deux approches :
–
IntServ (Integrated Services) :
 Réservation
de bout en bout de la bande
passante nécessaire
–
DiffServ (Differenciated Services) :
 Séparation
des flux en classes grâce à une
analyse de la trame.
10
Les Ordonnanceurs
11
Les Architectures d’ordonnancement (1/2)

Class Based Queuing
–
–
12
Les différents flux sont divisés en classes avec
des priorités différentes.
Les autres flux sont envoyés en Best-Effort.
Les Architectures d’ordonnancement (2/2)

Heriarchical Token Bucket
–
13
Même principe que pour CBQ (hiérarchisation
des flux) mais avec un sceau à jeton comme
ordonnanceur.
La Qualité de Service sous Linux
14

Les possibilités du noyau Linux 2.6

La commande TC

Les Scripts et Applications existantes
Les possibilités du noyau Linux 2.6

Marquage par Netfilter/Iptables :
–
15
Grâce à la table MANGLE, qui permet de
marquer n’importe quel paquet grâce à Netfilter.
La Commande TC
16

tc qdisc [ add | change | replace | link ] dev DEV
[ parent qdisc-id | root ] [ handle qdisc-id ]
qdisc [ qdisc specific parameters ]

tc class [ add | change | replace ] dev DEV
parent qdisc-id [ classid class-id ]
qdisc [ qdisc specific parameters ]

tc filter [ add | change | replace ] dev DEV [ parent qdisc-id | root ]
protocol protocol prio priority filtertype
[ filtertype specific parameters ] flowid flow-id

tc [-s | -d ] qdisc show [ dev DEV ]
tc [-s | -d ] class show dev DEV
tc filter show dev DEV
Les Classifieurs

3 classifieurs :
–
U32

–
Fw

–
Suivant le marquage avec Iptables/NetFilter
Route

17
Trouver un champ dans une trame IP
Suivant le numéro de route dans la table de routage
Les Scripts et Applications existants

Les Script de QoS
–
–

Les Applications
–
–
18
HTBInit et CBQInit
WonderShaper
TCNG
RCC
Les Script de QoS

CBQ.init et HTB.init
–
–

Avantage : Puissant, Beaucoup de possibilités
Inconvénient : Complexité de configuration
WonderShaper
–
Avantage : Simplicité de configuration,
« prioritisation » de flux internet (http,ftp,…)
–
19
Inconvénients : Fonctionnalités limitées
Traffic Control Next Generation (1/2)
20

Génère, à partir d’un pseudo langage du
genre C ou Perl et grâce à un compilateur
(TCC), plusieurs formes de commandes TC.

Offre aussi la possibilité de simuler différents
trafics (TCSIM).
Traffic Control Next Generation (2/2)
21
RCC




22
Très récent (Janvier 2005)
Application Client/Serveur écrite en C
Configuration Graphique
Centralisation des règles de filtrage
Notre Solution
CONTRAINTES

Écrire un script bash
–
–
–
24
Couvrant un maximum de besoins
Simple à configurer (pour un utilisateur de base)
Utilisant les mises à jours du Kernel 2.6
PRINCIPE DE NOTRE SOLUTION (1/2)

Réseau découpé en groupes de machines
INTERNET
GROUPE 1
Passerelle Linux
Sous-réseau 1
GROUPE 2
GROUPE 3
Sous-réseau 2
GROUPE 4
25
PRINCIPE DE NOTRE SOLUTION (2/2)
GROUPE 1
Classe mère 1
BANDE PASSANTE:
100 Kbit
Sous-réseau 1
Classe fille PRIO 1
26
Classe fille PRIO 2
Bande passante:
30%
Bande passante:
20%
Paquets:
dest:tcp/80
dest:tcp/110
Paquets:
dest:udp/554
Classe fille PRIO 3
Classe fille PRIO 4
Bande passante:
25%
Bande passante:
20%
Paquets:
default
Paquets:
icmp
Classe fille PRIO 5
Bande passante:
5%
Paquets:
dest:tcp/4661
dest:tcp/4662
src:tcp/4662
CONFIGURATION


27
Interface & débit montant maximum
Configuration de base
– Les classes filles sont configurées par défaut
 Prio1: applications spécifiques à forte priorité
 Prio2: ssh, telnet
 Prio3: http,https,divers
 Prio4: ftp
 Prio5: applications spécifiques à faible priorité
– Bande passante repartie équitablement
CONFIGURATION

Configuration avancée
–
Pour chaque classe fille sont configurables:


28
Le pourcentage de bande passante
Les différents trafics (protocole,port,…)
CHOIX D’IMPLEMENTATION

Architecture HTB
–
–
–


Files d’attente SFQ
Classifieur « fw »
–
29
Permet ce découpage en classe
Implémentation plus puissante que CBQ
Exploite les mises à jour du kernel 2.6
Conjointement avec des règles de filtrage Iptables
Conclusion
Conclusion

Bilan
–
–

Ce que le projet nous a apporté:
–
–
31
Configuration légère et évolutive
Répond à la plupart des problèmes de QoS
QoS domaine complexe
Compréhension des problèmes liés aux flux
réseaux
MERCI