layout: ../../../layouts/BlogLayout.astro title: “Performance Assessment: Warum ping und iperf nicht reichen” description: “Synthetische Benchmarks sagen die reale Migrations-Performance nicht voraus. So bewertest du Netzwerk, Storage und Parallelisierung, bevor du Daten bewegst.” date: “2026-02-03” author: “syncopio Team” category: “Best Practices” readingTime: “5 min” slug: “pre-migration-assessment-guide” tags: [“migration”, “assessment”, “netzwerk”, “performance”, “planung”] locale: “de”

iperf sagt dir 10 Gbps. Deine Migration läuft mit 200 MB/s. Das sind 1,6 Gbps. Wo sind die anderen 8,4 geblieben?

Du pingst das Ziel. 0,3 ms. Wunderbar. Deine NFS-Transfers stallen trotzdem alle 30 Sekunden.

Das ist die Lücke zwischen synthetischen Benchmarks und realer Migrations-Performance. Wenn du ein Cutover-Fenster auf Basis von iperf-Zahlen planst, wirst du es reißen. So führst du ein Assessment durch, das tatsächlich vorhersagt, was passieren wird.

Warum synthetische Benchmarks lügen

iperf misst den reinen TCP-Durchsatz zwischen zwei Hosts. Es öffnet einen Socket, ballert Daten durch und meldet die Rate. Diese Zahl sagt dir die Obergrenze. Sie sagt dir nicht, was deine Migration erreichen wird.

Echte Migrationen sind kein reines TCP. Sie sind NFS oder SMB, und das bedeutet:

• Protokoll-Overhead. Jedes File-Open, Stat, Read, Write, Close, Chmod und Chtimes ist ein separater RPC-Aufruf. Jeder hat Header, Authentifizierung und Round-Trip-Latenz.
• Metadaten-Operationen. Verzeichnisse erstellen, Berechtigungen setzen, Timestamps erhalten. Nichts davon taucht in iperf auf.
• Verbindungsaufbau. NFS-Mounts, Kerberos-Tickets, Session-Negotiation. Das passiert nur einmal, kann aber Sekunden dauern.
• Attribut-Caching. Der Client cached Metadaten und liefert manchmal veraltete Daten, was zu Retries und Verifizierungsfehlern führt.
• Small-File-Penalty. iperf testet mit großen Puffern. Dein Dataset hat 400.000 Dateien unter 4 KB. Diese Dateien verbringen mehr Zeit mit Syscall-Overhead als mit Datenübertragung.

Eine realistische Faustregel: Erwarte 15% bis 40% deines iperf-Durchsatzes für NFS-Dateitransfers. Für SMB erwarte 10% bis 30%. Für Workloads mit überwiegend kleinen Dateien erwarte noch weniger.

Netzwerk-Jitter: der versteckte Killer

Ein Netzwerk mit durchschnittlich 1 ms Latenz klingt großartig. Aber wenn es alle 10 Sekunden auf 50 ms hochschießt, hast du ein Problem.

NFS-Operationen sind synchron. Ein einzelner 50-ms-Spike bedeutet, dass ein Worker 50 ms stehen bleibt. Wenn das während einer metadatenintensiven Phase passiert (Tausende von Verzeichnissen erstellen), bekommst du eine Kaskade: Der Worker blockiert, seine Queue staut sich, der NFS-Server verarbeitet den verzögerten Burst auf einmal, und der Durchsatz bricht zusammen.

Die Durchschnittslatenz verbirgt das. Du musst dir die Ausreißer anschauen.

Miss Jitter, nicht nur Latenz:

# 60 Sekunden Ping mit Timing-Statistiken
ping -c 60 -i 0.5 nfs-server.local | tail -1
# Schau dir den max-Wert in min/avg/max/mdev an

# Besser: mtr mit 100 Probes ausführen
mtr -r -c 100 nfs-server.local
# Achte auf Paketverlust und hohe Standardabweichung

