La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Bonnes pratiques pour déployer des machines virtuelles dans Red Hat OpenShift Virtualization

08/18/2025 Contributeurs

Découvrez les meilleures pratiques pour déployer de nouvelles machines virtuelles dans OpenShift Virtualization et importer des machines virtuelles existantes à partir d’un VMware vSphere dans OpenShift Virtualization sur une plate-forme de conteneurs OpenShift.

Performances de la machine virtuelle

Lors de la création d'une nouvelle machine virtuelle dans OpenShift Virtualization, vous devez prendre en compte le modèle d'accès ainsi que les exigences de performances (IOP et débit) de la charge de travail qui s'exécutera sur la machine virtuelle. Cela influencera le nombre de machines virtuelles que vous devrez exécuter sur la plateforme OpenShift Virtualization dans un conteneur OpenShift et le type de stockage que vous devez utiliser pour les disques de machines virtuelles.

Le type de stockage que vous souhaitez choisir pour vos disques VM est influencé par les facteurs suivants :

L'accès au protocole dont vous avez besoin pour accéder aux données de vos charges de travail
Les modes d'accès dont vous avez besoin (RWO vs RWX)
Les caractéristiques de performance dont vous avez besoin pour vos charges de travail

Consultez la section Configuration du stockage ci-dessous pour plus de détails.

Haute disponibilité des charges de travail des machines virtuelles

OpenShift Virtualization prend en charge les migrations en direct d'une machine virtuelle. La migration en direct permet à une instance de machine virtuelle (VMI) en cours d’exécution de se déplacer vers un autre nœud sans interrompre la charge de travail. La migration peut être utile pour une transition en douceur lors des mises à niveau du cluster ou à chaque fois qu'un nœud doit être vidé pour des raisons de maintenance ou de modification de configuration. La migration en direct nécessite l’utilisation d’une solution de stockage partagé qui fournit le mode d’accès ReadWriteMany (RWX). Les disques VM doivent être sauvegardés par une option de stockage qui fournit le mode d'accès RWX. OpenShift Virtualization vérifiera qu'un VMI est migrable en direct et si tel est le cas, evictionStrategy sera défini sur LiveMigrate. Voir"À propos de la section sur la migration en direct dans la documentation Red Hat" pour plus de détails.

Il est important d'utiliser un pilote prenant en charge le mode d'accès RWX. Consultez la section Configuration du stockage ci-dessous pour plus de détails sur les pilotes ONTAP qui prennent en charge le mode d'accès RWX.

Configuration de stockage

Le provisionneur Trident CSI fournit plusieurs pilotes (nas, nas-economy, nas-flexgroup, san et san-economy) pour provisionner le stockage soutenu par les options de stockage NetApp .

Protocoles utilisés : * les pilotes NAS utilisent les protocoles NAS (NFS et SMB) * les pilotes SAN utilisent le protocole iSCSI ou NVMe/TCP

Les éléments suivants peuvent vous aider à décider de la configuration de stockage souhaitée en fonction des exigences de charge de travail et de l’utilisation du stockage.

Le pilote nas crée un volume persistant (PV) sur un FlexVolume.
Le pilote nas-economy crée un PV sur un qtree sur un FlexVolume partagé. (un FlexVolume pour 200 PV, configurable entre 50 et 300)
Le pilote nas-flexgroup est créé sur un PV sur un FlexGroup
le pilote san crée un PV sur LUN sur un FlexVolume dédié
Le pilote san-economy crée un PV sur LUN sur FlexVolume partagé (un FlexVolume pour 100 PV, configurable entre 50 et 200)

Le diagramme suivant illustre cela.

De plus, les modes d’accès pris en charge par les pilotes diffèrent.

ONTAP en charge des pilotes NAS ONTAP**
- Accès au système de fichiers et modes d'accès RWO, ROX, RWX, RWOP.
Les pilotes SAN ONTAP prennent en charge les modes bloc brut ainsi que système de fichiers**
- En mode bloc brut, il peut prendre en charge les modes d'accès RWO, ROX, RWX, RWOP.
- En mode système de fichiers, seuls les modes d'accès RWO et RWOP sont autorisés.

La migration en direct des machines virtuelles de virtualisation OpenShift nécessite que les disques disposent de modes d'accès RWX. Il est donc important de choisir des pilotes NAS ou des pilotes SAN en mode volume de bloc brut pour créer des PVC et des PV soutenus par ONTAP.

Meilleures pratiques de configuration du stockage

