Skip to main content
Enterprise applications
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Infrastructure de stockage Hyper-V sur NetApp

Contributeurs
PDF

Une infrastructure de stockage Hyper-V peut être hébergée sur des systèmes de stockage ONTAP. Le stockage d'Hyper-V pour stocker les fichiers de la machine virtuelle et ses disques peut être fourni à l'aide de LUN NetApp ou de partages CIFS NetApp, comme illustré dans la figure ci-dessous.

Infrastructure de stockage Hyper-V sur NetApp, largeur=624, hauteur=338

Stockage Hyper-V sur LUN NetApp

  • Provisionner un LUN NetApp sur le serveur Hyper-V. Pour plus d'informations, reportez-vous à la section «"Le provisionnement dans des environnements SAN"."

  • Ouvrez Hyper-V Manager dans la section Outils de Server Manager.

  • Sélectionnez le serveur Hyper-V et cliquez sur Paramètres Hyper-V.

  • Spécifiez le dossier par défaut pour stocker la machine virtuelle et son disque en tant que LUN. Le chemin par défaut est alors défini comme LUN pour le stockage Hyper-V. Si vous souhaitez spécifier explicitement le chemin d'accès à une machine virtuelle, vous pouvez le faire lors de la création de la machine virtuelle.

Stockage Hyper-V sur NetApp CIFS

Avant de commencer les étapes énumérées dans cette section, passez en revue la section «"Le provisionnement dans les environnements SMB"." Pour configurer le stockage Hyper-V sur le partage CIFS NetApp, effectuez les opérations suivantes :

  1. Ouvrez Hyper-V Manager dans la section Outils de Server Manager.

  2. Sélectionnez le serveur Hyper-V et cliquez sur Paramètres Hyper-V.

  3. Spécifiez le dossier par défaut pour stocker la machine virtuelle et son disque en tant que partage CIFS. Le chemin par défaut est alors défini comme partage CIFS pour le stockage Hyper-V. Si vous souhaitez spécifier explicitement le chemin d'accès à une machine virtuelle, vous pouvez le faire lors de la création de la machine virtuelle.

Chaque machine virtuelle d'Hyper-V peut à son tour être fournie avec les LUN NetApp et les partages CIFS fournis à l'hôte physique. Cette procédure est la même que pour tout hôte physique. Les méthodes suivantes peuvent être utilisées pour provisionner du stockage sur une VM :

  • Ajout d'une LUN de stockage à l'aide de l'initiateur FC au sein de la machine virtuelle

  • Ajout d'une LUN de stockage à l'aide de l'initiateur iSCSI dans la machine virtuelle

  • Ajout d'un disque physique pass-through à une machine virtuelle

  • Ajout de VHD/VHDX à une machine virtuelle à partir de l'hôte

Et des meilleures pratiques

  • Lorsqu'un serveur virtuel et ses données sont stockés sur un système de stockage NetApp, NetApp recommande d'exécuter régulièrement la déduplication NetApp au niveau du volume. Cette pratique permet de réaliser d'importantes économies d'espace lorsque des machines virtuelles identiques sont hébergées sur un partage CSV ou SMB. La déduplication s'exécute sur le contrôleur de stockage et n'affecte pas le système hôte ni les performances des machines virtuelles.

  • Lorsque vous utilisez des LUN iSCSI pour Hyper-V, assurez-vous de les activer iSCSI Service (TCP-In) for Inbound et iSCSI Service (TCP-Out) for Outbound Dans les paramètres du pare-feu sur l'hôte Hyper-V. Le trafic iSCSI peut ainsi passer de et vers l'hôte Hyper-V et le contrôleur NetApp.

  • NetApp recommande de décocher l'option Autoriser le système d'exploitation de gestion à partager cette carte réseau pour le commutateur virtuel Hyper-V. Cela crée un réseau dédié pour les machines virtuelles.

Choses à retenir

  • Le provisionnement d'une machine virtuelle à l'aide de la technologie Fibre Channel virtuelle requiert un N_Port ID Virtualisationâ€"Enabled FC HBA. Quatre ports FC au maximum sont pris en charge.

  • Si le système hôte est configuré avec plusieurs ports FC et présenté à la machine virtuelle, MPIO doit être installé dans la machine virtuelle pour activer les chemins d'accès multiples.

  • Les disques directs ne peuvent pas être provisionnés vers l'hôte si MPIO est utilisé sur cet hôte, car les disques directs ne prennent pas en charge MPIO.

  • Le disque utilisé pour les fichiers VHD/VHDx doit utiliser un formatage de 64 Ko pour l'allocation.

