Présentation de l’architecture JDM

Le principe de base de l’architecture désagrégée de Junos OS est la décomposition (désagrégation) du logiciel Junos OS étroitement lié et du matériel propriétaire en composants virtualisés qui peuvent potentiellement fonctionner non seulement sur le matériel de Juniper Networks, mais également sur des boîtes blanches ou des serveurs bare metal. Dans cette nouvelle architecture, le Gestionnaire de périphériques de Juniper (JDM) est un conteneur racine virtualisé qui gère les composants logiciels.

Le JDM est le seul conteneur racine de l’architecture désagrégée de Junos OS (d’autres modèles du secteur autorisent plus d’un conteneur racine, mais l’architecture désagrégée de Junos OS n’en fait pas partie). Le système désagrégé Junos OS est un modèle à racine unique . L’une des principales fonctions de JDM est d’empêcher les modifications et les activités sur la plate-forme d’affecter le système d’exploitation hôte sous-jacent (généralement Linux). En tant qu’entité racine, le JDM est parfaitement adapté à cette tâche. L’autre fonction majeure de JDM est de faire en sorte que le matériel de l’équipement ressemble le plus possible à un système physique traditionnel basé sur Junos OS. Cela nécessite également une certaine forme de capacités racines.

La figure 1 illustre la place importante qu’occupe JDM dans l’architecture globale.

Une VNF est une offre consolidée qui contient tous les composants nécessaires à la prise en charge d’un environnement réseau entièrement virtualisé. Les VNF ont pour objectif l’optimisation du réseau.

JDM offre les avantages suivants :

• Gestion des fonctions réseau virtualisées (VNF) invitées pendant leur cycle de vie.

• Installation de modules tiers.

• Formation des chaînes de services VNF.

• Gestion des images VNF invitées (leurs fichiers binaires).

• Contrôle de l’inventaire du système et de l’utilisation des ressources.

Notez que certaines implémentations de l’architecture de base incluent un moteur de transfert de paquets ainsi que les ports matériels habituels de la plate-forme Linux. Cela permet une meilleure intégration du plan de données de Juniper Networks avec le matériel bare metal d’une plate-forme générique.

L’architecture désagrégée de Junos OS permet à JDM de gérer des fonctions réseau virtualisées telles qu’un pare-feu ou des fonctions de traduction d’adresses réseau (NAT). Les autres VNF et conteneurs intégrés à JDM peuvent être des produits Juniper Networks ou des produits tiers en tant qu’applications Linux natives. L’architecture de base de Junos OS désagrégé est schématiquement illustrée à la Figure 2.

Remarque :

Il existe plusieurs façons d’implémenter l’architecture désagrégée de base de Junos OS sur diverses plates-formes. Les détails peuvent varier considérablement. Cette rubrique décrit l’architecture globale.

La virtualisation du processus logiciel simple fonctionnant sur du matériel fixe pose plusieurs défis dans le domaine de la communication interprocessus. Comment, par exemple, une VNF avec une fonction NAT fonctionne-t-elle avec un pare-feu fonctionnant en tant que conteneur sur le même équipement ? Après tout, il peut n’y avoir qu’un ou deux ports Ethernet externes sur l’ensemble de l’appareil, et les processus sont toujours internes à l’appareil. L’un des avantages est le fait que les interfaces entre ces processus virtualisés sont souvent virtualisées elles-mêmes, peut-être sous forme de ports SXE ; ce qui signifie que vous pouvez configurer un type de pont de couche MAC entre les processus directement, ou entre un processus et le système d’exploitation hôte, puis entre le système d’exploitation hôte et un autre processus. Il est ainsi possible d’enchaîner les services à mesure que le trafic entre dans l’appareil et en sort.

JDM fournit aux utilisateurs une CLI Junos OS familière et gère toutes les interactions avec le noyau Linux sous-jacent pour conserver l’aspect et la convivialité d’un périphérique Juniper Networks.

Voici quelques-uns des avantages de la désagrégation de Junos OS :

• L’ensemble du système peut être géré comme la gestion d’une plate-forme de serveur.

