Azure NFS-Migration von lokalem NFS

Azure NFS-Migration von lokalem NFS

Kontext: Wir arbeiten an einem Datenmigrationsprojekt, bei dem Daten zwischen einem lokalen NFS-Dateisystem und einer Azure NFS-basierten Dateifreigabe synchronisiert werden. Ziel ist es, einen nahtlosen Übergang von der lokalen Umgebung zu Azure sicherzustellen und dabei die Datenintegrität und -effizienz aufrechtzuerhalten.

Hintergrund:

Quelle: Lokales NFS-Dateisystem.

Ziel: Azure NFS-basierte Dateifreigabe.

Datengröße: Ungefähr 350 GB.

Werkzeugnutzung:

AzCopy (nicht unterstützt): Wir haben zunächst versucht, AzCopy für die Datenmigration zu verwenden, haben jedoch festgestellt, dass es von Azure NFS-Dateisystemen nicht unterstützt wird.

Rsync (Speicherwachstumsproblem): Wir haben dann Rsync zur Datensynchronisierung verwendet. Allerdings stellten wir am Azure-Ziel ein erhebliches Speicherwachstum fest und der Vorgang wurde nie abgeschlossen. Der Speicher wuchs ohne ersichtlichen Grund weiter an, sodass wir den Rsync-Vorgang abbrechen mussten.

Fpsync (erster Versuch erfolgreich): Um das Problem des Speicherwachstums zu lösen, sind wir zur Datensynchronisierung auf Fpsync umgestiegen. Beim ersten Versuch verlief dies vielversprechend, da die erste Synchronisierung erfolgreich abgeschlossen wurde.

Das Problem: Unerklärliches Speicherwachstum: Unsere größte Herausforderung ist das unerklärliche Wachstum der Speichernutzung am Azure NFS-Ziel, insbesondere mit Rsync. Selbst wenn die Quelldatengröße gleich bleibt, nimmt der Zielspeicher erheblich zu, was den Prozess unkontrollierbar macht.

Ziel: Wir suchen Erkenntnisse, Ratschläge oder Lösungen aus der Community, um dieses Speicherwachstumsproblem zu beheben und zu lösen. Unser Ziel ist es, eine effiziente Datensynchronisierung und minimale Speichernutzung am Azure-Ziel sicherzustellen.

Zusätzliche Informationen: Die Quelldaten, einschließlich versteckter Dateien und Verzeichnisse, sind korrekt formatiert und benannt.

Berechtigungen bleiben während der Synchronisierung erhalten.

Während wir mit Fpsync bei der ersten Synchronisierung zunächst Erfolg hatten, traten bei nachfolgenden Synchronisierungen immer noch Probleme mit dem Speicherwachstum auf. Für Vorschläge, Erkenntnisse oder Erfahrungen zu diesem Problem wären wir sehr dankbar. Wir möchten dieses Problem lösen und eine erfolgreiche Datenmigration zu Azure NFS sicherstellen.

Aktualisieren:

Jetzt habe ich das Dienstprogramm Rclone verwendet und bin auf dasselbe Problem gestoßen.

Antwort1

Lesen Sie man rsyncsorgfältig. Probieren Sie einige Optionen aus, um --dry-run --itemize-changes zu sehen, was genau passiert.

Wenn Sie keine Löschoption angeben, wird ein Löschvorgang auf der Quelle nicht auf dem Ziel widergespiegelt. Ideal für Archivierungsfälle, nicht so gut für Dinge mit begrenzter Aufbewahrungsdauer wie mit Datumsstempel versehene Protokolldateien. Vermeiden Sie außerdem *-Platzhalter, wenn Sie Dateien löschen möchten, gemäß Manpage:

   --delete
          This  tells rsync to delete extraneous files from the receiving side (ones that aren't on the sending
          side), but only for the directories that are being synchronized.  You must have asked rsync  to  send
          the  whole  directory  (e.g.  "dir"  or "dir/") without using a wildcard for the directory's contents
          (e.g. "dir/*") since the wildcard is expanded by the shell and rsync thus gets a request to  transfer
          individual  files,  not  the  files' parent directory. 

"Das Standardverhalten besteht darin, jede temporäre Datei im selben Verzeichnis wie die zugehörige Zieldatei zu erstellen." Diese temporären Dateien ermöglichen zwar den Abbruch der Übertragung, benötigen aber erheblichen zusätzlichen Speicherplatz. Gehen Sie vorsichtig von der doppelten Größe der Quelle aus, für den schlimmsten Fall, wenn alles aktualisiert werden muss. Die vielleicht aggressivste Möglichkeit, dieses Verhalten zu ändern, besteht darin, --inplaceDateien direkt zu überschreiben. Achtung: Dadurch werden die auf dem Ziel verwendeten Dateien beschädigt. Dies ist nicht für Active/Active-Anwendungsfälle geeignet.

Bezüglich der Leistung sollten Sie herausfinden, welche Faktoren sowohl bei lokalen als auch bei Remote-Systemen die einschränkenden Faktoren sind. Wenn ich mir die schlimmsten Zahlen ausdenke, könnte es Stunden dauern, eine Million Dateien auf langsamen Spindeln mit 100 IOPS aufzulisten und die Dateiliste zu vergleichen. Wenn es jedoch darum geht, Dateidaten zu kopieren, können Engpässe auf die Netzwerkbandbreite und die CPU für SSH und Komprimierung übergehen.

Überlegen Sie sich alternative Pläne für eine erste Kopie, die keine Dateisynchronisierungstools sind. Erstellen Sie beispielsweise eine lokale Sicherungskopie der Freigabe und stellen Sie sie auf einem Host in Azure mit dem bereitgestellten NFS wieder her. Im Vergleich zur inkrementellen Dateisynchronisierung ist es schneller und einfacher, ein Archiv (.tar oder was auch immer) über das Netzwerk zu kopieren und vollständig zu extrahieren.

Apropos, rsync könnte als inkrementelles Verfahren nützlich sein, um nach dem ersten Kopieren alles wieder auf den neuesten Stand zu bringen. Der Vergleich wird zwar immer noch einige Zeit in Anspruch nehmen, ist aber viel schneller, wenn die Änderungsrate niedrig ist und nicht viel zu kopieren ist.

verwandte Informationen