Login
Newsletter
Werbung

Thema: Image-Dateien virtueller Maschinen flink übers Netzwerk kopieren

2 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von Markus B. am Fr, 2. Dezember 2016 um 19:57 #

Wenn alles glatt läuft, ist Kopieren von einer lokal gemounteten Offline-DRBD-Platte auf einen anderen lokalen Datenträger naturgemäß die beste Variante, da ja der Netzwerk-Overhead wegfällt. Meiner Erfahrung nach gibt es allerdings ein Problem, wenn beide Platten am selben Controller hängen. Da bricht recht schnell die Datenrate ein, sobald der Cache voll ist. Darauf war meine Aussage mit dem Bottleneck bezogen. In diesem Szenario geht es bei mir schneller mit netcat.

Das Praktische an netcat ist für mich, dass es sofort zur Hand ist und man nicht erst einen NFS-Server installieren und konfigurieren muss, um mal eben schnell ein Backup zu machen.

Optionen bezüglich Blockgrösse kenne ich keine, macht aber m.E. auch keinen Sinn, da sich nc rein aufs Pipen übers Netz beschränkt und den Rest den vorigen und nächsten Prozessen in der Pipe überlässt.

Dass nc+tar mehr CPU-Power benötigen als NFS+cp, wundert mich insofern, als dass im Fall von NFS ein Server involviert ist, der ja einen gewissen Overhead mitbringt. NFS läuft im Kernel - hast du dir in htop die Kernel-Threads eingeblendet bzw. in top auf die Angabe bei "sy" geachtet?

[
| Versenden | Drucken ]
  • 0
    Von Urs Pfister2 am Fr, 2. Dezember 2016 um 20:23 #

    Ich werde nochmals (aber frühestens nächste Woche) Tests mit 10 und 40 GBit fahren, und dabei nc gerne auch berücksichtigen, auch wenn ich heute eher das Gefühl hatte, nc wäre langsamer.

    Und sicher ist nc recht praktisch, da überall verfügbar, auch wenn ich die Syntax jetzt nicht wahnsinnig berauschend finde. Zugegeben, dies NFS und DRDB konfiguriert sind, das dürfte länger dauern, in dieser Hinsicht ist nc dann gerade wieder einfach.

    [
    | Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung