¿Cuál es la forma más rápida de enviar grandes cantidades de datos entre dos computadoras? [cerrado]

Esta es una situación en la que estoy frecuentemente:

• Tengo un servidor de origen con un disco duro de 320 GB en su interior y 16 GB de RAM ( especificaciones exactas disponibles aquí , pero como este es un problema que también encuentro con frecuencia en otras máquinas, preferiría que la respuesta funcione en cualquier máquina Linux "razonable")
• Tengo un servidor de respaldo con varios terabytes de espacio en el disco duro ( especificaciones exactas aquí , ver descargo de responsabilidad más arriba)

Quiero transferir 320 GB de datos del servidor de origen al servidor de destino (específicamente, los datos de /dev/sda).

1. Las dos computadoras están físicamente una al lado de la otra, por lo que puedo tender cables entre ellas.
2. Estoy en una LAN y estoy usando un enrutador nuevo , lo que significa que la velocidad de mi red debería ser "idealmente" de 1000Mbit, ¿verdad?
3. La seguridad no es un problema. Estoy en una red local y confío en todas las máquinas de la red, incluido el enrutador.
4. (opcional) No necesito necesariamente una suma de verificación firmada de los datos, pero se debe detectar la comprobación básica de errores (como paquetes descartados o que la unidad se vuelva ilegible) en lugar de simplemente desaparecer en la salida.

Busqué esta pregunta en línea y probé varios comandos. La que aparece con más frecuencia es esta:

ssh user@192.168.1.100 'dd bs=16M if=/dev/sda | gzip' > backup_sda.gz

Este comando ha demostrado ser demasiado lento (se ejecutó durante una hora, solo obtuvo aproximadamente 80 GB a través de los datos). El paquete de prueba de 1 GB tardó aproximadamente 1 minuto y 22 segundos, y terminó siendo el doble de rápido cuando no se comprimió. Los resultados también pueden haber sido sesgados por el hecho de que el archivo transferido es menor que la cantidad de RAM en el sistema fuente.

Además (y esto fue probado en piezas de prueba de 1 GB), obtengo problemas si uso el gzipcomando y dd; el archivo resultante tiene una suma de comprobación diferente cuando se extrae en el destino, que si se canaliza directamente. Todavía estoy tratando de entender por qué sucede esto.

Dado que los servidores están físicamente uno al lado del otro, y usted mencionó en los comentarios que tiene acceso físico a ellos, la forma más rápida sería sacar el disco duro de la primera computadora, colocarlo en la segunda y transferir los archivos sobre la conexión SATA.

netcat es ideal para situaciones como esta donde la seguridad no es un problema:

# on destination machine, create listener on port 9999
nc -l 9999 > /path/to/outfile

# on source machine, send to destination:9999
nc destination_host_or_ip 9999 < /dev/sda
# or dd if=/dev/sda | nc destination_host_or_ip 9999

Tenga en cuenta que si está utilizando ddGNU coreutils, puede enviarlo SIGUSR1al proceso y emitirá progreso a stderr. Para BSD dd, use SIGINFO.

pv es aún más útil para informar el progreso durante la copia:

# on destination
nc -l 9999 | pv > /path/to/outfile

# on source
pv /dev/sda | nc destination_host_or_ip 9999
# or dd if=/dev/sda | pv | nc destination_host_or_ip 9999

1. No utilice rápida compresión.

   • Cualquiera que sea su medio de transferencia, especialmente para la red o el usb, estará trabajando con ráfagas de datos para lecturas, cachés y escrituras, y estas no estarán exactamente sincronizadas.
   • Además del firmware del disco, las memorias caché de disco y las memorias caché de kernel / ram, si también puede emplear las CPU de los sistemas de alguna manera para concentrar la cantidad de datos intercambiados por ráfaga, entonces debe hacerlo .
   • Cualquier algoritmo de compresión manejará automáticamente ejecuciones dispersas de entrada lo más rápido posible, pero hay muy pocas que manejen el resto en los rendimientos de la red.
   • lz4 es tu mejor opción aquí:

     LZ4 es un algoritmo de compresión sin pérdidas muy rápido, que proporciona velocidad de compresión a 400 MB / s por núcleo, escalable con CPU de múltiples núcleos. También presenta un decodificador extremadamente rápido, con velocidad en múltiples GB / s por núcleo, que generalmente alcanza los límites de velocidad de RAM en sistemas de múltiples núcleos.

