SupportConsoleDéveloppeursCommencer un essaiContact

23.4. Configuration d'un périphérique de réseau SR-IOV

Vous pouvez configurer un dispositif de virtualisation d'E/S à racine unique (SR-IOV) dans votre cluster.

23.4.1. Objet de configuration du nœud de réseau SR-IOV

Vous spécifiez la configuration du dispositif de réseau SR-IOV pour un nœud en créant une stratégie de nœud de réseau SR-IOV. L'objet API de la stratégie fait partie du groupe API sriovnetwork.openshift.io.

Le fichier YAML suivant décrit une politique de nœuds de réseau SR-IOV : 

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: <name> 1
  namespace: openshift-sriov-network-operator 2
spec:
  resourceName: <sriov_resource_name> 3
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true" 4
  priority: <priority> 5
  mtu: <mtu> 6
  needVhostNet: false 7
  numVfs: <num> 8
  nicSelector: 9
    vendor: "<vendor_code>" 10
    deviceID: "<device_id>" 11
    pfNames: ["<pf_name>", ...] 12
    rootDevices: ["<pci_bus_id>", ...] 13
    netFilter: "<filter_string>" 14
  deviceType: <device_type> 15
  isRdma: false 16
    linkType: <link_type> 17
  eSwitchMode: "switchdev" 18
1
Nom de l'objet ressource personnalisé.
2
L'espace de noms dans lequel l'opérateur de réseau SR-IOV est installé.
3
Le nom de la ressource du plugin de périphérique réseau SR-IOV. Vous pouvez créer plusieurs stratégies de nœuds de réseau SR-IOV pour un nom de ressource.

Lorsque vous spécifiez un nom, veillez à utiliser l'expression syntaxique acceptée ^[a-zA-Z0-9_] $ dans le formulaire resourceName.

4
Le sélecteur de nœuds indique les nœuds à configurer. Seuls les périphériques de réseau SR-IOV sur les nœuds sélectionnés sont configurés. Le plugin SR-IOV Container Network Interface (CNI) et le plugin de périphérique sont déployés sur les nœuds sélectionnés uniquement.
5
Facultatif : La priorité est une valeur entière comprise entre 0 et 99. Plus la valeur est petite, plus la priorité est élevée. Par exemple, une priorité de 10 est plus élevée que celle de 99. La valeur par défaut est 99.
6
Facultatif : L'unité de transmission maximale (MTU) de la fonction virtuelle. La valeur maximale du MTU peut varier selon les modèles de contrôleurs d'interface réseau (NIC).
7
Facultatif : Définissez needVhostNet sur true pour monter le périphérique /dev/vhost-net dans le pod. Utilisez le périphérique /dev/vhost-net monté avec le kit de développement du plan de données (DPDK) pour transmettre le trafic à la pile réseau du noyau.
8
Le nombre de fonctions virtuelles (VF) à créer pour le périphérique de réseau physique SR-IOV. Pour un contrôleur d'interface réseau (NIC) Intel, le nombre de VF ne peut pas être supérieur au nombre total de VF pris en charge par le périphérique. Pour un NIC Mellanox, le nombre de VF ne peut pas être supérieur à 128.
9
Le sélecteur NIC identifie le dispositif à configurer par l'opérateur. Il n'est pas nécessaire de spécifier des valeurs pour tous les paramètres. Il est recommandé d'identifier le périphérique réseau avec suffisamment de précision pour éviter de sélectionner un périphérique par inadvertance.

Si vous spécifiez rootDevices, vous devez également spécifier une valeur pour vendor, deviceID ou pfNames. Si vous spécifiez pfNames et rootDevices en même temps, assurez-vous qu'ils se réfèrent au même appareil. Si vous spécifiez une valeur pour netFilter, il n'est pas nécessaire de spécifier d'autres paramètres car un ID de réseau est unique.

10
Facultatif : Le code hexadécimal du fournisseur de l'appareil de réseau SR-IOV. Les seules valeurs autorisées sont 8086 et 15b3.
11
Facultatif : Le code hexadécimal du périphérique du réseau SR-IOV. Par exemple, 101b est l'ID d'un périphérique Mellanox ConnectX-6.
12
Facultatif : Un tableau d'un ou plusieurs noms de fonctions physiques (PF) pour l'appareil.
13
Facultatif : Un tableau d'une ou plusieurs adresses de bus PCI pour le PF de l'appareil. Indiquer l'adresse au format suivant : 0000:02:00.1.
14
Facultatif : Le filtre réseau spécifique à la plateforme. La seule plateforme prise en charge est Red Hat OpenStack Platform (RHOSP). Les valeurs acceptables utilisent le format suivant : openstack/NetworkID:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. Remplacez xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx par la valeur du fichier de métadonnées /var/config/openstack/latest/network_data.json.
15
Facultatif : Le type de pilote pour les fonctions virtuelles. Les seules valeurs autorisées sont netdevice et vfio-pci. La valeur par défaut est netdevice.

