Лучший способ скопировать миллионы файлов между двумя серверами


39

У меня есть около 5 миллионов маленьких (5-30 тыс.) Файлов в одном каталоге, которые я хотел бы скопировать на другой компьютер в той же гигабитной сети. Я попытался использовать rsync, но после нескольких часов работы он замедлится до сканирования, я полагаю, из-за того, что rsync должен каждый раз проверять файл источника и назначения?

Моей второй мыслью было бы использовать scp, но я хотел узнать мнение других людей, чтобы узнать, есть ли лучший способ. Благодарность!


Узким местом, вероятно, является файловая система на принимающей стороне. Большинство файловых систем будет экспоненциально медленнее, чем больше файлов вы поместите в один каталог (то есть, каждый раз, когда rsync добавляет новый файл на принимающей стороне, принимающая сторона замедляется для оставшейся части передачи). Многие старые файловые системы не могут даже содержать более 32 КБ файлов в одном каталоге.
Микко Ранталайнен

Ответы:


41

Примерно так должно хорошо работать:

tar c some/dir | gzip - |  ssh host2 tar xz

Возможно, также опустите gzip и флаг "z" для извлечения, так как вы находитесь в гигабитной сети.


Нужно ли его сжать, или ssh все равно сжимает поток? Или можно заставить это сделать?
Тило

1
ssh сожмет поток, если вы передадите «-C». За пределами сети я бы не стал сжимать поток; по интернету я бы наверное, если бы он не был уже сжат.

6
Лично я бы оставил gzip включенным: даже через гигабитный Ethernet узким местом вряд ли будет процессор.
Бенджи XVI

6
@ BenjiXVI узким местом, безусловно, будет центральный процессор, который gzipбудет работать только на одном ядре. Можно разумно ожидать около 30 МБ / с при уровне сжатия по умолчанию 6, но это не будет максимально использовать Gigabit Ethernet.
syneticon-dj

2
использовать pbzip2? ...
Apache

19

Я уверен, что тот факт, что у вас есть все ПЯТЬ МИЛЛИОНОВ файлов в одном каталоге, приведёт в замешательство множество инструментов. Я не удивлен, что rsync не справился с этим изящно - это довольно «уникальная» ситуация. Если бы вы могли найти способ структурировать файлы в какую-то структуру каталогов, я уверен, что стандартные инструменты синхронизации, такие как rsync, будут гораздо более отзывчивыми.

Тем не менее, просто для того, чтобы дать какой-то реальный совет - возможно, одним из решений было бы физическое перемещение накопителя на конечный компьютер, чтобы вы могли сделать копию файлов на реальном сервере (не по сети). Затем переместите диск назад и используйте rsync, чтобы поддерживать актуальность.


6
+1 за физическое движение вождения, так гораздо быстрее
Роберт Гулд

1
Это наверняка лучше, чем копировать все на скачке и переходить туда-сюда ...
VirtuosiMedia

@RobertGould Давайте использовать IPoAC в качестве протокола передачи: "D
coolcat007

12

Чтобы скопировать миллионы файлов через гигабитный коммутатор (в доверенной среде), вы также можете использовать комбинацию netcat (or nc)и tar, как уже было предложено пользователем 55286. Это приведет к потоковой передаче всех файлов как одного большого файла (см. Быстрое копирование файлов - Linux! (39 ГБ) ).

# requires netcat on both servers
nc -l -p 2342 | tar -C /target/dir -xzf -   # destination box
tar -cz /source/dir | nc Target_Box 2342    # source box

В наши дни, когда все больше и больше пробует IPv6, вам может понадобиться использовать ключ -4 с командой nc на обоих концах, чтобы он работал в «старой» локальной сети IPv4.
BeowulfNode42,

5

У нас было около 1 миллиона файлов в каталоге (около 4 лет).

