Forma rápida de copiar un archivo grande en una LAN

24

Tengo algunos problemas con NFS, y me gustaría intentar usar simplemente el viejo TCP.

Sin embargo, no tengo idea de por dónde empezar.

En cuanto al hardware, estoy usando un cable cruzado ethernet para conectar en red dos netbooks.

Para conectarlos en red, escribo

$ 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

en el primer netbook y

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

en el segundo

donde /mnt/network1se especifica en / etc / fstab como

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

así como en /etc/exports(usando la sintaxis de ese archivo), en el primer netbook.

Lo anterior funciona bien, pero los archivos y directorios son enormes. Los archivos promedian aproximadamente medio gigabyte por pieza, y los directorios tienen entre 15 y 50 gigabytes.

Estoy usando rsyncpara transferirlos, y el comando (on 192.168.1.2) es

$ rsync -avxS /mnt/network1 ~/somedir

No estoy seguro de si hay una manera de ajustar mi configuración de NFS para manejar mejor los archivos grandes, pero me gustaría ver si ejecutar un rsyncdemonio sobre TCP antiguo funciona mejor que rsyncsobre NFS.

Entonces, para reiterar, ¿cómo configuro una red similar con TCP?

ACTUALIZAR:

Entonces, después de un buen intento a las pocas horas de sacarme del pantano de mi propia ignorancia (o, como me gusta pensar, levantarme con mis propias botas), se me ocurrieron algunos datos útiles.

Pero antes que nada, lo que me llevó en este camino de conejos en lugar de simplemente aceptar la mejor respuesta actual fue: nces un programa increíblemente genial que resueltamente no funciona para mí. He probado el netcat-openbsdy netcat-traditionalpaquetes sin ningún tipo de suerte.

El error que obtengo en la máquina receptora ( 192.168.1.2) es:

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 da:

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

Pero, aquí están las buenas noticias: tener las direcciones IP estáticas establecidas /etc/network/interfaces, lo que comencé a hacer mientras intentaba nctrabajar, solucionó todos mis problemas de NFS y reavivó mi amor por NFS.

La configuración exacta que utilicé (con 192.168.1.1la primera netbook, por supuesto) fue:

auto eth0
iface eth0 inet static
address 192.168.1.2
netmask 255.255.255.0

Con esa configuración, las dos netbooks podrán hacer ping entre sí directamente después de arrancar, sin siquiera una ifup.

De todos modos, todavía me gustaría ver ncen acción, así que espero que alguien me ayude a depurar este proceso.

ixtmixilix
fuente
Si ambos directorios son locales, es mejor que solo use el viejo /bin/cpo no use NFS en absoluto
Karlson el
1
Ejecutar rsync contra un archivo al que se accede a través de NFS significa que todo el contenido del archivo debe copiarse en la red al menos una vez. No necesita un demonio para invocar un rsync de cliente / servidor, simplemente ejecútelo a través de ssh. (es teóricamente posible invocar el extremo remoto a través de telnet / rsh, pero es bastante tonto ejecutar un servicio de este tipo en la práctica, ssh no agrega mucha sobrecarga).
symcbean
NFSv2 es bastante viejo. ¿Qué sistema operativo estás usando?
Nils
el último Debian y el último Ubuntu, respectivamente. obtuve todos esos comandos (incluido nfsvers=2) de este tutorial ( michaelminn.com/linux/home_network )
ixtmixilix
55
en realidad, ssh agrega una gran cantidad de gastos generales, el cifrado no es barato. A velocidades normales de Internet, no importa, pero a través de una LAN (o una conexión cruzada directa, en este caso) puede notar. Más de gigabit, excepto en las máquinas más rápidas (o las que tienen instrucciones AES-NI, si SSH las usa), estoy bastante seguro de que se notará.
derobert

Respuestas:

43

El camino rapido

La más rápida manera de transferir archivos a través de una LAN probable es que no es rsync, a menos que haya pocos cambios. rsync pasa bastante tiempo haciendo sumas de verificación, calculando diferencias, etc. Si sabe que va a transferir la mayoría de los datos de todos modos, simplemente haga algo como esto (nota: hay múltiples implementaciones de netcat; revise el manual para las opciones correctas. En particular, la suya podría no querer -p):

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

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

