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

Présentation de la mobilité des données des SVM

Contributeurs
PDF

Depuis la version ONTAP 9.10.1, les administrateurs de cluster peuvent déplacer un SVM d'un cluster source vers un cluster de destination sans interruption. Ils peuvent ainsi gérer l'équilibrage de la capacité et de la charge, ou encore procéder à des mises à niveau d'équipement ou à des consolidations de data Center via l'interface de ligne de commande ONTAP.

Cette fonctionnalité de déplacement de SVM sans interruption est prise en charge sur les plateformes AFF dans ONTAP 9.10.1 et 9.11.1. Depuis la version ONTAP 9.12.1, cette fonctionnalité est prise en charge à la fois sur les plateformes FAS et AFF et sur les agrégats hybrides.

Le nom et l'UUID du SVM restent inchangés après la migration, ainsi que le nom de la LIF de données, l'adresse IP et les noms d'objet, comme le nom du volume. L'UUID des objets du SVM sera différent.

Flux de production de la migration SVM

Le schéma représente le workflow standard d'une migration de SVM. Démarrer une migration SVM depuis le cluster destination. Vous pouvez contrôler la migration depuis la source ou la destination. Vous pouvez effectuer une mise en service manuelle ou automatique. La mise en service automatique est effectuée par défaut.

Flux de travail de la migration des SVM. Cette section récapitule les étapes à suivre.

Prise en charge de la plateforme de migration SVM

Famille de contrôleurs

Versions de ONTAP prises en charge

AFF A-Series

ONTAP 9.10.1 et versions ultérieures

AFF série C.

ONTAP 9.12.1 correctif 4 et ultérieur

FAS

ONTAP 9.12.1 et versions ultérieures
Remarque Lors de la migration d'un cluster AFF vers un cluster FAS avec des agrégats hybrides, le placement automatique de volumes tente d'effectuer une correspondance d'agrégat similaire à celle-ci. Par exemple, si le cluster source compte 60 volumes, le placement du volume tente de trouver un agrégat AFF sur la destination pour placer les volumes. Lorsqu'il n'y a pas suffisamment d'espace sur les agrégats AFF, les volumes sont placés sur des agrégats avec des disques non Flash.

Prise en charge de l'évolutivité par version ONTAP

Version ONTAP

Paires HAUTE DISPONIBILITÉ dans la source et la destination

ONTAP 9.14.1

12

ONTAP 9.13.1

6

ONTAP 9.11.1

3

ONTAP 9.10.1

1

Exigences de performances de l'infrastructure réseau pour le temps de réponse aller-retour TCP (RTT) entre le cluster source et le cluster de destination

En fonction de la version ONTAP installée sur le cluster, le réseau qui connecte les clusters source et destination doit avoir un temps d'aller-retour maximal, comme indiqué :

Version ONTAP

RTT maximum

ONTAP 9.12.1 et versions ultérieures

10 ms.

ONTAP 9.11.1 et versions antérieures

2 ms.

Nombre maximal de volumes pris en charge par SVM

Source

Destination

ONTAP 9.14.1

ONTAP 9.13.1

ONTAP 9.12.1

ONTAP 9.11.1 et versions antérieures

AFF

AFF

400

200

100

100

FAS

FAS

80

80

80

S/O

FAS

AFF

80

80

80

S/O

AFF

FAS

80

80

80

S/O

Prérequis

Avant de lancer une migration d'un SVM, vous devez réunir les conditions préalables suivantes :

  • Vous devez être un administrateur de cluster.

  • "Les clusters source et destination doivent être mis en cluster par groupes".

  • SnapMirror doit être synchrone sur les clusters source et destination "licence installée". Cette licence est incluse avec "ONTAP One".

  • Tous les nœuds du cluster source doivent exécuter ONTAP 9.10.1 ou une version ultérieure. Pour connaître la prise en charge spécifique du contrôleur de baie ONTAP, reportez-vous à la section "Hardware Universe".

  • Tous les nœuds du cluster source doivent exécuter la même version de ONTAP.

  • Tous les nœuds du cluster destination doivent exécuter la même version de ONTAP.

  • La version du ONTAP du cluster de destination doit être identique ou ne doit pas être supérieure à deux versions majeures plus récentes que le cluster source.

  • Les clusters source et destination doivent prendre en charge le même sous-réseau IP pour l'accès aux LIF de données.

  • La SVM source doit contenir moins de nombre maximal de volumes de données pris en charge pour la version.

  • Un espace suffisant pour le placement des volumes doit être disponible sur la destination

  • Onboard Key Manager doit être configuré sur le site de destination si le SVM source possède des volumes chiffrés

  • Si vous migrez un SVM entre une configuration non MetroCluster et une configuration MetroCluster, ou entre deux configurations MetroCluster, vérifiez que votre configuration répond aux exigences suivantes :

    • Les clusters MetroCluster source et destination sont dans un état « normal ». Cela signifie qu'ils ne peuvent pas être en mode de basculement ou en état d'attente de rétablissement.

    • Les clusters MetroCluster source et destination ne sont pas en cours de transition FC vers IP ni d'actualisation matérielle.

    • Le cluster de destination exécute une version ONTAP identique ou ultérieure à celle du cluster source.

    • Si la source est un cluster MetroCluster, le sous-type du SVM est « sync-source » (pas « sync-destination »).

      Remarque Si la destination est un cluster MetroCluster, le SVM créé sur la destination est toujours « sync-source ». Si la destination est un cluster non-MetroCluster, le sous-type du SVM est toujours « default ».

