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.

Déplacez un volume vers un niveau local ONTAP compatible FabricPool

Contributeurs johnlantz netapp-dbagwell netapp-bhouser netapp-lenida netapp-thomi netapp-aherbin
PDF

A "déplacement de volumes"permet à ONTAP de déplacer un volume d'un niveau local (source) vers un autre (destination) sans interruption. Les déplacements de volumes peuvent être effectués pour diverses raisons, mais les principales raisons sont la gestion du cycle de vie matériel, l'extension des clusters et l'équilibrage de la charge.

Il est important de comprendre le fonctionnement de la migration de volumes avec FabricPool, car les modifications qui ont lieu à la fois au niveau local et au niveau cloud associé, et au volume (règles de Tiering des volumes) peuvent avoir un impact majeur sur la fonctionnalité.

Remarque Avant ONTAP 9.7, System Manager utilise le terme aggregate pour décrire un niveau local. Quelle que soit votre version de ONTAP, l'interface de ligne de commandes de ONTAP utilise le terme aggregate. Pour en savoir plus sur les niveaux locaux, voir "Disques et niveaux locaux".

Niveau local de destination

Si le Tier local de destination d'un déplacement de volume n'est associé à aucun Tier cloud, les données du volume source stocké sur le Tier cloud sont écrites sur le Tier local du Tier local de destination.

À partir de ONTAP 9.8, lorsqu'un volume est "reporting des données inactives" activé, FabricPool utilise la carte thermique du volume pour mettre immédiatement en file d'attente les données inactives afin de commencer le Tiering dès qu'elles sont écrites sur le Tier local de destination.

Avant ONTAP 9.8, le déplacement d'un volume vers un autre niveau local réinitialise la période d'inactivité des blocs sur le niveau local. Par exemple, un volume utilisant la règle de Tiering automatique du volume avec des données sur le Tier local qui ont été inactives pendant 20 jours, mais n'avaient pas encore été hiérarchisées, la température des données est réinitialisée à 0 jours après un déplacement de volume.

Déplacement optimisé des volumes

À partir de ONTAP 9.6, si le Tier local de destination du déplacement de volume utilise le même compartiment que le Tier local source, les données du volume source stocké dans le compartiment ne reviennent pas au niveau local. Les données hiérarchisées restent au repos et seules les données actives doivent être déplacées d'un Tier local à un autre. Cette migration de volume optimisée se traduit par une efficacité réseau considérable.

Par exemple, un déplacement de volume optimisé de 300 To signifie que même si 300 To de données froides sont déplacées d'un niveau local à un autre, cela ne déclenchera pas 300 To de lectures et 300 To d'écritures dans le magasin d'objets.

Les déplacements de volumes non optimisés génèrent un trafic réseau et de calcul supplémentaire (lectures/écritures/écritures/écritures), ce qui augmente les demandes sur le cluster ONTAP et le magasin d'objets, ce qui peut entraîner une augmentation des coûts lors du Tiering vers des magasins d'objets publics.

Remarque

Certaines configurations sont incompatibles avec les déplacements de volumes optimisés :

  • Modification de la règle de Tiering pendant le déplacement de volumes

  • Les niveaux locaux source et de destination utilisent différentes clés de chiffrement

  • Volumes FlexClone

  • Volumes parents FlexClone

  • MetroCluster (prise en charge des déplacements de volume optimisés dans ONTAP 9.8 et versions ultérieures)

  • Compartiments miroir FabricPool non synchronisés

Si le Tier local de destination d'un déplacement de volume dispose d'un Tier cloud associé, les données du volume source stocké sur le Tier cloud sont d'abord écrites sur le Tier local du Tier local de destination. Elle est ensuite écrite sur le Tier cloud du Tier local de destination si cette approche est appropriée pour la règle de Tiering du volume.

L'écriture des données sur le niveau local améliore d'abord les performances du déplacement de volume et réduit le délai de mise en service. Si aucune règle de hiérarchisation de volume n'est spécifiée lors du déplacement de volume, le volume de destination utilise la règle de hiérarchisation du volume source.

Si une règle de hiérarchisation différente est spécifiée lors du déplacement de volume, le volume de destination est créé avec la règle de hiérarchisation spécifiée et le déplacement de volume n'est pas optimisé.

Métadonnées de volume

Qu'un déplacement de volume soit optimisé ou non, ONTAP stocke une quantité importante de métadonnées concernant l'emplacement, l'efficacité du stockage, les autorisations, les modes d'utilisation, etc., de toutes les données, locales et hiérarchisées. Les métadonnées restent toujours au niveau local et ne sont pas hiérarchisées. Lorsqu'un volume est déplacé d'un niveau local à un autre, ces informations doivent également être déplacées vers le niveau local de destination.

Durée

Les déplacements de volume prennent toujours du temps et il faut s'attendre à ce qu'un déplacement de volume optimisé prenne à peu près le même temps que le déplacement d'une quantité égale de données non hiérarchisées.

Il est important de comprendre que le « débit » rapporté par le volume move show la commande ne représente pas le débit en termes de données déplacées depuis le niveau cloud, mais les données de volume mises à jour localement.

Remarque Dans une relation de SVM DR, les volumes source et de destination doivent utiliser la même règle de Tiering.
Étapes

  1. Utilisez volume move start la commande pour déplacer un volume d'un niveau local source vers un niveau local de destination.

Exemple de déplacement d'un volume

L'exemple suivant illustre la migration d'un volume nommé myvol2 vs1 SVM vers dest_FabricPool, un niveau local compatible FabricPool.

cluster1::> volume move start -vserver vs1 -volume myvol2
-destination-aggregate dest_FabricPool