• Les clients peuvent installer des applications, outils et services tiers, tels que Chef, Wiireshark ou Quagga, dans une machine virtuelle (VM) ou un conteneur.

• Ces applications et outils peuvent être mis à niveau à l’aide de référentiels Linux classiques et sont indépendants des versions de Junos OS.

• La modularité augmente la fiabilité car les défauts sont contenus dans le module.

• Les plans de contrôle et de données peuvent être programmés directement via des API.

La spécification désagrégée de Junos OS inclut un modèle architectural. Le modèle architectural d’une maison peut avoir des indications pour inclure une cuisine, un toit et une salle à manger, et peut représenter différents types d’habitations ; d’un chalet en bord de mer à un manoir somptueux. Toutes ces maisons ont l’air très différentes, mais suivent toujours un modèle architectural de base et partagent de nombreuses caractéristiques.

De même, dans le cas des modèles architecturaux désagrégés de Junos OS, les modèles couvrent des types de plates-formes très différents, du simple équipement sur site client (CPE) à l’équipement de commutation complexe installé dans un grand centre de données, mais présentent certaines caractéristiques de base communes.

Quelles sont les caractéristiques communes entre ces plateformes ? Toutes les plates-formes Junos OS désagrégées sont construites sur trois couches. Ces couches et certains contenus possibles sont illustrés à la figure 3.

La couche la plus basse est la couche matérielle. En plus de la mémoire (RAM) et de l’espace disque (SSD), le matériel de la plate-forme dispose d’un processeur multicœur avec un port NIC externe utilisé pour la gestion. Dans certains cas, un seul port NIC est utilisé pour les plans de contrôle et de données, mais ce port peut également être utilisé pour communiquer avec un moteur de transfert de paquets pour les flux de trafic utilisateur.

La couche logicielle de la plate-forme repose sur la couche matérielle. Toutes les fonctions dépendantes de la plate-forme ont lieu ici. Ces fonctions peuvent inclure une fonction de commutation logicielle pour divers composants virtuels afin de relier le trafic entre eux. Une machine virtuelle Linux ou basée sur un noyau (KVM) exécute la plate-forme et, dans certains modèles, un agent téléphonique contacte un fournisseur ou un fournisseur de services pour effectuer des tâches d’autoconfiguration. L’agent d’accueil téléphonique est particulièrement préféré pour les petites plateformes CPE.

Au-dessus de la couche logicielle de la plate-forme se trouve la couche logicielle du client, qui exécute diverses fonctions indépendantes de la plate-forme. Certains des composants peuvent être des machines virtuelles de Juniper Networks, telles qu’un périphérique SRX virtuel (pare-feu virtuel vSRX) ou le plan de contrôle Junos (JCP). Le JCP fonctionne avec le JDM pour que l’appareil ressemble à une plate-forme Juniper Networks dédiée, mais avec beaucoup plus de flexibilité. Cette flexibilité provient en grande partie de la prise en charge d’une ou plusieurs VNF qui implémentent une fonction réseau virtualisée (VNF). Ces VNF prennent en charge de nombreux types de tâches, telles que la traduction d’adresses réseau (NAT), des recherches de serveurs DNS (Domain Name System), etc.

En général, le nombre de cœurs de processeur est fixe et l’espace disque est limité. Mais dans un environnement virtuel, l’allocation et l’utilisation des ressources sont plus complexes. Les ressources virtuelles telles que les interfaces, l’espace disque, la mémoire ou les cœurs sont réparties entre les VNF exécutées à ce moment-là, comme déterminé par l’image VNF.

Les VNF, qu’il s’agisse de machines virtuelles (VM) ou de conteneurs, qui partagent l’équipement physique doivent souvent communiquer entre elles. Les paquets ou trames pénètrent dans un équipement par le biais d’une interface physique (un port) et sont distribués à une VNF initiale. Après un certain traitement du flux de trafic, la VNF le transmet à une autre VNF si elle est configurée à cet effet, puis à une autre, avant que le trafic ne quitte l’équipement physique. Ces VNF forment une chaîne de services de plan de données qui est parcourue à l’intérieur de l’équipement.

