¿Cuál es la mejor manera de transferir un solo archivo grande a través de un enlace WAN de alta velocidad y alta latencia?

21

Esto parece relacionado con este , pero es algo diferente.

Existe este enlace WAN entre dos sitios de la compañía, y necesitamos transferir un solo archivo muy grande (volcado de Oracle, ~ 160 GB).

Tenemos un ancho de banda completo de 100 Mbps (probado), pero parece que una sola conexión TCP no puede maximizarla debido a cómo funciona TCP (ACK, etc.). Probamos el enlace con iperf , y los resultados cambian drásticamente al aumentar el tamaño de la ventana TCP: con la configuración básica obtenemos un rendimiento de ~ 5 Mbps, con un WS más grande podemos obtener hasta ~ 45 Mbps, pero no más que eso. La latencia de la red es de alrededor de 10 ms.

Por curiosidad, ejecutamos iperf utilizando más de una conexión, y descubrimos que, al ejecutar cuatro de ellas, alcanzarían una velocidad de ~ 25 Mbps cada una, llenando todo el ancho de banda disponible; entonces la clave parece estar en ejecutar múltiples transferencias simultáneas.

Con FTP, las cosas empeoran: incluso con configuraciones TCP optimizadas (tamaño de ventana alto, MTU máximo, etc.) no podemos obtener más de 20 Mbps en una sola transferencia. Intentamos FTPing algunos archivos grandes al mismo tiempo, y de hecho las cosas mejoraron mucho más que al transferir uno solo; pero luego el culpable se convirtió en E / S de disco, porque leer y escribir cuatro archivos grandes de los mismos cuellos de botella del disco muy pronto; Además, parece que no podemos dividir ese único archivo grande en archivos más pequeños y luego fusionarlo de nuevo, al menos no en momentos aceptables (obviamente, no podemos pasar el empalme / fusión del archivo un tiempo comparable al de transfiriéndolo).

La solución ideal aquí sería una herramienta multiproceso que pudiera transferir varios fragmentos del archivo al mismo tiempo; Algo así como los programas peer-to-peer como eMule o BitTorrent ya lo hacen, pero desde una sola fuente a un solo destino. Idealmente, la herramienta nos permitiría elegir cuántas conexiones paralelas usar y, por supuesto, optimizar la E / S de disco para no saltar (también) locamente entre varias secciones del archivo.

¿Alguien sabe de tal herramienta?

O, ¿alguien puede sugerir una mejor solución y / o algo que ya no probamos?

PD: Ya pensamos en hacer una copia de seguridad en cinta / disco y enviarlo físicamente al destino; esa sería nuestra medida extrema si WAN simplemente no lo corta, pero, como dijo AS Tanenbaum, "nunca subestimes el ancho de banda de una camioneta llena de cintas que se precipitan por la carretera".

networking bandwidth tcp file-transfer Massimo
fuente
1
Por curiosidad, ¿es realmente tan crítico el tiempo que lleva? Además, ¿saturar el enlace por la duración de una transferencia de 160 Gb no tendría un impacto en el resto de su red?
Bryan
66
Recuerdo haber entregado algunos cargadores automáticos DLT y un par de cientos de cartuchos a un Cliente en el '99. Calculamos la capacidad bruta de mi automóvil con alrededor de 200 cartuchos DLT IV cargados (35GB de capacidad bruta cada uno) a aproximadamente 6.3 TB. Conduje desde nuestra oficina hasta el sitio del Cliente en aproximadamente 55 minutos, dándole al mecanismo de transporte de respaldo "Evan in a Geo Metro manejando como loco por la Interestatal" un rendimiento efectivo de alrededor de 118GB / min. Buen rendimiento, pero la latencia fue mortal ...> sonrisa <
Evan Anderson
Bryan: sí, el tiempo es crítico (se necesitan unas VEINTE HORAS con FTP estándar y configuración de red estándar), y no, no habrá ningún problema en saturar el enlace, ya que la transferencia se programará fuera del horario laboral.
Massimo
Evan: eso es exactamente lo que quise decir ;-)
Massimo
He estado lidiando con una situación similar, con ~ 200GB de SQL .bak, excepto que la única forma en que he podido saturar el enlace WAN es con FTP. Terminé usando 7-zip con compresión cero para dividirlo en fragmentos de 512 MB. Los tiempos de "compresión" y "descompresión" fueron agradablemente cortos; en general, mucho mejor que palear medios físicos en todo el país. (Los sitios son en costas opuestas de los EE.UU.)
Adrien

Respuestas:

15

La búsqueda de "transferencia de archivos de alta latencia" trae muchos éxitos interesantes. Claramente, este es un problema en el que tanto la comunidad CompSci como la comunidad comercial se han puesto a pensar.

Algunas ofertas comerciales que parecen encajar en la factura:

  • FileCatalyst tiene productos que pueden transmitir datos a través de redes de alta latencia, ya sea utilizando UDP o múltiples transmisiones TCP. También tienen muchas otras características (compresión sobre la marcha, transferencias delta, etc.).

  • La "tecnología" de transferencia de archivos fasp de Aspera también parece ajustarse a la factura de lo que está buscando.

