Передача 15 ТБ крошечных файлов

Я архивирую данные с одного сервера на другой. Изначально я начал rsyncработу. Потребовалось 2 недели для создания списка файлов только для 5 ТБ данных и еще одна неделя для передачи 1 ТБ данных.

Затем мне пришлось убить работу, так как нам нужно немного простоя на новом сервере.

Было решено, что мы доработаем это, так как нам, вероятно, больше не понадобится доступ к нему. Я думал разбить его на куски по 500 ГБ. После того, как я tarэто тогда, я собирался скопировать это через ssh. Я использовал tarи, pigzно это все еще слишком медленно.

Есть ли лучший способ сделать это? Я думаю, что оба сервера на Redhat. Старый сервер Ext4, а новый XFS.

Размеры файлов варьируются от нескольких кб до нескольких мегабайт, а в 5 ТБ - 24 млн. JPEG. Так что я предполагаю около 60-80 миллионов за 15 ТБ.

редактировать: после игры с rsync, nc, tar, mbuffer и pigz в течение нескольких дней. Узким местом будет дисковый ввод-вывод. Поскольку данные распределяются на 500 дисках SAS и около 250 миллионов jpegs. Однако теперь я узнал обо всех этих замечательных инструментах, которые я смогу использовать в будущем.

У меня были очень хорошие результаты , используя tar, pigz(параллельный GZIP) и nc.

Исходная машина:

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

Машина назначения:

Извлекать:

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

Сохранить архив:

nc source_machine_ip 9876 > smallstuff.tar.gz

Если вы хотите видеть скорость передачи данных только через трубу pvпосле pigz -d!

Я бы придерживался решения rsync. Современный (3.0.0+) rsync использует инкрементный список файлов, поэтому ему не нужно создавать полный список перед передачей. Так что перезапуск не потребует от вас повторной передачи в случае проблем. Разделение передачи на каталог верхнего или второго уровня оптимизирует это еще больше. (Я бы использовал rsync -a -Pи добавил, --compressесли ваша сеть работает медленнее, чем ваши диски.)

Настройте VPN (если это Интернет), создайте виртуальный диск некоторого формата на удаленном сервере (сделайте его ext4), подключите его на удаленном сервере, затем подключите его на локальном сервере (используя протокол уровня блока, такой как iSCSI). ), и используйте dd или другой инструмент уровня блока, чтобы сделать передачу. Затем вы можете скопировать файлы с виртуального диска на реальный (XFS) диск по своему усмотрению.

Две причины:

1. Отсутствие накладных расходов на файловую систему, что является основным виновником производительности
2. Не ищите, вы смотрите на последовательное чтение / запись с обеих сторон

Если старый сервер выводится из эксплуатации и файлы могут оставаться в автономном режиме в течение нескольких минут, то часто быстрее всего просто вытащить диски из старого блока и подключить их к новому серверу, смонтировать их (снова подключить к сети) и скопировать файлы на новые серверы родные диски.

Используйте mbuffer, и если он находится в защищенной сети, вы можете избежать шага шифрования.

(Многие разные ответы могут работать. Вот еще один.)

Создайте список файлов с помощью find -type f(это должно закончиться через пару часов), разделите его на маленькие порции и перенесите каждый порцию с помощью rsync --files-from=....

Вы рассматривали sneakernet? Под этим я подразумеваю перенос всего на тот же диск, затем физическое перемещение этого диска.

около месяца назад Samsung представила накопитель на 16 ТБ (технически это 15,36 ТБ), который также является SSD: http://www.theverge.com/2015/8/14/9153083/samsung-worlds-largest-hard -Драйв-16TB

Я думаю, что этот диск будет только для этого. Вам все равно придется копировать все файлы, но, поскольку у вас нет задержки в сети и, возможно, вы можете использовать SATA или аналогичную быструю технику, она должна быть намного быстрее.

Если есть вероятность получить высокий коэффициент успеха при дедупликации, я бы использовал что-то вроде borgbackup или Attic.

Если нет, проверьте решение netcat + tar + pbzip2 , измените параметры сжатия в соответствии с вашим оборудованием - проверьте, что является узким местом (ЦП? Сеть? IO?). Pbzip2 будет приятно работать на всех процессорах, обеспечивая лучшую производительность.

Вы используете RedHat Linux, так что это не будет применяться, но в качестве другого варианта:

Я имел большой успех, используя ZFS для хранения миллионов файлов, так как inode не проблема.

Если это вариант для вас, вы можете сделать снимки и использовать zfs для отправки инкрементных обновлений. Я имел большой успех, используя этот метод для передачи, а также архивирования данных.

ZFS - это прежде всего файловая система Solaris, но ее можно найти в illumos (форк с открытым исходным кодом Sun's OpenSolaris). Я знаю, что также было немного удачного использования ZFS в BSD и Linux (используя FUSE?) - но у меня нет опыта в этом.

Запустите rsyncдемон на целевой машине. Это значительно ускорит процесс передачи.

Вы можете сделать это с помощью tar и ssh, вот так:

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

Или, если вы хотите сохранить отдельные файлы:

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