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

111

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 [email protected] '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.

networking backup dd file-transfer IQAndreas
fuente
54
No te olvides de sneakernet
gwillie
44
¿Quieres transferir /dev/sdacomo una imagen o simplemente los archivos? ¿Por qué rsync no tiene opción? ¿Está /dev/sdamontado mientras dded?
Jodka Lemon
15
Sus datos de rendimiento (1 GB / 80 segundos, 80 GB / 1 h) coinciden perfectamente con lo que deberíamos esperar en 100 MB. Verifica tu hardware. ... y gerrit tiene razón, 320 GB pueden ser grandes, pero la "gran cantidad de datos" genera expectativas erróneas.
blafasel
8
"Nunca subestimes el ancho de banda de un tren de carga lleno de discos". .. ¿Estás preguntando sobre el rendimiento, la latencia o alguna combinación de ambos?
keshlam
8
Un amigo mío siempre decía: "Nunca subestimes el ancho de banda de una pila de discos duros en un camión".
AMADANON Inc.

Respuestas:

139

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.

BlueRaja - Danny Pflughoeft
fuente
15
+1: La transferencia por vía física parece ser la ruta más rápida, incluso si eso significa obtener un gran disco duro externo desde algún lugar. Es alrededor de £ 40, y es probable que he pasado mucho tiempo ya,
deworde
3
Estoy completamente en desacuerdo con esta idea si uno está obteniendo la máxima velocidad en una red de gigabits. Las pruebas a través de NFS / SMB a través de un conmutador Gigabit Zyxel entre un microservidor HP Gen 7 y una máquina Pentium G630 me dan una transferencia de ~ 100 MB / s. (Hasta que salga del borde exterior de los discos de la unidad). Así que creo que sería realista en menos de 3 horas. A menos que esté utilizando SSD o unidades / almacenamiento de alto rendimiento, no creo que 2 copias puedan producir un rendimiento de 100 MB / s, eso requeriría que cada operación de copia sea de 200 MB / s solo para alcanzar el punto de equilibrio.
Phises
3
@Phizes: obviamente no se copia a un temporal. Esa fue la mala idea de Deword, no de lo que todos los demás están hablando. El punto de conectar la unidad de origen a la máquina de destino es ir SATA-> SATA con dd(o una copia de árbol del sistema de archivos).
Peter Cordes
10
"Nunca subestimes el ancho de banda de un camión lleno de discos duros. Sin embargo, una latencia infernal"
Kevin
3
@ Kevin: sí, mi punto era que una copia directa entre discos en la misma computadora es al menos tan rápida como cualquier otro método posible. Saqué los números de ancho de banda de la vida real para reconocer el punto de Phize de que repasar gigE está bien para la unidad anterior de los OP, pero un cuello de botella para las nuevas unidades. (Un caso donde ambas unidades en una computadora no es la mejor opción es cuando tener computadoras separadas que usan su RAM para almacenar en caché los metadatos de la fuente y el destino es importante, por ejemplo, para rsync de miles de millones de archivos.)
Peter Cordes
69

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
zackse
fuente
2
Para el segundo ejemplo, ¿es ddincluso obligatorio, o puede pv/ nctratarse /dev/sdabien solo? (He notado que algunos comandos "vomitan" cuando intento leer archivos especiales como ese, o archivos con 0x00bytes)
IQAndreas
55
@ user1794469 ¿Ayudará la compresión? Estoy pensando que la red no está donde está el cuello de botella.
IQAndreas
17
No olvide que en bashuno puede usar > /dev/tcp/ el  / puerto IP y < /dev/tcp/ las  redirecciones de / puerto IP en lugar de canalizar hacia y desde netcat respectivamente.
Incnis Mrsi
55
Buena respuesta. Gigabit Ethernet a menudo es más rápido que la velocidad del disco duro, por lo que la compresión es inútil. Para transferir varios archivos considere tar cv sourcedir | pv | nc dest_host_or_ip 9999y cd destdir ; nc -l 9999 | pv | tar xv. Son posibles muchas variaciones, es posible que desee, por ejemplo, mantener una .tar.gzen el lado de destino en lugar de copias. Si copia un directorio a otro, para mayor seguridad, puede realizar una sincronización posterior, por ejemplo, desde dest rsync --inplace -avP [email protected]:/path/to/source/. /path/to/destination/., garantizará que todos los archivos sean copias exactas.
Stéphane Gourichon
3
En lugar de usar IPv4, puede lograr un mejor rendimiento al usar IPv6 porque tiene una mayor carga útil. Ni siquiera lo configura, si las máquinas son compatibles con IPv6, probablemente ya tengan una dirección local de enlace IPv6
David Costa
33

  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