Pour qu'une carte d'interface réseau Mellanox fonctionne en mode DPDK sur des nœuds métalliques nus, utilisez le type de pilote netdevice et définissez isRdma comme true.

16
Facultatif : Permet d'activer ou non le mode d'accès direct à la mémoire à distance (RDMA). La valeur par défaut est false.

Si le paramètre isRdma est réglé sur true, vous pouvez continuer à utiliser le VF compatible RDMA comme un périphérique réseau normal. Un périphérique peut être utilisé dans l'un ou l'autre mode.

Définissez isRdma sur true et needVhostNet sur true pour configurer une carte d'interface réseau Mellanox à utiliser avec les applications Fast Datapath DPDK.

17
Optionnel : Le type de lien pour les VF. La valeur par défaut est eth pour Ethernet. Remplacez cette valeur par "ib" pour InfiniBand.

Lorsque linkType est défini sur ib, isRdma est automatiquement défini sur true par le webhook de l'opérateur de réseau SR-IOV. Lorsque linkType est défini sur ib, deviceType ne doit pas être défini sur vfio-pci.

Ne pas définir linkType sur 'eth' pour SriovNetworkNodePolicy, car cela peut conduire à un nombre incorrect de périphériques disponibles rapportés par le plugin de périphérique.

18
Facultatif : Pour activer le délestage matériel, le champ "eSwitchMode" doit être défini sur "switchdev".

23.4.1.1. Exemples de configuration de nœuds de réseau SR-IOV

L'exemple suivant décrit la configuration d'un dispositif InfiniBand :

Exemple de configuration d'un dispositif InfiniBand

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-ib-net-1
  namespace: openshift-sriov-network-operator
spec:
  resourceName: ibnic1
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 4
  nicSelector:
    vendor: "15b3"
    deviceID: "101b"
    rootDevices:
      - "0000:19:00.0"
  linkType: ib
  isRdma: true

L'exemple suivant décrit la configuration d'un périphérique réseau SR-IOV dans une machine virtuelle RHOSP :

Exemple de configuration d'un dispositif SR-IOV dans une machine virtuelle

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-sriov-net-openstack-1
  namespace: openshift-sriov-network-operator
spec:
  resourceName: sriovnic1
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 1 1
  nicSelector:
    vendor: "15b3"
    deviceID: "101b"
    netFilter: "openstack/NetworkID:ea24bd04-8674-4f69-b0ee-fa0b3bd20509" 2

1
Le champ numVfs est toujours défini sur 1 lors de la configuration de la stratégie de réseau de nœuds pour une machine virtuelle.
2
Le champ netFilter doit faire référence à un ID de réseau lorsque la machine virtuelle est déployée sur RHOSP. Les valeurs valides pour netFilter sont disponibles à partir d'un objet SriovNetworkNodeState.

23.4.1.2. Partitionnement des fonctions virtuelles (VF) pour les dispositifs SR-IOV

Dans certains cas, vous pouvez souhaiter répartir les fonctions virtuelles (VF) d'une même fonction physique (PF) dans plusieurs pools de ressources. Par exemple, vous pouvez vouloir que certaines fonctions virtuelles se chargent avec le pilote par défaut et que les autres se chargent avec le pilote vfio-pci. Dans un tel déploiement, le sélecteur pfNames de votre ressource personnalisée (CR) SriovNetworkNodePolicy peut être utilisé pour spécifier une plage de VF pour un pool en utilisant le format suivant : <pfname>#<first_vf>-<last_vf>.

Par exemple, le YAML suivant montre le sélecteur pour une interface nommée netpf0 avec les VF 2 et 7: 

pfNames: ["netpf0#2-7"]
  • netpf0 est le nom de l'interface PF.
  • 2 est le premier indice VF (basé sur 0) qui est inclus dans la plage.
  • 7 est le dernier indice VF (basé sur 0) qui est inclus dans la plage.

Il est possible de sélectionner des VF dans la même CP en utilisant des CR de polices différentes si les conditions suivantes sont remplies :

  • La valeur numVfs doit être identique pour les polices qui sélectionnent la même CP.
  • L'indice VF doit être compris entre 0 et <numVfs>-1. Par exemple, si vous avez une police dont la valeur numVfs est définie sur 8, la valeur <first_vf> ne doit pas être inférieure à 0, et la valeur <last_vf> ne doit pas être supérieure à 7.
  • Les fourchettes de valeurs des différentes politiques ne doivent pas se chevaucher.
  • L'adresse <first_vf> ne doit pas être plus grande que l'adresse <last_vf>.