Machines virtuelles de stockage dédiées (SVM)

Les machines virtuelles de stockage (SVM) fournissent une isolation et une séparation administrative entre les locataires sur un système ONTAP . Dédier une SVM aux conteneurs OpenShift et aux machines virtuelles de virtualisation OpenShift permet la délégation de privilèges et permet d'appliquer les meilleures pratiques pour limiter la consommation de ressources.

Limiter le nombre maximal de volumes sur le SVM

Pour empêcher Trident de consommer tous les volumes disponibles sur le système de stockage, vous devez définir une limite sur le SVM. Vous pouvez le faire à partir de la ligne de commande :

vserver modify -vserver <svm_name> -max-volumes <num_of_volumes>

La valeur max-volumes correspond au total des volumes provisionnés sur tous les nœuds du cluster ONTAP , et non sur un nœud ONTAP individuel. Par conséquent, vous pouvez rencontrer certaines conditions dans lesquelles un nœud de cluster ONTAP peut avoir beaucoup plus ou moins de volumes provisionnés Trident qu'un autre nœud. Pour éviter cela, assurez-vous qu'un nombre égal d'agrégats de chaque nœud du cluster sont attribués au SVM utilisé par Trident.

Limiter la taille maximale des volumes créés par Trident

Vous pouvez définir une limite de taille de volume maximale par SVM dans ONTAP:

Créez le SVM avec la commande vserver create et définissez la limite de stockage :

vserver create -vserver vserver_name -aggregate aggregate_name -rootvolume root_volume_name -rootvolume-security-style {unix|ntfs|mixed} -storage-limit value

Pour modifier la limite de stockage sur une SVM existante :

vserver modify -vserver vserver_name -storage-limit value -storage-limit-threshold-alert percentage

Les limites de stockage ne peuvent pas être configurées pour un SVM contenant des volumes de protection des données, des volumes dans une relation SnapMirror ou dans une configuration MetroCluster .

En plus de contrôler la taille du volume au niveau de la baie de stockage, vous devez également exploiter les fonctionnalités de Kubernetes.

Pour configurer la taille maximale des volumes pouvant être créés par Trident, utilisez le paramètre limitVolumeSize dans votre définition backend.json.
Pour configurer la taille maximale des FlexVols utilisés comme pools pour les pilotes ontap-san-economy et ontap-nas-economy, utilisez le paramètre limitVolumePoolSize dans votre définition backend.json.

Utiliser la politique QOS SVM

Appliquez la politique de qualité de service (QoS) au SVM pour limiter le nombre d'IOPS consommables par les volumes provisionnés Trident . Cela permet d'éviter que les charges de travail utilisant le stockage provisionné Trident n'affectent les charges de travail en dehors du SVM Trident .

Les groupes de politiques QoS ONTAP fournissent des options QoS pour les volumes et permettent aux utilisateurs de définir le plafond de débit pour une ou plusieurs charges de travail. Pour plus d'informations sur les groupes de politiques QoS, reportez-vous à"Commandes QoS ONTAP 9.15"

Limiter l'accès aux ressources de stockage aux membres du cluster Kubernetes

Utiliser les espaces de noms Limiter l’accès aux volumes NFS et aux LUN iSCSI créés par Trident est un élément essentiel de la posture de sécurité de votre déploiement Kubernetes. Cela empêche les hôtes qui ne font pas partie du cluster Kubernetes d’accéder aux volumes et de modifier potentiellement les données de manière inattendue.

De plus, un processus dans un conteneur peut accéder au stockage monté sur l'hôte, mais qui n'est pas destiné au conteneur. L’utilisation d’espaces de noms pour fournir une limite logique aux ressources peut éviter ce problème. Cependant,

Il est important de comprendre que les espaces de noms constituent la limite logique des ressources dans Kubernetes. Il est donc essentiel de veiller à ce que les espaces de noms soient utilisés pour assurer la séparation lorsque cela est approprié. Cependant, les conteneurs privilégiés fonctionnent avec des autorisations au niveau de l'hôte nettement plus importantes que la normale. Alors, désactivez cette fonctionnalité en utilisant"politiques de sécurité des pods" .

Utiliser une politique d'exportation dédiée Pour les déploiements OpenShift qui ont des nœuds d'infrastructure dédiés ou d'autres nœuds qui ne peuvent pas planifier les applications utilisateur, des politiques d'exportation distinctes doivent être utilisées pour limiter davantage l'accès aux ressources de stockage. Cela inclut la création d'une politique d'exportation pour les services déployés sur ces nœuds d'infrastructure (par exemple, les services de métriques et de journalisation OpenShift) et les applications standard déployées sur des nœuds non infrastructurels.

