Rechercher

23.12. Configuration du délestage matériel

download PDF

En tant qu'administrateur de cluster, vous pouvez configurer le délestage matériel sur les nœuds compatibles afin d'augmenter les performances de traitement des données et de réduire la charge sur les processeurs hôtes.

23.12.1. À propos du délestage matériel

Le déchargement matériel Open vSwitch est une méthode de traitement des tâches réseau qui consiste à les détourner de l'unité centrale et à les décharger sur un processeur dédié sur un contrôleur d'interface réseau. Les clusters peuvent ainsi bénéficier de vitesses de transfert de données plus rapides, d'une réduction de la charge de travail de l'unité centrale et d'une baisse des coûts informatiques.

L'élément clé de cette fonctionnalité est une classe moderne de contrôleurs d'interface réseau connus sous le nom de SmartNIC. Un SmartNIC est un contrôleur d'interface réseau capable de gérer des tâches de traitement réseau lourdes en termes de calcul. De la même manière qu'une carte graphique dédiée peut améliorer les performances graphiques, un SmartNIC peut améliorer les performances du réseau. Dans chaque cas, un processeur dédié améliore les performances pour un type spécifique de tâche de traitement.

Dans OpenShift Container Platform, vous pouvez configurer le délestage matériel pour les nœuds bare metal qui ont un SmartNIC compatible. Le délestage matériel est configuré et activé par l'opérateur du réseau SR-IOV.

Le délestage matériel n'est pas compatible avec toutes les charges de travail ou tous les types d'application. Seuls les deux types de communication suivants sont pris en charge :

  • de pod à pod
  • pod-to-service, où le service est un service ClusterIP soutenu par un pod régulier

Dans tous les cas, le délestage matériel n'a lieu que lorsque les pods et les services sont affectés à des nœuds dotés d'un SmartNIC compatible. Supposons, par exemple, qu'un module sur un nœud avec délestage matériel essaie de communiquer avec un service sur un nœud normal. Sur le nœud normal, tout le traitement a lieu dans le noyau, de sorte que les performances globales de la communication entre le pod et le service sont limitées aux performances maximales de ce nœud normal. Le déchargement matériel n'est pas compatible avec les applications DPDK.

Le fait d'activer le délestage matériel sur un nœud, mais de ne pas configurer les pods pour qu'ils l'utilisent, peut entraîner une diminution des performances de débit pour le trafic des pods. Vous ne pouvez pas configurer le délestage matériel pour les pods qui sont gérés par OpenShift Container Platform.

23.12.2. Dispositifs pris en charge

Le délestage matériel est pris en charge par les contrôleurs d'interface réseau suivants :

Tableau 23.15. Contrôleurs d'interface réseau pris en charge
FabricantModelID du vendeurID de l'appareil

Mellanox

Famille MT27800 [ConnectX-5]

15b3

1017

Mellanox

Famille MT28880 [ConnectX-5 Ex]

15b3

1019

Tableau 23.16. Technologie Aperçu des contrôleurs d'interface réseau
FabricantModelID du vendeurID de l'appareil

Mellanox

Famille MT2892 [ConnectX-6 Dx]

15b3

101d

Mellanox

Famille MT2894 [ConnectX-6 Lx]

15b3

101f

Mellanox

MT42822 BlueField-2 en mode NIC ConnectX-6

15b3

a2d6

Important

L'utilisation d'un périphérique ConnectX-6 Lx ou BlueField-2 en mode ConnectX-6 NIC est une fonctionnalité d'aperçu technologique uniquement. Les fonctionnalités de l'aperçu technologique ne sont pas prises en charge par les accords de niveau de service (SLA) de production de Red Hat et peuvent ne pas être complètes sur le plan fonctionnel. Red Hat ne recommande pas de les utiliser en production. Ces fonctionnalités offrent un accès anticipé aux fonctionnalités des produits à venir, ce qui permet aux clients de tester les fonctionnalités et de fournir un retour d'information pendant le processus de développement.

