Dans le
premier article, je voulais montrer que le développement FPGA est une tâche intéressante, et la mise en œuvre d'un encapsulateur de flux est un projet assez simple qui pourrait très bien servir de projet académique pour des étudiants seniors ou des étudiants diplômés.
Même si la conception matérielle ne vaut que pour le plaisir, dans cet article, je veux prêter attention à la valeur pratique de cette leçon. En particulier, notre conversation portera sur la façon de créer une infrastructure réseau pour les opérateurs de télécommunications en utilisant l'encapsuleur Etherblade.net implémenté sur FPGA.
Ce texte est un aperçu des technologies de réseau et afin d'intégrer un sujet aussi vaste dans le cadre d'un article, j'ai décidé de l'écrire dans le contexte d'un plan d'action ou, si vous le souhaitez, la réponse à la question suivante - «Comment remplacer l'équipement utilisant FPGA et open source aussi efficacement que possible de Cisco et Juniper. "
Commençons donc.
Le concept de SDN (mise en réseau définie par logiciel) contre les grands fournisseurs
Traditionnellement, depuis des décennies, les équipements réseau sont fabriqués par des géants tels que Cisco et Juniper. Aujourd'hui, les grands opérateurs de réseau développant leur propre équipement de réseau deviennent la nouvelle norme. L'objectif qu'ils souhaitent atteindre est l'indépendance vis-à-vis des fournisseurs de composants et un meilleur contrôle de l'infrastructure.
En Russie, pour des raisons politiques, cette approche associée au remplacement de produits tiers par des systèmes avec un pourcentage plus élevé de composants intellectuels développés localement (blocs de propriété intellectuelle ou noyaux IP) est généralement appelée substitution à l'importation.
Il faut comprendre que les grandes entreprises disposent d'une énorme quantité de ressources d'ingénierie et s'appuient sur un modèle de développement intégré verticalement. Et qu'en est-il des fabricants relativement petits?
Le manque de ressources peut être compensé par l'open source. Et le manque d'intégration verticale avec une répartition correcte des sous-tâches entre les petits acteurs.
L'architecture des périphériques réseau traditionnellement produite par les grands fournisseurs est facilement segmentée. Afin de paralléliser le processus et de mettre en évidence des sous-tâches individuelles, le concept de SDN (mise en réseau définie par logiciel) suggère de segmenter l'architecture des périphériques réseau en niveaux, en particulier, en séparant le niveau de gestion du réseau (plan de contrôle) du niveau des périphériques de transfert de données (plan de données).
Je note qu'aujourd'hui le SDN est devenu un puissant outil de marketing pour les grands fournisseurs qui le présentent comme un ensemble de «nouvelles fonctionnalités» utiles à l'utilisateur final. Ce qui est drôle, c'est que, historiquement, comme je l'ai déjà noté, le concept de SDN a été créé juste en contraste avec les géants de l'industrie.
SDN propose donc un modèle d'architecture d'un routeur réseau sous une forme démontée. Notre tâche est d'identifier la composante qui nous intéresse dans ce modèle et de commencer à le développer.
«Commençons petit» - encapsulation sur les routeurs et superposition SDN
Il est naturel de répondre à tous les besoins du monde en une seule fois. Ainsi, lors de la construction de grands systèmes, il est logique de commencer petit et de rendre le système extensible, afin que des fonctionnalités supplémentaires puissent être introduites en intégrant des blocs supplémentaires ou en modifiant ceux qui existent. Par les mots «commencer petit», je veux dire la sélection d'une fonction de réseau complète suffisante pour construire un système qui fonctionne.
Dans le projet Etherblade.net, en tant que telles fonctions, il a été décidé de mettre en place un mécanisme d'encapsulation du trafic réseau.
L'encapsulation dans les réseaux est une chose ordinaire. Décomposons le routeur et examinons comment ses composants correspondent aux composants du modèle SDN et déterminons la place que l'encapsulation prend dans les deux modèles.
Par exemple, prenez l'un des routeurs indiqués dans la figure au tout début de l'article et décrivez-le dans la figure ci-dessous - mais déjà sous une forme «préparée».
Dans la même figure, nous contrastons le routeur avec un «modèle SDN de superposition» alternatif qui offre des fonctionnalités similaires.
Le niveau supérieur (vert) est le plan de contrôle / orchestration SDN. Il s'agit du cerveau du système, en fait du microprocesseur sur lequel le logiciel réseau de contrôle est exécuté. Dans les routeurs traditionnels, ce composant est intégré. Dans SDN, cette fonctionnalité est généralement transférée vers un «contrôleur d'orchestration» externe - un ordinateur qui dessert de nombreux périphériques réseau.
Niveau moyen (bleu) - chemin de transfert. Le rôle principal de ce niveau est la fourniture de transport réseau (commutation / routage du trafic). Dans les routeurs traditionnels - cette fonctionnalité est implémentée comme une unité de commutation interne. Dans notre modèle «SDN-overlay», le rôle de ce composant de «commutation» peut être complètement réduit en connectant directement les périphériques périphériques (whitebox) au réseau de transport.
Inférieur (orange) - bord / niveau d'accès. Sur ces composants, toutes les manipulations du trafic réseau telles que l'encapsulation et les autres conversions de protocole se produisent. Ce niveau est caractérisé par une vitesse de traitement élevée et une fonctionnalité déterministe - un endroit idéal pour ASIC / FPGA. Dans les routeurs traditionnels, cette fonctionnalité est implémentée sur des modules linéaires (linecards), dans SDN ce sont les soi-disant «dispositifs de boîte blanche».
Ainsi, en résumant ce qui précède, nous pouvons dire que Etherblade.net est essentiellement un projet de développement de dispositifs «whitebox» pour «SDN-overlay».
«Forward to data centers !!!» - encapsulateur en fonction de NFV (virtualisation de la fonction réseau)
Après avoir compris à quoi ressemble le système que nous développons, il est logique de parler des options pour son incarnation physique.
Sur la gauche se trouve un encapsulateur Etherblade en tant que périphérique CPE séparé (version campus). À droite, l'encapsuleur Etherblade implémenté à l'intérieur du serveur (option pour les centres de données).Il est intéressant qu'en implémentant un encapsulateur sur une carte avec une interface PCIe et en «cachant» cette carte à l'intérieur du serveur, nous pouvons réellement créer l'illusion de virtualiser cette fonction réseau. Cette approche est appelée NFV - virtualisation des fonctions réseau.
Le concept de NFV implique de se débarrasser des périphériques réseau externes tels que les pare-feu, les équilibreurs de charge, etc. en raison de la virtualisation de leurs fonctions à l'intérieur des serveurs. L'implémentation de l'encapsuleur en tant que fonction NFV nous permet de nous débarrasser des routeurs physiques «périphériques».
Ainsi, NFV est à la mode et pratique. La difficulté est qu'en termes de conception matérielle, limiter PCIe n'est pas aussi simple que Ethernet. Si Ethernet est un protocole série, PCIe est un protocole transactionnel complexe avec de nombreux états finaux (essentiellement une pile réseau implémentée dans le matériel). N'oubliez pas que le système d'exploitation nécessite les pilotes appropriés pour fonctionner avec le périphérique PCIe.
L'une des solutions les plus élégantes au problème est l'utilisation de cartes FPGA, similaires à celle présentée au tout début de l'article. La figure suivante montre l'architecture de la carte et les deux options pour implémenter l'encapsuleur dessus.
Comme vous pouvez le voir, cette carte FPGA dispose de cartes réseau «externes», qui sont essentiellement des convertisseurs entre Ethernet et PCIe. Ainsi, la mise en œuvre de l'encapsuleur sur de tels appareils permet d'obtenir NFV «dès la sortie de l'emballage» - sans problèmes inutiles avec PCIe et les pilotes d'écriture.
Du «privé au général» - création d'un référentiel ouvert de cœurs IP de réseau
On ne peut pas être en désaccord avec le fait qu'aujourd'hui il existe de nombreux ASIC réseau spécialisés (par exemple, de Broadcom) qui peuvent traduire un tel projet dans une autre histoire de la série "Enjoying Working with FPGA". Le scepticisme est approprié dans ce cas, cependant, je tiens à vous rappeler que le projet Etherblade.net ne se limite pas à la création d'un périphérique réseau distinct. Le principal objectif d'Etherblade.net est de créer un référentiel ouvert de cœurs IP paramétrés et documentés.
Ce référentiel peut devenir une base efficace pour créer toute une gamme de périphériques réseau (y compris les plus exotiques), qui à leur tour peuvent être mis en œuvre à la fois sur FPGA et sous la forme d'ASIC.
Sur cela - je termine. Dans le prochain article, nous passerons directement à la conception matérielle, mais pour l'instant je vous invite à vous familiariser avec le projet plus près de
etherblade.net .