Назад | Перейти на главную страницу

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

Мне нужно передать огромное количество mp3 между двумя серверами (Ubuntu). Под огромным я подразумеваю около миллиона файлов, размер которых в среднем составляет 300 КБ. Я пробовал с scp но это заняло бы около недели. (около 500 КБ / с) Если я передаю один файл по HTTP, я получаю 9-10 МБ / с, но я не знаю, как передать их все.

Есть ли способ быстро их все перенести?

Я бы порекомендовал tar. Когда деревья файлов уже похожи, rsync выполняет очень хорошо. Однако, поскольку rsync будет выполнять несколько проходов анализа для каждого файла, а затем копировать изменения, это намного медленнее, чем tar для начальной копии. Эта команда, скорее всего, сделает то, что вы хотите. Он будет копировать файлы между машинами, а также сохранять как разрешения, так и права собственности пользователей / групп.

tar -c /path/to/dir | ssh remote_server 'tar -xvf - -C /absolute/path/to/remotedir'

Согласно комментарию Макинтоша ниже, это команда, которую вы использовали бы для rsync

rsync -avW -e ssh /path/to/dir/ remote_server:/path/to/remotedir

Внешний жесткий диск и доставка курьером в тот же день.

Я бы использовал rsync.

Если вы экспортировали их через HTTP с доступными списками каталогов, вы также можете использовать wget и аргумент --mirror.

Вы уже видите, что HTTP быстрее, чем SCP, потому что SCP все шифрует (и, таким образом, создает узкие места в ЦП). HTTP и rsync будут двигаться быстрее, потому что они не шифруют.

Вот несколько документов по настройке rsync в Ubuntu: https://help.ubuntu.com/community/rsync

В этих документах говорится о туннелировании rsync через SSH, но если вы просто перемещаете данные в частной локальной сети, SSH вам не нужен. (Я предполагаю, что вы находитесь в частной локальной сети. Если вы получаете 9-10 МБ / с через Интернет, тогда я хочу знать, какие у вас соединения!)

Вот еще несколько очень простых документов, которые позволят вам настроить относительно небезопасный сервер rsync (без зависимости от SSH): http://transamrit.net/docs/rsync/

Без особых обсуждений используйте netcat, сетевой швейцарский нож. Никаких накладных расходов протокола, вы напрямую копируете в сетевой сокет. пример

srv1$ tar cfv - *mp3 | nc -w1 remote.server.net 4321

srv2$ nc -l -p 4321 |tar xfv -

С большим количеством файлов, если вы используете rsync, Я бы попробовал установить версию 3 или выше на обоих концах. Причина в том, что младшая версия перечислит каждый файл перед началом передачи. Новая функция называется инкрементная рекурсия.

Новый алгоритм инкрементной рекурсии теперь используется, когда rsync обращается к другой версии 3.x. Это запускает передачу быстрее (до того, как все файлы будут найдены) и требует гораздо меньше памяти. См. Параметр --recursive на странице руководства для ознакомления с некоторыми ограничениями.

При перемещении вчера 80 ТБ данных (миллионы крошечных файлов), переключение с rsync к tar оказался намного быстрее, поскольку мы перестали пытаться

# slow
rsync -av --progress /mnt/backups/section01/ /mnt/destination01/section01

и переключился на tar вместо...

# fast
cd /mnt/backups/
tar -cf - section01 | tar -xf - -C /mnt/destination01/

Поскольку эти серверы находятся в одной локальной сети, место назначения монтируется по NFS в исходной системе, которая выполняет push. Не делать еще быстрее, мы решили не сохранять atime файлов:

mount -o remount,noatime /mnt/backups
mount -o remount,noatime /mnt/destination01

На приведенном ниже рисунке показана разница, произошедшая при переходе с rsync на tar. Это был мой босса идея и мой коллега оба выполнили это и сделали великий запись в его блоге. мне просто нравится красивые картинки. :)

rsync, как и другие уже рекомендовали. Если накладные расходы ЦП из-за шифрования являются узким местом, используйте другой алгоритм с меньшей нагрузкой на ЦП, например blowfish. Например. что-то вроде

rsync -ax -e 'ssh -c blowfish' /local/path user@host:/remote/path

При копировании большого количества файлов я обнаружил, что такие инструменты, как tar и rsync, более неэффективны, чем они должны быть, из-за накладных расходов на открытие и закрытие многих файлов. Я написал инструмент с открытым исходным кодом под названием fast-archiver, который работает быстрее, чем tar для следующих сценариев: https://github.com/replicon/fast-archiver; он работает быстрее, выполняя несколько одновременных файловых операций.

