Pregunta Cómo copiar una gran cantidad de archivos rápidamente entre dos servidores


Necesito transferir una gran cantidad de mp3 entre dos servidores (Ubuntu). Por enorme me refiero a alrededor de un millón de archivos que son en promedio 300K. Lo intenté con scp pero habría tomado alrededor de una semana. (aproximadamente 500 KB / s) Si transfiero un solo archivo mediante HTTP, obtengo 9-10 MB / s, pero no sé cómo transferirlos todos.

¿Hay una manera de transferir todos ellos rápidamente?


81
2018-06-02 19:55


origen


¿Qué tipo de red tienes entre los servidores? He utilizado un crossover Ethernet de GB entre 1 NIC en cada máquina. Obtuve muy bien a través de poner en esa configuración utilizando SCP - Jim Blizard
Es posible que desee investigar por qué scp es tan lento. Puede que sea más lento que cosas como ftp debido al cifrado, pero no debería ser mucho más lento. - Zoredache
Tengo 100 mbps entre ellos. scp es más lento en los archivos pequeños (la mayoría de ellos son pequeños) - nicudotro


Respuestas:


Yo recomendaría tar. Cuando los árboles de archivos ya son similares, rsync realiza muy bien. Sin embargo, dado que rsync realizará múltiples pases de análisis en cada archivo y luego copiará los cambios, es mucho más lento que el tar para la copia inicial. Este comando probablemente hará lo que quieras. Copiará los archivos entre las máquinas, así como preservará los permisos y las propiedades de los usuarios / grupos.

tar -c /path/to/dir | ssh remote_server 'tar -xvf - -C /absolute/path/to/remotedir'

Según el comentario de Mackintosh a continuación, este es el comando que usaría para rsync

rsync -avW -e ssh /path/to/dir/ remote_server:/path/to/remotedir

109
2018-06-02 20:04



+1 La opción tar es mucho más eficiente para grandes cantidades de archivos pequeños, ya que tanto scp como rsync tendrán muchos más viajes de ida y vuelta por archivo a través de la red. - Sekenre
rsync funcionó mejor para mí que el alquitrán - nicudotro
Además, si tiene suficiente CPU disponible (en ambos extremos), pero (al menos) un enlace lento entre los hosts, puede valer la pena habilitar la compresión (gzip o bzip) en el comando tar. - Vatine
@Jamie: Si estás usando ssh-agent, entonces deberías usarlo. De lo contrario, solo use la opción '-i' para especificar dónde encontrar la clave privada. Vea la página del manual para más detalles. - Scott Pack
@niXar El ~ el carácter de escape solo se habilita si SSH está utilizando un terminal. Este no es el caso cuando especifica un comando remoto (a menos que pase el -t opción). Entonces tu preocupación es inválida. - Gilles


Entrega de disco duro externo y mensajería el mismo día.


32
2018-06-02 20:00



Je je je ... ninguna tecnología de red supera el ancho de banda de una camioneta cargada con cintas haciendo 90 MPH, ¿eh? (risita) Supuse que estaba en una LAN porque dijo que estaba obteniendo 9-10MB / seg con HTTP. - Evan Anderson
Obtengo ese tipo de velocidad en internet, ¡pero tengo suerte en el lugar donde vivo! Si está en una LAN, entonces aún más barato! - Adam
Ahh, no miré tu ubicación. Sí, escuché que la conectividad a Internet en Corea es bastante espectacular. Atascado aquí en los EE. UU., Estoy feliz de obtener 900 KB / s sobre la red ... - Evan Anderson
Sí, pero puedes obtener deliciosos burritos mientras esperas que se complete la descarga y solo hay unos tres restaurantes mexicanos medio decentes incluso en Seúl ... - Adam


Yo uso rsync.

Si los ha exportado a través de HTTP con listas de directorios disponibles, también podría usar wget y el argumento --rorror.

Ya estás viendo que HTTP es más rápido que SCP porque SCP está encriptando todo (y, por lo tanto, bloqueando la CPU). HTTP y rsync se moverán más rápido porque no están encriptados.

Aquí hay algunos documentos sobre la configuración de rsync en Ubuntu: https://help.ubuntu.com/community/rsync

Esos documentos hablan sobre tuning rsync a través de SSH, pero si solo estás moviendo datos en una LAN privada, no necesitas SSH. (Supongo que está en una LAN privada. Si obtiene 9-10MB / seg a través de Internet, entonces quiero saber qué tipo de conexiones tiene).

Aquí hay otros documentos muy básicos que le permitirán configurar un servidor rsync inseguro relativo (sin dependencia de SSH): http://transamrit.net/docs/rsync/


16
2018-06-02 19:57