2. Preferiblemente no busques innecesariamente.

   • Esto puede ser difícil de medir.

   • Si hay mucho espacio libre en el dispositivo desde el que copia, y el dispositivo no se ha puesto a cero recientemente, pero todos los sistemas de archivos de origen deben copiarse, entonces probablemente valga la pena hacerlo primero algo como:

     </dev/zero tee >empty empty1 empty2; sync; rm empty*

   • Pero eso depende de qué nivel debería estar leyendo la fuente. Por lo general, es deseable leer el dispositivo de principio a fin desde su /dev/some_diskarchivo de dispositivo, porque la lectura en el nivel del sistema de archivos generalmente implica buscar de ida y vuelta y alrededor del disco de manera no secuencial. Y entonces su comando de lectura debería ser algo como:

     </dev/source_device lz4 | ...

   • Sin embargo, si su sistema de archivos de origen no se debe transferir por completo, entonces la lectura a nivel del sistema de archivos es bastante inevitable, por lo que debe aumentar sus contenidos de entrada en una secuencia. paxgeneralmente es la mejor y más simple solución en ese caso, pero también puede considerarla mksquashfs.

     pax -r /source/tree[12] | lz4 | ...
     mksquashfs /source/tree[12] /dev/fd/1 -comp lz4 | ...
     

3. No sin cifrar con ssh.

   • Agregar gastos generales de cifrado a un medio confiable es innecesario y puede ser muy perjudicial para la velocidad de las transferencias sostenidas, ya que la lectura de datos necesita leerse dos veces .
   • El PRNG necesita los datos leídos, o al menos algunos de ellos, para mantener la aleatoriedad.
   • Y, por supuesto, también necesita transferir los datos.
   • También debe transferir la sobrecarga de cifrado, lo que significa más trabajo por menos datos transferidos por ráfaga .

   • Y, por lo tanto, debería usar netcat( o, como prefiero, el nmapproyecto es más capazncat ) para una copia de red simple, como se ha sugerido en otra parte:

     ###  on tgt machine...
     nc -l 9999 > out.lz4
     ###  then on src machine...
     ... lz4 | nc tgt.local 9999
     

Existen varias limitaciones que podrían limitar la velocidad de transferencia.

1. Hay una sobrecarga de red inherente en una tubería de 1 Gbps. Por lo general, esto reduce el rendimiento ACTUAL a 900 Mbps o menos. Luego debe recordar que se trata de tráfico bidireccional y debe esperar una disminución significativa de menos de 900 Mbps.

2. Aunque esté utilizando un "enrutador nuevo", ¿está seguro de que el enrutador admite 1 Gbps? No todos los nuevos enrutadores admiten 1 Gbps. Además, a menos que sea un enrutador de nivel empresarial, es probable que pierda ancho de banda de transmisión adicional para que el enrutador sea ineficiente. Aunque basado en lo que encontré a continuación, parece que estás superando los 100Mbps.

3. Podría haber congestión de red de otros dispositivos que comparten su red. ¿Has intentado usar un cable conectado directamente como dijiste que podías hacer?

4. ¿Qué cantidad de tu disco IO estás usando? Probablemente, estás limitado, no por la red, sino por la unidad de disco. La mayoría de los discos duros de 7200 rpm solo obtendrán alrededor de 40 MB / s. ¿Estás usando la incursión? ¿Estás usando SSD? ¿Qué estás usando en el extremo remoto?

Sugiero usar rsync si se espera que esto se vuelva a ejecutar para las copias de seguridad. También puede usar scp, ftp (s) o http utilizando un descargador como filezilla en el otro extremo, ya que paralelará las conexiones ssh / http / https / ftp. Esto puede aumentar el ancho de banda ya que las otras soluciones están en una sola tubería. Una sola tubería / subproceso todavía está limitada por el hecho de que tiene un solo subproceso, lo que significa que incluso podría estar vinculada a la CPU.

