Multiplexación inversa para acelerar la transferencia de archivos

He enviado una gran cantidad de datos de una máquina a otra. Si envío con rsync (o cualquier otro método), irá a 320kb / seg. Si inicio dos o tres transferencias a la vez, cada una irá a 320, y si hago cuatro a la vez, maximizarán el enlace.

Necesito poder enviar datos lo más rápido posible, por lo que necesito una herramienta que pueda hacer multiplexación inversa con transferencias de archivos. Necesito una solución general, por lo que no es práctico ejecutar split en la máquina fuente y juntarlos en el otro extremo. Necesito que esto funcione de manera automatizada.

¿Existe alguna herramienta que haga esto o necesito hacer la mía? El remitente es CentOS, el receptor es FreeBSD.

Prueba de que todo suma: presento el 'santo grial' de los comandos de espejo remoto. Gracias a davr por la lftpsugerencia.

lftp -c "mirror --use-pget-n=10 --verbose sftp://username:password@server.com/directory" 

¡Lo anterior reflejará recursivamente un directorio remoto, dividiendo cada archivo en 10 hilos mientras se transfiere!

Hay un par de herramientas que podrían funcionar.

• LFTP : admite FTP, HTTP y SFTP. Admite el uso de múltiples conexiones para descargar un solo archivo. Suponiendo que desea transferir un archivo de remoteServer a localServer, instale LFTP en localServer y ejecute:

  lftp -e 'pget -n 4 sftp://userName@remoteServer.com/some/dir/file.ext'

  El '-n 4' es cuántas conexiones usar en paralelo.

• Luego están las muchas herramientas de 'acelerador de descarga', pero generalmente solo admiten HTTP o FTP, que es posible que no desee configurar en el servidor remoto. Algunos ejemplos son Axel , aria2 y ProZilla

Si usa pocos y grandes archivos lftp -e 'mirror --parallel=2 --use-pget-n=10 <remote_dir> <local_dir>' <ftp_server>: descargará 2 archivos con cada archivo dividido en 10 segmentos con un total de conexiones de 20 ftp <ftp_server>;

Si tiene una gran cantidad de archivos pequeños, use lftp -e 'mirror --parallel=100 <remote_dir> <local_dir>' <ftp_server>: descargará 100 archivos en paralelo sin segmentación, entonces. Se abrirán un total de 100 conexiones. Esto puede agotar los clientes disponibles en el servidor, o puede prohibirle el acceso a algunos servidores.

Puede usar --continuepara reanudar el trabajo :) y la -Ropción de cargar en lugar de descargar (luego cambiar el orden de los argumentos a <local_dir> <remote_dir>).

Es posible que pueda modificar su configuración de TCP para evitar este problema, dependiendo de lo que está causando los 320 KB / s por límite de conexión. Mi conjetura es que es no la velocidad de conexión por la limitación explícita por el ISP. Hay dos posibles culpables del estrangulamiento:

1. Algún vínculo entre las dos máquinas está saturado y descartando paquetes.
2. Las ventanas TCP están saturadas porque el producto de retraso de ancho de banda es demasiado grande.

En el primer caso, cada conexión TCP competiría efectivamente en el control estándar de congestión TCP. También podría mejorar esto cambiando los algoritmos de control de congestión o reduciendo la cantidad de retroceso.

En el segundo caso, no está limitado por la pérdida de paquetes. Agregar conexiones adicionales es una forma cruda de expandir el tamaño total de la ventana. Si puede aumentar manualmente el tamaño de las ventanas, el problema desaparecerá. (Esto podría requerir el escalado de la ventana TCP si la latencia de conexión es suficientemente alta).

Puede saber aproximadamente qué tan grande debe ser la ventana multiplicando el tiempo de "ping" de ida y vuelta por la velocidad total de la conexión. 1280 KB / s necesita 1280 (1311 para 1024 = 1 KB) bytes por milisegundo de ida y vuelta. Un búfer de 64K se maximizará con una latencia de aproximadamente 50 ms, lo cual es bastante típico. Un búfer de 16K se saturaría alrededor de 320KB / s.

¿Cómo se estructuran sus datos? ¿Algunos archivos grandes? ¿Algunos directorios grandes? Puede generar múltiples instancias de rsync en ramas específicas de su árbol de directorios.

Todo depende de cómo se estructuran sus datos de origen. Hay toneladas de herramientas Unix para cortar, cortar en dados y volver a montar archivos.

