Вопрос: Переносить 15 Тбайт крошечных файлов


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

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

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

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

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

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


73
2017-09-09 15:23


Источник


возможный дубликат linux to linux, передача 10TB? - D34DM347
Один из вариантов - создание сжатых файлов tar на внешнем диске и перенос их в новую систему. Дополнительный диск ускорит создание tar-файлов (не будет записываться на существующие диски в системе, возможно, при попытке прочитать 15 ТБ от них) и не связывает новый сервер. - Brian
Есть ли лучший способ сделать это? - Да, репликация Windows Server 2012 R2 DFS подготовит это примерно через 10 часов, И он будет синхронизировать изменения и забрать, где он остановился после перезагрузки. - TessellatingHeckler
@TessellatingHeckler: вы предлагаете, чтобы OP мигрировал из Redhat в Windows перед архивированием? - Thomas Weller
@ThomasWeller Они спросили: «Есть ли лучший способ?», И есть. Я не рекомендую использовать их лучше. Они могут свободно использовать команды в трубе, которые не могут восстановить прерывание, не будут проверять содержимое файла, не могут сообщать о статусе копирования, не могут использовать ранее скопированные блоки, чтобы избежать копирования частей файлов, не имеют никакого подразумеваемого поддержка низкоприоритетного копирования, не может быть приостановлена, не имеет упоминания о копировании списков ACL и требует, чтобы кто-то остался включенным для его запуска. Тем не менее, любой другой, кто может следовать за ним, может быть заинтересован, или попросить сказать «x делает это в Linux». - TessellatingHeckler


Ответы:


У меня были очень хорошие результаты, используя 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!


62
2017-09-09 16:29



FYI, вы можете заменить pigz с gzip или удалить его вообще, но скорость будет значительно медленнее. - h0tw1r3
Как это можно принять, если ОП уже пробовал tar а также pigz? Я не понимаю ... - Thomas Weller
@ThomasWeller, где вы поняли, что он пробовал pigz? Из вопроса, похоже, он только пытался rsync до сих пор принимая во внимание с помощью tar для разделения и объединения данных. Особенно, если он не использовал -z/--compress вариант на rsync, pigz теоретически может значительно помочь. - Doktor J
@ThomasWeller да, действительно, я уже пробовал смолы и свиньи, но не nc. Я использовал ssh, поэтому он добавил намного больше накладных расходов. - lbanz
@lbanz, что просто означает, что tar не дает данных достаточно быстро для pigz для использования большого количества CPU для сжатия. Чтение большого количества небольших файлов включает в себя еще много системных вызовов, еще много обращений к диску и намного больше затрат на ядро, чем чтение того же количества байтов больших файлов, и похоже, что вы просто узкие места на фундаментальном уровне. - hobbs


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


20
2017-09-09 18:44



Я использую rsync 2.6.8 на старом сервере. Поскольку это один из тех ящиков, где нам не разрешено устанавливать / обновлять что-либо, как указано поставщиком, или оно лишает гарантию. Я мог бы обновить его и посмотреть, будет ли он быстрее. - lbanz
Найдите (или создайте) статически связанный двоичный файл rsync и просто запустите его из своего дома. Надеюсь, это не испортит никакой гарантии. - Fox


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

Две причины:

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

15
2017-09-09 16:17



Обход файловой системы хорош. Копирование уровня блока файловой системы с записью на чтение и запись - очень плохая идея. Сначала отключите или установите только чтение. - JB.
Имея копию 15 ТБ, тоже засасывает. Это означает, что для нового сервера требуется минимум 30. - Arthur Kay
Если сервер использует LVM, можно сделать снимок только для чтения файловой системы и скопировать его. Космические накладные расходы только для изменений в файловой системе, которые происходят во время чтения моментального снимка. - liori


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


9
2017-09-10 03:14



Это около 1PB приводов 2TB, так что это слишком много. - lbanz


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


3
2017-09-09 15:39





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

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


3
2017-09-10 23:34





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

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

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


3
2017-09-12 17:56





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

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


2
2017-09-09 20:38



lzma (xz) распаковывается быстрее, чем bzip2, и хорошо работает на большинстве входных данных. К сожалению, xzМногопоточная опция еще не реализована. - Peter Cordes
Обычно на стадии сжатия требуется больше мощности, чем при распаковке, поэтому, если процессор является ограничивающим фактором, pbzip2 приведет к повышению общей производительности. Декомпрессия не должна влиять на процесс, если обе машины подобны. - neutrinus
Да, я считаю, что стыдно, что нет однопотоковой многопоточной lzma. Хотя для этого случая использования передачи целых файловых систем данных, pigz будет пробным. быть самым медленным компрессором, который вы хотите использовать. Или даже lz4, (Есть lz4mt доступно многопоточное для одного потока. Он не очень эффективен в потоке (очень часто порождает новые потоки), но он получает надежное ускорение) - Peter Cordes


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

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

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

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


2
2017-09-10 18:49



Некоторое время уже был родной Linux-порт ZFS, не поддерживающий FUSE: zfsonlinux.org - EEAA♦


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


1
2017-09-11 15:50





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

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

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

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


-1
2017-09-11 18:06



Он не будет дедуплицировать, никоим образом не возобновить, сжимать, используя только один процессор. - neutrinus