И мы использовали robocopy для перемещения файлов в каталог YYYY / MM (около 35-45 000 файлов в месяц). Мы поместили скрипт robocopy в файл .bat, например так:

ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20081101 /MINAGE:20081201 /MOV H:\Cs\out\fix H:\BCK_REPORT\2008\11
ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20081201 /MINAGE:20090101 /MOV H:\Cs\out\fix H:\BCK_REPORT\2008\12
ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20090101 /MINAGE:20090201 /MOV H:\Cs\out\fix H:\BCK_REPORT\2009\01
ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20090201 /MINAGE:20090301 /MOV H:\Cs\out\fix H:\BCK_REPORT\2009\02

краткие заметки .. /ns /nc /nfl /npэто для того, чтобы избежать раздувания файла журнала с дополнительной информацией /log+..., чтобы записать сводную информацию в файл журнала.

/minage and /maxage is to copy files modified with in that date range. 

так, например, файлы, измененные> = 01 / ноябрь 2008 года (включительно) для файлов, измененных <01 / декабря / 2008 (не включительно)

ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20081101 /MINAGE:20081201 /MOV H:\Cs\out\fix H:\BCK_REPORT\2008\11

/mov переместить файлы

затем приходит исходный каталог

затем идет каталог назначения (каталоги будут создаваться на лету по мере необходимости).

На передачу за 1 месяц ушло около 40–60 минут (около 35–45 000 файлов). Мы считаем, что на передачу за 1 год уходит около 12 часов или меньше.

Использование Windows Server 2003.

Все вещи записываются в файл журнала ... Время начала, Время окончания и Количество скопированных файлов.

Робокопия спасла день.


В наши дни robocopy имеет параметр / MT [: n] для выполнения многопоточных копий с n потоками (по умолчанию 8), чтобы добиться того же эффекта только лучше и без зависимости от диапазонов дат, и допускает использование одной командной строки вместо одной за нитку. Хотя переключатель MT недоступен в Windows 2003.
BeowulfNode42

4

Вы знаете, я добавил -1 решение для tar, но - в зависимости от среды - возникает еще одна идея. Вы можете подумать об использовании dd (1) . Проблема скорости с чем-то вроде этого заключается в том, что для открытия и закрытия файла требуется много движений головы, что вы будете делать пять миллионов раз. Вы могли бы гарантировать, что они назначены непрерывно, вместо этого вы могли бы использовать их, что уменьшило бы количество движений головы в 5 и более раз.


4

Я предпочитаю использовать lz4 как самый быстрый инструмент сжатия на данный момент. Опция SSH -c arcfour128 использует более быстрый алгоритм шифрования, чем по умолчанию. [1]

Таким образом, передача каталога выглядит примерно так:

tar -c folder | lz4 -c | ssh -carcfour128 somehost 'lz4 -d | tar -x > folder'

Обратите внимание, что в Debian команда lz4 - это lz4c, а в CentOS - lz4.


Шифрование / дешифрование ssh может быть узким местом из-за использования ЦП в ЦП источника или назначения и однопоточного характера почти всех реализаций ssh. Это частная гигабитная локальная сеть, поэтому не нужно шифровать.
BeowulfNode42

3

Robocopy отлично подходит для таких вещей. Он попытается снова после тайм-аутов сети, а также позволяет установить задержку между пакетами, чтобы теперь переполнить канал.

[Редактировать]

Обратите внимание, что это приложение только для Windows.


Предполагая, что вы находитесь на окнах, конечно. Приятной особенностью robocopy является то, что приложение отвечает за итерации по файлам. Проблема с утилитами unix заключается в том, что вам может не хватить пространства оболочки, расширяющего имена.
Мартин Беккет

3

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


3

В настоящее время мы изучаем эту проблему. Нам нужно передать около 18 миллионов небольших файлов - всего около 200 ГБ. Мы добились наилучшей производительности, используя обычный старый XCopy, но это все еще заняло ДОЛГОЕ время. Около 3 дней с одного сервера на другой, около 2 недель на внешний диск!

