inetdoc.net

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 ...