Con rsync, elimina una gran parte de la complejidad de su solución y permite la compresión, la conservación de permisos y permite transferencias parciales. Hay varias otras razones, pero generalmente es el método de respaldo preferido (o ejecuta los sistemas de respaldo) de las grandes empresas. Commvault en realidad usa rsync debajo de su software como mecanismo de entrega para las copias de seguridad.

Según su ejemplo dado de 80 GB / h, está obteniendo alrededor de 177 Mbps (22,2 MB / s). Creo que podría duplicar esto fácilmente con rsync en una línea de Ethernet dedicada entre las dos cajas, ya que he logrado obtener esto en mis propias pruebas con rsync a través de gigabit.

Nos ocupamos de esto regularmente.

Los dos métodos principales que tendemos a usar son:

1. SATA / eSATA / sneakernet
2. Montaje directo NFS, luego local cporsync

El primero depende de si la unidad se puede reubicar físicamente. Este no es siempre el caso.

El segundo funciona sorprendentemente bien. En general, maximizamos una conexión de 1 gbps con bastante facilidad con montajes NFS directos. No se acercará a esto con scp, dd sobre ssh o algo similar (a menudo obtendrá una tasa máxima sospechosamente cercana a 100mpbs). Incluso en procesadores multinúcleo muy rápidos, se encontrará con un cuello de botella en el rendimiento máximo de cifrado de uno de los núcleos en la más lenta de las dos máquinas, que es deprimentemente lento en comparación con cp o rsync de diámetro completo en un montaje de red sin cifrar. Ocasionalmente golpeará una pared de iops por un tiempo y se quedará atascado alrededor de ~ 53MB / s en lugar de los ~ 110MB / s más típicos, pero eso generalmente es de corta duración a menos que el origen o el destino sea realmenteun solo disco, entonces podría terminar estando limitado por la velocidad sostenida del disco en sí (que varía lo suficiente por razones aleatorias que no sabrá hasta que realmente lo pruebe) - meh.

NFS puede ser un poco molesto de configurar si está en una distribución desconocida, pero en general ha sido la forma más rápida de llenar las tuberías lo más completamente posible. La última vez que hice esto a más de 10 gbps, en realidad nunca descubrí si había maximizado la conexión, porque la transferencia terminó antes de que volviera de tomar un café, por lo que puede haber algún límite natural que alcance allí. Si tiene unos pocos dispositivos de red entre el origen y el destino, puede encontrar algunos retrasos leves o hipo del efecto furtivo de la red, pero generalmente esto funcionará en toda la oficina (sin otro tráfico que lo arruine) o desde un extremo del centro de datos hasta el otro (a menos que tenga algún tipo de filtrado / inspección que ocurra internamente, en cuyo caso todas las apuestas están desactivadas ).

EDITAR

Noté algunas conversaciones sobre la compresión ... no comprima la conexión. Te ralentizará de la misma manera que lo hará una capa criptográfica. El cuello de botella siempre será un núcleo único si comprime la conexión (y ni siquiera obtendrá una utilización particularmente buena del bus de ese núcleo). Lo más lento que puede hacer en su situación es usar un canal encriptado y comprimido entre dos computadoras ubicadas una al lado de la otra en una conexión de 1gbps o superior.

PRUEBA FUTURA

Este consejo está vigente a mediados de 2015. Esto seguramente no será el caso por muchos años más. Así que tome todo con un grano de sal, y si se enfrenta a esta tarea regularmente, intente una variedad de métodos con cargas reales en lugar de imaginar que obtendrá algo cercano a los óptimos teóricos, o incluso tasas de rendimiento de compresión / cifrado típicas para cosas como la web tráfico, gran parte del cual es textual (resumen: las transferencias masivas generalmente consisten principalmente en imágenes, audio, video, archivos de bases de datos, código binario, formatos de archivos de oficina, etc. que ya están comprimidosa su manera y se benefician muy poco de ser ejecutados a través de otra rutina de compresión, cuyo tamaño de bloque de compresión está casi garantizado de no alinearse con sus datos binarios ya comprimidos ...).