Lecture ultérieure

Transfert de données allégé

Microsoft ODX, également appelé allègement de la charge des copies, permet des transferts directs de données au sein d'un dispositif de stockage ou entre des dispositifs de stockage compatibles sans transférer les données via l'ordinateur hôte. ONTAP prend en charge la fonction ODX pour les protocoles CIFS et SAN. ODX peut améliorer les performances si les copies se trouvent dans le même volume, réduire l'utilisation du processeur et de la mémoire sur le client et réduire l'utilisation de la bande passante des E/S réseau.

Avec ODX, il est plus rapide et efficace de copier des fichiers au sein des partages SMB, au sein des LUN et entre les partages SMB et les LUN s'ils se trouvent dans le même volume. Cette approche s'avère plus utile dans le cas où plusieurs copies de l'image de référence d'un système d'exploitation (VHD/VHDX) sont requises au sein du même volume. Plusieurs copies de la même image de référence peuvent être réalisées en beaucoup moins de temps si les copies se trouvent dans le même volume. ODX est également appliqué à la migration dynamique du stockage Hyper-V pour le déplacement du stockage des machines virtuelles.

Si la copie se trouve sur plusieurs volumes, les performances peuvent ne pas être nettement supérieures à celles des copies basées sur l'hôte.

Pour activer la fonction ODX sur CIFS, exécutez les commandes CLI suivantes sur le contrôleur de stockage NetApp :

  1. Activez ODX pour CIFS.
    #définissez le niveau de privilège sur diagnostic
    cluster:> diagnostic set -privilege

    #enable the odx feature
cluster::> vserver cifs options modify -vserver <vserver_name> -copy-offload-enabled true
    #return to admin privilege level
cluster::> set privilege admin

  2. Pour activer la fonction ODX sur SAN, exécutez les commandes CLI suivantes sur le contrôleur de stockage NetApp :
    #définissez le niveau de privilège sur diagnostic
    cluster:> diagnostic set -privilege

    #enable the odx feature
cluster::> copy-offload modify -vserver <vserver_name> -scsi enabled
    #return to admin privilege level
cluster::> set privilege admin

Choses à retenir

  • Pour CIFS, ODX est disponible uniquement lorsque le client et le serveur de stockage prennent en charge SMB 3.0 et la fonction ODX.

  • Pour les environnements SAN, ODX est disponible uniquement lorsque le client et le serveur de stockage prennent en charge la fonctionnalité ODX.

Lecture ultérieure

Pour plus d'informations sur ODX, voir "Amélioration des performances de Microsoft Remote Copy" et "Transferts de données allégés par Microsoft" .

Mise en cluster Hyper-V : haute disponibilité et évolutivité pour les machines virtuelles

Les clusters de basculement offrent une haute disponibilité et une évolutivité aux serveurs Hyper-V. Un cluster de basculement est un groupe de serveurs Hyper-V indépendants qui fonctionnent ensemble pour améliorer la disponibilité et l'évolutivité des machines virtuelles.

Les serveurs en cluster Hyper-V (appelés nœuds) sont connectés par le réseau physique et par un logiciel de cluster. Ces nœuds utilisent un stockage partagé pour stocker les fichiers de la machine virtuelle, notamment les fichiers de configuration, les fichiers des disques durs virtuels (VHD) et les copies Snapshot. Le stockage partagé peut être un partage SMB/CIFS NetApp ou un fichier CSV sur un LUN NetApp, comme illustré ci-dessous. Ce stockage partagé fournit un namespace cohérent et distribué auquel tous les nœuds du cluster peuvent accéder simultanément. Par conséquent, si un nœud tombe en panne dans le cluster, l'autre nœud assure le service par un processus appelé basculement. Les clusters de basculement peuvent être gérés à l'aide du composant logiciel enfichable Failover Cluster Manager et des applets de commande de mise en cluster de basculement Windows PowerShell.

Volumes partagés de cluster

