Große File-Migration mit rclone-Bridge

Use Case

• Kategorie: Migration großer Dateibestände
• Ziel: STACKIT File Service
• Methode: rclone-Transferpfad, wenn kein direkter dualer NFS-Mount verfügbar ist

Netzwerk- und Architektur-Rahmenbedingungen (validiert)

• rclone hebt die privaten SFS-Zugriffsregeln nicht auf: Auch mit rclone bleibt der Ziel-SFS-Share NFS-basiert und netzwerkbeschränkt durch SNA-Routing und ACL-/Export-Policies. Siehe File-Storage-Konzepte und Resource Pools und Shares mounten .
• Bridge-Host muss beidseitig erreichbar sein: Der Transfer-Host muss Quelle und Ziel unter dem tatsächlichen Netzwerkmodell erreichen, nicht nur theoretisch.
• Anbieter-Realität ist anderswo ähnlich: Private File-Share-Dienste anderer Anbieter (zum Beispiel AWS EFS) sind by default ebenfalls nicht Internet-exponiert, private Konnektivität ist für Migrationspfade also erforderlich. Siehe AWS EFS network access .

Verbindliche Voraussetzungen

• Ziel-Erreichbarkeit vom Bridge-Host: Der Bridge-Host kann den Ziel-SFS-Share über private Konnektivität im zugehörigen SNA-Scope mounten.
• Quell-Erreichbarkeit vom Bridge-Host: Der Bridge-Host erreicht den Quell-Endpunkt (Internet, privates Netz oder VPN-angebunden).
• Endpunkt-Zugriff validiert: Die Migrationsumgebung kann sowohl Quell- als auch Ziel-Endpunkte erreichen.
• Protokoll-Mapping validiert: Für jede Seite ist eine rclone-Backend-Konfiguration verfügbar.
• Credential-Governance definiert: Verantwortlichkeiten für Secret-Ablage und Rotation sind zugewiesen.
• Konsistenzfenster vereinbart: Initial-Copy-, Inkremental-Sync- und finale Freeze-Fenster sind freigegeben.

Nicht geeignet, wenn

• Keine sichere Bridge existiert: Eine konforme Ausführungsumgebung erreicht nicht beide Endpunkte.
• Ziel-SFS nicht privat erreichbar ist: Keine Route vom Bridge-Host zum SNA-angebundenen SFS verfügbar.
• Unkontrollierte Quell-Änderungen: Eine schreibintensive Quelle kann kein finales Konsistenzfenster bieten.

VPN-Machbarkeit

• VPN ist ein valider Bridge-Enabler: VPN kann den fehlenden privaten Pfad zwischen quellseitigen Netzen und SNA-Ressourcen bereitstellen.
• VPN-Scope ist Site-to-Site: STACKIT VPN ist Site-to-Site und SNA-basiert; das Bridge-Design muss also Netz-zu-Netz-Konnektivität nutzen, keine Point-to-Site-Annahmen. Siehe STACKIT VPN Produktübersicht .
• Routing- und Policy-Checks sind Pflicht: Routen-Austausch und Security-Regeln für den Data-Plane-Traffic vor dem Produktions-Sync bestätigen.

Wann diese Variante wählen

• rclone-Bridge wählen, wenn: Duales NFS-Mounting auf einem Host nicht machbar ist, aber ein kontrollierter Bridge-Host sowohl Quelle als auch SFS-Ziel erreicht.
• rclone-Bridge nicht wählen, wenn: Keine einzelne sichere Ausführungsumgebung beide Endpunkte mit der nötigen Bandbreite und Stabilität erreicht.
• Alternative: Das NFS-und-fpsync-Runbook verwenden, wenn direktes duales NFS-Mounting möglich ist.

Ausnahme-Variante: Quellseitiger Transfer-Host mit Internet-SFTP-Relay

Diese Variante nur nutzen, wenn duales NFS-Mounting auf einer Migrations-VM nicht machbar ist.

Wenn eine Migrations-VM in STACKIT platziert werden kann und Quelle wie Ziel über private Konnektivität gemountet werden können (inklusive Site-to-Site-VPN zur Quelle), ist das NFS-und-fpsync-Runbook zu bevorzugen.

• Ablauf: AWS EFS -> AWS EC2 (NFS-Mount) -> Internet (SSH/SFTP) -> STACKIT-Jump-Host -> SFS (NFS-Mount).
• Tooling: Auf AWS EC2 rclone mit einem SFTP-Remote auf den STACKIT-Jump-Host verwenden, alternativ rsync/scp über SSH.
• Validierungsbedingungen: Der Jump-Host erreicht SFS, der SFTP-Ingress ist kontrolliert, der Durchsatz ist realistisch, Integritätschecks sind deterministisch und der SFTP-Zielpfad mappt eindeutig auf den gemounteten SFS-Pfad.

Durchsatz- und Parallelitäts-Tuning

• Transfer-Parallelität: Gleichzeitige Dateitransfers mit rclone --transfers <parallelism> erhöhen.
• Metadaten-/Check-Parallelität: Listing- und Vergleichsarbeit mit --checkers <parallelism> skalieren, um Metadaten-Engpässe zu vermeiden.
• SFTP-Backend-Tuning: Für SFTP-lastige Pfade backend-spezifische Optionen wie SFTP-Concurrency und Chunk-Größe anhand der Server-Fähigkeiten bewerten.
• Qualität des Netzwerkpfads: Latenz, Paketverlust und MTU zwischen Quell-Transfer-Host und STACKIT-Jump-Host stabilisieren.
• Verschlüsselungs-Overhead: SSH-/SFTP-Verschlüsselung kann auf beiden Seiten CPU-gebunden werden; CPU-Reserven auf EC2 und Jump-Host beim Skalieren der Transfers validieren.
• NFS-Zielpfad-Tuning: NFS-Mount-Verhalten auf dem Jump-Host tunen (rsize, wsize und nconnect wo unterstützt), weil die finalen Schreibzugriffe über NFS auf SFS gehen.
• Dateigrößen-Profil beachten: Große Dateien profitieren meist von Transfer-Parallelität; hohe Anzahlen kleiner Dateien erfordern oft stärkeres Checker-/Listing-Tuning.
• Messdisziplin: Effektive MB/s, Dateien/s, Retries, Transferfehler und CPU-Last nach jeder Tuning-Änderung erfassen.

Umsetzungsvorlage

Phase 1: Transfer-Bridge aufbauen

1. Migrations-Host vorbereiten und sichere Credential-Injection einrichten.
2. rclone-Remotes für Quelle und Ziel konfigurieren.
3. Dry-Run und Baseline-Performance-Sampling durchführen.

Phase 2: Kontrollierte Kopie und Sync

1. Initiale Kopie mit kontrollierter Parallelität fahren.
2. Inkrementelle Sync-Zyklen fahren und Fehler-Logs prüfen.
3. Retries verfolgen und ungelöste Transferfehler klassifizieren.

Phase 3: Finalisierung

1. Finales Quell-Freeze-Fenster auslösen.
2. Finalen Sync und Integritätschecks fahren.
3. Handover an den konsumierenden Workload freigeben und Logs archivieren.

Validierungscheckliste

• Transfer-Vollständigkeit: Datei-Anzahl- und Größen-Parität validiert.
• Integritäts-Stichprobe: Hash-Vergleichs-Stichprobe abgeschlossen.
• Fehlerbehandlungs-Nachweis: Fehlgeschlagene Transfers geprüft und gelöst oder freigegeben.
• Security-Nachweis: Credential- und Zugriffs-Logs dokumentiert.