Et des meilleures pratiques

Lors d'une migration d'un SVM, il est recommandé de laisser une marge de 30 % sur le cluster source et le cluster de destination pour permettre l'exécution de la charge de travail du processeur.

Opérations SVM

Vous devez vérifier si les opérations peuvent entrer en conflit avec une migration SVM :

  • Aucune opération de basculement n'est en cours

  • WAFLIRON ne peut pas être en cours d'exécution

  • L'empreinte digitale n'est pas en cours

  • Le déplacement de volumes, le réhébergement, le clonage, la création, la conversion ou l'analytique ne sont pas en cours d'exécution

Fonctionnalités prises en charge et non prises en charge

Le tableau présente les fonctionnalités ONTAP prises en charge par la mobilité des données des SVM et les versions ONTAP dans lesquelles la prise en charge est disponible.

Pour plus d'informations sur l'interopérabilité de la version ONTAP entre une source et une destination dans une migration SVM, voir "Compatibilité des versions ONTAP pour les relations SnapMirror".

Fonction

Version d'abord prise en charge

Commentaires

Protection autonome contre les ransomwares

ONTAP 9.12.1

Cloud Volumes ONTAP

Non pris en charge

Gestionnaire de clés externe

ONTAP 9.11.1

FabricPool

Non pris en charge

Relation de type « fanout » (la source de migration possède un volume source SnapMirror avec plusieurs destinations)

ONTAP 9.11.1

SAN FC

Non pris en charge

Flash Pool

ONTAP 9.12.1

Volumes FlexCache

Non pris en charge

FlexGroup

Non pris en charge

Stratégies IPsec

Non pris en charge

LIF IPv6

Non pris en charge

San iSCSI

Non pris en charge

Réplication de la planification des tâches

ONTAP 9.11.1

Dans ONTAP 9.10.1, les planifications de tâches ne sont pas répliquées au cours de la migration et doivent être créées manuellement sur le volume de destination. Depuis ONTAP 9.11.1, les planifications des tâches utilisées par la source sont automatiquement répliquées au cours de la migration.

Miroirs de partage de charge

Non pris en charge

SVM MetroCluster

ONTAP 9.16.1

Depuis la version ONTAP 9.16.1, les migrations de SVM MetroCluster suivantes sont prises en charge :

  • Migration d'un SVM entre une configuration non MetroCluster et une configuration MetroCluster IP

  • Migration d'un SVM entre deux configurations MetroCluster IP

  • Migration d'un SVM entre une configuration FC MetroCluster et une configuration IP MetroCluster

Les migrations SVM MetroCluster suivantes ne sont pas prises en charge pour toutes les versions de ONTAP :

  • Migration d'un SVM entre deux configurations MetroCluster FC

  • Migration d'un SVM entre une configuration non MetroCluster et une configuration MetroCluster FC

Chiffrement d'agrégat NetApp (NAE)

ONTAP 9.11.1

Les volumes NAE doivent être placés sur la destination de support NAE. Si aucune destination NAE n'est disponible, l'opération de migration échoue.

Configurations NDMP

Non pris en charge

NVE (NetApp Volume Encryption)

ONTAP 9.10.1

Les volumes NVE seront migrés en tant que volumes NVE sur la destination.

Journaux d'audit NFS et SMB

ONTAP 9.13.1
Remarque

Pour la migration SVM sur site avec audit activé, vous devez désactiver l'audit sur le SVM source, puis effectuer la migration.

Avant la migration des SVM :