Que usa netcat (nc ) para enviar tar a través de una conexión TCP sin procesar en el puerto 1234. No hay cifrado, comprobación de autenticidad, etc., por lo que es muy rápido. Si su conexión cruzada se ejecuta a gigabit o menos, vinculará la red; si es más, vinculará el disco (a menos que tenga una matriz de almacenamiento o un disco rápido). Las vbanderas para tar hacen que imprima los nombres de los archivos a medida que avanza (modo detallado). Con archivos grandes, prácticamente no hay gastos generales. Si estuvieras haciendo toneladas de archivos pequeños, lo apagarías. Además, puede insertar algo como pven la tubería para obtener un indicador de progreso:

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

Por supuesto, también puede insertar otras cosas, como gzip -1 (y agregar el zindicador en el extremo receptor; el zindicador en el extremo emisor usaría un nivel de compresión superior a 1, a menos que establezca la variable de entorno GZIP, por supuesto). Aunque gzip probablemente será más lento, a menos que sus datos realmente se compriman.

Si realmente necesitas rsync

Si realmente solo está transfiriendo una pequeña porción de los datos que han cambiado, rsync puede ser más rápido. También es posible que desee ver el-W--whole-file opción / , como con una red realmente rápida (como una conexión cruzada) que puede ser más rápida.

La forma más fácil de ejecutar rsync es a través de ssh. Querrá experimentar con los cifrados ssh para ver cuál es el más rápido, ya sea AES, ChaCha20 o Blowfish (aunque existen algunas preocupaciones de seguridad con el tamaño de bloque de 64 bits de Blowfish), dependiendo de si su chip tiene el AES de Intel -NI instrucciones (y tu OpenSSL las usa). En un ssh lo suficientemente nuevo, rsync-over-ssh se ve así:

user@source:~$ rsync -e 'ssh -c [email protected]' -avP /source/ user@dest-ip:/target

Para ssh / sshd anteriores, intente aes128-ctroaes128-cbc en lugar de [email protected].

ChaCha20 sería [email protected] (también necesita un ssh / sshd lo suficientemente nuevo) y Blowfish sería blowfish-cbc. OpenSSH no permite ejecutar sin un cifrado. Por supuesto, puede usar las opciones de rsync que desee en lugar de -avP. Y, por supuesto, puede ir en la otra dirección y ejecutar el rsync desde la máquina de destino (pull) en lugar de la máquina de origen (push).

Hacer rsync más rápido

Si ejecuta un demonio rsync, puede deshacerse de la sobrecarga de cifrado. Primero, crearía un archivo de configuración de daemon ( /etc/rsyncd.conf), por ejemplo en la máquina fuente (lea la página de manual de rsyncd.conf para más detalles):

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

Luego, en la máquina de destino, ejecutaría:

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

También puede hacer esto al revés (pero, por supuesto, tendrá que configurar la lectura solo como no). Hay opciones de autenticación, etc., consulte la página de manual para obtener más detalles.

derobert
fuente
2
Esta es una excelente respuesta. El otro también es genial. ¿No hay una respuesta aceptada solo porque el autor de la pregunta no puede elegir entre ellos?
sudo
¿Qué tan robusto es el netcatenfoque? Si la red descarta paquetes, parece que perderá partes aleatorias de los archivos.
sudo
1
@sudo está utilizando TCP, que retransmitirá según sea necesario. Por lo tanto, debería estar bien contra la pérdida de paquetes, la corrupción aleatoria (en la medida en que las sumas de comprobación de TCP y Ethernet lo atrapen), etc. Por supuesto, no es seguro contra ataques como el túnel sobre ssh.
derobert
1
@sudo puedes hacerlo todo a la vez, inserta algunos teecomandos en la tubería en ambos lados para calcular las sumas de verificación.
derobert
1
@TheStoryCoder El punto en la tarparte le dice que haga el directorio actual. Eso no es realmente parte del nccomando, tar se está utilizando para crear un archivo tar, que se está canalizando a netcat (y, por otro lado, netcat se está canalizando a tar para extraer el archivo). Estoy un comentario miedo no es realmente suficiente para explicar las tuberías, pero es de esperar que sea lo suficientemente para que pueda empezar ...
Derobert
17

¿Cómo? O TL; DR

El método más rápido que he encontrado es una combinación de tar, mbufferyssh .

P.ej:

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

Con esto, he logrado transferencias de red local sostenidas de más de 950 Mb / s en enlaces de 1 Gb. Reemplace las rutas en cada comando tar para que sean apropiadas para lo que está transfiriendo.

¿Por qué? mbuffer!