Me imagino que en el futuro conceptos como SCTP serán llevados a un lugar más interesante, donde las conexiones unidas (o conexiones de fibra canalizadas unidas internamente por espectro) son típicas, y cada canal puede recibir un flujo independiente de los demás, y cada uno el flujo puede ser comprimido / encriptado en paralelo, etc. etc. ¡Eso sería maravilloso! Pero ese no es el caso hoy en 2015, y aunque fantasear y teorizar es agradable, la mayoría de nosotros no tenemos clústeres de almacenamiento personalizados que se ejecutan en una cámara criogénica que alimentan los datos directamente a las entrañas de un Gene Azul / Q que genera respuestas para Watson. Eso no es realidad. Tampoco tenemos tiempo para analizar nuestra carga útil de datos exhaustivamente para determinar si la compresión es una buena idea o no: la transferencia en sí misma terminaría antes de que terminemos nuestro análisis,

Pero...

Los tiempos cambian y mi recomendación contra la compresión y el cifrado no se mantendrá. Realmente me encantaría que este consejo sea revocado en el caso típico muy pronto. Me facilitaría la vida.

Una herramienta ingeniosa que he usado en el pasado es bbcp. Como se ve aquí: https://www.slac.stanford.edu/~abh/bbcp/ .

Ver también http://pcbunn.cithep.caltech.edu/bbcp/using_bbcp.htm

He tenido velocidades de transferencia muy rápidas con esta herramienta.

Si obtiene un primer pase de alguna manera (por cable / sneakernet / lo que sea), puede buscar rsyncciertas opciones que pueden acelerar enormemente las transferencias posteriores. Un muy buen camino a seguir sería:

rsync -varzP sourceFiles destination

Las opciones son: detallado, modo de archivo, recursivo, comprimir, progreso parcial

Se agregó la insistencia del póster original en los comentarios a la respuesta de zackse, aunque no estoy seguro de que sea el más rápido en circunstancias típicas.

bashtiene una sintaxis especial redirección:
Para la salida:      > /dev/tcp/ IP  / puerto
Para la entrada:       < /dev/tcp/ IP  / puerto
IP prohibición sea ya sea IP decimal con puntos o un nombre de host; La prohibición de puertos puede ser un número decimal o un nombre de puerto /etc/services.

No hay /dev/tcp/directorio real . Es un kludge sintáctico especial que ordena bashcrear un socket TCP, conectarlo al destino especificado y luego hacer lo mismo que hace una redirección de archivo habitual (es decir, reemplazar la secuencia estándar respectiva con el socket usando dup2 (2)).

Por lo tanto, uno puede transmitir datos desde ddo taren la máquina fuente directamente a través de TCP. O, por el contrario, para transmitir datos taro algo similar directamente a través de TCP. En cualquier caso, se elimina un netcat superfluo.

Notas sobre netcat

Hay una inconsistencia en la sintaxis entre netcat clásico y netcat de GNU . Usaré la sintaxis clásica a la que estoy acostumbrado. Reemplace -lpcon -lpara GNU netcat.

Además, no estoy seguro de si GNU netcat acepta el -qinterruptor.

Transferir una imagen de disco

(En la línea de la respuesta de zackse.)
En el destino:

nc -lp 9999 >disk_image

En la fuente:

dd if=/dev/sda >/dev/tcp/destination/9999
 

Crear un archivo tar.gz, con tar

En destino:

nc -lp 9999 >backup.tgz

En la fuente:

tar cz files or directories to be transferred >/dev/tcp/destination/9999

Reemplace .tgzcon .tbzy czcon cjpara obtener un bzip2archivo comprimido.

Transferencia con expansión inmediata al sistema de archivos

También con tar.
En destino:

cd backups
tar x </dev/tcp/destination/9999

En la fuente:

tar c files or directories to be transferred |nc -q 1 -lp 9999

Funcionará sin -q 1, pero netcat se atascará cuando finalicen los datos. Ver tar (1) para la explicación de la sintaxis y advertencias de tar. Si hay muchos archivos con alta redundancia (baja entropía), entonces la compresión (e. G. cz, Y xzen lugar de cy x) puede ser tratado, pero si los archivos son típicos y la red es lo suficientemente rápido, sólo se frenaría el proceso. Consulte la respuesta de mikeserv para obtener detalles sobre la compresión.

