Transfiere 15 TB de archivos pequeños

Estoy archivando datos de un servidor a otro. Inicialmente comencé un rsynctrabajo. Le tomó 2 semanas construir la lista de archivos solo para 5 TB de datos y otra semana para transferir 1 TB de datos.

Luego tuve que matar el trabajo ya que necesitamos un tiempo de inactividad en el nuevo servidor.

Se acordó que lo alquilaremos, ya que probablemente no necesitemos acceder a él nuevamente. Estaba pensando en dividirlo en trozos de 500 GB. Después de eso tar, iba a copiarlo ssh. Estaba usando tary pigztodavía es demasiado lento.

Hay una mejor manera de hacerlo? Creo que ambos servidores están en Redhat. El servidor anterior es Ext4 y el nuevo es XFS.

Los tamaños de archivo varían de pocos kb a pocos mb y hay 24 millones de jpegs en 5TB. Entonces supongo que alrededor de 60-80 millones por 15 TB.

editar: Después de jugar con rsync, nc, tar, mbuffer y pigz durante un par de días. El cuello de botella será el disco IO. A medida que los datos se dividen en 500 discos SAS y alrededor de 250 millones de archivos JPEG. Sin embargo, ahora aprendí sobre todas estas buenas herramientas que puedo usar en el futuro.

He tenido muy buenos resultados usando tar, pigz(gzip paralelo) y nc.

Máquina de origen:

tar -cf - -C /path/of/small/files . | pigz | nc -l 9876

Máquina de destino:

Extraer:

nc source_machine_ip 9876 | pigz -d | tar -xf - -C /put/stuff/here

Para mantener el archivo:

nc source_machine_ip 9876 > smallstuff.tar.gz

Si quieres ver la tasa de transferencia, ¡solo pasa pvdespués pigz -d!

Me apegaría a la solución rsync. Modern (3.0.0+) rsync usa una lista de archivos incremental, por lo que no tiene que crear una lista completa antes de la transferencia. Por lo tanto, reiniciar no requerirá que realice una transferencia completa nuevamente en caso de problemas. Dividir la transferencia por directorio de nivel superior o segundo optimizará esto aún más. (Usaría rsync -a -Py agregaría --compresssi su red es más lenta que sus unidades).

Configure una VPN (si es Internet), cree una unidad virtual de algún formato en el servidor remoto (hágalo ext4), móntela en el servidor remoto, luego móntela en el servidor local (usando un protocolo de nivel de bloque como iSCSI ) y utilice dd u otra herramienta de nivel de bloque para realizar la transferencia. Luego puede copiar los archivos de la unidad virtual a la unidad real (XFS) a su conveniencia.

Dos razones:

1. Sin sobrecarga del sistema de archivos, que es el principal culpable del rendimiento
2. Sin buscar, estás viendo lectura / escritura secuencial en ambos lados

Si el servidor antiguo se está retirando del servicio y los archivos pueden estar desconectados durante unos minutos, a menudo es más rápido sacar las unidades de la caja anterior y conectarlas al nuevo servidor, montarlas (volver a conectarlas ahora) y copiar los archivos a los nuevos servidores discos nativos.

Use mbuffer y si está en una red segura puede evitar el paso de cifrado.

(Muchas respuestas diferentes pueden funcionar. Aquí hay otra).

Genere la lista de archivos con find -type f(esto debería terminar en un par de horas), divídala en pequeños fragmentos y transfiera cada fragmento utilizando rsync --files-from=....

¿Has considerado sneakernet? Con eso, me refiero a transferir todo a la misma unidad, luego mover físicamente esa unidad.

Hace aproximadamente un mes, Samsung presentó una unidad de 16 TB (técnicamente, es 15.36 TB), que también es un SSD: http://www.theverge.com/2015/8/14/9153083/samsung-worlds-largest-hard -drive-16tb

Creo que esta unidad podría hacer por esto. Aún tendría que copiar todos los archivos, pero como no tiene latencia de red y probablemente puede usar SATA o una técnica similarmente rápida, debería ser mucho más rápido.

Si hay alguna posibilidad de obtener una alta tasa de éxito cuando se realiza la deduplicación, usaría algo como borgbackup o Attic.

Si no es así, verifique la solución netcat + tar + pbzip2 , adapte las opciones de compresión de acuerdo con su hardware; verifique cuál es el cuello de botella (CPU? Red? IO?). El pbzip2 abarcaría muy bien todas las CPU, proporcionando un mejor rendimiento.

Está utilizando RedHat Linux, por lo que esto no se aplicaría, pero como otra opción:

He tenido un gran éxito al usar ZFS para almacenar millones de archivos, ya que los inodos no son un problema.

Si esa fuera una opción para usted, podría tomar instantáneas y usar zfs para enviar actualizaciones incrementales. He tenido mucho éxito al usar este método para transferir y archivar datos.

ZFS es principalmente un sistema de archivos Solaris, pero se puede encontrar en los illumos (bifurcación de código abierto de Sun's OpenSolaris). Sé que también ha habido algo de suerte al usar ZFS bajo BSD y Linux (¿usando FUSE?), Pero no tengo experiencia en intentarlo.

Inicia un rsyncdemonio en la máquina objetivo. Esto acelerará mucho el proceso de transferencia.

Puedes hacer esto solo con tar y ssh, así:

tar zcf - <your files> | ssh <destination host> "cat > <your_file>.tar.gz"

O, si desea mantener archivos individuales:

tar zcf - <your files> | ssh <destination host> "tar zxf -"