Auf dieser Seite finden Sie eine Übersicht über das Feature zur Volume-Migration.
Informationen zur Volume-Migration
Mit dem Feature zur Volume-Migration können Sie Volumes von ONTAP-basierten Quellen zu Google Cloud NetApp Volumes migrieren. Dabei wird eine auf SnapMirror basierende Migration verwendet. SnapMirror funktioniert auf Volume-Ebene und kann ein Quell-Volume auf ein Ziel-Volume auf einem anderen System replizieren.
SnapMirror bietet viele Vorteile gegenüber herkömmlichen Methoden zum Kopieren von Daten:
Es funktioniert über jedes IP-Netzwerk und ist widerstandsfähig gegen Netzwerkprobleme. Es unterstützt eine Vielzahl von Netzwerkgeschwindigkeiten und Latenzen.
Es werden nur verwendete Daten kopiert.
Nach einer ersten Baseline-Datenübertragung sind die nachfolgenden Übertragungen inkrementell. Dabei werden nur geänderte Daten kopiert, und zwar auf unbestimmte Zeit. Die Berechnung von Änderungen für inkrementelle Übertragungen ist außergewöhnlich schnell und unabhängig vom Datentyp, der im Volume gespeichert ist.
Bei den Übertragungen bleibt die Speichereffizienz erhalten. Wenn das Quell-Volume deduplizierte oder komprimierte Daten enthält, werden diese Effizienzen übernommen, wodurch die zu übertragende Datenmenge reduziert wird.
Alle Übertragungen werden während der Übertragung verschlüsselt.
Sie können das Quell-Volume ohne spürbare Leistungseinbußen verwenden.
Sie können das Ziel-Volume nach Abschluss der Baseline-Übertragung im schreibgeschützten Modus verwenden.
Alle Daten, einschließlich Metadaten wie komplexe Access Control Lists (ACLs) und gesperrte Dateien, werden übertragen.
Mit SnapMirror können Volumes zwischen ONTAP-Systemen übertragen werden, auch über verschiedene geografische Standorte hinweg.
Google Cloud NetApp Volumes verwendet SnapMirror für die Volume-Replikation zwischen NetApp Volumes in verschiedenen Google-Regionen. Außerdem können Sie SnapMirror verwenden, um zwischen externen ONTAP-basierten Volumes und NetApp Volumes zu replizieren. Dies wird als Hybrid-Replikation bezeichnet.
Es gibt zwei Arten von Hybrid-Replikationen:
Die Volume-Migration ist für einmalige Übertragungen von ONTAP zu NetApp Volumes vorgesehen.
Die externe Replikation ist für laufende Replikationen zur Notfallwiederherstellung vorgesehen, bei denen die Replikationsrichtung umgekehrt werden kann.
Übersicht über den Migrationsprozess
Die Hybrid-Replikation sorgt für schnelle, konsistente und vollständige Datenmigrationen von der Quelle zum Ziel mit minimalen Auswirkungen auf die Produktion. Dieser Prozess besteht aus den folgenden Phasen:
Authentifizierung
In der Authentifizierungsphase müssen die Speicheradministratoren des ONTAP-Quellsystems NetApp Volumes die Berechtigung erteilen, ein Volume aus dem Quellsystem abzurufen. Dies erfolgt durch administrative Schritte im ONTAP-Quellsystem, die als Cluster-Peering und SVM-Peering bezeichnet werden. Der Volume-Migrationsprozess generiert die ONTAP-Befehle, die Administratoren im Quellsystem ausführen müssen.
Baseline-Übertragung
Nachdem Sie eine Migration eingerichtet haben, wird mit einem Snapshot ein Konsistenzpunkt im Quellsystem erstellt. Alle Daten, die aus diesem Snapshot erfasst wurden, einschließlich älterer Snapshots, werden dann in einer ersten Phase, die als Baseline-Übertragung bezeichnet wird, zu NetApp Volumes übertragen.
Eine Baseline-Übertragung kann Minuten, Stunden, Tage oder Wochen dauern. Die Dauer hängt von den folgenden Faktoren ab:
Die Datenmenge im Snapshot.
Die Netzwerkgeschwindigkeit zwischen Ihrem ONTAP-Quellsystem und NetApp Volumes.
Die Durchsatzeinstellung Ihrer NetApp Volumes.
Während der Baseline-Übertragung verarbeitet das Quell-Volume weiterhin Ihre Arbeitslast und Daten werden hinzugefügt, geändert oder gelöscht. Diese Änderungen haben keine Auswirkungen auf den Snapshot, der für den Konsistenzpunkt der Baseline verwendet wird. Während die Baseline ausgeführt wird, ist das Ziel-Volume für Clients nicht verfügbar. Nach Abschluss der Baseline wird das Ziel-Volume online geschaltet und ist für den Clientzugriff im Lesemodus verfügbar. Das Ziel-Volume hat eine andere IP-Adresse.
Im Gegensatz zur Volume-Replikation kann bei der Volume-Migration nicht auf die Parameter des Quell-Volumes wie Größe, Protokollauswahl und Export- oder Snapshot-Richtlinien zugegriffen werden. Daher müssen Sie diese Einstellungen für das Ziel-Volume korrekt konfigurieren.
Sie können das Ziel-Volume jetzt in VMs einbinden oder zuordnen, um sich auf das Ende der Migration vorzubereiten.
Inkrementelle Übertragungen
Nach Abschluss der Baseline-Übertragung werden durch die Migration stündliche inkrementelle Übertragungen ausgelöst.
Bei jeder inkrementellen Übertragung werden die folgenden Aktionen ausgeführt:
Es wird ein neuer Snapshot des Quell-Volumes erstellt.
Die Datenänderungen zwischen dem aktuellen und dem vorherigen Snapshot werden berechnet.
Diese Änderungen werden an das Ziel übertragen.
Wenn seit dem Baseline-Snapshot eine erhebliche Anzahl von Änderungen vorgenommen wurde und eine inkrementelle Übertragung noch ausgeführt wird, wenn die nächste stündliche Übertragung geplant ist, wird diese Übertragung übersprungen. Bei der nächsten inkrementellen Übertragung wird ein neuer Quell-Snapshot erstellt, der älteste SnapMirror-Snapshot gelöscht, die Änderungen berechnet und übertragen.
Clients, die das Ziel-Volume einbinden, sehen eine schreibgeschützte Ansicht mit statischen Inhalten. Sobald eine inkrementelle Übertragung abgeschlossen ist, werden die Inhalte des Volumes jedoch durch einen einzigen atomaren Vorgang sofort vom vorherigen Replikations-Snapshot auf den neuesten aktualisiert.
Sofern die Menge der neuen Daten, die dem Quell-Volume hinzugefügt wurden, nicht die Menge übersteigt, die innerhalb einer Stunde übertragen werden kann, nimmt die Größe der inkrementellen Übertragung mit jeder erfolgreichen Übertragung ab. Dieser Vorgang wird fortgesetzt, bis er sich mit einer Rate stabilisiert, die durch die stündliche Änderungsrate des Quell-Volumes definiert wird. Das kann einige Wiederholungen dauern. Sobald dieser stabile Zustand erreicht ist, können Sie eine Umstellung planen. Um die erforderliche Ausfallzeit während der Umstellung zu minimieren, sollten Sie die Änderungen zwischen dem Quell- und dem Ziel-Volume reduzieren.
Umstellung
Bei einer Umstellung verschieben Sie Ihre Arbeitslasten ohne Datenverlust (RPO = 0) und mit minimaler Ausfallzeit (RTO) vom Quell-Volume zum Ziel-Volume. Der Umstellungsprozess besteht aus den folgenden Teilschritten:
Änderungen beenden
Da inkrementelle Übertragungen asynchron sind, enthält das Quell-Volume möglicherweise Änderungen, die noch nicht im Ziel-Volume berücksichtigt wurden. So synchronisieren Sie die Daten: Beenden Sie alle Änderungen am Quell-Volume, indem Sie:
Alle Anwendungen beenden, die Daten ändern.
Optional: Die Volume-Berechtigungen in „Schreibgeschützt“ ändern, um zu verhindern, dass Clients die Daten ändern.
Auf aktuelle Übertragung warten
Achten Sie darauf, dass alle laufenden inkrementellen Übertragungen abgeschlossen sind.
Manuelle inkrementelle Übertragung ausführen
Führen Sie eine manuelle inkrementelle Übertragung aus, um die neuesten Daten an das Zielsystem zu senden. Das sollte nur einige Sekunden bis Minuten dauern, je nach Menge der seit der letzten Übertragung geänderten Daten, der Netzwerkgeschwindigkeit und den Durchsatzlimits der Ziel-Volumes.
Nach Abschluss der manuellen inkrementellen Übertragung sind die neuesten Daten am Ziel verfügbar.
Replikation beenden
Führen Sie den Vorgang zum Beenden der Replikation aus, um das Ziel-Volume schreib-/lesbar zu machen. Damit ist die Datenmigration abgeschlossen.
Anwendungen neu konfigurieren und neu starten
Konfigurieren Sie Ihre Anwendungen so, dass sie das Ziel-Volume verwenden, und starten Sie sie dann neu. Achten Sie darauf, dass der gesamte Datenzugriff auf das Quell-Volume beendet wird, damit keine Anwendung das Quell-Volume versehentlich verwendet.
Bereinigen
Wenn die Umstellung erfolgreich war, können Sie die folgenden Bereinigungsschritte ausführen:
Beendete Replikation löschen: Wenn Sie die beendete Replikation löschen, wird die Replikationsressource gelöscht, das Ziel-Volume jedoch nicht. Bei diesem Vorgang wird auch die SnapMirror-Beziehung gelöscht, die im Backend mit dem Quellsystem verwendet wird.
Cluster-Peering entfernen: Wenn dies die letzte SnapMirror-Beziehung zwischen NetApp Volumes und Ihrem Quellcluster war, können Sie das Cluster-Peering aus dem ONTAP-Quellsystem entfernen. Außerdem können Sie alle Netzwerke entfernen, die nur für Migrationszwecke zwischen der Quelle und dem Ziel konfiguriert wurden.