Вот пример быстрого архивирования и tar при резервном копировании более двух миллионов файлов; fast-archiver архивируется за 27 минут, а tar - за 1 час 23 минуты.

$ time fast-archiver -c -o /dev/null /db/data
skipping symbolic link /db/data/pg_xlog
1008.92user 663.00system 27:38.27elapsed 100%CPU (0avgtext+0avgdata 24352maxresident)k
0inputs+0outputs (0major+1732minor)pagefaults 0swaps

$ time tar -cf - /db/data | cat > /dev/null
tar: Removing leading `/' from member names
tar: /db/data/base/16408/12445.2: file changed as we read it
tar: /db/data/base/16408/12464: file changed as we read it
32.68user 375.19system 1:23:23elapsed 8%CPU (0avgtext+0avgdata 81744maxresident)k
0inputs+0outputs (0major+5163minor)pagefaults 0swaps

Для передачи файлов между серверами вы можете использовать быстрый архиватор с ssh, например:

ssh postgres@10.32.32.32 "cd /db; fast-archive -c data --exclude=data/\*.pid" | fast-archiver -x

Я использую смолу netcat подход, за исключением того, что я предпочитаю использовать socat - гораздо больше возможностей для оптимизации для вашей ситуации - например, путем настройки mss. (Также смейтесь, если хотите, но я нахожу socat аргументы легче запомнить, потому что они последовательны). Так что для меня это очень распространено в последнее время, поскольку я перемещаю вещи на новые серверы:

host1$ tar cvf - filespec | socat stdin tcp4:host2:portnum

host2$ socat tcp4-listen:portnum stdout | tar xvpf -

Псевдонимы необязательны.

  • Сетевая файловая система (NFS) а затем скопируйте их как хотите, например Midnight Commander (mc), Наутилус (от gnome). Я использовал NFS v3 с хорошими результатами.
  • Самба (CIFS) а затем скопируйте файлы с чем угодно, но я понятия не имею, насколько это эффективно.
  • HTTP с участием wget --mirror так как Эван Андерсон предложил или любой другой http-клиент. Будьте осторожны, чтобы не иметь неприятных символических ссылок или вводящих в заблуждение индексных файлов. Если все, что у вас есть, это MP3, вы должны быть в безопасности.
  • rsync. Я использовал его с довольно хорошими результатами, и одна из его приятных особенностей - то, что вы можете прервать и возобновить передачу позже.

Я заметил, что другие люди рекомендовали использовать netcat. На основе мой опыт с ним я могу сказать, что он медленный по сравнению с другими решениями.

Похоже, в верхнем ответе может быть пара опечаток. Это может сработать лучше:

tar -cf - /path/to/dir | ssh remote_server 'tar -xvf - -C /path/to/remotedir'

Другая альтернатива - Унисон. В этом случае может быть немного более эффективным, чем Rsync, и настроить слушателя несколько проще.

Благодаря замечательному ответу Скотта Пака (раньше я не знал, как это сделать с помощью ssh), я могу предложить это улучшение (если bash это ваша оболочка). Это добавит параллельное сжатие, индикатор выполнения и проверит целостность сетевого соединения:

tar c file_list |
    tee >(sha512sum >&2) |
    pv -prab |
    pigz -9 |
    ssh [user@]remote_host '
        gunzip |
        tee >(sha512sum >&2) |
        tar xC /directory/to/extract/to
    '

pv - прекрасная программа просмотра прогресса для вашей трубы и pigz - это параллельная программа gzip, которая по умолчанию использует столько потоков, сколько имеет ваш процессор (я считаю, что до 8 максимум). Вы можете настроить уровень сжатия, чтобы лучше соответствовать соотношению пропускной способности ЦП и сети, и заменить его с помощью pxz -9e и pxz -d если у вас гораздо больше ЦП, чем пропускная способность. Вам нужно только убедиться, что две суммы совпадают по завершении.

Эта опция полезна для очень больших объемов данных, а также для сетей с высокой задержкой, но не очень полезна, если связь нестабильна и обрывается. В таких случаях rsync, вероятно, является лучшим выбором, поскольку он может возобновиться.

Пример вывода:

6c1fe5a75cc0280709a794bdfd23d7b8b655f0bbb4c320e59729c5cd952b4b1f84861b52d1eddb601259e78249d3e6618f8a1edbd20b281d6cd15f80c8593c3e  -                     ]
 176MiB [9.36MiB/s] [9.36MiB/s] [                                            <=>                                                                        ]
6c1fe5a75cc0280709a794bdfd23d7b8b655f0bbb4c320e59729c5cd952b4b1f84861b52d1eddb601259e78249d3e6618f8a1edbd20b281d6cd15f80c8593c3e  -

Для блочных устройств:

dd if=/dev/src_device bs=1024k |
    tee >(sha512sum >&2) |
    pv -prab |
    pigz -9 |
    ssh [user@]remote_host '
        gunzip |
        tee >(sha512sum >&2) |
        dd of=/dev/src_device bs=1024k
    '

Очевидно, убедитесь, что они одинакового размера или ограничения с count =, skip =, seek = и т. Д.

Когда я копирую файловые системы таким образом, я часто сначала dd if=/dev/zero of=/thefs/zero.dat bs=64k && sync && rm /thefs/zero.dat && umount /thefs обнулить большую часть неиспользуемого пространства, что ускоряет xfer.

Вот небольшой тест для сравнения некоторых методов,

  • Источник: 4-ядерный процессор Intel (R) Xeon (R) E5-1620 @ 3,60 ГГц с 250 Мбит / с и диском SATA.
  • Назначение - 6-ядерный процессор Intel (R) Xeon (R) E-2136 @ 3,30 ГГц с пропускной способностью 1 Гбит / с и SSD-накопитель.

Количество файлов: 9632, Общий размер: 814 Мбайт, средний размер: 84 Кбайт

  • RSYNC: 1 мин. 40,570 сек.
  • RSYNC + СЖАТИЕ: 0 мин. 26,519 сек.
  • TAR + NETCAT: 1 мин. 58,763 сек.
  • ТАР + СЖАТИЕ + NETCAT: 0 мин. 28,009 с

Команда для tar / netcat была:

Source : tar -cf - /sourcedir/ | nc -v 11.22.33.44 5000
Dest : nc -v -l 5000 | tar -xf -

На @scottpack ответ опции rSync

Чтобы отобразить ход загрузки, используйте параметр --progress после -avW в команде, как показано ниже.

rsync -avW --progress -e ssh /path/to/dir/ remote_server:/path/to/remotedir

Я думаю, что мой ответ здесь немного запоздалый, но я получил хороший опыт использования mc (Midnight Commander) на одном сервере для подключения через SFTP к другому серверу.

Вариант подключения через FTP находится в меню «Левый» и «Правый» путем ввода адреса следующим образом:

/#ftp:name@server.xy/

или

/#ftp:name@ip.ad.dr.ess/

Вы можете перемещаться и выполнять файловые операции почти так же, как в локальной файловой системе.

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

Вы также можете попробовать использовать команду BBCP для перевода. Это буферизованный параллельный ssh, который действительно кричит. Обычно мы можем получить 90% + линейную ставку при условии, что мы будем держать трубу под напряжением. 

$ bbcp -s 8 -w 64M -N io 'tar -cO srcdirectory' desthostname:'tar -x -C destdir'

Обычно мы очень стараемся не передвигаться. Мы используем пулы ZFS, к которым всегда можно просто «добавить» больше дискового пространства. Но иногда ... тебе просто нужно перемещать вещи. Если у нас есть "живая" файловая система, копирование которой может занять часы (или дни) даже при полномасштабном запуске ... мы выполняем одну двухэтапную процедуру отправки zfs:

  1. Сделайте моментальный снимок ZFS и перенесите его в новый пул на новой машине. Пусть это займет столько времени, сколько потребуется.
  2. Сделайте второй снимок и отправьте его как инкрементальный. Инкрементный снимок включает только (гораздо меньший) набор изменений с момента первого, поэтому он выполняется относительно быстро.
  3. После того, как инкрементный снимок будет завершен, вы можете перевернуть оригинал и перейти к новой копии, а время простоя в автономном режиме будет сведено к минимуму.

Мы также отправляем наши дампы zfs через BBCP ... это максимизирует использование нашей сети и минимизирует время передачи.

BBCP находится в свободном доступе, вы можете погуглить, и это прямая компиляция. Просто скопируйте его в свой / usr / local / bin как на src, так и на целевую машину, и он будет работать.

Если у вас есть ftp-сервер на стороне src, вы можете использовать ncftpget из сайт ncftp. Он отлично работает с небольшими файлами, поскольку использует tar внутри.

Одно сравнение показывает следующее: перемещение небольших файлов размером 1,9 ГБ (33926 файлов)

  1. Использование scp занимает 11 мин. 59 сек.
  2. Использование rsync занимает 7 минут 10 секунд.
  3. Использование ncftpget занимает 1 мин. 20 сек.

Простой scp с соответствующими параметрами легко достигнет 9-10 МБ / с по локальной сети: 

scp -C -c arcfour256 ./local/files.mp3 remoteuser@remoteserver:/opt/remote

С этими параметрами вполне вероятно, что пропускная способность станет в 4 или 5 раз быстрее, чем без параметров (по умолчанию).

Вы не упомянули, находятся ли две машины в одной локальной сети или безопасный канал (например, с использованием SSH) является обязательным, но вы можете использовать другой инструмент. netcat.

Я бы использовал на принимающей машине следующее:

cd <destdir>
netcat -l -p <port> | gunzip | cpio -i -d -m

Затем на отправляющей стороне:

cd <srcdir>
find . -type f | cpio -o | gzip -1 | netcat <desthost> <port>

Он имеет следующие преимущества:

  • Нет накладных расходов ЦП для шифрования, которое имеет ssh.
  • В gzip -1 обеспечивает легкое сжатие, не перегружая ЦП, поэтому дает хороший компромисс, давая небольшое сжатие при сохранении максимальной пропускной способности. (Возможно, не так выгодно для данных MP3, но не повредит.)
  • Если вы можете разделить файлы на группы, вы можете запустить два или более каналов параллельно и действительно обеспечить насыщение полосы пропускания сети.

например.,

find <dir1> <dir2> -type f | cpio -o | gzip -1 | netcat <desthost> <portone>
find <dir3> <dir4> -type f | cpio -o | gzip -1 | netcat <desthost> <porttwo>

Ноты:

  • Каким бы способом вы ни перенесли, я бы, вероятно, запустил rsync или унисон потом, чтобы убедиться, что у вас есть все.
  • Вы могли бы использовать tar вместо того cpio Если вы предпочитаете.
  • Даже если вы в конечном итоге будете использовать ssh, я бы удостоверился, что он не использует никакого сжатия и пропускает через gzip -1 вместо этого, чтобы избежать перегрузки процессора. (Или, по крайней мере, установите для параметра CompressionLevel значение 1.)

Я столкнулся с этим, за исключением того, что переносил журналы Oracle.

Вот разбивка

  • scp

    inefficient and encrypted (encrypted = slower than unencrypted 
depending on the link and your processor)

  • rsync 

    efficient but typically encrypted (though not necessarily)

  • FTP / HTTP

    both seem to be efficient, and both are plaintext.

Я использовал FTP с большим успехом (где большой успех эквивалентен ~ 700 Мбит / с в сети Gb). Если вы получаете 10 МБ (что равно 80 МБ / с), вероятно, что-то не так.

Что вы можете рассказать нам об источнике и получателе данных? Это одиночный привод на одиночный привод? RAID на USB?

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

Для 100 МБ / с теоретическая пропускная способность составляет 12,5 МБ / с, поэтому при 10 МБ / с у вас все хорошо.

Я бы также поддержал предложение сделать rsync, возможно, через ssh. Что-то вроде:

rsync -avW -e ssh $SOURCE $USER@$REMOTE:$DEST

При скорости 100 Мбит / с ваши процессоры должны иметь возможность обрабатывать шифрование / дешифрование без заметного влияния на скорость передачи данных. А если вы прервете поток данных, вы сможете продолжить с того места, где остановились. Остерегайтесь, с "миллионами" файлов запуск займет некоторое время, прежде чем что-либо действительно передаст.

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

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

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

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

rsync, или вы можете захотеть удалить его в один файл, а затем scp. Если вам не хватает места на диске, вы можете направить tar прямо через ssh во время его создания.

Я попробовал несколько инструментов для копирования файла размером 1 ГБ. Результат ниже: HTTP - самый быстрый, с wget -c nc - второй в строке scp - самый медленный и пару раз терпел неудачу. Невозможно возобновить работу rsync использует ssh в качестве бэкэнда, поэтому результат тот же. В заключение, я бы выбрал http с wget -bqc и подождал. Надеюсь, это поможет

Мне пришлось скопировать диск BackupPC на другую машину.

Я использовал rsync.

В машине было 256 МБ памяти.

Я выполнил следующую процедуру:

  • казнен rsync без -H (заняло 9 часов)
  • когда rsync закончил, я синхронизировал cpool каталог и начал с pc каталог; Я перерезал передачу.
  • затем перезапустили rsync с участием -H флаг, и все файлы жестко связаны в pc были правильно перенесены (процедура нашла все реальные файлы в cpool а затем связан с pc справочник) (заняло 3 часа).

В конце концов я мог проверить с df -m что не было потрачено лишнего места.

Таким образом я избегаю проблемы с памятью и rsync. Все время я могу проверить производительность, используя top и atop, и в итоге я передал 165 ГБ данных.