L'exemple suivant illustre le partitionnement des cartes réseau pour un périphérique SR-IOV.

La politique policy-net-1 définit un pool de ressources net-1 qui contient le VF 0 de PF netpf0 avec le pilote VF par défaut. La politique policy-net-1-dpdk définit un pool de ressources net-1-dpdk qui contient les VF 8 à 15 de la PF netpf0 avec le pilote VF vfio.

Politique policy-net-1: 

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-net-1
  namespace: openshift-sriov-network-operator
spec:
  resourceName: net1
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 16
  nicSelector:
    pfNames: ["netpf0#0-0"]
  deviceType: netdevice

Politique policy-net-1-dpdk: 

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-net-1-dpdk
  namespace: openshift-sriov-network-operator
spec:
  resourceName: net1dpdk
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 16
  nicSelector:
    pfNames: ["netpf0#8-15"]
  deviceType: vfio-pci

Vérification de la réussite du partitionnement de l'interface

Confirmez que l'interface est partitionnée en fonctions virtuelles (VF) pour le périphérique SR-IOV en exécutant la commande suivante. 

ip link show <interface> 1
1
Remplacez <interface> par l'interface que vous avez spécifiée lors du partitionnement en VF pour le périphérique SR-IOV, par exemple, ens3f1.

Exemple de sortie

5: ens3f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 3c:fd:fe:d1:bc:01 brd ff:ff:ff:ff:ff:ff

vf 0     link/ether 5a:e7:88:25:ea:a0 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
vf 1     link/ether 3e:1d:36:d7:3d:49 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
vf 2     link/ether ce:09:56:97:df:f9 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
vf 3     link/ether 5e:91:cf:88:d1:38 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
vf 4     link/ether e6:06:a1:96:2f:de brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off

23.4.2. Configuration des périphériques de réseau SR-IOV

L'opérateur de réseau SR-IOV ajoute la ressource SriovNetworkNodePolicy.sriovnetwork.openshift.io CustomResourceDefinition à OpenShift Container Platform. Vous pouvez configurer un périphérique réseau SR-IOV en créant une ressource personnalisée (CR) SriovNetworkNodePolicy.

Note

Lors de l'application de la configuration spécifiée dans un objet SriovNetworkNodePolicy, l'opérateur SR-IOV peut vidanger les nœuds et, dans certains cas, les redémarrer.

L'application d'une modification de configuration peut prendre plusieurs minutes.

Conditions préalables

  • Vous avez installé l'OpenShift CLI (oc).
  • Vous avez accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.
  • Vous avez installé l'opérateur de réseau SR-IOV.
  • Vous avez suffisamment de nœuds disponibles dans votre cluster pour gérer la charge de travail expulsée des nœuds épuisés.
  • Vous n'avez sélectionné aucun nœud du plan de contrôle pour la configuration des équipements du réseau SR-IOV.

Procédure

  1. Créez un objet SriovNetworkNodePolicy, puis enregistrez le YAML dans le fichier <name>-sriov-node-network.yaml. Remplacez <name> par le nom de cette configuration.
  2. Facultatif : Étiqueter les nœuds de cluster compatibles SR-IOV avec SriovNetworkNodePolicy.Spec.NodeSelector s'ils ne le sont pas déjà. Pour plus d'informations sur l'étiquetage des nœuds, voir "Understanding how to update labels on nodes".

  3. Créer l'objet SriovNetworkNodePolicy: 

    oc create -f <name>-sriov-node-network.yaml

    où <name> spécifie le nom de cette configuration.

    Après l'application de la mise à jour de la configuration, tous les pods de l'espace de noms sriov-network-operator passent à l'état Running.

  4. Pour vérifier que le dispositif de réseau SR-IOV est configuré, entrez la commande suivante. Remplacez <node_name> par le nom d'un nœud avec le dispositif de réseau SR-IOV que vous venez de configurer. 

    oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'

Ressources supplémentaires

23.4.3. Dépannage de la configuration SR-IOV

Après avoir suivi la procédure de configuration d'un périphérique de réseau SR-IOV, les sections suivantes traitent de certaines conditions d'erreur.

Pour afficher l'état des nœuds, exécutez la commande suivante : 

oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name>

où : <node_name> indique le nom d'un nœud doté d'un dispositif de réseau SR-IOV.

Sortie d'erreur : Impossible d'allouer de la mémoire

"lastSyncError": "write /sys/bus/pci/devices/0000:3b:00.1/sriov_numvfs: cannot allocate memory"