Si bien SCP usa cierta CPU para cifrar los datos, no creo que tenga un uso de CPU del 100%, por lo que la CPU no es un cuello de botella. También he notado muchas veces que el SCP es ineficiente cuando se trata de transferencias rápidas. - Cristian Ciupitu
Dado que estaba viendo 300K para SCP y 9MB para HTTP, asumí que un cuello de botella relacionado con SCP (normalmente CPU) estaba entrando en juego. Sin embargo, podría ser otra cosa. Sin saber las especificaciones de hardware de las máquinas en cuestión, es difícil decirlo. - Evan Anderson
rsync casi definitivamente usará ssh para el transporte, ya que este es el comportamiento predeterminado, por lo que cualquier sobrecarga causada por el cifrado en scp también estará presente en rsync - Daniel Lawson
"Ya estás viendo que HTTP es más rápido que SCP porque SCP está cifrando todo" → MAL. A menos que tenga servidores de 10 años, no está obligado por CPU para esta tarea. - niXar
@RamazanPOLAT - Tienes una línea de comandos que es demasiado larga. Especifique la selección de archivos de manera diferente y funcionará bien para usted. Normalmente, solo puede especificar el directorio de origen sin un comodín al final. También puedes usar el --include y --exclude Argumentos para obtener más matices. - Evan Anderson


Sin mucha discusión, usa netcat, red swissarmy knife. Sin sobrecarga de protocolo, estás copiando directamente al socket de la red. Ejemplo

srv1$ tar cfv - *mp3 | nc -w1 remote.server.net 4321

srv2$ nc -l -p 4321 |tar xfv -

14
2018-06-02 20:17



Desafortunadamente, por lo que he notado, netcat es muy ineficiente, incluso si no debería serlo. - Cristian Ciupitu
Te estoy votando porque este es un consejo realmente terrible. Hay una respuesta correcta: rsync. Podría enumerar todas las razones por las que es mejor, pero no cabría en esta página, y mucho menos en este pequeño cuadro de comentarios. - niXar
@niXar: Si todo lo que desea hacer es una transferencia de un solo archivo (no es necesario realizar más sincronizaciones), entonces Tarpipe es todo lo que necesita. - Witiko
@niXar netcat está bien si lo hace en un entorno seguro como vlan privado y / o sobre VPN. - Lester Cheung


Con muchos archivos si vas con rsync, Intentaría obtener la versión 3 o superior en ambos extremos. La razón es que una versión menor enumerará cada archivo antes de iniciar la transferencia. La nueva característica se llama recursion incremental.

Un nuevo algoritmo de recursión incremental.   ahora se usa cuando rsync está hablando         a otra versión 3.x. Esto hace que la transferencia sea más rápida.         (antes de que se hayan encontrado todos los archivos), y requiere mucha menos memoria.         Vea la opción --recursiva en la página del manual para algunas restricciones.


8
2018-06-02 20:41





rsync, como otros ya lo han recomendado. Si la sobrecarga de CPU del cifrado es un cuello de botella, use otro algoritmo de CPU menos intensivo, como el pez globo. P.ej. algo como

rsync -ax -e 'ssh -c blowfish' /local/path user@host:/remote/path


7
2018-06-02 20:56



+1 por punto sobre cambiar el cifrado - Daniel Lawson
La CPU no será un cuello de botella, a menos que tenga 10G ethernet y una CPU de 10 años. - niXar
solo comente: el cifrado "-c arcfour" es más rápido. - Arman
@niXar: Pero si ya tiene una tarea que consume CPU en su máquina, es una preocupación. - Isaac


Al copiar una gran cantidad de archivos, descubrí que las herramientas como tar y rsync son más ineficientes de lo que deberían ser debido a la sobrecarga de abrir y cerrar muchos archivos. Escribí una herramienta de código abierto llamada fast-archiver que es más rápida que tar para estos escenarios: https://github.com/replicon/fast-archiver; trabaja más rápido al realizar múltiples operaciones de archivos concurrentes.

Aquí hay un ejemplo de archivador rápido vs. tar en una copia de seguridad de más de dos millones de archivos; El archivador rápido tarda 27 minutos en archivarse, mientras que el tar toma en 1 hora y 23 minutos.

$ time fast-archiver -c -o /dev/null /db/data
skipping symbolic link /db/data/pg_xlog
1008.92user 663.00system 27:38.27elapsed 100%CPU (0avgtext+0avgdata 24352maxresident)k
0inputs+0outputs (0major+1732minor)pagefaults 0swaps

$ time tar -cf - /db/data | cat > /dev/null
tar: Removing leading `/' from member names
tar: /db/data/base/16408/12445.2: file changed as we read it
tar: /db/data/base/16408/12464: file changed as we read it
32.68user 375.19system 1:23:23elapsed 8%CPU (0avgtext+0avgdata 81744maxresident)k
0inputs+0outputs (0major+5163minor)pagefaults 0swaps

Para transferir archivos entre servidores, puede usar el archivador rápido con ssh, como esto:

ssh postgres@10.32.32.32 "cd /db; fast-archive -c data --exclude=data/\*.pid" | fast-archiver -x

4
2017-08-26 20:51