Через другой процесс нам нужно было продублировать сервер. Это было сделано с Acronis. Прошло около 3 часов !!!

Мы будем исследовать это еще немного. Предложение ДД выше, вероятно, даст аналогичные результаты.


2

Уже куча хороших предложений, но хотелось добавить Beyond Compare . Недавно я перенес около 750 000 файлов от 5 КБ до 20 МБ с одного сервера на другой через гигабитный коммутатор. Это даже не сбой вообще. Конечно, это заняло некоторое время, но я ожидаю, что с таким большим количеством данных.



1

Упакуйте их в один файл, прежде чем копировать, затем распакуйте их снова после копирования.


1

В аналогичной ситуации я попытался использовать tar для пакетирования файлов. Я написал крошечный скрипт для передачи вывода команды tar на целевой компьютер напрямую в принимающий процесс tar, который разделил файлы.

Тар-подход почти удвоил скорость передачи по сравнению с scp или rsync (YMMV).

Вот команды tar. Обратите внимание, что вам нужно включить r-команды, создавая файлы .rhosts в домашних каталогах каждого компьютера (удалите их после завершения копирования - это печально известные проблемы безопасности). Также обратите внимание, что, как обычно, HP-UX неудобен - тогда как остальная часть мира использует «rsh» для команды удаленной оболочки, HP-UX использует «remsh». «rsh» - это своего рода ограниченная оболочка на языке HP.

box1> cd source_directory; tar cf - . | remsh box2 "cd target_directory; tar xf - "

Первая команда tar создает файл с именем «-», который в данном случае является специальным токеном, означающим «стандартный вывод». Созданный архив содержит все файлы в текущем каталоге (.) Плюс все подкаталоги (по умолчанию tar является рекурсивным). Этот архивный файл передается в команду remsh, которая отправляет его на компьютер box2. Во вставке 2 я сначала перехожу на правильный каталог приема, затем извлекаю из '-' или 'стандартного ввода' входящие файлы.

У меня было 6 из этих команд tar, работающих одновременно, чтобы гарантировать, что сетевое соединение было насыщено данными, хотя я подозреваю, что доступ к диску мог быть ограничивающим фактором.


1

Обход файловой системы.

Вы можете размонтировать этот раздел, чтобы файлы находились на нем, или смонтировать его только для чтения? Сделайте это, тогда что-то вроде:

dd if=/dev/PARTITION | ssh username@host "dd of=diskimage.bin"

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

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


0

Вы можете попробовать следующее (может быть в пакетах файлов)

  • tar пакет файлов
  • сжать их
  • если возможно, скопируйте с помощью scp
  • Gunzip
  • распаковать файлы

0

Как подсказывает sth, вы можете попробовать tar поверх ssh.

Если вам не требуется шифрование (изначально вы использовали rsync, но не упомянули, что это rsync + ssh), вы можете попробовать использовать tar через netcat, чтобы избежать накладных расходов ssh.

Конечно, вы также можете сократить время, необходимое для использования gzip или другого метода сжатия.


0

Есть что-то еще, чтобы рассмотреть. Попробуй это:

  • Создать VHD, динамический размер
  • Смонтируйте его, возможно, как каталог
  • Установите атрибут «сжать весь диск»

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

В Windows я установил размер TCP-пакета по умолчанию, например, 16348. Это означает, что заголовок IP-адреса будет меньше.

Однако я столкнулся с тем, что для передачи по сети или USB лучше сохранять размеры файлов менее 100 Мб. Для этого я использую Rar.exe - чтобы разделить файлы.

Работает как чемпион. Это эквивалент 'dd' в Linux. Концепция монтирования сжатой файловой системы в каталог также нормальна для Linux, поэтому применяется та же логика. Вы должны убедиться, что все файлы закрыты до начала операции, как и в других методах.

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

VHD, отформатированный как NTFS, также может обрабатывать миллионы файлов в папке.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.