NFS v3, NFS v4.1 et NFS v4.2

ONTAP 9.10.1

NFS v4.0

ONTAP 9.12.1

NFSv4.1 avec pNFS

ONTAP 9.14.1

NVMe over Fabric

Non pris en charge

Gestionnaire de clés intégré OKM (Onboard Key Manager) avec le mode critères communs activé sur le cluster source

Non pris en charge

Qtrees

ONTAP 9.14.1

Quotas

ONTAP 9.14.1

S3

Non pris en charge

Protocole SMB

ONTAP 9.12.1

Les migrations SMB sont perturbatrices et qui nécessitent une mise à jour du client après la migration.

Relations cloud SnapMirror

ONTAP 9.12.1

À partir de ONTAP 9.12.1, lorsque vous migrez un SVM sur site avec des relations cloud SnapMirror, le cluster de destination doit être installé et la "Licence cloud SnapMirror"capacité disponible doit être suffisante pour prendre en charge le déplacement de la capacité des volumes mis en miroir vers le cloud.

Destination asynchrone SnapMirror

ONTAP 9.12.1

Source asynchrone SnapMirror

ONTAP 9.11.1

  • Les transferts peuvent se poursuivre normalement sur les relations FlexVol SnapMirror pendant la majeure partie de la migration.

  • Tout transfert en cours est annulé pendant la mise en service et les nouveaux transferts échouent pendant la mise en service et ils ne peuvent pas être redémarrés tant que la migration n'est pas terminée.

  • Les transferts planifiés annulés ou manqués pendant la migration ne sont pas automatiquement démarrés une fois la migration terminée.

    Remarque

    Lors de la migration d'une source SnapMirror, ONTAP n'empêche pas la suppression du volume après la migration tant que la mise à jour SnapMirror n'a pas lieu. Cela se produit car les informations relatives à SnapMirror pour les volumes source SnapMirror migrés sont disponibles uniquement une fois la migration terminée et après la première mise à jour.

Paramètres SMTape

Non pris en charge

SnapLock

Non pris en charge

Synchronisation active SnapMirror

Non pris en charge

Relations entre les pairs SVM SnapMirror

ONTAP 9.12.1

Reprise d'activité de SVM SnapMirror

Non pris en charge

SnapMirror synchrone

Non pris en charge

Snapshots

ONTAP 9.10.1

Verrouillage à toute épreuve des copies Snapshot

ONTAP 9.14.1

Le verrouillage inviolable des snapshots n'est pas équivalent à SnapLock. SnapLock Enterprise et SnapLock Compliance ne sont toujours pas pris en charge.

LIF/BGP IP virtuelles

Non pris en charge

Virtual Storage Console 7.0 et versions ultérieures

Non pris en charge

Clones de volumes

Non pris en charge

VStorage

Non pris en charge

La migration n'est pas autorisée lorsque vStorage est activé. Pour effectuer une migration, désactivez l'option vStorage, puis réactivez-la une fois la migration terminée.

Opérations prises en charge pendant la migration

Le tableau suivant indique les opérations de volume prises en charge au sein du SVM de migration en fonction de l'état de migration :

Opération de volume

État de la migration SVM

En cours

Pause

Mise en service

Création

Non autorisé

Autorisé

Non pris en charge

Supprimer

Non autorisé

Autorisé

Non pris en charge

Désactivation de l'analyse du système de fichiers

Autorisé

Autorisé

Non pris en charge

Activation de l'analyse du système de fichiers

Non autorisé

Autorisé

Non pris en charge

Modifier

Autorisé

Autorisé

Non pris en charge

Hors ligne/en ligne

Non autorisé

Autorisé

Non pris en charge

Déplacer/réhéberger

Non autorisé

Autorisé

Non pris en charge

Création/modification qtree

Non autorisé

Autorisé

Non pris en charge

Création/modification de quotas

Non autorisé

Autorisé

Non pris en charge

Renommer

Non autorisé

Autorisé

Non pris en charge

Redimensionner

Autorisé

Autorisé

Non pris en charge

Limiter

Non autorisé

Autorisé

Non pris en charge

Les attributs des snapshots sont modifiés

Autorisé

Autorisé

Non pris en charge

Modification de la suppression automatique du snapshot

Autorisé

Autorisé

Non pris en charge

Création de snapshots

Autorisé

Autorisé

Non pris en charge

Suppression de Snapshot

Autorisé

Autorisé

Non pris en charge

Restaurer le fichier à partir du snapshot

Autorisé

Autorisé

Non pris en charge