Si puede configurar el inicio de sesión ssh sin contraseña, esto abrirá 4 conexiones scp concurrentes (-n) con cada conexión manejando 4 archivos (-L):

encontrar . -tipo f | xargs -L 4 -n 4 /tmp/scp.sh usuario @ host: ruta

Archivo /tmp/scp.sh:

#!/bin/bash

#Display the help page
function showHelp()
{
    echo "Usage: $0 <destination> <file1 [file2 ... ]>"
}

#No arguments?
if [ -z "$1" ] || [ -z "$2" ]; then
    showHelp
    exit 1
fi

#Display help?
if [ "$1" = "--help" ] || [ "$1" = "-h" ]; then
    showHelp
    exit 0
fi

#Programs and options
SCP='scp'
SCP_OPTS='-B'
DESTINATION="$1";shift;

#Check other parameters
if [ -z "$DESTINATION" ]; then
    showHelp
    exit 1
fi

echo "$@"

#Run scp in the background with the remaining parameters.
$SCP $SCP_OPTS $@ $DESTINATION &

Intente ordenar todos los archivos en inode (find / mydir -type f -print | xargs ls -i | sort -n) y transfiéralos con, por ejemplo, cpio sobre ssh. Esto maximizará su disco y creará un cuello de botella en la red. Más rápido que eso, es difícil ir al cruzar la red.

Conozco una herramienta que puede transferir archivos en fragmentos. La herramienta se llama paquete / puerto 'rtorrent' que está disponible en ambos hosts;) Los clientes BitTorrent a menudo reservan espacio en el disco antes de la transferencia, y los fragmentos se escriben directamente desde los sockets al disco. Además, podrá revisar TODOS los estados de las transferencias en una bonita pantalla ncurses.

Puede crear scripts de bash simples para automatizar la creación de archivos "* .torrent" y enviar un comando a la máquina remota para que lo descargue. Esto se ve un poco feo, pero no creo que encuentre una solución simple sin desarrollar :)

FTP utiliza múltiples conexiones para descargas. Si puede configurar un canal seguro para FTP a través de una VPN o FTP a través de SSH , debería poder maximizar su enlace de red. (Tenga en cuenta que se requieren consideraciones especiales para FTP sobre SSH; consulte el enlace).

FTPS (FTP sobre SSL) también puede hacer lo que necesita.

También podría usar un cliente SFTP que admita múltiples conexiones, pero no estoy seguro de si SFTP admite múltiples conexiones para un solo archivo. Esto debería hacer lo que necesita la mayor parte del tiempo, pero es posible que no le brinde el rendimiento máximo cuando solo tiene que transferir un archivo grande.

Solución 1: no estoy seguro de si esto es práctico en su caso, pero podría crear un archivo extendido (por ejemplo, un archivo tar dividido en fragmentos o un archivo 7zip extendido), luego use varias instancias de rsync para enviarlos la red y reensamblarlos / extraerlos del otro lado. Podría escribir un script de propósito general cuyos argumentos son el directorio que se transferirá y la cantidad de conexiones que se utilizarán. La desventaja obvia es que necesitará el doble de espacio libre en ambos lados, y tendrá la sobrecarga adicional de archivar / extraer los archivos en ambos extremos.

Solución 2: una mejor solución sería escribir un script o programa que divida el árbol de directorios grande en subárboles según el tamaño, luego copia esos subárboles en paralelo. Podría simplificar las cosas si copia primero toda la estructura de directorios (sin los archivos).

¿Están ustedes dos máquinas funcionando en un entorno confiable? Podrías probar netcat . En el lado del servidor:

tar -czf - ./yourdir | nc -l 9999

y en el cliente:

nc your.server.net 9999 > yourdir.tar.gz

Puede hacer que la conexión del cliente use un túnel ssh:

ssh -f -L 23333:127.0.0.1:9999 foo@your.server.net sleep 10; \
    nc 127.0.0.1 23333 > yourdir.tar.gz

Incluso una partición completa se puede mover de esta manera:

dd if=/dev/sda1 | gzip -9 | nc -l 9999

y en el cliente:

nc your.server.net 9999 > mysda1.img.gz

.

Nota

netcat no es la herramienta de transferencia más segura que existe, pero en el entorno adecuado puede ser rápido porque tiene una sobrecarga baja.

HowtoForge tiene una buena página de ejemplos .