Was die Zahlen bedeuten:

Wenn du periodische Spikes siehst, prüfe auf konkurrierenden Traffic. Backup-Jobs, Replikation, VM-Snapshots. Alles, was die Leitung oder den Storage-Controller für ein paar Sekunden sättigt, erzeugt genau dieses Muster.

Parallele Streams testen: den Sweet Spot finden

Ein einzelner Transfer-Stream wird eine 10-Gbps-Leitung niemals sättigen. NFS hat Pro-Operation-Latenz, und ein einzelner Thread kann nur eine Operation gleichzeitig im Flug haben. Die Antwort sind parallele Streams. Aber wie viele?

Zu wenige und du verschwendest Bandbreite. Zu viele und der NFS-Server thrasht. Seine Festplattenköpfe suchen ständig, seine CPU brennt wegen Lock-Contention, und der Gesamtdurchsatz sinkt tatsächlich.

Der Sweet Spot hängt von deiner Hardware ab. Du musst ihn testen.

Schneller Test des parallelen Durchsatzes:

# Testverzeichnis mit repräsentativen Dateien erstellen
mkdir -p /tmp/parallel-test
# 100 Dateien à ~100 MB generieren
for i in $(seq 1 100); do
  dd if=/dev/urandom of=/tmp/parallel-test/file_$i bs=1M count=100 2>/dev/null
done

# Test mit 1, 2, 4, 8, 16 parallelen Streams
for streams in 1 2 4 8 16; do
  echo "--- $streams streams ---"
  sync; echo 3 > /proc/sys/vm/drop_caches
  time find /tmp/parallel-test -type f | \
    xargs -P $streams -I {} cp {} /mnt/nfs-dest/
  rm -rf /mnt/nfs-dest/*
done

Zeichne die Ergebnisse auf. Du wirst so etwas sehen:

In diesem Beispiel sind 8 Streams der Sweet Spot. Bei 16 wird es sogar schlechter. Deine Zahlen werden anders sein. Der Punkt ist, zu testen statt zu raten.

File-Sampling: mit realistischen Daten testen

Benchmarke nicht mit einem Ordner voller 1-KB-Konfigdateien, um dann ein NAS voller 500-MB-Videorender zu migrieren. Die Performance-Charakteristiken sind komplett verschieden.

Sample über dein tatsächliches Dataset:

# 200 Dateien aus jedem Größenbereich samplen
find /path/to/source -type f -size -128k | shuf -n 200 > /tmp/sample-small.txt
find /path/to/source -type f -size +128k -size -100M | shuf -n 200 > /tmp/sample-medium.txt
find /path/to/source -type f -size +100M | shuf -n 200 > /tmp/sample-large.txt

# Jedes Sample übertragen und messen
for bracket in small medium large; do
  echo "--- $bracket files ---"
  sync; echo 3 > /proc/sys/vm/drop_caches
  time rsync -a --files-from=/tmp/sample-$bracket.txt / /mnt/nfs-dest/
  rm -rf /mnt/nfs-dest/*
done

Das gibt dir Transfer-Raten pro Größenbereich. Kombiniere sie mit deiner Größenverteilung (siehe unseren Guide zur Dateianzahl-Planung) und du bekommst eine realistische Schätzung.

Storage-Assessment: Wie viel muss wirklich umziehen?

Bevor du ein Wochenende für ein Cutover opferst, frag dich: Muss wirklich alles umziehen?

Kapazität und veraltete Daten:

# Gesamtgröße
du -sh /path/to/source

# Dateien, auf die seit 2+ Jahren nicht zugegriffen wurde
find /path/to/source -type f -atime +730 -printf '%s\n' | \
  awk '{ total += $1 } END { printf "Veraltet: %.1f GB\n", total/1073741824 }'

# Dateien, die in den letzten 30 Tagen geändert wurden (aktive Daten)
find /path/to/source -type f -mtime -30 -printf '%s\n' | \
  awk '{ total += $1 } END { printf "Aktiv: %.1f GB\n", total/1073741824 }'

Auf einem typischen Enterprise-NAS wurden 30% bis 60% der Daten seit über einem Jahr nicht angefasst. Das ändert deine Migrationsstrategie. Vielleicht verschiebst du aktive Daten zuerst, machst das Cutover, und migrierst dann veraltete Daten im Hintergrund. Vielleicht geht ein Teil davon in Cold Storage statt auf das neue NAS.

Wachstumsrate:

# Snapshots vergleichen, falls vorhanden, oder Quota-Berichte prüfen
# Schnelle Schätzung aus aktuellen Dateien:
find /path/to/source -type f -mtime -90 -printf '%s\n' | \
  awk '{ total += $1 } END { printf "Wachstum letzte 90 Tage: %.1f GB\n", total/1073741824 }'

Die Wachstumsrate bestimmt, ob du überhaupt ein Cutover-Fenster brauchst. Wenn das Dataset um 5 GB/Tag wächst und du 500 MB/s sustain kannst, können inkrementelle Syncs unbegrenzt mithalten. Du machst einen Bulk-Transfer einmalig, dann inkrementelle Updates, bis du DNS umstellst. Kein Ausfallzeitfenster nötig.

Planungsvorlage: Bandbreite mal Zeit gleich bewegte Daten (so ungefähr)

Hier ist die Formel, die jeder benutzt:

transfer_time = total_bytes / throughput

Und hier ist, warum sie falsch ist: Sie nimmt konstanten Durchsatz an. In der Praxis brauchst du Overhead-Faktoren.

Realistische Planungsformel:

effective_throughput = iperf_throughput × protocol_factor × parallelism_factor × jitter_factor

transfer_time = total_bytes / effective_throughput

Beispiel: 10-Gbps-Leitung, 50 TB zu bewegen, gemischter Workload:

effective = 10 Gbps × 0,25 (kombinierter Faktor) = 2,5 Gbps = 312 MB/s

50.000.000 MB / 312 MB/s = 160.256 Sekunden ≈ 44 Stunden

Rechne 20% Puffer für Retries, Verifizierung und Überraschungen dazu: ungefähr 53 Stunden. Das ist dein Cutover-Fenster. Nicht die 11 Stunden, die reines iperf suggerieren würde.

Die Assessment-Checkliste

Bevor du eine Migration über 1 TB startest, geh das hier durch:

1. iperf3 zwischen Quelle und Ziel. Das ist deine Obergrenze. Wenn sie nicht dem entspricht, was du erwartest, behebe zuerst das Netzwerkproblem.
2. Jitter-Test während deines geplanten Migrationsfensters. 60+ Sekunden Ping, Max-Latenz und Paketverlust prüfen.
3. Test paralleler Streams. Den Punkt finden, ab dem mehr Streams nicht mehr helfen.
4. File-Size-Sampling. Transfers mit Dateien aus jedem Größenbereich deines Datasets testen.
5. Storage-Audit. Gesamtgröße, Anteil veralteter Daten, Wachstumsrate über 90 Tage.
6. Realistische Transferzeit berechnen. Verwende die Overhead-Faktoren oben, nicht den Roh-Durchsatz.
7. Strategie festlegen. Big-Bang-Cutover, inkrementeller Sync oder phasenweise nach Priorität?

Überspringe einen dieser Punkte und du rätst. Raten ist der Grund, warum du am Sonntagmorgen um 3 Uhr dein Cutover-Fenster neu buchen musst.

Weiterführende Artikel:

• Die Dateianzahl-Lüge: Warum 1,2 Millionen Dateien dir nicht sagen, wie lange die Migration dauert
• NFS Mount-Optionen Cheat Sheet
• rsync vs rclone vs Robocopy
• Datenmigration: Der komplette Guide