Les machines virtuelles ou les conteneurs doivent communiquer entre eux, y compris au sein du même hôte ou avec des périphériques physiques ou virtuels en dehors de l'hôte.Dans les deux cas, une carte réseau est requise pour la communication.
Il existe deux moyens de communication, l'un via l'interface virtualisée et l'autre via l'interface physique dédiée de la machine virtuelle. Bien sûr, l'interface physique n'est utilisée que pour communiquer avec le périphérique en dehors de l'hôte. Cependant, étant donné que le nombre d'interfaces requises par une machine virtuelle est généralement bien supérieur au nombre d'interfaces physiques disponibles pour l'infrastructure, un mécanisme de virtualisation au niveau de l'interface est inévitable. La couche NFVI est chargée de réaliser cette fonction (et bien sûr d'autres fonctions), dont la vNIC (virtual Network Interface Card, carte réseau virtuelle) qui peut être utilisée par les machines virtuelles.
La machine virtuelle considère ces vNIC comme de véritables interfaces physiques et utilise ces interfaces pour envoyer et recevoir des paquets en dehors de la machine virtuelle. Afin de permettre aux interfaces virtuelles d'avoir des fonctions d'évolutivité et de commutation partielle, et d'exécuter des fonctions de commutation de paquets sans réduire considérablement les performances, l'industrie a fourni plusieurs méthodes pour mettre en œuvre ces fonctions.Ce qui suit analyse certaines des méthodes courantes.
1. Commutateur virtuel
L'utilisation de ponts virtuels est une solution simple pour interfacer la virtualisation, mais les ponts virtuels manquent de fonctionnalités, d'évolutivité et de flexibilité. Afin de résoudre le problème des fonctionnalités insuffisantes, plusieurs autres logiciels de commutateur virtuel peuvent être utilisés pour la communication des machines virtuelles afin de fournir des fonctions de commutation améliorées, telles que le Nexus 1000v de Cisco, le commutateur virtuel de VMware (commutateur virtuel) et OVS (Open Virtual Switch, open échange virtuel).
OVS est un choix plus populaire parmi les commutateurs open source. Il peut non seulement s'exécuter dans Hypervisor, mais prend également en charge un riche ensemble de fonctionnalités (telles que la prise en charge de sFlow, NetFlow et OpenFlow). La grande popularité d'OVS en fait une plate-forme pour OpenStack et d'autres orchestrations de machines virtuelles La sélection par défaut pour .
Le problème avec cette approche est qu'il peut y avoir un certain impact sur les performances lors de la mise à l'échelle vers des interfaces à débit plus élevé. Étant donné que le logiciel ou le noyau de l'hyperviseur doit supporter la charge de lire les paquets à partir des files d'attente d'entrée ou de sortie, puis de mettre en file d'attente et de distribuer le trafic vers et depuis les machines virtuelles, ces opérations consomment beaucoup de cycles CPU, ce qui rend cette méthode en termes d'évolutivité, il semble relativement inefficace.
Les problèmes de charge de virtualisation, en particulier lorsque les machines virtuelles exécutent des fonctions réseau avec des VNF directement dans le chemin du trafic de données, deviendront plus graves. La dégradation des performances due à la charge de la virtualisation aura un impact direct sur le trafic de bout en bout.
La solution pour résoudre la charge de la virtualisation est le mécanisme d'intercommunication, qui contourne l'hyperviseur, et la vNIC communique directement avec la carte réseau physique d'une manière de mappage un à un. Bien que cette méthode puisse éviter le problème de la charge de la virtualisation, cela entraînera des problèmes de performances plus graves car la méthode attribue une interface physique à une interface virtuelle.
Étant donné que les serveurs n'ont généralement pas beaucoup d'interfaces physiques, cela limite considérablement le nombre de machines virtuelles pouvant utiliser le mode relais. De plus, la méthode pass-through présente également le problème de prise en charge du pilote de périphérique du système d'exploitation client.
2、SR-IOV
SR-IOV (Single Root Input/Output Virtualization, Single Root Input/Output Virtualization) aide à réaliser la virtualisation au niveau de l'interface, qui fournit une norme pour qu'une seule carte réseau devienne plusieurs cartes réseau pouvant être utilisées par le système d'exploitation hôte. la charge de virtualisation de la carte réseau du noyau ou de l'hyperviseur est résolue et les ressources de la carte réseau sont utilisées pour gérer la virtualisation de l'interface, ce qui réduit considérablement la pression sur le processeur hôte.
Pour être précis, SR-IOV peut multiplexer n'importe quel périphérique d'entrée/sortie (E/S) qui utilise la spécification PCI (Peripheral Component Interconnect, Peripheral Component Interconnect) pour se connecter à plusieurs composants système.
SR-IOV est créé et maintenu par PCI-SIG (Peripheral Component Interconnect Special Interest Group, Peripheral Component Interconnect Special Interest Group).
Lors de la mise en œuvre de la virtualisation d'interface réseau dans un hyperviseur ou un hôte, le processeur hôte est interrompu par des paquets arrivant sur la carte réseau qui doivent être lus et traités. Une fois que l'hôte a terminé le traitement, ces paquets de données doivent être mis en file d'attente sur leurs machines virtuelles respectives et occuper les ressources CPU virtuelles correspondantes, ce qui affectera indirectement le CPU hôte, car le CPU hôte doit traiter la file d'attente de lecture à partir de la carte réseau et la charger dans la machine virtuelle. La demande de ces paquets est à nouveau traitée dans l'environnement.
Après avoir adopté SR-IOV, la carte réseau n'a besoin de traiter que la première interruption parmi ces interruptions, qui joue un rôle de blindage sur le processeur hôte.
Créez d'abord plusieurs interfaces virtuelles, puis présentez ces interfaces virtuelles comme une interface physique à la couche supérieure (hôte et hyperviseur, etc.). En termes de SR-IOV, ces interfaces virtuelles sont VF (fonction virtuelle, fonction virtuelle), et certaines cartes réseau qui fonctionnent et exécutent des fonctions d'interface physique réelles sont appelées PF (fonction physique, fonction physique). Attention à ne pas confondre le terme VF avec VNF (Virtualized Network Function, fonction de réseau virtuel), les deux n'ont rien en commun si ce n'est qu'ils sont liés à la technologie de virtualisation.
À ce stade, l'hyperviseur peut fournir ces interfaces VF en tant que pNIC (NIC physique, carte réseau physique) à la machine virtuelle (connectée de manière directe). De cette manière, après l'arrivée des paquets de données à l'interface physique, le processeur hôte ne sera pas interrompu, mais la carte réseau est responsable de la lecture des paquets de données à partir du lien et de leur traitement, puis de la transformation de ces paquets de données dans l'interface virtuelle attribuée. à la file d'attente de la machine virtuelle de destination, ces tâches sont toutes exécutées par PF, et la file d'attente appartient à l'espace mémoire de VF. Afin de mettre ces paquets en file d'attente dans la bonne VF, SR-IOV utilise des identifiants tels que les adresses MAC et les balises VLAN qui peuvent identifier de manière unique la bonne VF.
La figure suivante montre un diagramme schématique de la mise en œuvre de SR-IOV :
Bien que SR-IOV présente des interfaces virtuelles à l'hôte, il ne cache pas le fait que ces interfaces sont virtualisées. VF n'est utilisé que pour déplacer des données entre l'hôte et PF, et n'a pas besoin d'agir comme un périphérique PCI conventionnel, de sorte que l'hôte, l'hyperviseur et les machines virtuelles doivent tous prendre en charge SR-IOV. Par exemple, si l'hyperviseur fournit une connexion pass-through pour la VM à la VF, alors la VNF doit comprendre qu'elle communique avec un périphérique PCI émulé qui ne nécessite pas de configuration de ressources.
Un inconvénient de SR-IOV est que le bus PCI est utilisé pour l'échange de paquets de données entre le VF et le processeur hôte. Après avoir utilisé la chaîne de fonctions de service, le paquet de données peut aller et venir plusieurs fois sur ce chemin, ce qui rend la bande passante de le bus PCI un facteur restrictif.
3. Accès direct à la mémoire
L'un des modes de communication entre machines virtuelles consiste à utiliser l'espace mémoire partagé de l'OS hôte, cette technologie réserve à cet effet une partie de la mémoire de l'hôte accessible par la machine virtuelle. La machine virtuelle peut lire et écrire dans cet espace de stockage et le voir comme un périphérique PCI. Cet emplacement mémoire agit donc comme une liaison de données permettant à la machine virtuelle d'envoyer des paquets dans les deux sens.
Cette méthode rompt le principe d'isolation de la virtualisation, car à ce moment l'espace mémoire utilisé par les machines virtuelles est un espace partagé, qui n'appartient pas à ces machines virtuelles, mais à l'hôte.
De plus, afin d'assurer le fonctionnement normal de ce mécanisme, l'Hyperviseur doit supporter ce mécanisme, comme le montre la figure ci-dessous.
4. Améliorez les performances de vSwitch
L'objectif de l'approche de virtualisation d'interface décrite précédemment est de fournir aux machines virtuelles des interfaces réseau évolutives avec de bonnes performances de transfert. Étant donné que ces technologies trouvent leurs racines dans le monde de la virtualisation des serveurs, des fonctionnalités de commutation limitées et une certaine dégradation des performances (par rapport aux performances bare metal natives) sont acceptables, car la majeure partie du trafic est dirigée vers les applications.
Mais pour NFV, puisque ces interfaces se trouvent dans le chemin des données, leurs performances reflètent directement les performances du réseau NFV. Étant donné que la machine virtuelle doit exécuter des fonctions réseau spécifiques et se trouve également dans le chemin des données, les facteurs de performances tels que le débit de l'interface, le délai et la gigue deviennent très importants. Une légère diminution des performances de l'interface du VNF affectera l'ensemble du chemin des données. et entraîner une baisse de la qualité de service.
De même, NFV peut bénéficier de l'ajout d'intelligence à la couche de virtualisation pour activer les capacités de chaînage de services. Si un commutateur virtuel peut comprendre les informations de chaînage de services, il peut agir comme un SFF et simplifier considérablement le chemin des paquets entre les VNF, comme illustré dans la figure ci-dessous.
Parmi les méthodes décrites précédemment, l'approche du commutateur virtuel a le pire débit car toute la charge est supportée par le chemin logiciel, qui n'est pas optimisé pour le traitement des paquets.
Le débit de SR-IOV est relativement bon, et le débit obtenu par la méthode de mémoire partagée est meilleur parmi les trois. Cependant, la technologie de mémoire partagée présente les problèmes de sécurité susmentionnés, et ni SR-IOV ni la technologie de partage de mémoire ne sont le meilleur choix pour implémenter des fonctionnalités de commutation avancées, et le débit des commutateurs virtuels est faible, mais c'est le meilleur choix pour implémenter ces fonctionnalités supplémentaires. .meilleur choix. Par conséquent, il existe généralement de nombreuses façons d'améliorer les performances lors de l'utilisation d'un commutateur virtuel lié aux fonctionnalités requises.
Certaines manières courantes d'améliorer les performances de commutation de base sont décrites ci-dessous.
1. DPDK
La principale raison des mauvaises performances des commutateurs logiciels (virtuels) est qu'ils ne sont pas optimisés ou conçus pour gérer et commuter les paquets à un débit excessivement élevé, et le DPDK (Data Plane Development Kit) est conçu pour résoudre ce problème. Avant d'expliquer comment DPDK améliore la situation, il convient de passer en revue les limites des commutateurs virtuels classiques.
En raison du manque d'optimisation du traitement des paquets de données à haut débit par le commutateur virtuel, de nombreuses étapes du processus de traitement des paquets de données utiliseront le CPU.Puisque le CPU doit gérer le multitâche, sa disponibilité (surtout en cas de surcharge ) entraînera des goulots d'étranglement des performances. . De plus, les commutateurs virtuels n'utilisent pas efficacement la mémoire système, ils copient d'abord les paquets dans une mémoire tampon, puis interrompent le processeur client et copient le paquet dans la mémoire client, et enfin lisent les données de la vNIC vers l'application. Les opérations de traitement telles que l'allocation de mémoire, la désallocation et les interruptions du processeur générées par la lecture et l'écriture pures de la mémoire réduiront les performances du commutateur virtuel.
L'objectif du développement de DPDK est de fournir aux logiciels un moyen optimisé de traiter les paquets de données. DPDK est un ensemble de fonctions de bibliothèque et de pilotes de carte réseau créé par Intel Corporation. Il a été initialement publié à la fin de 2012. En 2013, Intel a mis DPDK à la disposition de la communauté des développeurs en tant que kit de développement open source, permettant aux développeurs d'utiliser ces fonctions de bibliothèque dans des commutateurs logiciels et des applications similaires qui tirent parti des capacités de réglage fin fournies par DPDK. Bien que DPDK soit le même pour tous les logiciels qui souhaitent l'utiliser, son utilisation dans OVS est plus importante. Après avoir utilisé DPDK, les performances d'OVS peuvent être considérablement améliorées et la combinaison des deux est généralement appelée OVS accéléré ou OVS-DPDK.
DPDK remplace le plan de données intégré du noyau Linux par ses propres fonctions de bibliothèque. Les fonctions de bibliothèque légères de DPDK utilisent un mécanisme de traitement de la mémoire très efficace, c'est-à-dire l'utilisation de tampons en anneau entre les cartes réseau physiques et les applications qui utilisent DPDK (telles que OVS) Les paquets de données sont transmis dans les deux sens entre eux, améliorant ainsi les performances globales du système.
Afin de réduire le nombre d'interruptions CPU requises pour la lecture des paquets de données, DPDK adopte un mécanisme d'interrogation périodique et le noyau du système interroge périodiquement les nouveaux paquets de données. Si le débit de paquets tombe à une valeur très faible, il est possible de passer en mode interruption au lieu d'une interrogation périodique. Grâce à une gestion efficace du cache, à un nombre minimum d'interruptions CPU optimisé et à d'autres améliorations, il est confirmé que DPDK permet à OVS d'atteindre des performances quasi natives.
Cependant, DPDK a moins de fonctionnalités et ne possède pas sa propre pile de protocoles réseau. La fonction principale est de terminer le traitement et le transfert des paquets de données. DPDK peut fournir des fonctions riches lorsqu'il est combiné avec des applications qui implémentent des fonctions réseau (telles que OVS-DPDK ) et de bonnes performances de transmission.
2. VPP
Nous avons discuté de la façon dont DPDK améliore les performances de transfert de paquets. En optimisant l'utilisation du processeur et de la mémoire, DPDK traite les paquets dans un flux série. Chaque paquet passe par les fonctions de pile de protocole réseau de manière séquentielle, un paquet à la fois, et cette méthode de traitement est généralement appelée scalaire. traitement (traitement scalaire).
VPP (Vector Packet Processing, traitement vectoriel des paquets de données) fournit des fonctions améliorées en plus de DPDK pour traiter les paquets de données par lots (plutôt qu'un par un). Cette méthode de traitement parallèle ou par lots est généralement appelée traitement vectoriel (Vector Processing) .
En général, les paquets appartenant au même flux sont très susceptibles d'être traités et transmis de la même manière, de sorte que le traitement vectoriel tire parti de cette possibilité et permet d'obtenir une amélioration supplémentaire des performances en regroupant les paquets.
La technologie utilisée par VPP est la technologie propriétaire de Cisco, qui est utilisée dans les plates-formes de routage haut de gamme de Cisco (telles que les équipements des séries CRS et ASR9000).
Début 2016, Cisco a ouvert la technologie VPP en tant que logiciel open source dans le projet FD.io (Fido). VPP est étroitement intégré à DPDK et complète DPDK, et peut fonctionner sur n'importe quel système x86. Étant donné que VPP fournit une très bonne pile de protocoles réseau, qui réalise principalement les fonctions de la couche 2 à la couche 4, il peut être considéré et utilisé comme un routeur virtuel ou un commutateur virtuel hautes performances. Coopérant avec des applications de haut niveau, il peut fournir des fonctions réseau telles que des pare-feu, des routeurs complets (prenant en charge divers protocoles de routage) et des équilibreurs de charge.
En fait, VPP prétend avoir le premier commutateur de transfert de paquets à vitesse filaire dans l'espace utilisateur avec des capacités de mise en réseau.
1) Comment fonctionne VPP
Bien que les détails sur la mise en œuvre et l'optimisation de VPP soient très utiles pour les travaux de recherche de haut niveau. Pendant le traitement scalaire du paquet de données, lorsque le paquet de données traverse la pile de protocoles de transfert, des opérations telles que la désencapsulation, la vérification et la segmentation peuvent être effectuées. Il est important de faire correspondre la table de transfert pour déterminer si le paquet de données doit être transféré et son Envoyé à des couches supérieures pour un traitement ultérieur, ou simplement rejeté.
La figure ci-dessous montre les étapes de traitement par lesquelles passent deux types de flux différents. Chaque fois que le processus de traitement est appelé, il passera par des étapes de traitement telles que l'encapsulation Ethernet, la commutation d'étiquettes ou les décisions de transfert, appelant le processeur à traiter le paquet.
Ces opérations sont effectuées sur chaque paquet qui passe par ce processus. VPP fait référence à ces étapes de traitement sous le nom de graphe de traitement des paquets, qui est appliqué à l'ensemble des paquets.
VPP est un logiciel hautement modulaire qui peut facilement ajouter des fonctions graphiques de traitement de paquets supplémentaires et s'intégrer dans le flux via des plug-ins. Étant donné que VPP fonctionne dans l'espace utilisateur, il n'est pas nécessaire de le modifier au niveau du noyau pour utiliser des plug-ins ou faire des ajustements, ce qui est facile à mettre en œuvre et à ajouter.
2) VPP et FD.io
Après la sortie de VPP en tant que logiciel open source, la Linux Foundation a pris le code propriétaire de Cisco et l'a nommé projet FD.io ou Fido. Outre Cisco, les autres membres fondateurs de FD.io incluent 6WIND, Intel, Brocade, Comcast, Ericsson, Huawei, Metaswitch Networks et Red Hat.
FD.io adopte également les contributions des autres membres.Il convient de mentionner qu'il suit le code DPDK du logiciel open source sous licence BSD (Berkeley Software Distribution, Berkeley software suite). Grâce aux contributions conjointes de chacun, il existe de nombreux outils de gestion, de débogage et de développement fournis avec FD.io. En même temps, combiné aux fonctions d'amélioration de transfert de DPDK et VPP, FD.io est devenu un commutateur virtuel utilisable ou un commutateur virtuel avec capacités de débogage et de développement routeur.
Veuillez noter que FD.io est généralement appelé Open-VPP ou simplement VPP dans de nombreux endroits, car VPP joue un rôle très important dans le code FD.io.
3) Interagissez avec VPP
La pile de protocoles réseau du VPP est accessible via les API sous-jacentes publiées par le VPP, et ces API peuvent être appelées par des applications qui exécutent des fonctions réseau. Étant donné que les applications doivent utiliser et gérer VPP pour effectuer des opérations de transfert de données, le terme DPA (Data Plane Management Agent, Data Plane Management Agent) est parfois utilisé pour désigner les applications.
Le proxy Honeycomb fourni par FD.io peut agir en tant que DPA. Il fournit également des interfaces RESTCONF et NETCONF vers le nord. Les applications et les contrôleurs (en particulier ODL) interagissent avec VPP via les interfaces NETCONF (en utilisant le modèle de données YANG).
Le schéma ci-dessous donne les différentes possibilités d'utilisation de VPP :
4) Avantages et performances du VPP
Étant donné que VPP est le premier commutateur open source hautes performances dans l'espace utilisateur avec transfert intégré et pile de protocoles réseau, des tests en laboratoire menés par une organisation tierce indépendante montrent que, par rapport à OVS-DPDK, VPP a apporté des améliorations significatives en termes de performances, se rapprochant des performances natives dans les environnements virtualisés.
La figure ci-dessous montre l'impact de la taille de la table de transfert et de la taille du paquet de données sur le débit et le délai. De la comparaison entre les deux, il est facile de voir les avantages de VPP.
VPP est une application 64 bits qui prend en charge le chaînage de services et les champs d'en-tête de métadonnées, ce qui en fait un commutateur idéal pour les environnements NFV.
5. Considérations sur les performances des données
La virtualisation ajoute une couche de surcharge qui a un certain impact sur le débit réel. Comme mentionné précédemment, la couche de virtualisation occupera les ressources CPU, mémoire et NIC du matériel, et créera également un pool virtuel pour les VNF. Pour un VNF, généralement situé dans le chemin des données, il doit être hautement optimisé pour ses performances de traitement des paquets. Bien que les méthodes d'amélioration des performances de traitement des paquets pour les commutateurs virtuels et les vNIC aient été discutées, elles ne suffisent pas à atteindre des performances élevées pour les VNF.
Dans un environnement virtualisé, l'efficacité de l'utilisation des ressources de CPU, de stockage et de mémoire joue un rôle important dans l'amélioration des performances globales du chemin de données dans l'environnement virtuel.
Le VNF doit pouvoir lire, traiter et réécrire les paquets sans devenir un goulot d'étranglement dans le chemin des paquets. Voici une brève introduction à certaines méthodes qui peuvent être utilisées pour optimiser les performances d'utilisation du processeur et de la mémoire des machines virtuelles. Si vous souhaitez en savoir plus sur ces contenus et êtes intéressé par d'autres paramètres qui ajustent les performances de VNF, il est recommandé de vérifiez vous-même les informations.
Avant de plonger dans les problèmes de performances, il est important de souligner qu'un environnement virtualisé ne peut pas dépasser les ressources qui lui sont allouées. Parfois, la seule façon d'améliorer les performances est d'allouer plus de ressources aux machines virtuelles (élasticité), ou d'utiliser plusieurs copies de machines virtuelles pour réaliser des modules de partage de charge de trafic (élasticité et clustering), de gestion et d'orchestration) ou des applications de haut niveau pour la gestion et la mise en oeuvre.
Le mécanisme d'optimisation décrit ci-dessous permet aux machines virtuelles d'utiliser l'environnement de virtualisation de manière plus efficace et de réduire les frais généraux de virtualisation.Ces techniques d'optimisation sont très importantes pour améliorer les performances globales des VNF (y compris le débit et la latence).
1. Optimiser l'utilisation du processeur
Lorsque vous discutez des techniques d'optimisation du processeur, vous devez comprendre les termes de processeur suivants.
- Multi-socket : Un socket CPU est le connecteur électrique que le CPU branche sur la carte mère. Un système multi-socket permet d'utiliser plusieurs CPU physiques sur le même matériel hôte physique.
- Multicœur : le processeur physique actuel possède plusieurs moteurs de traitement ou unités de traitement indépendants. Ces unités de traitement sont des cœurs, et ces cœurs peuvent augmenter le nombre d'instructions exécutées par le processeur en même temps. Ces cœurs peuvent être considérés comme des voies séparées qui traitent les instructions CPU requises par un ou plusieurs processus du système d'exploitation.
- Multithreading (ou multithreading simultané) : cette technologie permet aux cœurs de processeur de traiter simultanément les instructions de différents threads d'application. L'utilisation de la technologie SMT (multithreading simultané, multithreading synchrone) pour améliorer l'utilisation du cœur du processeur peut généralement améliorer considérablement les performances des applications. Intel utilise sa propre technologie propriétaire pour implémenter SMT, et elle s'appelle HT (Hyper-Threading, Hyper-Threading).
L'utilitaire Linux permettant de vérifier le nombre de processeurs, de sockets et de cœurs disponibles est lscpu (qui fait partie du package util-linux), et un exemple de sortie de cet utilitaire est donné ci-dessous.
Linux:~$ lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 32
On-line CPU(s) list: 0-31
Thread(s) per core: 2
Core(s) per socket: 8
Socket(s): 2
NUMA node(s): 2
<snip>Comme le montre la sortie, le système est un système à 32 processeurs (car le système dispose de 2 sockets CPU et chaque socket CPU a 8 cœurs), capable d'effectuer plusieurs tâches et chaque cœur exécute deux threads.
Un système avec 8 cœurs et 2 sockets peut fournir 16 cœurs dédiés, et le système d'exploitation hôte ou l'hyperviseur peut tirer parti des capacités multitâches du processeur pour fournir au système plus de processeurs virtuels. Si ces processeurs sont compatibles avec le double thread, le système peut être considéré comme fournissant jusqu'à 32 processeurs virtuels (2 sockets x 8 cœurs/socket x 2 threads/cœur).
La plupart des serveurs hautes performances utilisent des processeurs multisockets et multicœurs. Après la virtualisation du processeur, tous les cœurs peuvent théoriquement être alloués au VNF, et une autre machine virtuelle utilisant l'hôte peut également allouer le même nombre de cœurs.Ce n'est pas un problème, car l'hyperviseur peut gérer l'utilisation des cœurs du processeur sur les machines virtuelles, mais cela peut entraîner des problèmes imprévisibles de disponibilité du processeur, en particulier si une machine virtuelle consomme instantanément la plupart des ressources du processeur.
Pour les applications urgentes qui dépendent de la disponibilité du processeur, telles que le traitement des paquets, cette situation peut entraîner une gigue excessive ou même une perte de paquets.
Si vous souhaitez améliorer les performances de VNF, vous pouvez envisager les technologies courantes suivantes.
- désactiver l'hyperthreading
L'activation de la technologie HT ou SMT peut entraîner des performances incohérentes en raison de la nécessité de partager logiquement les cœurs physiques entre les threads. Normalement, la désactivation de SMT ou HT permettra au VNF d'obtenir des performances de traitement de paquets plus fluides, car le CPU n'a pas à migrer entre le VNF et d'autres applications, mais cela réduira l'évolutivité du système (nombre réduit de logiques processeurs).
Cependant, il n'est pas toujours possible de désactiver HT ou SMT dans les applications pratiques, car cette opération doit être effectuée dans le BIOS du serveur (Basic Input/Output System, Basic Input/Output System), ce qui signifie que tout le serveur doit être redémarré. Une solution possible consiste à isoler les cœurs de processeur pour le VNF (en tirant parti des espaces de noms ou de techniques similaires) et à empêcher d'autres applications d'utiliser les threads de processeur que le VNF utilise.
- Liaison CPU ou affinité processeur
Une fois le processus lié au processus physique, le thread de l'hyperviseur ne migrera pas entre les processeurs, ce qui permet d'obtenir des performances fluides et une meilleure utilisation du cache mémoire.
Si vous souhaitez utiliser cette technique, vous devez faire attention à ne pas lier plusieurs threads d'un processeur à des processeurs sur le même socket.
- Utiliser un noyau non perturbateur
Le noyau Linux peut être compilé avec des drapeaux qui permettent à des cœurs de processeur spécifiques d'effectuer des tâches connexes sans ralentir le système en interrompant le traitement. Évidemment, cela nécessite de recompiler le noyau et ne peut pas être fait sur un système en cours d'exécution.
Cependant, si les opérations ci-dessus doivent être réalisées, l'utilisation d'un noyau Tickless peut grandement améliorer les performances des applications VNF.
2. Optimiser l'utilisation de la mémoire
Le processeur a besoin de lire et d'écrire fréquemment dans la mémoire pendant le traitement, et la mémoire haute vitesse peut garantir que le processeur ne passe pas trop de cycles à attendre pour récupérer des données de la mémoire ou stocker des données dans la mémoire. Le temps d'accès à la mémoire est important pour rechercher et faire correspondre les données stockées et pour mettre en file d'attente les données qui ont été lues et attendent d'être traitées.
Par exemple, certains routeurs physiques utilisent des mémoires hautes performances dédiées telles que TCAM (Ternary Content Addressable Memory) pour stocker des données consultables (telles que des informations de routage), mais si le VNF fonctionne sur du matériel à usage général et est partagé avec d'autres mémoires de processus, alors les privilèges correspondants ne peuvent pas être obtenus.
Pour les systèmes plus anciens, le processeur accède à une seule banque de mémoire, connue sous le nom d'accès mémoire unifié. Un serveur multi-socket et multiprocesseur avec une grande quantité de mémoire divise la mémoire en régions (également appelées nœuds) qui sont couplées avec des sockets CPU. Pour cette technologie NUMA (Non-Uniform Memory Access, non-uniform memory access), chaque Le processeur accédera d'abord à sa propre mémoire locale (lecture et écriture plus rapides) avant d'accéder à la mémoire partagée au-delà des limites NUMA. Tant que les applications sont limitées au fonctionnement dans les limites NUMA, les performances du système peuvent être efficacement améliorées.