Déployer le vRouter DPDK pour une mise en réseau de conteneur optimale

Présentation de DPDK

Cloud-Native Contrail^® Networking prend en^™ charge le kit de développement du plan de données (DPDK). DPDK est un ensemble open source de bibliothèques et de pilotes pour un traitement rapide des paquets. Cloud-Native Contrail Networking accélère la mise en réseau de conteneurs grâce à la technologie vRouter DPDK (Data Plane Development Kit). DPDK permet un traitement rapide des paquets en permettant aux cartes d’interface réseau (NICO) d’envoyer des paquets d’accès mémoire direct (DMA) directement dans l’espace d’adressage d’une application. Cette méthode de routage de paquets permet à l’application de rechercher des paquets, ce qui évite le surcharge des interruptions de la NIC.

L’utilisation de DPDK permet au vRouter Cloud-Native Contrail de traiter plus de paquets par seconde qu’il ne le pourrait en tant que module de noyau interface DPDK pour les fonctions de service de conteneur. Cloud-Native Contrail Networking exploite la puissance de traitement du vRouter DPDK pour alimenter les fonctions de service de conteneur à forte demande.

Lorsque vous provisionnez un nœud de calcul Contrail avec DPDK, le fichier YAML correspondant spécifie le nombre de cœurs de processeur à utiliser pour le transfert de paquets, le nombre de pages énormes à allouer pour DPDK et le pilote UIO à utiliser pour DPDK.

Prise en charge du vRouter DPDK pour les charges de travail DPDK et non-DPDK

Lorsqu’un conteneur ou un pod doit accéder au vRouter DPDK, les types de charges de travail suivants se produisent :

Charge de travail (pod) non DPDK : cette charge de travail inclut des applications pod non DPDK qui ne connaissent pas le vRouter DPDK sous-jacent. Ces applications ne sont pas conçues pour DPDK et n’utilisent pas de fonctionnalités DPDK. Dans Cloud-Native Contrail Networking, ce type de charge de travail fonctionne normalement dans un cluster compatible VRouter DPDK.
Charge de travail DPDK conteneurisée : ces charges de travail sont construites sur la plate-forme DPDK. Les interfaces DPDK sont mises en place à l’aide du protocole vHost, qui agit comme un chemin de données pour les fonctions de gestion et de contrôle. Les pods agissent comme serveur vHost et le vRouter DPDK sous-jacent agit comme vHost Client.
Mélange de tâches non DPDK et DPDK : le canal de gestion ou de contrôle d’une application dans ce pod peut être non-DPDK (paire Veth) et le chemin de données peut être une interface DPDK.

Présentation des pods non-DPDK

Une paire Ethernet virtuel (Veth) plombe la mise en réseau d’un pod non-DPDK. Une extrémité de la paire Veth s’attache à l’espace de noms du pod. L’autre extrémité se rattache au noyau de la machine hôte. Le CNI (Container Networking Interface) établit la paire Veth et alloue des adresses IP à l’aide de l’IPAM (gestion des adresses IP).

Présentation du pod DPDK

Un pod DPDK contient une interface vhost et une interface virtio. Le pod utilise l’interface vhost à des fins de gestion et l’interface virtio pour les applications de traitement de paquets à haut débit. Une application DPDK dans le pod utilise le protocole vhost pour établir la communication avec le vRouter DPDK dans l’hôte. L’application DPDK reçoit un argument pour établir un chemin de fichier pour un socket UNIX. Le vRouter utilise ce socket pour établir le canal de contrôle, exécuter des négociations et créer des vrings sur d’énormes pages de mémoire partagée pour des chemins de données haut débit.

Présentation des pods non-DPDK et DPDK

Ce pod peut contenir des applications non-DPDK et DPDK. Une application non-DPDK utilise une interface non-DPDK (paire Veth) et l’application DPDK utilise les interfaces DPDK (vhost, virtio). Ces deux charges de travail se produisent simultanément.

DPDK vRouter Architecture

Le vRouter Contrail DPDK est un conteneur qui s’exécute à l’intérieur du nœud de calcul Contrail. Le vRouter s’exécute soit comme un module noyau Linux, soit comme un processus DPDK d’espace utilisateur et est responsable de la transmission des paquets entre les charges de travail virtuelles (locataires, invités) sur les équipements physiques. Le vRouter transmet également des paquets entre les interfaces virtuelles et les interfaces physiques.

Le vRouter Cloud-Native Contrail prend en charge les protocoles d’encapsulation suivants :

MPLS sur UDP (MPLSoUDP)
MPLS sur GRE (MPLSoGRE)
Virtual Extensible LAN (VXLAN)

Par rapport au déploiement traditionnel du noyau Linux, le déploiement du vRouter en tant que processus DPDK d’espace utilisateur augmente considérablement les performances et la vitesse de traitement de l’application vRouter. Cette augmentation des performances est le résultat des facteurs suivants :

Les fonctions réseau virtuelles (VNF) opérant dans l’espace utilisateur sont conçues pour DPDK et conçues pour tirer parti de la puissance de traitement des paquets de DPDK.
Les pilotes PMD (Poll Mode Drivers) de DPDK utilisent l’interface physique (NIC) de l’hôte d’une VM, au lieu des pilotes basés sur les interruptions du noyau Linux. Les registres de la carte réseau fonctionnent dans l’espace utilisateur, ce qui les rend accessibles par les PMD de DPDK.

En conséquence, le système d’exploitation Linux n’a pas besoin de gérer les registres de la NIC. Cela signifie que l’application DPDK gère l’interrogation des paquets, le traitement des paquets et le transfert de paquets d’une carte réseau. Au lieu d’attendre une interruption d’E/S, une application DPDK interroge constamment les paquets et traite ces paquets dès leur réception.

Prise en charge de l’interface DPDK pour les conteneurs

Les avantages et l’architecture de DPDK optimisent généralement la mise en réseau des VM. Cloud-Native Contrail Networking permet à vos conteneurs Kubernetes de tirer pleinement parti de ces fonctionnalités. Dans Kubernetes, un pod DPDK conteneurisé contient généralement deux interfaces ou plus. Les interfaces suivantes forment la dorsale d’un pod DPDK :

Protocole utilisateur Vhost (pour la gestion) : Le protocole vhost user est un composant back-end qui s’interface avec l’hôte. Dans Cloud-Native Contrail Networking, l’interface vhost agit comme un chemin de données pour les fonctions de gestion et de contrôle entre le pod et le vRouter. Ce protocole comprend les deux plans suivants :
- Le plan de contrôle échange des informations (mappage mémoire pour DMA, négociation des capacités pour établir et terminer le plan de données) entre un pod et vRouter via une prise Unix.
- Le plan de données est implémenté via un accès mémoire direct et transmet les paquets de données entre un pod et vRouter.
Interface Virtio (pour les applications haut débit) : À un niveau élevé, virtio est un équipement virtuel qui transmet des paquets entre un pod et vRouter. L’interface virtio est une solution de mémoire partagée (shm) qui permet aux pods d’accéder aux bibliothèques et fonctionnalités DPDK.

Ces interfaces permettent au vRouter DPDK de transmettre des paquets entre pods. Les interfaces permettent aux pods d’accéder aux fonctionnalités réseau avancées fournies par le vRouter (énormes pages, tampons d’anneau sans verrouillage, pilotes de mode de vote). Pour plus d’informations sur ces fonctionnalités, consultez Le parcours vers le domaine vhost-users.

Les applications utilisent DPDK pour créer des interfaces vhost et virtio. L’application ou le pod utilise ensuite directement les bibliothèques DPDK pour établir des canaux de contrôle à l’aide de sockets de domaine Unix. Les interfaces établissent des chemins de données entre un pod et un vRouter à l’aide de vrings de mémoire partagée.

Pré-requis de l’hôte vRouter DPDK

Pour déployer un vRouter DPDK, vous devez effectuer les énormes pages et configurations NIC suivantes sur le nœud hôte :

Configuration de pages énormes : spécifiez le pourcentage de mémoire de l’hôte à réserver pour les pages énormes DPDK. La ligne de commande suivante affiche d’énormes pages définies à 2 Mo :
L’exemple suivant alloue quatre pages énormes de 1 Go et 1024 2 Mo de pages énormes :
Note:
Nous vous recommandons d’allouer 1 Go pour la taille énorme des pages.
Activer l’IOMMU (unité de gestion de la mémoire d’entrée-sortie) : les applications DPDK nécessitent une prise en charge de l’IOMMU. Configurez les paramètres de l’IOMMU et activez l’IOMMU à partir du BIOS. Appliquez les indicateurs suivants en tant que paramètres de démarrage pour activer l’IOMMU :
Assurez-vous que le pilote du noyau est chargé sur port forward 0 (port 0) de la carte réseau de l’hôte. Assurez-vous que les pilotes PMD DPDK sont chargés sur port forward 1 (port 1) de la carte réseau de l’hôte.
Note:
Dans un environnement où les pilotes DPDK et de noyau utilisent des ports différents d’une carte réseau commune, nous vous recommandons fortement de déployer un nœud DPDK avec des pilotes de noyau liés au port 0 sur la carte réseau, et des pilotes DPDK PMD liés au port 1 de cette carte. D’autres configurations d’attribution de ports peuvent entraîner des problèmes de performances. Pour plus d’informations, consultez la section 24.9.11 de la documentation DPDK suivante : I40E Poll Mode Driver.