mikeserv
fuente
1
Fantástica respuesta. Un punto gramatical menor: "disminuir la cantidad de datos que necesita intercambiarse por ráfaga", creo que está utilizando la compresión para aumentar la densidad de información ya que las 'ráfagas' son de ancho fijo y, por lo tanto, la cantidad de datos intercambiados permanece constante aunque la información transferida por ráfaga puede variar.
Ingeniero Dollery
@EngineerDollery: sí, eso fue tonto. Creo que es mejor,
mikeserv
@ IQAndreas: consideraría seriamente esta respuesta. Personalmente uso pigz, y el aumento de velocidad es increíble . El paralelismo es una gran victoria; Las CPU son mucho más rápidas que cualquier otra parte de la tubería de datos, por lo que dudo que la compresión paralela lo desacelere (gzip no es paralelizable). Puede encontrar esto lo suficientemente rápido como para que no haya incentivos para hacer malabarismos con los discos duros; No me sorprendería si este es en general más rápido (incluido el tiempo de intercambio de disco). Se puede comparar con y sin compresión. En cualquier caso, la respuesta de intercambio de discos de BlueRaja o esta debería ser su respuesta aceptada.
Mike S
La compresión rápida es un excelente consejo. Sin embargo, debe tenerse en cuenta que solo ayuda si los datos son razonablemente comprimibles, lo que significa, por ejemplo, que ya no deben estar en un formato comprimido.
Walter Tross
@WalterTross: ayudará si alguna entrada es compresible, sin importar la relación, siempre que el trabajo de compresión supere al trabajo de transferencia. En un sistema moderno de cuatro núcleos, un lz4trabajo debería seguir fácilmente incluso a GIGe completamente abierto, y USB 2.0 no tiene ninguna posibilidad. Además, lz4fue diseñado solo para funcionar cuando debería, en parte es muy rápido porque sabe cuándo se debe intentar la compresión y cuándo no. Y si se está transfiriendo un archivo de dispositivo, incluso la entrada precomprimida puede comprimirse de alguna manera si hay alguna fragmentación en el sistema de archivos de origen.
mikeserv
25

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.

Khrystoph
fuente
12
+1 para rsync. Puede que no sea más rápido la primera vez que lo ejecute, pero ciertamente lo será para todas las veces posteriores.
Skrrp
44
> La mayoría de los discos duros de 7200 rpm solo obtendrán alrededor de 40 MB / s. IME es más probable que vea más de 100 MB / s secuenciales con una unidad moderna (y esto incluye ~ 5k unidades). Sin embargo, este podría ser un disco más antiguo.
Bob
2
@Bob: los modernos todavía pueden leer solo 5400 pistas circulares por minuto. Estos discos siguen siendo rápidos porque cada pista contiene más de un megabyte. Eso significa que también son discos bastante grandes, un disco pequeño de 320 GB no puede contener demasiados kilobytes por pista, lo que necesariamente limita su velocidad.
MSalters
1
40 MB / s es definitivamente muy pesimista para la lectura secuencial de cualquier unidad realizada en la última década. Las unidades actuales de 7200 RPM pueden superar los 100 MB / s, como dice Bob.
hobbs
3
Gigabit Ethernet es 1000 mbps full duplex . Obtienes 1000mbps (o, como dices, alrededor de 900mbps en realidad) en cada dirección . Segundo ... los discos duros ahora obtienen de manera rutinaria 100 MB / seg. 40 MB / seg es lento, a menos que sea una unidad de una década de antigüedad.
derobert
16

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.

