La nouvelle édition du support de travaux pratiques sur la configuration des
fonctions réseau et la compilation du noyau Linux est en ligne. Toute relecture
critique est la bienvenue !
Outre le fait de démystifier la compilation du noyau Linux auprès des
étudiants, le but de ce support est de mettre en relation les fonctions réseau
au sens large (routage, commutation, protocoles) et l'architecture du système
d'exploitation associé à une plateforme matérielle. Avec l'évolution des
architectures des équipements réseau, il est de plus en plus difficile
d'identifier les fonctions qui sont traitées au niveau logiciel ou au niveau
matériel. Je tente ici un rapprochement entre l'architecture d'un routeur et
d'un serveur.
Dans un routeur, la couche Control Plane correspond à des fonctions
purement logicielles telles que les démons de protocoles de routage par
exemple. Une fois la décision logicielle d'acheminement d'un paquet vers une
nouvelle destination prise, cette décision est mémorisée pour être exploitée de
façon optimale par le matériel de la couche Data Plane.
C'est au niveau de cette couche Data Plane que les capacités de
traitement des composants matériels sont prépondérantes dans le choix d'un
équipement. Les composants doivent permettre le transit d'un maximum de flux
réseau en parallèle. On parle ici de commutation de paquets et les composants
spécialisés sont là pour «garantir» la bande passante par port comme le font
les composants d'un commutateur de trames Ethernet au niveau liaison de
données.
Lorsqu'il est question d'architecture, nous sommes bien souvent noyés dans
le jargon. Forwarding
Plane, Data Plane, et autres Crossbar Fabrics sont autant
de noms différents pour un même principe général. Les seuls acronymes qui sont
devenus à peu près standard et transversaux entre différents systèmes sont
RIB pour Routing Information Base (au niveau Control
Plane) et FIB pour Forwarding Information Base (au niveau
Data Plane).
Challenge à 2€cts : retrouver l'algorithme proposé pour le traitement des
entrées de la Forwarding Information Base dans la rubrique routage
avancé des options du noyau Linux.
Maintenant, si l'on se réfère à l'architecture d'un PC datant d'une dizaine
d'année, les performances ne pouvaient pas être comparables à celles de
l'architecture décrite ci-dessus. En effet, chaque paquet devait transiter deux
fois sur un bus partagé unique entre l'interface réseau et le processeur ; une
fois à la réception et une fois à l'émission. Les évolutions dans
l'architecture des serveurs ont conduit à une augmentation du nombre des cœurs
et du nombre des bus. Tant et si bien qu'il est devenu légitime de se poser la
question du choix entre les deux architectures lorsque le nombre d'interfaces
est limité à 4 ou 8 ports.
Dans l'image ci-dessus, j'ai essayé de transposer l'architecture d'un
routeur sur le modèle Nehalem utilisé dans de
nombreux serveurs rackés. C'est une simplification dont le but est de montrer
que le traitement de multiples flux réseau en parallèle est possible sur des
chemins dédiés à cet usage. Il existe de nombreuses autres
représentations possibles.
Puisque les deux familles d'architectures tendent à se «neutraliser», la
différence devrait se faire sur les services proposés en plus des deux niveaux
Control Plane et Data Plane. C'est ici qu'intervient le thème à
la mode qui assure un bon clivage : la virtualisation. Dans un routeur, la
virtualisation est généralement directement intégrée dans le système. La
solution Virtual
Routing and Forwarding en est un exemple chez Cisco. À l'opposé, une
société comme Vyatta a bâti son
portefeuille de solutions sur les fonctions de virtualisation présentes dans le
noyau Linux ; le tout étant intégré dans des serveurs rackés.
On peut imaginer que lors des évolutions à venir les différences de
conception sur la virtualisation vont s'estomper (une fois que KVM aura
été adopté par tous les acteurs) et qu'un nouveau sujet clivant émergera. Il
est donc essentiel de chercher à assimiler les mécanismes de fonctionnement du
noyau Linux pour préparer cet avenir radieux ... où pas.
Lire la suite ...