En el mundo de código abierto, el proyecto uftp parece prometedor. En particular, no necesita sus capacidades de multidifusión, pero la idea básica de enviar un archivo a los receptores, recibir NAK por bloques perdidos al final de la transferencia y luego eliminar los bloques NAK (espuma, enjuague, repetición) Parece que haría lo que necesita, ya que no hay ACK'ing (o NAK'ing) del receptor hasta que la transferencia de archivos se haya completado una vez. Asumiendo que la red está latente y no tiene pérdidas, esto también puede hacer lo que necesita.

Evan Anderson
fuente
uftp parece realmente prometedor, pude alcanzar 30 Mbps entre dos computadoras de escritorio (que definitivamente no son tan buenas en rendimiento de disco); Lo probaré en los servidores "reales" pronto. No pude obtener una licencia de demostración de FileCatalyst debido a algún error en el formulario de registro (sigue diciendo que el número de solicitud ya se ha utilizado), y fasp simplemente no los ofrece.
Massimo
60 Mbps entre dos computadoras con discos adecuados y un gran búfer de recepción. ¡Excelente!
Massimo
¡Me encanta el software libre / de código abierto! > smile <Definitivamente voy a probar uftp con algunas cosas que estoy haciendo. Me pregunto cómo funcionaría en una solución de imágenes de disco de multidifusión basada en Linux que armé hace un par de años usando "udpcast".
Evan Anderson
Hace un tiempo le pregunté a serverfault.com/questions/173358/multicast-file-transfers Finalmente, llegué a la conclusión de que uftp y mrsync eran las herramientas de elección. Publique los comentarios allí si hace algo útil con uftp, ya que volveré a utilizar uno u otro este año (preparación para una conferencia).
Jed Daniels
2
Cuando estaba trabajando con UFTP, UDT y Tsunami UDP, UFTP tuvo el peor rendimiento de los tres sobre todos. Por supuesto, es probablemente el protocolo más maduro. UDT solo proporciona un protocolo de transferencia simple y fue diseñado para actuar como una biblioteca para desarrollar software personalizado y el autor de Tsunami realmente nos apuntó hacia UDT ya que Tsunami no se ha desarrollado activamente recientemente debido a la falta de tiempo.
Thomas Owens
9

Sugerencia realmente extraña. Configure un servidor web simple para alojar el archivo en su red (sugiero nginx, por cierto), luego configure una PC con firefox en el otro extremo e instale la extensión DownThemAll .

Es un acelerador de descargas que admite fragmentación y reensamblaje.
Puede dividir cada descarga en 10 fragmentos para volver a ensamblar, ¡y en realidad hace las cosas más rápidas!

(Advertencia: nunca lo he probado en algo tan grande como 160 GB, pero funciona bien con archivos iso de 20 GB)

Tom O'Connor
fuente
40 Mbps entre las mismas computadoras. También se ve muy bien.
Massimo
1
reemplace firefox con axel.alioth.debian.org y no es una mala sugerencia.
Justin
7

El transporte UDT es probablemente el transporte más popular para comunicaciones de alta latencia. Esto lleva a su otro software llamado Sector / Sphere, un "Sistema de archivos distribuidos de alto rendimiento y un motor de procesamiento de datos en paralelo" que podría valer la pena echarle un vistazo.

Steve-o
fuente
1
Trabajé un poco con UDT para transferencias a través de redes con alta latencia y alta pérdida de paquetes. UDT es mucho más resistente a la latencia y la pérdida de paquetes que los protocolos basados ​​en TCP, especialmente una vez que se cambia el algoritmo de control de congestión para adaptarse a la topografía de su red.
Thomas Owens
Incluso hay una versión de rsync con UDT incorporada, se llama "UDR". github.com/LabAdvComp/UDR
Max
5

Mi respuesta es un poco tardía, pero acabo de encontrar esta pregunta, mientras buscaba fasp. Durante esa búsqueda también encontré esto: http://tsunami-udp.sourceforge.net/ , el "Protocolo UDP Tsunami".

Desde su sitio web:

Un protocolo rápido de transferencia de archivos en el espacio del usuario que utiliza el control TCP y los datos UDP para la transferencia a través de redes de larga distancia de muy alta velocidad (≥ 1 Gbps e incluso 10 GE), diseñado para proporcionar un mayor rendimiento que sea posible con TCP a través de las mismas redes. redes

En cuanto a la velocidad, la página menciona este resultado (usando un enlace entre Helsinki, Finlandia a Bonn, Alemania a través de un enlace de 1GBit:

Figura 1: transferencia internacional a través de Internet, con un promedio de 800 Mbit / segundo

Si desea utilizar un acelerador de descargas, eche un vistazo a lftp, este es el único acelerador de descargas que puede hacer un espejo recursivo, que yo sepa.

Jan van Haarst
fuente
1
En el proyecto que comenté anteriormente en la respuesta de Steve-o, comparamos UDT, Tsunami UDP y UFTP. Descubrimos que la latencia tenía un gran impacto en el rendimiento, mientras que la pérdida de paquetes no (contrario a la documentación del Tsunami). Agregar 100 ms de latencia a la red de prueba redujo el rendimiento del Tsunami de aproximadamente 250Mbits / segundo a aproximadamente 50Mbits / segundo (creo que tengo mis números y unidades correctamente, ha pasado un tiempo, pero fue una gran caída). Agregar una pérdida de paquetes del 10% sin una red de latencia mínima, por otro lado, solo disminuyó el rendimiento de 250 Mbits / segundo a aproximadamente 90 Mbits / segundo.
Thomas Owens