Comment les VNF, qui sont des machines virtuelles ou des conteneurs isolés, transmettent-elles le trafic de l’une à l’autre ? La chaîne de services est configurée pour transmettre le trafic d’une interface physique à une ou plusieurs interfaces virtuelles internes. Par conséquent, des NIC virtuels sont associés à chaque VM ou conteneur, tous connectés par un commutateur virtuel ou une fonction de pont à l’intérieur de l’appareil. Cette relation générique, qui permet la communication entre les interfaces physiques et virtuelles, est illustrée à la figure 4.

Dans ce modèle général, qui peut varier selon les plates-formes, les données entrent par un port sur le NIC physique et sont pontées via la fonction commutateur virtuel vers la machine virtuelle 1 via Virtual NIC 1, en fonction du adresse MAC de destination. Le trafic peut également être ponté via une autre interface virtuelle configurée vers la machine virtuelle 2 ou plusieurs VNF jusqu’à ce qu’il soit renvoyé à un port physique et quitte l’équipement.

À des fins de configuration, ces interfaces peuvent avoir des désignations familières telles que ge-0/0/0 ou fxp0, ou de nouvelles désignations telles que sxe0 ou hsxe0. Certains peuvent être réels, mais des ports internes (tels que sxe0) et d’autres peuvent être des constructions complètement virtuelles (telles que hsxe0) nécessaires pour rendre l’équipement opérationnel.

Les VNF et les conteneurs permettent le multiplexage du matériel avec des dizaines ou des centaines de VNF partageant un serveur physique. Cela permet non seulement un déploiement rapide de nouveaux services, mais aussi l’extension et la migration des charges de travail en période d’utilisation intensive (lorsque l’extension peut être utilisée) ou la maintenance physique (lorsque la migration peut être utilisée).

Dans un environnement de cloud computing, il est courant d’utiliser des VNF pour effectuer le gros du travail sur les vastes fermes de serveurs qui caractérisent le Big Data dans les réseaux modernes. La virtualisation de serveur permet aux applications écrites pour différents environnements de développement, plates-formes matérielles ou systèmes d’exploitation de s’exécuter sur du matériel générique qui exécute une suite logicielle appropriée.

Les VNF s’appuient sur un hyperviseur pour gérer l’environnement physique et répartir les ressources entre les VNF exécutées à un moment donné. Les hyperviseurs les plus populaires incluent Xen, KVM et VMWare ESXi, mais il en existe beaucoup d’autres. Les VNF s’exécutent dans l’espace utilisateur au-dessus de l’hyperviseur et incluent une implémentation complète du système d’exploitation de l’application VM. Par exemple, une application écrite en langage C++, conforme et exécutée sur le système d’exploitation Microsoft Windows peut être exécutée sur un système d’exploitation Linux à l’aide de l’hyperviseur. Dans ce cas, Windows est un système d’exploitation invité.

L’hyperviseur fournit au système d’exploitation invité une vue émulée du matériel des VNF. L’hyperviseur, entre autres ressources telles que l’espace disque de mémoire, fournit une vue virtualisée de la carte d’interface réseau (NIC) lorsque les points de terminaison de différentes machines virtuelles résident sur différents serveurs ou hôtes (une situation courante). L’hyperviseur gère les cartes réseau physiques et n’expose que les interfaces virtualisées aux VNF.

L’hyperviseur exécute également un environnement de commutateur virtuel, qui permet aux VNF de la couche trame VLAN d’échanger des paquets à l’intérieur du même boîtier ou sur un réseau (virtuel).

Le plus grand avantage des VNF est que la plupart des applications peuvent être facilement portées dans l’environnement de l’hyperviseur et fonctionner correctement sans modification.

Le plus gros inconvénient est que, souvent, la surcharge gourmande en ressources du système d’exploitation invité doit inclure une version complète du système d’exploitation, même si la fonction de l’ensemble de la VNF est de fournir un service simple tel qu’un système de noms de domaine (DNS).

