Copie archivos grandes de un servidor Linux a otro

20

Estoy intentando copiar un tgz de 75 gigabytes (instantánea de mysql lvm) de un servidor Linux en nuestro centro de datos de Los Ángeles a otro servidor Linux en nuestro centro de datos de Nueva York a través de un enlace de 10 MB.

Estoy obteniendo aproximadamente 20-30Kb / s con rsync o scp que fluctúa entre 200-300 horas.

Por el momento es un enlace relativamente silencioso ya que el segundo centro de datos aún no está activo y he obtenido excelentes velocidades de transferencias de archivos pequeños.

He seguido diferentes guías de ajuste de TCP que he encontrado a través de Google en vano (tal vez estoy leyendo las guías incorrectas, ¿tengo una buena?).

He visto la sugerencia del túnel tar + netcat, pero entiendo que solo es bueno para MUCHOS archivos pequeños y no te actualiza cuando el archivo termina de transferirse.

Antes de recurrir al envío de un disco duro, ¿alguien tiene alguna buena información?

ACTUALIZACIÓN: Bueno ... puede ser el enlace después de todo :( Ver mis pruebas a continuación ...

Traslados desde NY a LA:

Obteniendo un archivo en blanco.

[nathan@laobnas test]$ dd if=/dev/zero of=FROM_LA_TEST bs=1k count=4700000
4700000+0 records in
4700000+0 records out
4812800000 bytes (4.8 GB) copied, 29.412 seconds, 164 MB/s
[nathan@laobnas test]$ scp -C obnas:/obbkup/test/FROM_NY_TEST .
FROM_NY_TEST                                    3%  146MB   9.4MB/s   07:52 ETA

Obteniendo la instantánea tarball.

[nathan@obnas db_backup]$ ls -la db_dump.08120922.tar.gz
-rw-r--r-- 1 root root 30428904033 Aug 12 22:42 db_dump.08120922.tar.gz

[nathan@laobnas test]$ scp -C obnas:/obbkup/db_backup/db_dump.08120922.tar.gz .
db_dump.08120922.tar.gz            0%   56MB 574.3KB/s 14:20:40 ET

Traslados de LA a NY:

Obteniendo un archivo en blanco.

[nathan@obnas test]$ dd if=/dev/zero of=FROM_NY_TEST bs=1k count=4700000
4700000+0 records in
4700000+0 records out
4812800000 bytes (4.8 GB) copied, 29.2501 seconds, 165 MB/s
[nathan@obnas test]$ scp -C laobnas:/obbkup/test/FROM_LA_TEST .
FROM_LA_TEST                                    0% 6008KB 497.1KB/s 2:37:22 ETA

Obteniendo la instantánea tarball.

[nathan@laobnas db_backup]$ ls -la db_dump_08120901.tar.gz
-rw-r--r-- 1 root root 31090827509 Aug 12 21:21 db_dump_08120901.tar.gz

[nathan@obnas test]$ scp -C laobnas:/obbkup/db_backup/db_dump_08120901.tar.gz .
db_dump_08120901.tar.gz                0%  324KB  26.8KB/s 314:11:38 ETA

Supongo que hablaré con las personas que administran nuestras instalaciones. El enlace está etiquetado como un enlace MPLS / Ethernet de 10 MB. (encogimiento de hombros)

Nathan Milford
fuente
Solo un comentario, recientemente recibí un lanzamiento de un proveedor de software en un Seagate FreeAgent (disco USB) que tenía aproximadamente 50 GBytes. La empresa en cuestión tenía presencia en la web y, por lo general, solicitaba a los clientes que simplemente descargaran desde su sitio web. Pensé que era una solución interesante y pensé que esto podría agregar información para ayudarlo en su decisión.
mdpc
¿Qué tipo de latencia estás viendo?
retroceder
Unos 80 ms a través del enlace.
Nathan Milford el
Sí, ahora estoy confundido y frustrado. ¡Lo he dividido en trozos de 50 MB y todavía funciona lentamente! Pero rsyncing otros datos se 500kb / s ... debe haber algo terriblemente mal ehre me falta ....
Nathan Milford
Inspeccione su tráfico con tcpdump. Puede ayudarlo a descubrir qué ralentiza la transferencia.
lexsys

Respuestas:

16

Sneakernet Alguien?

Suponiendo que se trata de una copia única, no creo que sea posible copiar el archivo en un CD (u otro medio) y pasar la noche en el destino.

Esa podría ser su opción más rápida ya que una transferencia de archivos de ese tamaño, a través de esa conexión, podría no copiarse correctamente ... en cuyo caso puede comenzar de nuevo.


rsync

Mi segunda opción / intento sería rsync ya que detecta transferencias fallidas, transferencias parciales, etc. y puede retomar desde donde se quedó.

rsync --progress file1 file2 user@remotemachine:/destination/directory

La bandera --progress te dará algunos comentarios en lugar de solo quedarte allí sentado y dejarte dudar de ti mismo. :-)


