Au début, les routeurs étaient des ordinateurs ordinaires avec des cartes d'interface réseau (NIC) attachées au bus.
Figure 1 - Cartes d'interface réseau connectées au bus.
Jusqu'à un certain point, un tel système fonctionnait. Dans cette architecture, les paquets entraient dans la carte réseau et étaient transférés de la carte réseau vers la mémoire par le processeur. La CPU a pris la décision de transfert et a sorti le paquet vers la carte réseau externe. Le processeur et la mémoire sont des ressources centralisées avec une prise en charge limitée des périphériques. Le bus était également une limitation supplémentaire: la bande passante du bus devait prendre en charge la bande passante de toutes les cartes réseau en même temps.
S'il est nécessaire d'étendre le réseau, les problèmes commencent à survenir très rapidement. Vous pouvez acheter un processeur plus rapide, mais comment augmenter la puissance du bus? Si vous doublez la vitesse du bus, vous devez doubler la vitesse de l'interface du bus sur chaque NIC et CPU. Cela augmente le coût de toutes les cartes, même si la capacité d'une seule carte réseau n'augmente pas.
Leçon 1: le coût d'un routeur devrait augmenter de manière linéaire avec ses capacités
Malgré la leçon apprise, une solution pratique pour la mise à l'échelle était d'ajouter un autre bus et un processeur:
Figure 2 - La solution au problème de mise à l'échelle du système consistait à ajouter un nouveau bus et un nouveau processeur.
L'unité logique arithmétique (ALU) était une puce de traitement du signal numérique (DSP) choisie pour son rapport qualité-prix supérieur. Le bus supplémentaire a augmenté la bande passante, mais l'architecture n'a pas grandi de toute façon. En d'autres termes, plus d'ALU et de bus n'auraient pas pu être ajoutés pour augmenter la productivité.
Étant donné que les ALU constituaient toujours une limitation importante, l'étape suivante consistait à ajouter un FPGA (Field Programmable Gate Array) à l'architecture pour réduire la charge de recherche LPM (Longest Prefix Match).
Figure 3 - L'étape suivante consistait à ajouter le réseau de portes programmables sur site.
Bien que cela ait aidé, cela n'a pas complètement résolu le problème. ALU était toujours débordé. Les LPM constituaient la majeure partie de la charge, mais l'architecture centralisée ne s'adaptait toujours pas bien, même si nous nous débarrassions d'une partie du problème.
Leçon deux: LPM peut être implémenté en silicium et ne constitue pas un obstacle à la performance
Malgré cette leçon, l'étape suivante a été franchie dans une direction différente: le remplacement de l'ALU et du FPGA par un processeur standard. Les concepteurs ont essayé de passer à l'échelle en ajoutant plus de processeurs et plus de bus. Il a fallu beaucoup d'efforts, même pour une petite augmentation de la puissance, et le système souffrait toujours des limitations de bande passante du bus centralisé.
À ce stade de l'évolution d'Internet, des forces plus sérieuses sont entrées en jeu. À mesure que le Web est devenu populaire auprès du grand public, le potentiel d'Internet a commencé à devenir plus évident. Les opérateurs télécoms ont acquis des réseaux NSFnet régionaux et ont commencé à construire des complexes commerciaux. Les circuits intégrés spécifiques aux applications (ASIC) sont devenus des technologies éprouvées, permettant d'implémenter plus de fonctionnalités directement dans le silicium. La demande de routeurs a grimpé en flèche et le besoin d'améliorations significatives de l'évolutivité a finalement vaincu le conservatisme technique. Pour répondre à cette demande, de nombreuses startups ont vu le jour avec un large éventail de solutions possibles.
La barre transversale programmée est devenue l'une des alternatives:
Figure 4 - Barre transversale programmée.
Dans cette architecture, chaque NIC avait une entrée et une sortie. Le processeur NIC a pris la décision de transfert, sélectionné le NIC de sortie et envoyé une demande de planification au commutateur (crossbar). Le planificateur a reçu toutes les demandes des cartes réseau, a élaboré la solution optimale, programmé la solution dans le commutateur et dirigé les entrées pour la transmission.
Le problème avec ce schéma était que chaque sortie pouvait «écouter» une entrée à la fois, et le trafic Internet pulsait. Si deux paquets devaient atteindre la même sortie, l'un d'eux devait attendre. L'attente d'un paquet a provoqué l'attente d'autres paquets sur la même entrée, après quoi le système a commencé à souffrir du blocage de tête de ligne (HOLB), entraînant de très mauvaises performances du routeur.
Leçon trois: la structure interne du routeur ne doit pas bloquer les signaux même dans des conditions de charge
La migration vers des puces spécialisées a également motivé les concepteurs à migrer vers des structures internes à base de cellules, car la commutation de petites cellules de taille fixe est beaucoup plus facile que de traiter des paquets de longueur variable, parfois volumineux. Cependant, l'utilisation des cellules de commutation signifiait également que l'ordonnanceur devait fonctionner à une fréquence plus élevée, ce qui rendrait l'ordonnancement beaucoup plus difficile.
Une autre approche innovante consistait à transformer la carte réseau en un tore:
Figure 5 - NIC en forme de tore.
Dans un tel schéma, chaque carte réseau avait des connexions à quatre voisins, et la carte réseau d'entrée devait calculer un chemin à travers la structure pour atteindre la carte de ligne de sortie. Ce système avait des problèmes - la bande passante n'était pas la même. La largeur de transmission dans la direction nord-sud était plus élevée que dans la direction est-ouest. Si le modèle de trafic entrant devait se déplacer d'est en ouest, il y aurait de la congestion.
Leçon quatre: la structure interne du routeur doit avoir une répartition uniforme de la bande passante, car nous ne pouvons pas prédire la répartition du trafic.
Une approche complètement différente consistait à créer un réseau de communication NIC-NIC complet et à répartir les cellules sur toutes les cartes réseau:
Figure 6 - Structure entièrement connectée avec distribution des cellules à tous les NIC.
Malgré l'apprentissage des leçons précédentes, de nouveaux problèmes ont été identifiés. Dans cette architecture, tout fonctionnait assez bien jusqu'à ce qu'il fût nécessaire de retirer la carte pour la réparation. Étant donné que chaque carte réseau contenait des cellules pour tous les paquets du système, lorsque la carte a été retirée, aucun des paquets n'a pu être recréé, ce qui a entraîné des temps d'arrêt courts mais douloureux.
Leçon cinq: les routeurs ne devraient pas avoir un point de défaillance unique
Nous avons même pris cette architecture et l'avons renversée:
Figure 7 - Ici, tous les paquets vont à la mémoire centrale, puis au NIC de sortie.
Ce système fonctionnait plutôt bien, mais la mise à l'échelle de la mémoire est devenue un problème. Vous pouvez simplement ajouter quelques contrôleurs et banques de mémoire, mais à un moment donné, la bande passante globale devient trop complexe pour la conception physique. Face à des contraintes physiques pratiques, nous avons été obligés de penser dans d'autres directions.
Le réseau téléphonique est devenu une source d'inspiration pour nous. Il y a longtemps, Charles Close a réalisé que des commutateurs évolutifs pouvaient être créés en construisant des réseaux de commutateurs plus petits. Il s'est avéré que toutes les merveilleuses propriétés dont nous avons besoin sont présentes dans le réseau du Clos:
Figure 8 - Réseau Clos.
Fermer les propriétés du réseau:
- La puissance augmente avec l'échelle.
- N'a pas de point de défaillance unique.
- Maintient une redondance suffisante pour la tolérance aux pannes.
- Résout les surcharges en répartissant la charge dans toute la structure.
Nous implémentons toujours les entrées et les sorties ensemble, donc nous plions généralement cette image le long de la ligne pointillée. Il en résulte un réseau Clos replié, et c'est ce que nous utilisons aujourd'hui dans les routeurs multi-cas: certains cas ont une carte réseau et une couche de commutateurs, dans d'autres - des couches supplémentaires de commutateurs.
Figure 9 - Réseau Clos réduit.
Malheureusement, même cette architecture a ses propres problèmes. Le format des cellules utilisées entre les commutateurs est propriétaire et appartient au fabricant de puces, ce qui conduit à une dépendance vis-à-vis des chipsets. La dépendance à un fournisseur de puces n'est pas beaucoup mieux que la dépendance à un fournisseur de routeur unique, les problèmes sont les mêmes: lier les prix et la disponibilité des appareils à une seule source. Les mises à niveau matérielles sont difficiles car le nouveau commutateur de cellule doit simultanément prendre en charge les connexions et les formats de cellule existants pour maintenir l'interopérabilité, ainsi que tous les débits de liaison et tous les formats de cellule des nouveaux équipements.
Chaque cellule doit être adressée pour indiquer la carte réseau de sortie vers laquelle elle doit transmettre des informations. Un tel adressage est fini, ce qui crée une limite d'évolutivité. Le contrôle et la gestion dans les routeurs multi-cas sont encore totalement propriétaires, ce qui pose un autre problème de fournisseur unique dans la pile logicielle.
Heureusement, nous pouvons résoudre ces problèmes en modifiant notre philosophie d'architecture. Au cours des cinquante dernières années, nous nous sommes efforcés de faire évoluer les routeurs. Nous avons appris de l'expérience de la construction de grands nuages que la philosophie de mise à l'échelle est souvent plus efficace.
L'architecture évolutive utilise une stratégie de division pour conquérir plutôt que de créer un serveur unique énorme et extrêmement rapide. Un rack de petits serveurs peut faire le même travail tout en étant plus fiable, flexible et rentable.
Cette approche est également applicable aux routeurs. Est-il possible de prendre plusieurs petits routeurs et de les aligner dans une topologie Clos pour obtenir des avantages architecturaux similaires tout en évitant les problèmes liés au maillage? En fait, ce n'est pas particulièrement difficile:
Figure 10 - Remplacement des commutateurs de cellule par des commutateurs de paquets, en préservant la topologie Clos pour une mise à l'échelle plus facile.
En remplaçant les commutateurs de cellules par des commutateurs de paquets et en conservant la topologie Clos, nous offrons une facilité d'évolutivité.
La mise à l'échelle est possible en deux dimensions: soit l'ajout de nouveaux routeurs d'entrée et de commutateurs de paquets en parallèle avec les couches existantes, soit l'ajout de couches de commutateurs supplémentaires. Étant donné que les routeurs individuels sont aujourd'hui assez standardisés, nous évitons de dépendre d'un seul fournisseur. Toutes les liaisons utilisent Ethernet standard, il n'y a donc pas de problèmes de compatibilité.
Les mises à niveau sont simples et directes: si le commutateur a besoin de plus de canaux, vous pouvez simplement le remplacer par un commutateur plus grand. Si vous avez besoin de mettre à niveau un canal séparé et que les deux extrémités du canal ont cette capacité, il vous suffit de mettre à niveau l'optique. Des taux de transmission différents de liaisons différentes au sein d'une structure ne sont pas un problème car chaque routeur agit comme un mappeur de débit.
Cette architecture est déjà populaire dans le monde des centres de données et, selon le nombre de couches de commutation, est appelée architecture leaf-spine ou super-spine. Il s'est avéré hautement fiable, stable et flexible.
Du point de vue du plan de transmission, il est clair qu'il s'agit d'une alternative viable à l'architecture. Des problèmes subsistent avec le plan de contrôle et le plan de contrôle. La mise à l'échelle du plan de contrôle nécessite une amélioration de l'ordre de grandeur de l'échelle de nos protocoles de contrôle. Nous essayons de l'implémenter en améliorant les mécanismes d'abstraction en créant une représentation proxy de l'architecture qui décrit toute la topologie comme un nœud unique.
De même, nous travaillons à développer des abstractions de plan de contrôle qui nous permettront de contrôler toute la structure Clos comme un seul routeur. Ce travail est effectué en tant que norme ouverte, de sorte qu'aucune des technologies impliquées n'est propriétaire.
En cinquante ans, les architectures de routeurs ont évolué à pas de géant, et de nombreuses erreurs ont été commises dans le processus de recherche de compromis entre différentes technologies. Évidemment, notre évolution n'est pas encore terminée. À chaque itération, nous avons abordé les problèmes de la génération précédente et découvert de nouveaux défis.
Espérons qu'en étudiant attentivement notre expérience passée et actuelle, nous pourrons progresser vers une architecture plus flexible et plus fiable et créer des améliorations futures sans remplacer complètement le matériel.