Trident peut créer et gérer automatiquement des politiques d’exportation. De cette façon, Trident limite l’accès aux volumes qu’il provisionne aux nœuds du cluster Kubernetes et simplifie l’ajout/la suppression de nœuds.

Mais si vous choisissez de créer une politique d’exportation manuellement, remplissez-la avec une ou plusieurs règles d’exportation qui traitent chaque demande d’accès au nœud.

Désactiver showmount pour l'application SVM Un pod déployé sur le cluster Kubernetes peut émettre la commande showmount -e sur le LIF de données et recevoir une liste des montages disponibles, y compris ceux auxquels il n'a pas accès. Pour éviter cela, désactivez la fonctionnalité showmount à l'aide de l'interface de ligne de commande suivante :

vserver nfs modify -vserver <svm_name> -showmount disabled

Pour plus de détails sur les meilleures pratiques en matière de configuration du stockage et d'utilisation de Trident , consultez"Documentation Trident"

Guide de virtualisation OpenShift - Réglage et mise à l'échelle

Red Hat a documenté"Recommandations et limitations de mise à l'échelle du cluster OpenShift" .

En outre, ils ont également documenté"Guide de réglage de la virtualisation OpenShift" et"Limites prises en charge pour OpenShift Virtualization 4.x" .

Un abonnement Red Hat actif est requis pour accéder au contenu ci-dessus.

Le guide de réglage contient des informations sur de nombreux paramètres de réglage, notamment :

Réglage des paramètres pour créer plusieurs machines virtuelles à la fois ou par lots importants
Migration en direct de machines virtuelles
"Configuration d'un réseau dédié pour la migration en direct"
Personnalisation d'un modèle de machine virtuelle en incluant un type de charge de travail

Les limites prises en charge documentent les valeurs maximales des objets testés lors de l'exécution de machines virtuelles sur OpenShift

Maximums de machines virtuelles inclus

Nombre maximal de CPU virtuels par machine virtuelle
Mémoire maximale et minimale par machine virtuelle
Taille maximale d'un disque unique par machine virtuelle
Nombre maximal de disques connectables à chaud par machine virtuelle

Nombre maximal d'hôtes incluant * Migrations en direct simultanées (par nœud et par cluster)

Nombre maximal de clusters incluant *Nombre maximal de machines virtuelles définies

Migration de machines virtuelles depuis un environnement VMware

Migration ToolKit pour OpenShift Virtualization est un opérateur fourni par Red Hat disponible sur l'OperatorHub de la plateforme de conteneurs OpenShift. Cet outil peut être utilisé pour migrer des machines virtuelles depuis vSphere, Red Hat Virtualization, OpenStack et OpenShift Virtualization.

Vous trouverez des détails sur la migration des machines virtuelles depuis VSphere sous"Flux de travail > Virtualisation Red Hat OpenShift avec NetApp ONTAP"

Vous pouvez configurer des limites pour divers paramètres à partir de l'interface de ligne de commande ou de la console Web de migration. Quelques exemples sont donnés ci-dessous

Nombre maximal de migrations simultanées de machines virtuelles Définit le nombre maximal de machines virtuelles pouvant être migrées simultanément. La valeur par défaut est de 20 machines virtuelles.
Intervalle de précopie (minutes) Contrôle l'intervalle auquel un nouvel instantané est demandé avant de lancer une migration à chaud. La valeur par défaut est de 60 minutes.
Intervalle d'interrogation des instantanés (secondes) Détermine la fréquence à laquelle le système vérifie l'état de la création ou de la suppression des instantanés pendant la migration à chaud d'oVirt. La valeur par défaut est de 10 secondes.

Si vous migrez plus de 10 machines virtuelles à partir d’un hôte ESXi dans le même plan de migration, vous devez augmenter la mémoire du service NFC de l’hôte. Sinon, la migration échouera car la mémoire du service NFC est limitée à 10 connexions parallèles. Pour plus de détails, consultez la documentation Red Hat :"Augmenter la mémoire du service NFC d'un hôte ESXi"

Voici une migration parallèle réussie de 10 machines virtuelles du même hôte dans VSphere vers OpenShift Virtualization à l'aide de Migration Toolkit for Virtualization.

VM sur le même hôte ESXi