Modo rapido per copiare un file di grandi dimensioni su una LAN


24

Sto riscontrando dei problemi con NFS e mi piacerebbe provare a usare semplicemente il vecchio TCP.

Non ho idea da dove cominciare, però.

Per quanto riguarda l'hardware, sto usando un cavo crossover Ethernet per collegare in rete due netbook.

Per collegarli in rete, scrivo

$ sudo ifconfig eth0 192.168.1.1 up && ping -c 10 -s 10 192.168.1.2 && sudo /etc/init.d/nfs-kernel-server start

sul primo netbook e

$ sudo ifconfig eth0 192.168.1.2 up
$ ping -c 10 -s 10 192.168.1.1
$ mount /mnt/network1

sul secondo

dove /mnt/network1è specificato in / etc / fstab come

192.168.1.1:/home /mnt/network1 nfs noauto,user,exec,soft,nfsvers=2 0 0

così come in /etc/exports(usando la sintassi di quel file), sul primo netbook.

Quanto sopra funziona bene, ma i file e le directory sono enormi. I file hanno una media di circa mezzo gigabyte al pezzo e le directory sono tutte comprese tra 15 e 50 gigabyte.

Sto usando rsyncper trasferirli, e il comando (on 192.168.1.2) è

$ rsync -avxS /mnt/network1 ~/somedir

Non sono sicuro che ci sia un modo per modificare le mie impostazioni NFS per gestire meglio i file di grandi dimensioni, ma mi piacerebbe vedere se l'esecuzione di un rsyncdemone su un semplice vecchio TCP funziona meglio di rsyncsu NFS.

Quindi, per ribadire, come posso configurare una rete simile con TCP?

AGGIORNARE:

Quindi, dopo qualche ora di tentativi di tentare di tirarmi fuori dalla massa della mia stessa ignoranza (o, come mi piace pensarci, di tirarmi su con i miei stivali), ho trovato alcuni fatti utili.

Ma prima di tutto, ciò che mi ha portato su questa pista da coniglio invece di accettare semplicemente la migliore risposta attuale è stato questo: ncè un programma incredibilmente bello che non riesce assolutamente a funzionare per me. Ho provato i pacchetti netcat-openbsde netcat-traditionalsenza fortuna.

L'errore che ottengo sulla macchina ricevente ( 192.168.1.2) è:

me@netbook:~$ nc -q 1 -l -p 32934 | tar xv
Can't grab 0.0.0.0:32934 with bind
tar: This does not look like a tar archive
tar: Exiting with failure status due to previous errors

route dà:

me@netbook:~$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         dir-615         0.0.0.0         UG    0      0        0 wlan0
link-local      *               255.255.0.0     U     1000   0        0 eth0
192.168.0.0     *               255.255.255.0   U     2      0        0 wlan0
192.168.1.0     *               255.255.255.0   U     0      0        0 eth0

Ma ecco la buona notizia: avere gli indirizzi IP statici impostati /etc/network/interfaces, che ho iniziato a fare mentre cercavo di ncfunzionare, risolto tutti i miei problemi di NFS e riacceso il mio amore per NFS.

La configurazione esatta che ho usato (con 192.168.1.1ovviamente per il primo netbook) era:

auto eth0
iface eth0 inet static
address 192.168.1.2
netmask 255.255.255.0

Con queste impostazioni, i due netbook saranno in grado di eseguire il ping tra loro direttamente dopo l'avvio, senza nemmeno un ifup.

Ad ogni modo, mi piacerebbe ancora vedere ncin azione, quindi spero che qualcuno mi aiuti a eseguire il debug di questo processo.


Se entrambe le directory sono locali, è meglio usare semplicemente il vecchio /bin/cpo non usare affatto NFS
Karlson,