Lorsqu'un nœud indique qu'il ne peut pas allouer de mémoire, vérifiez les éléments suivants :

  • Confirmez que les paramètres SR-IOV globaux sont activés dans le BIOS du nœud.
  • Confirmez que VT-d est activé dans le BIOS du nœud.

23.4.4. Affectation d'un réseau SR-IOV à un VRF

En tant qu'administrateur de cluster, vous pouvez affecter une interface réseau SR-IOV à votre domaine VRF en utilisant le plugin CNI VRF.

Pour ce faire, ajoutez la configuration VRF au paramètre facultatif metaPlugins de la ressource SriovNetwork.

Note

Les applications qui utilisent les VRF doivent se lier à un périphérique spécifique. L'usage courant est d'utiliser l'option SO_BINDTODEVICE pour une socket. SO_BINDTODEVICE lie la socket à un périphérique spécifié dans le nom de l'interface passée, par exemple, eth1. Pour utiliser SO_BINDTODEVICE, l'application doit avoir les capacités de CAP_NET_RAW.

L'utilisation d'une VRF via la commande ip vrf exec n'est pas prise en charge dans les pods OpenShift Container Platform. Pour utiliser la VRF, liez les applications directement à l'interface VRF.

23.4.4.1. Création d'un attachement réseau SR-IOV supplémentaire avec le plugin CNI VRF

L'opérateur de réseau SR-IOV gère les définitions de réseaux supplémentaires. Lorsque vous indiquez un réseau SR-IOV supplémentaire à créer, l'opérateur de réseau SR-IOV crée automatiquement la ressource personnalisée (CR) NetworkAttachmentDefinition.

Note

Ne modifiez pas les ressources personnalisées NetworkAttachmentDefinition gérées par l'opérateur de réseau SR-IOV. Cela pourrait perturber le trafic sur votre réseau supplémentaire.

Pour créer un attachement réseau SR-IOV supplémentaire avec le plugin CNI VRF, suivez la procédure suivante.

Conditions préalables

  • Installez le CLI (oc) de OpenShift Container Platform.
  • Connectez-vous au cluster OpenShift Container Platform en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

  1. Créez la ressource personnalisée (CR) SriovNetwork pour l'attachement supplémentaire au réseau SR-IOV et insérez la configuration metaPlugins, comme dans l'exemple de CR suivant. Enregistrez le YAML dans le fichier sriov-network-attachment.yaml. 

    apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: example-network
  namespace: additional-sriov-network-1
spec:
  ipam: |
    {
      "type": "host-local",
      "subnet": "10.56.217.0/24",
      "rangeStart": "10.56.217.171",
      "rangeEnd": "10.56.217.181",
      "routes": [{
        "dst": "0.0.0.0/0"
      }],
      "gateway": "10.56.217.1"
    }
  vlan: 0
  resourceName: intelnics
  metaPlugins : |
    {
      "type": "vrf", 1
      "vrfname": "example-vrf-name" 2
    }
    1
    type doit être réglé sur vrf.
    2
    vrfname est le nom du VRF auquel l'interface est assignée. S'il n'existe pas dans le pod, il est créé.

  2. Créer la ressource SriovNetwork: 

    $ oc create -f sriov-network-attachment.yaml

Vérification de la création de la CR NetworkAttachmentDefinition

  • Confirmez que l'opérateur du réseau SR-IOV a créé le CR NetworkAttachmentDefinition en exécutant la commande suivante. 

    oc get network-attachment-definitions -n <namespace> 1
    1
    Remplacez <namespace> par l'espace de noms que vous avez spécifié lors de la configuration de l'attachement au réseau, par exemple, additional-sriov-network-1.

    Exemple de sortie

    NAME                            AGE
additional-sriov-network-1      14m

    Note

    Il peut y avoir un délai avant que l'opérateur du réseau SR-IOV ne crée le CR.

Vérification de la réussite de l'attachement au réseau SR-IOV supplémentaire

Pour vérifier que le VRF CNI est correctement configuré et que l'attachement réseau SR-IOV supplémentaire est attaché, procédez comme suit :

  1. Créer un réseau SR-IOV qui utilise la VRF CNI.
  2. Attribuer le réseau à un pod.

  3. Vérifiez que l'attachement réseau du pod est connecté au réseau supplémentaire SR-IOV. Connectez-vous à distance au pod et exécutez la commande suivante : 

    $ ip vrf show

    Exemple de sortie

    Name              Table
-----------------------
red                 10

  4. Confirmez que l'interface VRF est maître de l'interface secondaire : 

    $ ip link

    Exemple de sortie

    ...
5: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master red state UP mode
...

23.4.5. Prochaines étapes

Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.