El mayor cuello de botella en la transferencia de archivos grandes a través de una red es, con mucho, la E / S de disco. La respuesta a eso es mbuffero buffer. Son en gran medida similares pero mbuffertiene algunas ventajas. El tamaño predeterminado del búfer es de 2 MB para mbuffery 1 MB para buffer. Es más probable que los buffers más grandes nunca estén vacíos. Elegir un tamaño de bloque que sea el múltiplo común más bajo del tamaño de bloque nativo tanto en el sistema de archivos de destino como en el de destino dará el mejor rendimiento.

Buffering es lo que hace que todo la diferencia! ¡Úselo si lo tiene! Si no lo tienes, ¡consíguelo! Usar (m}?buffermás cualquier cosa es mejor que cualquier cosa por sí mismo. Es casi literalmente una panacea para las transferencias lentas de archivos de red.

Si está transfiriendo múltiples archivos, úselos tarpara agruparlos en un solo flujo de datos. Si es un archivo único que puede usar cato redireccionamiento de E / S. La sobrecarga de tarvs. cates estadísticamente insignificante, por lo que siempre uso tar(o zfs -senddonde puedo) a menos que ya sea un tarball . Ninguno de estos está garantizado para darle metadatos (y en particular catno lo hará). Si desea metadatos, lo dejaré como un ejercicio para usted.

Finalmente, el uso sshde un mecanismo de transporte es seguro y lleva muy poca carga. Nuevamente, la sobrecarga de sshvs. nces estadísticamente insignificante.

bahamat
fuente
44
openssl speeden un i7-3770 da ~ 126–146 MB / seg para CBC blowfish y ~ 138–157 MB / seg para CBC AES (este chip tiene instrucciones AES-NI). Entonces ~ 200–300 MB / seg para sha256. Por lo tanto, apenas puede empujar 1 gigabit. Con OpenSSH 6.1+, puede usar AES GCM, que puede hacerlo a velocidades de cegamiento (370–1320 MB / seg, dependiendo del tamaño del mensaje). Así que creo que es cierto que OpenSSH tiene poca sobrecarga si está ejecutando 6.1+ en un chip con AES-NI y usando AES-GCM.
derobert
1
Ugh, cambié eso a 6.1+ en lugar de 6.2+ en el último minuto, después de haber revisado rápidamente. Por supuesto, eso fue un error, son cambios desde 6.1. Entonces OpenSSH 6.2+ es la versión correcta. Y ya no me dejará editar el comentario. Los comentarios anteriores a 5 minutos deben permanecer incorrectos. Por supuesto, si es menor que OpenSSH 6.4, consulte openssh.com/txt/gcmrekey.adv ya que sin un parche, hubo una falla explotable en la implementación de AES-GCM de OpenSSH.
derobert
La sobrecarga para ssh(o rsync sobre ssh) es muy, MUY importante. Tengo un NAS que usa una CPU Intel Atom. El cifrado SSH ABSOLUTAMENTE TANQUEA la velocidad de transferencia. Obtengo constantemente <400 Mbit / seg para RSA, anularlo manualmente a RC4 me da ~ 600 Mbits / seg, y si uso rsync como demonio, se ejecuta a la velocidad nativa del enlace (> 900 MBit / seg, en un gigabit conexión).
Nombre falso el
Si bien es cierto que para muchas situaciones, el transporte no es crítico, es absolutamente importante tenerlo en cuenta, especialmente si no se ejecuta en hardware de alta gama. En mi caso, el Atom (es un D525, dual core de 1.8 Ghz) lo convierte en un NAS completamente fino, con mucha velocidad para SMB, pero el cifrado lo mata por completo.
Nombre falso el
2
Obtengo un error fatal debido a la parametrización de mbuffer: 'mbuffer: fatal: la memoria total debe ser mayor que el tamaño del bloque \ n Terminado'. Para corregir, sospecho que debería leer algo como 'mbuffer -s 1K -m 512M' con la 'M' final que significa MByte (fuente: man mbuffer)
Peter Lustig
1

Ni siquiera necesita usar TCP. AoE es una implementación de ATA a través de Ethernet, siendo la capa 2, es un enfoque de gastos generales más bajos sin conocimiento de la pila TCP / IP. Le proporcionará la transferencia más rápida posible con la menor sobrecarga. ***

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

*** si la red es el cuello de botella, asegúrese de enviar datos comprimidos.

William Deans
fuente
Wow, eso es núcleo duro! :)
Me