1
L'esecuzione di rsync su un file a cui si accede tramite NFS significa che l'intero contenuto del file deve essere copiato sulla rete almeno una volta. Non è necessario un demone per invocare un client / server rsync - basta eseguirlo su ssh. (teoricamente è possibile invocare l'estremità remota su telnet / rsh - ma piuttosto sciocco per eseguire un tale servizio in pratica - ssh non aggiunge molto overhead).
symcbean,

NFSv2 è piuttosto vecchio. Quale sistema operativo stai usando?
Nils,

l'ultimo Debian e l'ultimo Ubuntu, rispettivamente. ho ricevuto tutti questi comandi (incluso nfsvers=2) da questo tutorial ( michaelminn.com/linux/home_network )
ixtmixilix,

5
in realtà, ssh aggiunge una grande quantità di costi generali, la crittografia non è economica. Alle normali velocità di Internet, non importa, ma su una LAN (o la connessione incrociata diretta, in questo caso) potresti notare. Su gigabit, tranne sulle macchine molto più veloci (o quelle con istruzioni AES-NI, se SSH le usa) sono abbastanza sicuro che sarà evidente.
derobert,

Risposte:


43

Il modo rapido

Il modo più rapido per trasferire file su una LAN non è probabilmente rsync, a meno che non ci siano poche modifiche. rsync impiega un bel po 'di tempo a fare checksum, calcolare differenze, ecc. Se sai che trasferirai comunque la maggior parte dei dati, fai qualcosa del genere (nota: ci sono più implementazioni di netcat; controlla il manuale per le opzioni corrette. In particolare, la tua potrebbe non voler -p):

user@dest:/target$ nc -q 1 -l -p 1234 | tar xv

user@source:/source$ tar cv . | nc -q 1 dest-ip 1234

Questo utilizza netcat ( nc) per inviare tar su una connessione TCP non elaborata sulla porta 1234. Non esiste crittografia, controllo di autenticità, ecc., Quindi è molto veloce. Se il tuo cross-connect funziona a gigabit o meno, ti collegherai alla rete; se è più, peggerai il disco (a meno che tu non abbia un array di archiviazione o un disco veloce). I vflag per tar lo fanno stampare i nomi dei file mentre procede (modalità dettagliata). Con file di grandi dimensioni, questo è praticamente nessun sovraccarico. Se stavi facendo tonnellate di piccoli file, lo spegni. Inoltre, puoi inserire qualcosa di simile pvnella pipeline per ottenere un indicatore di avanzamento:

user@dest:/target$ nc -q 1 -l -p 1234 | pv -pterb -s 100G | tar xv

Ovviamente puoi anche inserire altre cose, come gzip -1(e aggiungere il zflag sull'estremità ricevente: il zflag sull'estremità di invio userebbe un livello di compressione superiore a 1, a meno che tu non imposti la variabile d'ambiente GZIP, ovviamente). Anche se gzip sarà probabilmente in realtà essere più lento, a meno che i dati realmente comprime.

Se hai davvero bisogno di rsync

Se stai davvero trasferendo solo una piccola parte dei dati che sono stati modificati, rsync potrebbe essere più veloce. Potresti anche voler guardare l' opzione -W/ --whole-file, come con una rete molto veloce (come una connessione incrociata) che può essere più veloce.

Il modo più semplice per eseguire rsync è tramite ssh. Avrai voglia di sperimentare le cifre ssh per vedere quale è il più veloce, sarà AES, ChaCha20 o Blowfish (anche se ci sono alcuni problemi di sicurezza con la dimensione del blocco a 64 bit di Blowfish), a seconda se il tuo chip ha AES di Intel -NI istruzioni (e OpenSSL le utilizza). Su un nuovo ssh abbastanza, rsync-over-ssh si presenta così:

user@source:~$ rsync -e 'ssh -c aes128-gcm@openssh.com' -avP /source/ user@dest-ip:/target

Per vecchi ssh / sshd, provare aes128-ctro aes128-cbcal posto di aes128-gcm@openssh.com.

ChaCha20 sarebbe chacha20-poly1305@openssh.com(anche bisogno di un nuovo ssh / sshd abbastanza) e Blowfish sarebbe blowfish-cbc. OpenSSH non consente l'esecuzione senza un codice. Puoi ovviamente usare qualsiasi opzione rsync che preferisci al posto di -avP. E ovviamente puoi andare nell'altra direzione ed eseguire rsync dalla macchina di destinazione (pull) invece che dalla macchina di origine (push).

Rendere più veloce rsync

Se esegui un demone rsync, puoi eliminare l'overhead crittografico. Innanzitutto, crei un file di configurazione del daemon ( /etc/rsyncd.conf), ad esempio sul computer di origine (leggi la manpage rsyncd.conf per i dettagli):

[big-archive]
    path = /source
    read only = yes
    uid = someuser
    gid = somegroup

Quindi, sul computer di destinazione, avresti eseguito:

user@dest:~$ rsync -avP source-ip::big-archive/ /target

Puoi farlo anche al contrario (ma ovviamente dovrai impostare la lettura solo su no). Ci sono opzioni per l'autenticazione, ecc., Controlla la manpage per i dettagli.


2
Questa è una risposta eccellente Anche l'altro è fantastico. Non esiste una risposta accettata solo perché il richiedente non può scegliere tra di loro?
sudo,

Quanto è solido l' netcatapproccio? Se la rete elimina i pacchetti, sembra che perderà parti casuali dei file.
sudo,

1
@sudo sta usando TCP, che ritrasmetterà secondo necessità. Quindi dovrebbe andare bene contro la perdita di pacchetti, la corruzione casuale (nella misura in cui i checksum TCP ed Ethernet la rilevano), ecc. Naturalmente, non è sicuro contro attacchi come il tunneling su SSH.
derobert,

1
@sudo puoi fare tutto in una volta, inserire alcuni teecomandi nella pipe su entrambi i lati per calcolare i checksum.
derobert,

1
@TheStoryCoder Il punto nella tarparte indica che deve eseguire la directory corrente. In realtà non fa parte del nccomando, tar viene utilizzato per creare un archivio tar, che viene reindirizzato su netcat (e dall'altro lato, netcat viene reindirizzato su tar per estrarre l'archivio). Temo che un commento non sia davvero sufficiente per spiegare le pipe, ma spero che sia abbastanza per iniziare ...
derobert

17

Come? O TL; DR

Il metodo più veloce che ho trovato è una combinazione di tar, mbuffere ssh.

Per esempio:

tar zcf - bigfile.m4p | mbuffer -s 1K -m 512 | ssh otherhost "tar zxf -"

Usando questo ho ottenuto trasferimenti di rete locale sostenuti oltre 950 Mb / s su collegamenti da 1Gb. Sostituisci i percorsi in ciascun comando tar per essere appropriati per quello che stai trasferendo.

Perché? mbuffer!

Il maggiore collo di bottiglia nel trasferimento di file di grandi dimensioni su una rete è, di gran lunga, l'I / O del disco. La risposta è mbuffero buffer. Sono in gran parte simili ma mbufferpresenta alcuni vantaggi. La dimensione del buffer predefinita è 2 MB per mbuffere 1 MB per buffer. I buffer più grandi hanno maggiori probabilità di non essere mai vuoti. La scelta di una dimensione del blocco che è il minimo comune multiplo della dimensione del blocco nativo sul filesystem di destinazione e di destinazione fornirà le migliori prestazioni.

Buffering è la cosa che rende tutto la differenza! Usalo se ce l'hai! Se non lo hai, prendilo! Usare (m}?bufferpiù qualsiasi cosa è meglio di qualsiasi cosa da solo. è quasi letteralmente una panacea per i trasferimenti di file di rete lenti.

Se si trasferiscono più file, utilizzare tarper "raggrupparli" in un unico flusso di dati. Se si tratta di un singolo file è possibile utilizzare cato il reindirizzamento I / O. Il sovraccarico di tarvs. catè statisticamente insignificante, quindi uso sempre tar(o zfs -senddove posso) a meno che non sia già un tarball . Nessuno di questi è garantito per darti metadati (e in particolare catnon lo farà). Se vuoi metadati, lo lascerò come esercizio per te.

Infine, l'utilizzo sshper un meccanismo di trasporto è sia sicuro che comporta un carico minimo. Ancora una volta, l'overhead di sshvs. ncè statisticamente insignificante.


4
openssl speedsu un i7-3770 fornisce ~ 126–146 MB / sec per Blowfish CBC e ~ 138–157 MB / sec per AES CBC (questo chip ha istruzioni AES-NI). Quindi ~ 200–300 MB / sec per sha256. Quindi può spingere a malapena 1 gigabit. Con OpenSSH 6.1+, è possibile utilizzare AES GCM, cosa che può fare a tassi di accecamento (370–1320 MB / sec, a seconda della dimensione del messaggio). Quindi penso che sia solo vero che OpenSSH ha un piccolo overhead se si esegue 6.1+ su un chip con AES-NI e si utilizza AES-GCM.
derobert,

1
L'ho cambiato in 6.1+ anziché 6.2+ all'ultimo minuto, dopo aver ricontrollato rapidamente. Certo, quello è stato un errore, sono i cambiamenti dal 6.1. Quindi OpenSSH 6.2+ è la versione corretta. E non mi permetterà più di modificare il commento ora. I commenti più vecchi di 5 minuti devono rimanere errati. Naturalmente, se inferiore a OpenSSH 6.4, vedere openssh.com/txt/gcmrekey.adv come senza patch, si è verificato un difetto sfruttabile nell'implementazione AES-GCM di OpenSSH.
derobert,

Il sovraccarico per ssh(o rsync su ssh) è molto, MOLTO importante. Ho un NAS che utilizza una CPU Intel Atom. La crittografia SSH ASSOLUTAMENTE TANK la velocità di trasferimento. Ricevo costantemente <400 Mbit / sec per RSA, l'override manuale in RC4 mi porta a ~ 600 Mbits / sec, e se uso rsync come demone, funziona alla velocità nativa del collegamento (> 900 MBit / sec, su un gigabit connessione).
Nome falso

Sebbene sia vero che per molte situazioni, il trasporto non è fondamentale, è assolutamente importante considerarlo, in particolare se non si esegue hardware estremamente sofisticato. Nel mio caso, Atom (è un D525, dual core da 1,8 Ghz) è un NAS perfettamente funzionante, con molta velocità per le PMI, ma la crittografia lo uccide assolutamente.
Nome falso

2
Ottengo un errore fatale a causa della parametrizzazione di mbuffer: 'mbuffer: fatale: la memoria totale deve essere maggiore della dimensione del blocco \ n Terminato'. Per correggere, sospetto che dovrebbe leggere qualcosa come 'mbuffer -s 1K -m 512M' con la 'M' finale che sta per MByte (fonte: man mbuffer)
Peter Lustig,

1

Non è nemmeno necessario utilizzare TCP. AoE è un'implementazione ATA su Ethernet, essendo il livello 2 è un approccio a basso costo senza conoscenza dello stack TCP / IP. Ti fornirà il trasferimento più veloce possibile con il minimo sovraccarico. ***

https://en.wikipedia.org/wiki/ATA_over_Ethernet

*** se la rete è il collo di bottiglia, assicurarsi di inviare dati compressi.


Caspita, è un nocciolo duro! :) Mi chiedo se ci sono parametri di riferimento ...
rogerdpack
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.