Les CSV permettent à plusieurs nœuds d'un cluster de basculement de disposer simultanément d'un accès en lecture/écriture vers le même LUN NetApp provisionné en tant que volume NTFS ou ReFS. Avec les CSV, les rôles en cluster peuvent basculer rapidement d'un nœud à un autre sans nécessiter de changement de propriétaire de disque, ni de démontage/remontage d'un volume. Les CSV simplifient également la gestion d'un nombre potentiellement important de LUN dans un cluster de basculement. Les CSV proposent un système de fichiers en cluster à usage général qui se superpose au-dessus de NTFS ou ReFS.

Cluster de basculement Hyper-V et NetApp,largeur=624,hauteur=271

Et des meilleures pratiques

  • NetApp recommande de désactiver les communications de cluster sur le réseau iSCSI pour empêcher les communications de cluster internes et le trafic CSV de circuler sur le même réseau.

  • NetApp recommande de disposer de chemins réseau redondants (plusieurs commutateurs) pour assurer la résilience et la qualité de service.

Choses à retenir

  • Les disques utilisés pour CSV doivent être partitionnés avec NTFS ou ReFS. Les disques formatés avec FAT ou FAT32 ne peuvent pas être utilisés pour un CSV.

  • Les disques utilisés pour les CSV doivent utiliser un formatage de 64 Ko pour l'allocation.

Lecture ultérieure

Pour plus d'informations sur le déploiement d'un cluster Hyper-V, reportez-vous à l'Annexe B : "Déployez le cluster Hyper-V.".

Hyper-V Live migration : migration de machines virtuelles

Il est parfois nécessaire pendant toute la durée de vie des machines virtuelles de les déplacer vers un autre hôte du cluster Windows. Cela peut être nécessaire si l'hôte manque de ressources système ou si l'hôte doit redémarrer pour des raisons de maintenance. De même, il peut être nécessaire de déplacer une machine virtuelle vers une autre LUN ou un autre partage SMB. Cette condition peut être nécessaire si l'espace du LUN ou du partage actuel est insuffisant ou présente des performances inférieures à la valeur attendue. La migration dynamique Hyper-V déplace les machines virtuelles en cours d'exécution d'un serveur Hyper-V physique vers un autre sans affecter la disponibilité des machines virtuelles pour les utilisateurs. Vous pouvez migrer en direct des machines virtuelles entre des serveurs Hyper-V faisant partie d'un cluster de basculement ou entre des serveurs Hyper-V indépendants qui ne font pas partie d'un cluster.

Migration dynamique dans un environnement en cluster

Les machines virtuelles peuvent être déplacées de manière transparente entre les nœuds d'un cluster. La migration des machines virtuelles est instantanée, car tous les nœuds du cluster partagent le même stockage et ont accès à la machine virtuelle et à son disque. La figure suivante illustre la migration en direct dans un environnement en cluster.

Migration dynamique dans un environnement en cluster,largeur=580,hauteur=295

Et des meilleures pratiques

  • Disposer d'un port dédié pour le trafic de migration en direct.

  • Disposer d'un réseau dédié de migration dynamique des hôtes pour éviter les problèmes liés au réseau pendant la migration.

Lecture ultérieure

Pour plus d'informations sur le déploiement de la migration dynamique dans un environnement en cluster, reportez-vous à la section "Annexe C : déploiement de la migration dynamique Hyper-V dans un environnement en cluster".

Migration dynamique en dehors d'un environnement en cluster

Il est possible de migrer un serveur virtuel en direct entre deux serveurs Hyper-V indépendants non mis en cluster. Ce processus peut utiliser une migration dynamique sans partage ou partagée.

  • Dans la migration dynamique partagée, la machine virtuelle est stockée sur un partage SMB. Par conséquent, lorsque vous migrez une machine virtuelle en direct, le stockage de la machine virtuelle reste sur le partage SMB central pour un accès instantané par l'autre nœud, comme illustré ci-dessous.