Pour plus d'informations sur la portée de l'assistance des fonctionnalités de l'aperçu technologique de Red Hat, voir Portée de l'assistance des fonctionnalités de l'aperçu technologique.

23.12.3. Conditions préalables

23.12.4. Configuration d'un pool de configuration de machines pour le délestage matériel

Pour activer le délestage matériel, vous devez d'abord créer un pool de configuration machine dédié et le configurer pour qu'il fonctionne avec l'opérateur de réseau SR-IOV.

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.

Procédure

  1. Créez un pool de configuration pour les machines sur lesquelles vous souhaitez utiliser le délestage matériel.

    1. Créez un fichier, tel que mcp-offloading.yaml, dont le contenu ressemble à l'exemple suivant :

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfigPool
      metadata:
        name: mcp-offloading 1
      spec:
        machineConfigSelector:
          matchExpressions:
            - {key: machineconfiguration.openshift.io/role, operator: In, values: [worker,mcp-offloading]} 2
        nodeSelector:
          matchLabels:
            node-role.kubernetes.io/mcp-offloading: "" 3
      1 2
      Le nom du pool de configuration de la machine pour le délestage matériel.
      3
      Cette étiquette de rôle de nœud est utilisée pour ajouter des nœuds au pool de configuration de la machine.
    2. Appliquer la configuration pour le pool de configuration de la machine :

      $ oc create -f mcp-offloading.yaml
  2. Ajoutez des nœuds au pool de configuration de machines. Étiqueter chaque nœud avec l'étiquette de rôle de nœud de votre pool :

    $ oc label node worker-2 node-role.kubernetes.io/mcp-offloading=""
  3. Facultatif : Pour vérifier que le nouveau pool est créé, exécutez la commande suivante :

    $ oc get nodes

    Exemple de sortie

    NAME       STATUS   ROLES                   AGE   VERSION
    master-0   Ready    master                  2d    v1.25.0
    master-1   Ready    master                  2d    v1.25.0
    master-2   Ready    master                  2d    v1.25.0
    worker-0   Ready    worker                  2d    v1.25.0
    worker-1   Ready    worker                  2d    v1.25.0
    worker-2   Ready    mcp-offloading,worker   47h   v1.25.0
    worker-3   Ready    mcp-offloading,worker   47h   v1.25.0

  4. Ajouter ce pool de configuration machine à la ressource personnalisée SriovNetworkPoolConfig:

    1. Créez un fichier, tel que sriov-pool-config.yaml, dont le contenu ressemble à l'exemple suivant :

      apiVersion: sriovnetwork.openshift.io/v1
      kind: SriovNetworkPoolConfig
      metadata:
        name: sriovnetworkpoolconfig-offload
        namespace: openshift-sriov-network-operator
      spec:
        ovsHardwareOffloadConfig:
          name: mcp-offloading 1
      1
      Le nom du pool de configuration de la machine pour le délestage matériel.
    2. Appliquer la configuration :

      oc create -f <SriovNetworkPoolConfig_name>.yaml
      Note

      Lorsque vous appliquez la configuration spécifiée dans un objet SriovNetworkPoolConfig, l'opérateur SR-IOV vide et redémarre les nœuds du pool de configuration de la machine.

      L'application des changements de configuration peut prendre plusieurs minutes.

23.12.5. Configuration de la politique des nœuds de réseau SR-IOV

Vous pouvez créer une configuration de dispositif de réseau SR-IOV pour un nœud en créant une stratégie de nœud de réseau SR-IOV. Pour activer le délestage matériel, vous devez définir le champ .spec.eSwitchMode avec la valeur "switchdev".

La procédure suivante permet de créer une interface SR-IOV pour un contrôleur d'interface réseau avec délestage matériel.

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.