Vuze (torrente de bits)

La tercera opción probablemente sería intentar usar Vuze como un servidor torrent y luego hacer que su ubicación remota use un cliente bitorrent estándar para descargarlo. Sé de otros que han hecho esto, pero ya sabes ... para cuando lo pusieron todo en marcha, etc. Podría haber pasado por alto los datos ...

Depende de tu situación, supongo.

¡Buena suerte!


ACTUALIZAR:

Sabes, pensé un poco más en tu problema. ¿Por qué el archivo tiene que ser un gran tarball enorme? Tar es perfectamente capaz de dividir archivos grandes en archivos más pequeños (para abarcar medios, por ejemplo), entonces, ¿por qué no dividir ese enorme tarball en piezas más manejables y luego transferir las piezas?

KPWINC
fuente
3
+1, aunque probablemente no sea rentable en este caso. Nunca subestimes el ancho de banda de un 747 lleno de discos duros :)
Chad Huneycutt
2
No pude encontrar el enlace, pero hace un par de años Google estaba buscando cajas de envío de unidades. Si puede mover una caja de unidades con un total de 500 TB desde el punto A hasta el punto B, de cualquier forma que lo corte es un ancho de banda muy fino
STW
2
Tal vez se refiera a este artículo: arstechnica.com/science/news/2007/03/…
KPWINC
1
Sí, terminé enviando un disco duro. El verdadero problema, o eso me dijeron, era el control de flujo en los conmutadores.
Nathan Milford el
Bittorrent solo funciona mejor que una transferencia directa si tiene varias sembradoras. Incluso si OP instala bt en varias máquinas, solo tiene una conexión. Y ya ha determinado que varios archivos pequeños no van más rápido que uno grande, lo que señala la conexión de red.
Xalorous
7

Lo hice en el pasado, con un archivo tbz2 de 60GB. Ya no tengo el script, pero debería ser fácil reescribirlo.

Primero, divida su archivo en partes de ~ 2GB:

split --bytes=2000000000 your_file.tgz

Para cada pieza, calcule un hash MD5 (esto es para verificar la integridad) y guárdelo en algún lugar, luego comience a copiar las piezas y su md5 en el sitio remoto con la herramienta que elija (yo: netcat-tar-pipe en una pantalla sesión).

Después de un tiempo, verifique con el md5 si sus piezas están bien, luego:

cat your_file* > your_remote_file.tgz

Si también ha hecho un MD5 del archivo original, verifíquelo también. Si está bien, puede descomprimir su archivo, todo debería estar bien.

(Si encuentro el tiempo, volveré a escribir el guión)

edomaur
fuente
5

Normalmente soy un gran defensor de rsync, pero cuando transfiero un solo archivo por primera vez, no parece tener mucho sentido. Sin embargo, si volviese a transferir el archivo con solo pequeñas diferencias, rsync sería el claro ganador. Si elige usar rsync de todos modos, le recomiendo ejecutar un extremo en --daemonmodo para eliminar el túnel ssh que mata el rendimiento. La página del manual describe este modo completamente.

¿Mi recomendación? FTP o HTTP con servidores y clientes que admiten reanudar descargas interrumpidas. Ambos protocolos son rápidos y livianos, evitando la penalización del túnel ssh. Apache + wget estaría gritando rápido.

El truco de la tubería netcat también funcionaría bien. Tar no es necesario al transferir un solo archivo grande. Y la razón por la que no te avisa cuando está hecho es porque no se lo dijiste. Agregue una -q0bandera en el lado del servidor y se comportará exactamente como esperaría.

servidor $ nc -l -p 5000> outfile.tgz

cliente $ nc -q0 server.example.com 5000 <infile.tgz

La desventaja del enfoque de netcat es que no le permitirá reanudar si su transferencia muere 74GB en ...

Insyte
fuente
+1 para rsyncd. De hecho, lo uso para transferencias en mi LAN porque veo un mayor rendimiento en comparación con CIFS o NFS.
Ophidian
1
Mientras que FTP y HTTP evitan la "penalización de túnel ssh", debe considerarse la "penalización" por no cifrar los datos.
J.Money
3

Dale una oportunidad a netcat (a veces llamado nc). Lo siguiente funciona en un directorio, pero debería ser lo suficientemente fácil de modificar solo para hacer frente a un archivo.

En el cuadro de destino:

netcat -l -p 2342 | tar -C /target/dir -xzf -