Migration dynamique partagée dans un environnement non mis en cluster,largeur=331,hauteur=271

  • Dans le cas d'une migration dynamique sans partage, chaque serveur Hyper-V dispose de son propre stockage local (il peut s'agir d'un partage SMB, d'une LUN ou d'un DAS) et le stockage de la machine virtuelle est local sur son serveur Hyper-V. Lors de la migration en direct d'une machine virtuelle, le stockage de la machine virtuelle est mis en miroir sur le serveur de destination via le réseau client, puis la machine virtuelle est migrée. La machine virtuelle stockée sur le DAS, une LUN ou un partage SMB/CIFS peut être déplacée vers un partage SMB/CIFS sur l'autre serveur Hyper-V, comme illustré dans la figure ci-dessous. Il est également possible de le déplacer vers une LUN, comme illustré dans la seconde figure.

Migration dynamique sans partage dans un environnement non mis en cluster vers des partages SMB,largeur=624,hauteur=384

Migration dynamique sans partage dans un environnement non mis en cluster vers des LUN,largeur=624,hauteur=384

Lecture ultérieure

Pour plus d'informations sur le déploiement de la migration dynamique en dehors d'un environnement en cluster, reportez-vous à la section "Annexe D : déploiement de la migration dynamique Hyper-V en dehors d'un environnement en cluster".

Hyper-V Storage Live migration

Au cours de la durée de vie d'un serveur virtuel, vous devrez peut-être déplacer le stockage du serveur virtuel (VHD/VHDX) vers un autre LUN ou partage SMB. Cette condition peut être nécessaire si l'espace du LUN ou du partage actuel est insuffisant ou présente des performances inférieures à la valeur attendue.

La LUN ou le partage qui héberge actuellement la machine virtuelle peut être à court d'espace, reconverti ou offre des performances réduites. Dans ces circonstances, la machine virtuelle peut être déplacée sans interruption vers une autre LUN ou un autre partage sur un autre volume, agrégat ou cluster. Ce processus est plus rapide si le système de stockage dispose de fonctionnalités de copie auxiliaire. Les systèmes de stockage NetApp sont dotés de la fonctionnalité de copie auxiliaire activée par défaut dans les environnements CIFS et SAN.

La fonctionnalité ODX effectue des copies de fichiers complets ou de sous-fichiers entre deux répertoires résidant sur des serveurs distants. Une copie est créée en copiant les données entre les serveurs (ou le même serveur si les fichiers source et de destination se trouvent tous deux sur le même serveur). La copie est créée sans que le client ait lu les données à partir de la source ou écrit dans la destination. Ce processus réduit l'utilisation du processeur et de la mémoire pour le client ou le serveur et réduit la bande passante E/S du réseau. La copie est plus rapide si elle se trouve dans le même volume. Si la copie se trouve sur plusieurs volumes, les performances peuvent ne pas être nettement supérieures à celles des copies basées sur l'hôte. Avant de procéder à une opération de copie sur l'hôte, vérifiez que les paramètres de déchargement de copie sont configurés sur le système de stockage.

Lorsque la migration dynamique du stockage de machine virtuelle est initiée à partir d'un hôte, la source et la destination sont identifiées, et l'activité de copie est déchargée sur le système de stockage. Étant donné que l'activité est effectuée par le système de stockage, l'utilisation du processeur, de la mémoire ou du réseau de l'hôte est négligeable.

Les contrôleurs de stockage NetApp prennent en charge les différents scénarios d'ODX suivants :

  • IntraSVM. les données sont détenues par le même SVM :

  • Intravope, intranode. les fichiers source et de destination ou les LUN résident dans le même volume. La copie s'effectue à l'aide de la technologie de fichiers FlexClone, ce qui offre d'autres avantages en termes de performances de copie à distance.

  • Intervolue, intranode. les fichiers source et de destination ou les LUN se trouvent sur des volumes différents qui se trouvent sur le même nœud.

  • Intervolue, internœuds. les fichiers source et de destination ou les LUN se trouvent sur des volumes différents situés sur des nœuds différents.

  • InterSVM. les données appartiennent à différents SVM.

  • Intervolue, intranode. les fichiers source et de destination ou les LUN se trouvent sur des volumes différents qui se trouvent sur le même nœud.

  • Intervolue, internœuds. les fichiers source et de destination ou les LUN se trouvent sur des volumes différents qui se trouvent sur des nœuds différents.

  • Intercluster. depuis ONTAP 9.0, ODX est également pris en charge pour les transferts de LUN intercluster dans des environnements SAN. ODX intercluster est pris en charge pour les protocoles SAN uniquement, et non pour SMB.