Pilote PCI (vfio-pci, uio_pci_generic) : spécifiez le pilote PCI à utiliser en fonction du type de carte réseau.

Note:

Le vfio-pci est intégré.

Installez manuellement le module uio_pci_generic si nécessaire :

Vérifiez que le module uio_pci_generic est installé :

Déployer un cluster Kubernetes avec le vRouter DPDK dans un nœud de calcul

Cloud-Native Contrail Networking utilise un déployeur DPDK pour lancer un cluster Kubernetes avec compatibilité DPDK. Ce déployeur assure des fonctions de gestion du cycle de vie et applique les pré-requis du vRouter DPDK. Une ressource personnalisée (CR) pour le vRouter DPDK est un sous-ensemble du déploiement. Le CR contient les éléments suivants :

Contrôleurs pour le déploiement de ressources Cloud-Native Contrail Networking
Logique de contrôleur intégrée pour le vRouter

Appliquez le déploiement DPDK YAML et déployez le DPDK vRouter CR à agentModeType: dpdk l’aide de la commande suivante :

Après avoir appliqué le CR YAML, le déployeur crée un daemonset pour le vRouter. Ce deamonset fait tourner un pod avec un conteneur DPDK.

Si vous recevez un message d’erreur, assurez-vous que votre cluster dispose de la définition de ressource personnalisée (CRD) pour le vRouter à l’aide de la commande suivante :

Voici un exemple des sorties que vous recevez :

Si aucun CRD n’est présent dans le cluster, vérifiez le déployeur à l’aide de la commande suivante :

Vérifiez l’image utilisée par le contrail-k8s-crdloader conteneur. Cette image doit être la dernière image que le déployeur utilise. Mettez à jour l’image et assurez-vous que votre nouveau pod utilise cette image.

Une fois que vous avez vérifié que votre nouveau pod exécute la dernière image, vérifiez que le CRD du vRouter est présent à l’aide de la commande suivante :

Une fois que vous avez vérifié que le CRD du vRouter est présent, appliquez le vRouter CR à l’aide de la commande suivante :

Paramètres de ressources personnalisées du vRouteur DPDK

Vous pouvez configurer les paramètres suivants du CR du vRouter :

service_core_mask: spécifiez un masque central de service. Le masque de cœur de service vous permet d’allouer dynamiquement les cœurs de processeur aux services.
Vous pouvez saisir les formats d’entrée suivants :
- Hexadécimal (par exemple, 0xf)
- Liste des processeurs séparés par des virgules (par exemple, 1,2,4)
- Gamme de processeurs séparés par un tableau de bord (par exemple, 1-4)
Note:
Les PMD nécessitent la majeure partie de vos cœurs de processeur disponibles pour le traitement des paquets. Par conséquent, nous vous recommandons de réserver un maximum de 1 à 2 cœurs de processeur pour service_core_mask et dpdk_ctrl_thread_mask. Ces deux cœurs partagent la puissance du processeur.
cpu_core_mask: spécifiez un masque central du processeur. Les PMD de DPDK utilisent ces cœurs pour les applications de traitement de paquets à haut débit.
Les formats d’entrée suivants sont pris en charge :
- Hexadécimal (par exemple, 0xf)
- Liste des processeurs séparés par des virgules (par exemple, 1,2,4)
- Gamme de processeurs séparés par un tableau de bord (par exemple, 1-4)
dpdk_ctrl_thread_mask: spécifiez un masque de thread de contrôle. DPDK utilise ces threads centraux pour le traitement interne.
Les formats d’entrée suivants sont pris en charge :
- Hexadécimal (par exemple, 0xf)
- Liste des processeurs séparés par des virgules (par exemple, 1,2,4)
- Gamme de processeurs séparés par un tableau de bord (par exemple, 1-4)
Note:
Les PMD nécessitent la majeure partie de vos cœurs de processeur disponibles pour le traitement des paquets. Par conséquent, nous vous recommandons de réserver un maximum de 1 à 2 cœurs de processeur pour service_core_mask et dpdk_ctrl_thread_mask. Ces deux cœurs partagent la puissance du processeur.
dpdk_command_additional_args: spécifiez les paramètres du vRouter DPDK qui ne sont pas des paramètres par défaut. Les arguments que vous saisissez ici sont ajoutés à la ligne de commande DPDK PMD.
Voici un exemple d’argument :--yield_option 0
.

SUR CETTE PAGE