Procédure

  1. Créez un fichier, tel que sriov-node-policy.yaml, dont le contenu ressemble à l'exemple suivant :

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovNetworkNodePolicy
    metadata:
      name: sriov-node-policy <.>
      namespace: openshift-sriov-network-operator
    spec:
      deviceType: netdevice <.>
      eSwitchMode: "switchdev" <.>
      nicSelector:
        deviceID: "1019"
        rootDevices:
        - 0000:d8:00.0
        vendor: "15b3"
        pfNames:
        - ens8f0
      nodeSelector:
        feature.node.kubernetes.io/network-sriov.capable: "true"
      numVfs: 6
      priority: 5
      resourceName: mlxnics

    <.> Nom de l'objet ressource personnalisé. <.> Requis. Le délestage matériel n'est pas pris en charge par vfio-pci<.> Requis.

  2. Appliquer la configuration de la politique :

    $ oc create -f sriov-node-policy.yaml
    Note

    Lorsque vous appliquez la configuration spécifiée dans un objet SriovNetworkPoolConfig, l'opérateur SR-IOV vide et redémarre les nœuds du pool de configuration de la machine.

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

23.12.5.1. Exemple de politique de nœuds de réseau SR-IOV pour OpenStack

L'exemple suivant décrit une interface SR-IOV pour un contrôleur d'interface réseau (NIC) avec déchargement matériel sur Red Hat OpenStack Platform (RHOSP).

Une interface SR-IOV pour une carte d'interface réseau avec délestage matériel sur RHOSP

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: ${name}
  namespace: openshift-sriov-network-operator
spec:
  deviceType: switchdev
  isRdma: true
  nicSelector:
    netFilter: openstack/NetworkID:${net_id}
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: 'true'
  numVfs: 1
  priority: 99
  resourceName: ${name}

23.12.6. Création d'une définition de pièce jointe au réseau

Après avoir défini le pool de configuration machine et la stratégie de nœuds de réseau SR-IOV, vous pouvez créer une définition d'attachement réseau pour la carte d'interface réseau que vous avez spécifiée.

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.

Procédure

  1. Créez un fichier, tel que net-attach-def.yaml, dont le contenu ressemble à l'exemple suivant :

    apiVersion: "k8s.cni.cncf.io/v1"
    kind: NetworkAttachmentDefinition
    metadata:
      name: net-attach-def <.>
      namespace: net-attach-def <.>
      annotations:
        k8s.v1.cni.cncf.io/resourceName: openshift.io/mlxnics <.>
    spec:
      config: '{"cniVersion":"0.3.1","name":"ovn-kubernetes","type":"ovn-k8s-cni-overlay","ipam":{},"dns":{}}'

    <.> Le nom de la définition de la pièce jointe au réseau. <.> L'espace de noms pour votre définition de pièce jointe au réseau. <.> Il s'agit de la valeur du champ spec.resourceName que vous avez spécifiée dans l'objet SriovNetworkNodePolicy.

  2. Appliquer la configuration pour la définition de l'attachement au réseau :

    $ oc create -f net-attach-def.yaml

Vérification

  • Exécutez la commande suivante pour vérifier si la nouvelle définition est présente :

    $ oc get net-attach-def -A

    Exemple de sortie

    NAMESPACE         NAME             AGE
    net-attach-def    net-attach-def   43h

23.12.7. Ajouter la définition de l'attachement réseau à vos pods

Après avoir créé le pool de configuration machine, les ressources personnalisées SriovNetworkPoolConfig et SriovNetworkNodePolicy et la définition de l'attachement au réseau, vous pouvez appliquer ces configurations à vos modules en ajoutant la définition de l'attachement au réseau aux spécifications de votre module.

Procédure

  • Dans la spécification du pod, ajoutez le champ .metadata.annotations.k8s.v1.cni.cncf.io/networks et indiquez la définition de l'attachement réseau que vous avez créée pour le déchargement matériel :

    ....
    metadata:
      annotations:
        v1.multus-cni.io/default-network: net-attach-def/net-attach-def <.>

    <.> La valeur doit être le nom et l'espace de noms de la définition de l'attachement réseau que vous avez créée pour le déchargement matériel.

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.