Estilo alternativo (el puerto de escucha de destino)

En destino:

cd backups
nc -lp 9999 |tar x

En la fuente:

tar c files or directories to be transferred >/dev/tcp/destination/9999

Pruebe las sugerencias sobre conexiones directas y evite protocolos encriptados como ssh. Entonces, si aún desea obtener cada rendimiento, lea este sitio: https://fasterdata.es.net/host-tuning/linux/ para obtener algunos consejos sobre cómo optimizar sus ventanas TCP.

Usaría este script que escribí que necesita el socatpaquete.

En la máquina fuente:

tarnet -d wherefilesaretosend pass=none 12345 .

En la máquina de destino:

tarnet -d wherefilesaretogo pass=none sourceip/12345

Si el vbufpaquete (Debian, Ubuntu) está allí, el remitente del archivo mostrará un progreso de datos. El receptor de archivos mostrará qué archivos se reciben. La opción pass = se puede usar donde los datos pueden estar expuestos (más lento).

Editar:

Use la -nopción para desactivar la compresión, si la CPU es un cuello de botella.

Si el presupuesto no es la principal preocupación, puede intentar conectar las unidades con un "conector de unidad" Intel Xeon E5 de 12 núcleos. Este conector suele ser tan potente que incluso puede ejecutar el software del servidor actual en él. De ambos servidores!

Esto puede parecer una respuesta divertida, pero realmente debería considerar por qué está moviendo los datos entre servidores y si uno grande con memoria y almacenamiento compartidos podría tener más sentido.

¿No está seguro de las especificaciones actuales, pero la transferencia lenta puede estar limitada por las velocidades del disco, no por la red?

Si solo le interesan las copias de seguridad, y no un byte por copia de bytes del disco duro, le recomendaría backupPC. http://backuppc.sourceforge.net/faq/BackupPC.html Es un poco difícil de configurar, pero se transfiere muy rápidamente.

Mi tiempo de transferencia inicial para aproximadamente 500G de datos fue de alrededor de 3 horas. Las copias de seguridad posteriores se realizan en unos 20 segundos.

Si no está interesado en las copias de seguridad, pero está tratando de sincronizar las cosas, rsync o unison se adaptarían mejor a sus necesidades.

