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.

Verschieben Sie ein Volume auf eine lokale ONTAP-Tier mit FabricPool-Unterstützung

Beitragende johnlantz netapp-dbagwell netapp-bhouser netapp-lenida netapp-thomi netapp-aherbin
PDFs

Unter anderem "Volume-Verschiebung"verschiebt ONTAP ein Volume unterbrechungsfrei von einer lokalen Tier (Quelle) zu einem anderen (Ziel). Volume-Verschiebungen sind aus verschiedenen Gründen möglich, wenngleich die häufigsten Gründe dafür Hardware Lifecycle Management, Cluster-Erweiterung und Lastausgleich sind.

Es ist wichtig zu wissen, wie die Volume-Verschiebung mit FabricPool funktioniert, da die Änderungen, die sowohl auf der lokalen Tier, der Attached Cloud-Ebene als auch auf dem Volume (Volume-Tiering-Richtlinien) stattfinden, große Auswirkungen auf die Funktionalität haben können.

Hinweis Vor ONTAP 9.7 verwendet System Manager den Begriff „Aggregate“, um eine „Local Tier“ zu beschreiben. Unabhängig von Ihrer ONTAP-Version verwendet die ONTAP CLI den Begriff Aggregate. Weitere Informationen zu lokalen Ebenen finden Sie unter "Festplatten und lokale Tiers".

Lokale Ebene des Ziels

Verfügt die lokale Ziel-Tier einer Volume-Verschiebung nicht über eine verbundene Cloud-Tier, werden die Daten des in der Cloud-Tier gespeicherten Quell-Volumes in die lokale Tier der lokalen Ziel-Tier geschrieben.

Ab ONTAP 9.8 verwendet FabricPool, wenn ein Volume "Berichterstellung für inaktive Daten"aktiviert ist, die Heatmap des Volumes, um kalte Daten sofort in die Warteschlange einzureihen, um mit dem Tiering zu beginnen, sobald sie auf die lokale Ziel-Tier geschrieben werden.

Vor ONTAP 9.8 wird durch das Verschieben eines Volumes auf eine andere lokale Tier die Inaktivitätsdauer von Blöcken auf der lokalen Tier zurückgesetzt. Ein Volume mit der Tiering-Richtlinie für automatisches Volume mit Daten auf der lokalen Tier, das 20 Tage inaktiv, aber noch nicht gestaffelt war, hat beispielsweise die Temperatur der Daten nach einer Volume-Verschiebung auf 0 Tage zurückgesetzt.

Optimierte Verschiebung von Volumes

Ab ONTAP 9.6 werden die Daten des im Bucket gespeicherten Quell-Volume nicht zurück auf die lokale Tier verschoben, wenn die lokale Ziel-Tier einer Volume-Verschiebung denselben Bucket verwendet. Tiering-Daten bleiben im Ruhezustand, und nur heiße Daten müssen von einer lokalen Tier in eine andere verschoben werden. Diese optimierte Volume-Verschiebung führt zu einer erheblichen Netzwerkeffizienz.

Beispielsweise bedeutet eine optimierte Volumeverschiebung von 300 TB, dass zwar 300 TB kalte Daten von einer lokalen Ebene auf eine andere verschoben werden, dies jedoch keine Lese- und Schreibvorgänge von 300 TB im Objektspeicher auslöst.

Nicht optimierte Volume-Verschiebungen generieren zusätzlichen Netzwerk- und Computing-Datenverkehr (Lese-/Schreibvorgänge und Schreibvorgänge/Puts). Dadurch steigen die Anforderungen an das ONTAP-Cluster und den Objektspeicher, was möglicherweise die Kosten durch Tiering auf öffentliche Objektspeicher in die Höhe treibt.

Hinweis

Einige Konfigurationen sind nicht mit optimierten Volume-Verschiebungen kompatibel:

  • Tiering-Richtlinie wird während der Volume-Verschiebung geändert

  • Lokale Quell- und Ziel-Tiers mit unterschiedlichen Verschlüsselungsschlüsseln

  • FlexClone Volumes

  • Übergeordnete FlexClone Volumes

  • MetroCluster (unterstützt optimierte Volume-Verschiebungen in ONTAP 9.8 und höher)

  • Nicht synchronisierte FabricPool Mirror Buckets

Verfügt die lokale Tier einer Volume-Verschiebung über eine angeschlossene Cloud-Tier, werden die Daten des auf der Cloud-Tier gespeicherten Quell-Volumes zuerst auf die lokale Tier auf der lokalen Ziel-Tier geschrieben. Anschließend wird in die Cloud-Tier auf der lokalen Ziel-Tier geschrieben, sofern dieser Ansatz für die Tiering-Richtlinie des Volumes geeignet ist.

Durch das Schreiben von Daten in die lokale Tier wird zunächst die Performance der Volume-Verschiebung verbessert und die Umstellungszeit verkürzt. Wird bei der Verschiebung eines Volumes keine Tiering-Richtlinie angegeben, verwendet das Ziel-Volume die Tiering-Richtlinie des Quell-Volume.

Wird bei der Volume-Verschiebung eine andere Tiering-Richtlinie angegeben, wird das Ziel-Volume mit der angegebenen Tiering-Richtlinie erstellt und die Volume-Verschiebung nicht optimiert.

Volume-Metadaten

Unabhängig davon, ob eine Volume-Verschiebung optimiert ist, speichert ONTAP eine erhebliche Menge an Metadaten über Standort, Speichereffizienz, Berechtigungen, Nutzungsmuster usw. aller Daten, sowohl lokal als auch in Tiering-Ebenen. Metadaten verbleiben immer auf der lokalen Ebene und werden nicht in Tiering-Ebenen gespeichert. Wenn ein Volume von einer lokalen Ebene auf eine andere verschoben wird, muss diese Information ebenfalls in die lokale Ziel-Tier verschoben werden.

Dauer

Das Verschieben von Volumes nimmt immer noch einige Zeit in Anspruch und man sollte davon ausgehen, dass das Verschieben eines optimierten Volumes ungefähr genauso lange dauert wie das Verschieben einer gleichen Menge nicht gestaffelter Daten.

Es ist wichtig zu verstehen, dass der „Durchsatz“, der von der volume move show Der Befehl stellt nicht den Durchsatz im Hinblick auf die aus der Cloud-Ebene verschobenen Daten dar, sondern die lokal aktualisierten Volumendaten.

Hinweis In einer SVM-DR-Beziehung müssen Quell- und Ziel-Volumes dieselbe Tiering-Richtlinie verwenden.
Schritte

  1. Verwenden Sie den volume move start Befehl, um ein Volume von einer lokalen Quell-Tier auf eine lokale Ziel-Tier zu verschieben.

Beispiel für das Verschieben eines Volumes

Im folgenden Beispiel wird ein Volume mit dem Namen vs1 SVM in dest_FabricPool eine lokale Tier mit FabricPool-Aktivierung verschoben myvol2.

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