zxq9
fuente
1
@jofel Solo cuando la velocidad de la red es más lenta que el rendimiento de compresión del procesador, lo que nunca es cierto para conexiones de 1 gpbs o más. Sin embargo, en el caso típico, la red es el cuello de botella y la compresión acelera las cosas de manera efectiva, pero este no es el caso que describe el OP.
zxq9
2
lz4es lo suficientemente rápido como para no obstaculizar la presentación, pero dependiendo de lo que desee hacer con la copia, es posible que la necesite sin comprimir. lzop también es bastante rápido. En mi i5-2500k Sandybridge (3.8GHz), lz4 < /dev/raid0 | pv -a > /dev/nullva a ~ 180MB / s de entrada, ~ 105MB / s de salida, justo para gigE. Descomprimir en el lado de recepción es aún más fácil en la CPU.
Peter Cordes
1
Además, 3.8GHz es bastante más rápido que la mayoría de los procesadores de servidores (o muchos sistemas de nivel empresarial de cualquier sabor, al menos que estoy acostumbrado a ver). Es más común ver recuentos de núcleos mucho más altos con velocidades de reloj mucho más bajas en los centros de datos. La paralelización de las cargas de transferencia no ha sido un problema durante mucho tiempo, por lo que estamos atascados con la velocidad máxima de un solo núcleo en la mayoría de los casos, pero espero que esto cambie ahora que las velocidades de reloj generalmente están al máximo, pero las velocidades de red todavía tienen un un largo camino por recorrer antes de alcanzar sus máximos.
zxq9
2
Estoy completamente en desacuerdo con sus comentarios sobre la compresión. Depende completamente de la capacidad de compresión de los datos. Si pudiera obtener una relación de compresión del 99.9%, sería una tontería no hacerlo, ¿por qué transferir 100GB cuando puede salirse con la transferencia de 100MB? No estoy sugiriendo que este nivel de compresión sea el caso para esta pregunta, solo estoy demostrando que esto debe considerarse caso por caso y que no hay reglas absolutas.
Ingeniero Dollery
1
@EngineerDollery Esto no se juega en la transferencia masiva en absoluto en el mundo real. Hago esto casi todos los días y he probado una variedad de métodos y configuraciones. En el caso general, las grandes transferencias masivas de datos desconocidos (cualquier cosa en la que no tenga tiempo para ejecutar pruebas de ajuste de compresión, lo que significa que en la práctica casi todo en cualquier centro de datos, infraestructura corporativa, servidor de pequeñas empresas o red doméstica) es mucho más rápido a través de una conexión de 1gbps o superior. Ve a probarlo. El texto suele ser el mejor caso para la compresión. El texto comprende una pequeña fracción de una carga útil típica de transferencia masiva.
zxq9
6

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.

Corazón oscuro
fuente
1
El segundo enlace de esta respuesta explica cómo ajustar los parámetros del kernel para alcanzar velocidades más altas. El autor obtuvo 800 megabytes por segundo en enlaces de 10G y algunas cosas parecen aplicables a enlaces de 1Gbps.
Stéphane Gourichon
5

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

Saltando conejito
fuente
2
Rsync es más confiable que netcat, pero el archivo implica recursivo, por lo que r es redundante.
Tanath
Además, -zpuede ser increíblemente lento dependiendo de su CPU y qué datos está procesando. He experimentado transferencias que van de 30 MB / sa 125 MB / s cuando desactivé la compresión.
Lindhe
4

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
Incnis Mrsi
fuente
bash aparentemente no puede "escuchar" en un socket aparentemente, para esperar y recibir un archivo: unix.stackexchange.com/questions/49936/… así que tendría que usar algo más para al menos la mitad de la conexión ...
rogerdpack
3

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.

Brandon Xavier
fuente
2

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.

Skaperen
fuente
2

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?

usuario133111
fuente
1

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).

coteyr
fuente
1
¿Cómo acelera la transferencia de datos 400G de RAM?
Skaperen
No estoy seguro de que esta fuera la intención, pero lo leí como "cualquier medio más lento que la transferencia de RAM a RAM tomará un tiempo", en lugar de "comprar 400 GB de RAM y su transferencia de HDD a HDD irá más rápido".
MichaelS
Sí, ram te amortiguará y parecerá más rápido. Puede hacer una transferencia de HD a HD con RAM en búfer todo el tiempo y parecerá muy rápido. También tomará bastante tiempo descargar el disco, pero HD a RAM a RAM a HD es más rápido que HD a HD. (Tenga en cuenta que tiene que hacer HD a RAM a RAM a HD de todos modos, pero si tiene menos de su tamaño completo de transferencia de RAM, tendrá que "vaciar" en segmentos.)
coteyr
Otra forma de decirlo es que para comprimir o incluso simplemente enviar toda la unidad fuente debe leerse en la memoria RAM. Si no cabe todo a la vez, tiene que leer un segmento, enviar, descartar segmento, buscar, leer segmento, etc. Si cabe todo de una vez, entonces solo tiene que leer todo de una vez. Lo mismo en el destino.
coteyr
1
HD a RAM a RAM a HD es más rápido que HD a HD ¿Cómo puede ser más rápido?
AL
1

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.

