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.
fuente
lftp
es genial, pero no puedo hacer que haga varias partes al cargar UP. Estoy usandomirror --use-pget-n=20 -R
, pero parece que--use-pget-n
solo funciona al descargar.-P20
funciona para cargar varios archivos, pero no puedo crear varias partes de cada archivo.pget -n
.mirror
es bidireccional; elpget
argumento se aplica solo a los archivos que se descargan.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://[email protected]/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
fuente
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
--continue
para reanudar el trabajo :) y la-R
opción de cargar en lugar de descargar (luego cambiar el orden de los argumentos a<local_dir> <remote_dir>
).fuente
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:
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.
fuente
¿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.
fuente
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):
Archivo /tmp/scp.sh:
fuente
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.
fuente
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 :)
fuente
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.
fuente
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).
fuente
¿Están ustedes dos máquinas funcionando en un entorno confiable? Podrías probar netcat . En el lado del servidor:
y en el cliente:
Puede hacer que la conexión del cliente use un túnel ssh:
Incluso una partición completa se puede mover de esta manera:
y en el cliente:
.
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 .
fuente