En el cuadro de origen:

tar czf * | netcat target_box 2342

Puede intentar eliminar la opción 'z' en ambos comandos tar para obtener un poco más de velocidad, ya que el archivo ya está comprimido.

David
fuente
1

SCP y Rsync predeterminados (que usan SCP) son muy lentos para archivos grandes. Supongo que buscaría usar un protocolo con una sobrecarga más baja. ¿Has intentado usar un cifrado de cifrado más simple o no lo has hecho? Intente buscar en la --rshopción rsync para cambiar el método de transferencia.

¿Por qué no FTP o HTTP?

cmcginty
fuente
1
Hice el viejo "python -m SimpleHTTPServer" desde commandlinefu en el origen y wget'd el archivo en el destino. Todavía obtengo "18.5K / s eta 15d 3h"
Nathan Milford
1

Aunque agrega un poco de sobrecarga a la situación, BitTorrent es en realidad una buena solución para transferir archivos grandes. BitTorrent tiene muchas características interesantes, como fragmentar de forma nativa un archivo y suma de comprobación de cada fragmento que se puede retransmitir si está dañado.

Un programa como Azureus [ahora conocido como Vuze] contiene todas las piezas que necesitará para crear, servidor y descargar torrents en una sola aplicación. Ten en cuenta que Azureus no es la solución más magra disponible para BitTorrent y creo que también requiere su GUI; sin embargo, hay muchas herramientas de torrent impulsadas por línea de comandos para Linux.

DisabledLeopard
fuente
bt solo va más rápido que la transferencia directa si hay varias semillas. Él tiene una sola fuente. Más importante aún, tiene una red de fuente única con una mala conexión de red. Incluso copiar el archivo a múltiples ubicaciones localmente y luego configurar bt con múltiples semillas es contraproducente debido a esa mala conexión. Además, hacer varias copias y configurarlas como semillas multiplica el tiempo de copia en lugar de reducirlo. BT podría ser una solución viable si OP intentara hacer que un archivo grande esté disponible para múltiples destinatarios.
Xalorous
0

Bueno, personalmente, 20-30Kb / s parece bastante bajo para un enlace de 10Mb (suponiendo 10Mb y no 10MB).

Si fuera usted, haría una de dos cosas (suponiendo que el acceso físico no esté disponible):

Cualquiera de los dos, le aconsejo que divida el archivo grande en fragmentos más pequeños, alrededor de 500 MB. En caso de corrupción en tránsito.

Cuando tenga los fragmentos más pequeños, use rsync nuevamente, o personalmente prefiero usar una sesión privada segura de ftp, y luego CRC los archivos al finalizar.

William Hilsum
fuente
0

Algunas preguntas pueden ayudar en las discusiones: ¿cuán importantes son los datos que se transferirán? ¿Es esto para recuperación ante desastres, respaldo en caliente, almacenamiento fuera de línea o qué? ¿Tiene la intención de hacer una copia de seguridad de la base de datos mientras está activa o inactiva? ¿Qué pasa con la configuración de una base de datos en el sistema remoto y mantenerlos sincronizados mediante la agrupación o la actualización a través de registros de cambios (no estoy totalmente versado en las capacidades de un sistema de base de datos MySql). Esto podría ayudar a reducir la cantidad de datos que deben transferirse a través del enlace.

mdpc
fuente
Es una instantánea LVM de otra réplica MYSQL (de nuestra instancia principal de MYSQL en otro lugar). Una vez transferida y situada, la instancia mysql de destino puede simplemente actualizar la diferencia entre esa instantánea (úsela como un delta) y dónde está el maestro ahora. Que es una copia de seguridad MYSQL no es relevante, es solo una gran porción de datos que solo necesito mover una vez.
Nathan Milford el
0

bbcp fragmentará el archivo por usted y lo copiará con múltiples transmisiones.

Zaur
fuente
0

Respuesta tardía para googlers:

Al transferir grandes conjuntos de datos, rsync se puede usar para comparar el origen y el destino, y luego escribir un archivo por lotes en medios extraíbles locales utilizando el indicador --only-write-batch. Luego, envía los medios locales a la ubicación remota, lo conecta y ejecuta rsync nuevamente, usando --read-batch para incorporar los cambios en el conjunto de datos remoto.

Si los archivos de origen cambian durante el transporte físico, o si el medio de transporte se llena, puede seguir repitiendo el --only-write-batch | barco | --ciclo de lectura-lote hasta que el destino esté atrapado.

(Ref: fui uno de los autores de esta característica en rsync; para obtener más información y casos de uso, consulte esta discusión sobre la implementación del prototipo: https://lists.samba.org/archive/rsync/2005-March/011964 .html )

stevegt
fuente