Un byte por copia de un disco duro suele ser una idea horrible para realizar copias de seguridad (sin incrementos, sin ahorro de espacio, la unidad no puede estar en uso, debe hacer una copia de seguridad del "espacio vacío" y debe hacer una copia de seguridad de la basura (como un archivo de intercambio de 16 G o 200G de volcados de núcleo o algo así). Usando rsync (o backuppc u otros) puede crear "instantáneas" a tiempo para que pueda ir a "cómo se veía su sistema de archivos hace 30 minutos" con Muy poco sobrecarga.

Dicho esto, si realmente desea transferir un byte por una copia de byte, entonces su problema radicará en la transferencia y no en la obtención de datos de la unidad. Sin 400G de RAM, una transferencia de archivos de 320G llevará mucho tiempo. El uso de protocolos que no están encriptados es una opción, pero pase lo que pase, solo tendrá que sentarse allí y esperar varias horas (a través de la red).

Independientemente del programa, generalmente he encontrado que "arrastrar" archivos a través de una red es más rápido que "empujar". Es decir, iniciar sesión en la computadora de destino y hacer una lectura es más rápido que iniciar sesión en la computadora de origen y escribir.

Además, si va a usar una unidad intermedia, tenga en cuenta esto: obtenga una unidad externa (ya sea como un paquete o una unidad separada conectada a una estación de acoplamiento) que utiliza eSATA en lugar de USB. Luego, en cada una de las dos computadoras, instale una tarjeta con un puerto eSATA u obtenga un cable adaptador simple que lleve uno de los puertos SATA internos a un conector externo eSATA. Luego, conecte la unidad a la computadora de origen, encienda la unidad y espere a que se monte automáticamente (puede montarla de manera manual, pero si lo hace repetidamente, también podría colocarla en su archivo fstab). Entonces copia; estará escribiendo a la misma velocidad que en una unidad interna. Luego desmonte la unidad, apague, conecte la otra computadora, encienda, espere un montaje automático y lea.

Voy a recomendar que veas el trabajo en equipo de NIC. Esto implica el uso de múltiples conexiones de red que se ejecutan en paralelo. Suponiendo que realmente necesita más de 1 Gb de transferencia, y que 10 Gb tiene un costo prohibitivo, 2 Gbs proporcionados por el equipo de NIC serían un costo menor, y sus computadoras ya pueden tener puertos adicionales.

FWIW, siempre he usado esto:

tar -cpf - <source path> | ssh user@destserver "cd /; tar xf -"

Lo que ocurre con este método es que mantendrá los permisos de archivo / carpeta entre las máquinas (suponiendo que existan los mismos usuarios / grupos en ambos) (También lo hago normalmente para copiar imágenes de disco virtual ya que puedo usar un parámetro -S para manejar archivos dispersos. )

Solo probé esto entre dos servidores ocupados y administré ~ 14GB en 216s (aproximadamente 64MB / s) - podría funcionar mejor entre máquinas dedicadas y / o compresión ... YMMV

$ date; tar -cpf - Installers | ssh elvis "cd /home/elvis/tst; tar xf -"; date
Wed Sep  9 15:23:37 EDT 2015
Wed Sep  9 15:27:13 EDT 2015

$ du -s Installers
14211072   Installers

A menos que desee realizar análisis forenses del sistema de archivos, use un programa de volcado / restauración para su sistema de archivos para evitar copiar el espacio libre que el FS no está utilizando. Dependiendo del sistema de archivos que tenga, esto normalmente conservará todos los metadatos, incluidos ctime. Sin embargo, los números de inodo pueden cambiar nuevamente, dependiendo de qué sistema de archivos (xfs, ext4, ufs ...).

El objetivo de restauración puede ser un archivo en el sistema de destino.

Si desea una imagen de disco completo con la tabla de particiones, puede ddusar el primer 1M del disco para obtener la tabla de particiones / cargadores de arranque / cosas, pero luego xfsdumplas particiones.

No puedo decir por su volcado de información qué tipo de sistema de archivos tiene realmente. Si es BSD ufs, entonces creo que tiene un programa de volcado / restauración. Si es ZFS, bueno IDK, puede haber algo.

Generalmente, los discos de copia completa son demasiado lentos para cualquier cosa, excepto situaciones de recuperación. Tampoco puede hacer copias de seguridad incrementales de esa manera.

¡También puede configurar los sistemas para tener un almacenamiento compartido!

Estoy considerando que estos están uno al lado del otro, y es probable que hagas esto una y otra vez ...

¿Qué tal un cable cruzado ethernet? En lugar de confiar en las velocidades inalámbricas, está limitado a la velocidad por cable de su NIC.

Aquí hay una pregunta similar con algunos ejemplos de ese tipo de solución.

Aparentemente, un cable típico de Ethernet será suficiente hoy en día. Obviamente, cuanto mejor sea su NIC, más rápida será la transferencia.

Para resumir, si es necesaria alguna configuración de red, debe limitarse simplemente a configurar IP estáticas para su servidor y computadora de respaldo con una máscara de subred 255.255.255.0

¡Buena suerte!

Editar:

@Khrystoph tocó esto en su respuesta

Varias personas recomiendan que omita ssh porque el cifrado lo ralentizará. Las CPU modernas en realidad pueden ser lo suficientemente rápidas a 1 Gb, pero OpenSSH tiene problemas con su implementación de ventanas internas que pueden ralentizarlo drásticamente.

Si desea hacer esto con ssh, eche un vistazo a HPN SSH . Resuelve los problemas de ventanas y agrega cifrado multiproceso. Lamentablemente, deberá reconstruir ssh tanto en el cliente como en el servidor.

OK Intenté responder esta pregunta para dos computadoras con "tuberías muy grandes" (10Gbe) que están "cerca" una de la otra.

El problema con el que se encuentra aquí es: la mayoría de las compresiones tendrán un cuello de botella en la CPU, ya que las tuberías son muy grandes.

rendimiento para transferir archivos de 10 GB (conexión de red de 6 Gb [linode], datos no comprimibles):

$  time bbcp 10G root@$dest_ip:/dev/null
0m16.5s 

iperf:

server: $ iperf3 -s -F /dev/null
client:
$ time iperf3 -c $dest_ip -F 10G -t 20 # -t needs to be greater than time to transfer complete file
0m13.44s
(30% cpu)

netcat (1.187 openbsd):

server: $ nc -l 1234 > /dev/null
client: $ time nc $dest_ip 1234 -q 0 < 10G 
0m13.311s
(58% cpu)

scp:

$ time /usr/local/bin/scp 10G root@$dest_ip:/dev/null
1m31.616s
scp with hpn ssh patch (scp -- hpn patch on client only, so not a good test possibly): 
1m32.707s

socat:

server:
$ socat -u TCP-LISTEN:9876,reuseaddr OPEN:/dev/null,creat,trunc
client:
$ time socat -u FILE:10G TCP:$dest_ip:9876
0m15.989s

Y dos cajas en 10 Gbe, versiones ligeramente anteriores de netcat (CentOs 6.7), archivo de 10GB:

nc: 0m18.706s (100% cpu, v1.84, no -q option
iperf3: 0m10.013s (100% cpu, but can go up to at least 20Gbe with 100% cpu so not sure it matters)
socat: 0m10.293s (88% cpu, possibly maxed out)

Entonces, en una instancia, netcat usó menos CPU, en la otra, entonces YMMV.

Con netcat, si no tiene una opción "-N -q 0", puede transferir archivos truncados, tenga cuidado ... otras opciones como "-w 10" también pueden generar archivos truncados.

Lo que sucede en casi todos estos casos es que la CPU se está maximizando, no la red. scpalcanza un máximo de aproximadamente 230 MB / s, vinculando un núcleo al 100% de utilización.

Iperf3 desafortunadamente crea archivos corruptos . Algunas versiones de netcat parecen no transferir todo el archivo, muy raro. Especialmente versiones anteriores de la misma.

Varios encantamientos de "gzip como una tubería a netcat" o "mbuffer" también parecían maximizar la CPU con gzip o mbuffer, por lo que no resultó en una transferencia más rápida con tuberías tan grandes. lz4 podría ayudar. Además, algunas de las cosas de gzip pipe que intenté resultaron en transferencias corruptas para archivos muy grandes (> 4 GB), así que ten cuidado :)

Otra cosa que podría funcionar especialmente para una mayor latencia (?) Es ajustar la configuración de TCP. Aquí hay una guía que menciona los valores sugeridos:

http://pcbunn.cithep.caltech.edu/bbcp/using_bbcp.htm y https://fasterdata.es.net/host-tuning/linux/ (de otra respuesta) posiblemente configuraciones IRQ: https://fasterdata.es .net / host-tuning / 100g-tuning /

sugerencias de linode, agregue a /etc/sysctl.conf:

net.core.rmem_max = 268435456 
net.core.wmem_max = 268435456 
net.ipv4.tcp_rmem = 4096 87380 134217728
net.ipv4.tcp_wmem = 4096 65536 134217728
net.core.netdev_max_backlog = 250000
net.ipv4.tcp_no_metrics_save = 1
net.core.default_qdisc = fq 

Además, les gustaría que ejecutaras:

 /sbin/ifconfig eth0 txqueuelen 10000 

Vale la pena revisar después de ajustar para asegurarse de que los cambios no causen daño también.

También puede valer la pena ajustar el tamaño de la ventana: https://iperf.fr/iperf-doc.php#tuningtcp

Sin embargo, con conexiones lentas (er), la compresión definitivamente puede ayudar. Si tiene tuberías grandes, la compresión muy rápida puede ayudar con datos fácilmente comprimibles, no lo he probado.

La respuesta estándar para "sincronizar discos duros" es sincronizar los archivos, lo que evita la transferencia siempre que sea posible.

Otra opción: use "paralela scp" (de una forma u otra), luego usará más núcleos ...