Contrairement aux VNF, les conteneurs sont spécialement conçus pour être exécutés en tant que tâches indépendantes dans un environnement virtuel. Les conteneurs ne regroupent pas un système d’exploitation complet à l’intérieur comme le font les VNF. Les conteneurs peuvent être codés et regroupés de nombreuses façons, mais il existe également des moyens de construire des conteneurs standard faciles à entretenir et à étendre. Les conteneurs standard sont beaucoup plus ouverts que les conteneurs créés de manière aléatoire.

Les conteneurs Linux standard définissent une unité de livraison de logiciel appelée conteneur standard. Au lieu d’encapsuler l’ensemble du système d’exploitation invité, le conteneur standard encapsule uniquement l’application et toutes les dépendances requises pour effectuer la tâche pour laquelle l’application est programmée. Cet élément d’exécution unique peut être modifié, mais le conteneur doit ensuite être reconstruit pour inclure toutes les dépendances supplémentaires dont la fonction étendue pourrait avoir besoin. L’architecture globale des conteneurs est illustrée à la figure 5.

Les conteneurs s’exécutent sur le noyau du système d’exploitation hôte et non sur l’hyperviseur. L’architecture de conteneur utilise un moteur de conteneur pour gérer la plate-forme sous-jacente. Si vous souhaitez toujours exécuter des VNF, le conteneur peut également contenir un environnement complet d’hyperviseur et de système d’exploitation invité.

Les conteneurs standard comprennent :

• Un fichier de configuration.

• Un ensemble d’opérations standard.

• Un environnement d’exécution.

Le nom conteneur est emprunté aux conteneurs maritimes utilisés pour transporter des marchandises dans le monde entier. Les conteneurs maritimes sont des unités de livraison standard qui peuvent être chargées, étiquetées, empilées, soulevées et déchargées par des équipements spécialement conçus pour manipuler les conteneurs. Peu importe ce qu’il y a à l’intérieur, le conteneur peut être manipulé de manière standard, et chaque conteneur a son propre espace utilisateur qui ne peut pas être utilisé par d’autres conteneurs. Bien que Docker soit un système de gestion de conteneurs populaire pour exécuter des conteneurs sur un serveur physique, il existe des alternatives telles que Drawbridge ou Rocket à considérer.

Une interface virtuelle est attribuée à chaque conteneur. Les systèmes de gestion de conteneurs tels que Docker comprennent un pont Ethernet virtuel reliant plusieurs interfaces virtuelles et le NIC physique. Les variables de configuration et d’environnement dans le conteneur déterminent quels conteneurs peuvent communiquer entre eux, lesquels peuvent utiliser le réseau externe, etc. Le réseau externe est généralement réalisé avec le NAT, bien qu’il existe d’autres méthodes car les conteneurs utilisent souvent le même espace d’adressage réseau.

Le plus grand avantage des conteneurs est qu’ils peuvent être chargés sur un appareil et exécutés beaucoup plus rapidement que les VNF. Les conteneurs utilisent également les ressources avec beaucoup plus de parcimonie : vous pouvez exécuter beaucoup plus de conteneurs que de VNF sur le même matériel. En effet, les conteneurs ne nécessitent pas un système d’exploitation invité complet ou un temps de démarrage. Les conteneurs peuvent être chargés et exécutés en quelques millisecondes, et non en quelques dizaines de secondes. Cependant, le plus gros inconvénient des conteneurs est qu’ils doivent être écrits spécifiquement pour se conformer à une implémentation standard ou commune, alors que les VNF peuvent être exécutées dans leur état natif.

Vous pouvez activer la communication entre un périphérique virtualisé basé sur Linux et un module de virtualisation des fonctions réseau (NFV) à l’aide de virtio ou en utilisant le matériel approprié et la virtualisation d’E/S à racine unique (SR-IOV). Chaque méthode a des caractéristiques distinctes.

• Comprendre l’utilisation de Virtio
• Comprendre l’utilisation de la SR-IOV
• Comparaison de Virtio et de SR-IOV