Skip to main content
Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

Ein Volume auf eine FabricPool aktivierte ONTAP lokale Ebene verschieben

Beitragende johnlantz netapp-dbagwell netapp-bhouser netapp-lenida netapp-thomi netapp-aherbin
Änderungen vorschlagen
PDFs

A "Volume verschieben" ist die Methode, mit der ONTAP ein Volume unterbrechungsfrei von einer lokalen Ebene (Quelle) auf eine andere (Ziel) verschiebt. Volume-Verschiebungen können aus verschiedenen Gründen erfolgen, wobei die häufigsten Gründe das Hardware-Lebenszyklusmanagement, die Clustererweiterung und die Lastverteilung sind.

Es ist wichtig zu verstehen, wie Volume Move mit FabricPool funktioniert, da die Änderungen, die sowohl auf der lokalen Tier, der angeschlossenen Cloud-Tier als auch am Volume (Volume-Tiering-Richtlinien) vorgenommen werden, einen erheblichen Einfluss auf die Funktionalität haben können.

Hinweis Vor ONTAP 9.7 verwendet System Manager den Begriff aggregate, um eine lokale Ebene zu beschreiben. Unabhängig von der ONTAP Version verwendet die ONTAP CLI den Begriff aggregate. Weitere Informationen zu lokalen Ebenen finden sich unter "Festplatten und lokale Ebenen".

Ziel-Lokale Tier

Wenn der Ziel-Local-Tier einer Volume-Verschiebung keinen zugeordneten Cloud-Tier hat, werden Daten des Quell-Volumes, die im Cloud-Tier gespeichert sind, auf den Local-Tier des Ziel-Local-Tiers geschrieben.

Ab ONTAP 9.8, wenn ein Volume "Meldung inaktiver Daten" aktiviert hat, verwendet FabricPool die Heatmap des Volumes, um kalte Daten sofort in die Warteschlange zu stellen, damit das Tiering beginnt, sobald sie auf die lokale Zielebene geschrieben werden.

Vor ONTAP 9.8 wurde beim Verschieben eines Volumes auf eine andere lokale Tier die Inaktivitätsperiode der Blöcke auf der lokalen Tier zurückgesetzt. Beispielsweise wird bei einem Volume mit der Auto Volume-Tiering-Richtlinie, dessen Daten sich auf der lokalen Tier befinden und seit 20 Tagen inaktiv sind, aber noch nicht getiert wurden, die Temperatur der Daten nach dem Verschieben des Volumes auf 0 Tage zurückgesetzt.

Optimierte Volumenverschiebungen

Ab ONTAP 9.6 werden Daten auf dem Quellvolume, die im Bucket gespeichert sind, nicht zurück in den lokalen Tier verschoben, wenn der Ziel-Lokal-Tier denselben Bucket wie der Quell-Lokal-Tier verwendet. Tiered-Daten bleiben im Ruhezustand, und nur häufig genutzte Daten müssen von einem lokalen Tier zu einem anderen verschoben werden. Diese optimierte Volume-Verschiebung führt zu erheblichen Netzwerk-Effizienzen.

Beispielsweise bedeutet eine optimierte Volume-Verschiebung von 300 TB, dass, obwohl 300 TB an selten genutzten Daten von einer lokalen Ebene auf eine andere verschoben werden, dadurch nicht 300 TB an Lese- und 300 TB an Schreibvorgängen im Objektspeicher ausgelöst werden.

Nicht optimierte Volume-Verschiebungen erzeugen zusätzlichen Netzwerk- und Rechenverkehr (Lese-/GET- und Schreib-/PUT-Vorgänge), wodurch die Anforderungen an den ONTAP Cluster und den Objektspeicher steigen und beim Tiering auf öffentliche Objektspeicher potenziell höhere Kosten entstehen.

Hinweis

Einige Konfigurationen sind mit optimierten Volumenverschiebungen nicht kompatibel:

  • Änderung der Tiering-Richtlinie während einer Volumenverschiebung

  • Quell- und Ziel-Lokalschichten verwenden unterschiedliche Verschlüsselungsschlüssel

  • FlexClone Volumes

  • FlexClone übergeordnete Volumes

  • MetroCluster (unterstützt optimierte Volumenverschiebungen in ONTAP 9.8 und höher)

  • Nicht synchronisierte FabricPool Mirror Buckets

Wenn die lokale Ziel-Tier eines Volume-Verschiebung eine angehängte Cloud-Tier hat, werden Daten auf dem Quell-Volume, die auf der Cloud-Tier gespeichert sind, zuerst auf die lokale Tier der Ziel-Tier geschrieben. Anschließend werden sie auf die Cloud-Tier der Ziel-Tier geschrieben, sofern dies für die Tiering-Richtlinie des Volumes geeignet ist.

Das Schreiben von Daten auf die lokale Tier verbessert die Performance des Volume Move und verkürzt die Cutover-Zeit. Wenn beim Verschieben eines Volumes keine Volume Tiering-Policy angegeben wird, verwendet das Ziel-Volume die Tiering-Policy des Quell-Volumes.

Wird beim Verschieben des Volumes eine andere Tiering-Richtlinie angegeben, wird das Zielvolume mit der angegebenen Tiering-Richtlinie erstellt und das Verschieben des Volumes ist nicht optimiert.

Volume Metadaten

Unabhängig davon, ob eine Volume-Verschiebung optimiert ist, speichert ONTAP umfangreiche Metadaten zu Speicherort, Speichereffizienz, Berechtigungen, Nutzungsmustern usw. aller Daten, sowohl lokaler als auch gestaffelter Daten. Metadaten verbleiben stets auf der lokalen Tier und werden nicht gestaffelt. Wenn ein Volume von einer lokalen Tier zu einer anderen verschoben wird, müssen diese Informationen ebenfalls auf die Ziel-Tier übertragen werden.

Dauer

Volumenverschiebungen benötigen nach wie vor Zeit, und es ist zu erwarten, dass eine optimierte Volumenverschiebung ungefähr genauso lange dauert wie die Verschiebung einer gleich großen Menge nicht gestufter Daten.

Es ist wichtig zu verstehen, dass der vom volume move show Befehl gemeldete "Durchsatz" nicht den Durchsatz in Bezug auf die Bewegung von Daten aus der Cloud-Tier darstellt, sondern die lokal aktualisierten Volumendaten.

Hinweis Bei einer SVM DR-Beziehung müssen Quell- und Ziel-Volumes die gleiche Tiering-Richtlinie verwenden.
Schritte

  1. Mit dem volume move start Befehl lässt sich ein Volume von einer lokalen Quellebene auf eine lokale Zielebene verschieben.

Beispiel für das Verschieben eines Volumens

Im folgenden Beispiel wird ein Volume mit dem Namen myvol2 von vs1 SVM nach dest_FabricPool, einer FabricPool-aktivierten lokalen Ebene, verschoben.

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