Une fois la migration terminée, les règles de sauvegarde et de réplication doivent être reconfigurées pour refléter le nouveau volume contenant les machines virtuelles. Les sauvegardes précédentes qui ont été effectuées ne peuvent pas être utilisées.

Le stockage des serveurs virtuels (VHD/VHDX) peut être migré entre les types de stockage suivants :

  • Le stockage DAS et le partage SMB

  • DAS et LUN

  • Un partage SMB et un LUN

  • Entre LUN

  • Entre partages SMB

Migration dynamique du stockage Hyper-V, largeur=339, hauteur=352

Lecture ultérieure

Pour plus d'informations sur le déploiement de la migration dynamique du stockage, reportez-vous à la section "Annexe E : déploiement de la migration dynamique du stockage Hyper-V.".

Hyper-V Replica : reprise après incident pour les machines virtuelles

Le réplica Hyper-V réplique les machines virtuelles Hyper-V depuis un site principal vers des machines virtuelles de réplica sur un site secondaire, assurant ainsi une reprise après incident asynchrone pour les machines virtuelles. Le serveur Hyper-V sur le site principal hébergeant les machines virtuelles est appelé serveur principal ; le serveur Hyper-V sur le site secondaire qui reçoit les machines virtuelles répliquées est appelé serveur de réplica. Un exemple de scénario de réplica Hyper-V est illustré dans la figure suivante. Vous pouvez utiliser Hyper-V Replica pour les machines virtuelles entre des serveurs Hyper-V faisant partie d'un cluster de basculement ou entre des serveurs Hyper-V indépendants qui ne font pas partie d'un cluster.

Réplique Hyper-V,largeur=624,hauteur=201

La réplication

Lorsque Hyper-V Replica est activé pour une machine virtuelle sur le serveur principal, la réplication initiale crée une machine virtuelle identique sur le serveur de réplica. Après la réplication initiale, Hyper-V Replica conserve un fichier journal pour les VHD de la machine virtuelle. Le fichier journal est relu dans l'ordre inverse vers le VHD de réplica en fonction de la fréquence de réplication. Ce journal et l'utilisation de l'ordre inverse permettent de s'assurer que les dernières modifications sont stockées et répliquées de manière asynchrone. Si la réplication ne se produit pas conformément à la fréquence attendue, une alerte est émise.

Réplication étendue

Hyper-V Replica prend en charge la réplication étendue dans laquelle un serveur de réplica secondaire peut être configuré pour la reprise après incident. Un serveur de réplica secondaire peut être configuré pour que le serveur de réplica reçoive les modifications sur les machines virtuelles de réplica. Dans un scénario de réplication étendue, les modifications apportées aux machines virtuelles primaires du serveur principal sont répliquées sur le serveur de réplica. Les modifications sont ensuite répliquées sur le serveur de réplica étendu. Les machines virtuelles peuvent être défaillantes vers le serveur de réplica étendu uniquement lorsque les serveurs principal et de réplica sont en panne.

Basculement

Le basculement n'est pas automatique. Le processus doit être déclenché manuellement. Il existe trois types de basculement :

  • Test failover. ce type est utilisé pour vérifier qu'une machine virtuelle de réplica peut démarrer avec succès sur le serveur de réplica et qu'elle est lancée sur la machine virtuelle de réplica. Ce processus crée une machine virtuelle de test en double lors du basculement, sans affecter la réplication de production normale.

  • Basculement planifié. ce type est utilisé pour basculer les machines virtuelles pendant les temps d'arrêt planifiés ou les interruptions prévues. Ce processus est lancé sur la machine virtuelle principale, qui doit être désactivée sur le serveur principal avant l'exécution d'un basculement planifié. Après le basculement de la machine, Hyper-V Replica démarre la machine virtuelle de réplica sur le serveur de réplica.

  • Basculement non planifié. ce type est utilisé lorsque des pannes inattendues se produisent. Ce processus est lancé sur la machine virtuelle de réplica et ne doit être utilisé que si la machine principale échoue.

Reprise après incident

Lorsque vous configurez la réplication pour une machine virtuelle, vous pouvez spécifier le nombre de points de restauration. Les points de restauration représentent des points dans le temps à partir desquels les données peuvent être récupérées à partir d'une machine répliquée.

Lecture ultérieure