Mike Ciaraldi
fuente
2
¿Puede proporcionar detalles de cómo está "extrayendo" archivos? ¿Qué utilidades está utilizando y puede proporcionar alguna muestra que muestre este efecto?
STW
No estoy seguro de si esta será una respuesta más completa, pero considere este escenario: suponga que tiene dos computadoras, foo y bar, y desea copiar datos de foo a bar. (1) Inicia sesión en foo, luego monta remotamente la unidad que está físicamente conectada a la barra. Luego copia del disco de foo en el directorio montado remotamente (que está físicamente en la barra). Llamé a esto empujando los datos a la otra computadora. (2) Compare esto con la otra forma de copiar los mismos datos. Inicie sesión en bar, monte de forma remota el directorio adjunto a foo y lea desde foo en la unidad de disco de bar. Esto está tirando.
Mike Ciaraldi
Esta copia se puede hacer con el comando cp de Linux, desde un administrador de archivos GUI o cualquier otra forma de copiar archivos. Creo que la extracción resulta ser más rápida porque la escritura es más lenta que la lectura, y muchas de las decisiones sobre cómo escribir en el disco de destino se toman en la misma computadora a la que está conectada la unidad, por lo que hay menos sobrecarga. Pero tal vez este ya no sea el caso con los sistemas más modernos.
Mike Ciaraldi
1

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.

Byron Jones
fuente
Si se refiere al LACP (Protocolo de control de agregación de enlaces), no verá un aumento en la velocidad. Proporcionó redundancia y cierta capacidad para servir más conexiones concurrentes, pero no proporcionará un aumento de velocidad para este tipo de transferencia.
STW
@STW: Requiere soporte de conmutador para agregar dos enlaces a una máquina en un enlace de 2 gbit, pero es posible. Sin embargo, es útil solo si ambas máquinas tienen un enlace de 2 gbits al conmutador. Si tiene dos cables que ejecutan NIC <-> NIC, sin interruptor, eso también debería funcionar, pero no es muy útil (a menos que tenga una tercera NIC en una máquina para mantenerlos conectados a Internet).
Peter Cordes
¿Hay un nombre específico para esta función en los conmutadores?
STW
Hay varias variaciones de NIC-teaming, EtherChannel, etc. STW es adecuado para ciertas configuraciones, esto no ayudará, pero para algunas configuraciones, lo haría. Todo se reduce a si el canal unido acelera o no el rendimiento de un solo socket IP o no. Tendrá que investigar los detalles para determinar si esta es una solución viable para usted.
Byron Jones
802.3ad es el estándar abierto que buscarías en tus conmutadores. Sin embargo, como un truco rápido, es posible que solo conecte NIC adicionales a la red y les dé las direcciones IP apropiadas en subredes separadas en el espacio de direcciones privadas. (host 1 puerto a y host 2 puerto a obtienen una subred, host 1 puerto b y host 2 puerto b obtienen otra subred). Luego, ejecute dos trabajos paralelos para realizar la transferencia. Esto será mucho más simple que aprender los entresijos de Etherchannel, 802.3ad, etc.
Dan Pritts
1

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
ttstooge
fuente
1

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.

Peter Cordes
fuente
1

¡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 ...

usuario133526
fuente
1

¿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


fuente
¿Cómo mejorará las tasas de velocidad? ¿Puedes explicarme tu respuesta?
AL
1
Potencialmente mejoraría la velocidad porque no tendría que preocuparse de que la red intermedia lo desacelerara. Con respecto a los cables de Ethernet "típicos" frente a los "cruzados", Ethernet de 1 Gb se cruzará automáticamente según sea necesario. Los conmutadores Ethernet de HP harán esto a 100Mb. Otras marcas, generalmente no, y necesitarás un crossover si estás atascado a 100Mb.
Dan Pritts
1

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.

Dan Pritts
fuente
0

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 ...

rogerdpack
fuente