Быстрый способ скопировать большой файл в локальной сети

24

У меня возникли проблемы с NFS, и я хотел бы попробовать использовать просто старый TCP.

Я понятия не имею, с чего начать.

Аппаратно, я использую кроссовер Ethernet-кабель для подключения двух нетбуков.

Чтобы объединить их в сеть, я набираю

$ sudo ifconfig eth0 192.168.1.1 up && ping -c 10 -s 10 192.168.1.2 && sudo /etc/init.d/nfs-kernel-server start

на первом нетбуке и

$ sudo ifconfig eth0 192.168.1.2 up
$ ping -c 10 -s 10 192.168.1.1
$ mount /mnt/network1

на второй

где /mnt/network1указано в / etc / fstab как

192.168.1.1:/home /mnt/network1 nfs noauto,user,exec,soft,nfsvers=2 0 0

а также в /etc/exports(используя синтаксис этого файла), на первом нетбуке.

Выше работает отлично, но файлы и каталоги огромны. Файлы в среднем занимают около половины гигабайта за штуку, а каталоги имеют размер от 15 до 50 гигабайт.

Я использую rsyncдля их передачи, и команда (вкл 192.168.1.2)

$ rsync -avxS /mnt/network1 ~/somedir

Я не уверен, есть ли способ изменить мои настройки NFS, чтобы лучше обрабатывать огромные файлы, но я хотел бы увидеть, работает ли rsyncдемон на более старых TCP лучше, чем rsyncна NFS.

Итак, еще раз, как я могу настроить аналогичную сеть с TCP?

ОБНОВИТЬ:

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

Но, прежде всего, то, что привело меня на этот путь кролика вместо того, чтобы просто принять текущий лучший ответ, заключалось в следующем: ncэто невероятно крутая программа, которая решительно не работает для меня. Я попробовал netcat-openbsdи netcat-traditionalпакеты без удачи вообще.

Ошибка, которую я получаю на принимающей машине ( 192.168.1.2):

me@netbook:~$ nc -q 1 -l -p 32934 | tar xv
Can't grab 0.0.0.0:32934 with bind
tar: This does not look like a tar archive
tar: Exiting with failure status due to previous errors

route дает:

me@netbook:~$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         dir-615         0.0.0.0         UG    0      0        0 wlan0
link-local      *               255.255.0.0     U     1000   0        0 eth0
192.168.0.0     *               255.255.255.0   U     2      0        0 wlan0
192.168.1.0     *               255.255.255.0   U     0      0        0 eth0

Но вот хорошая новость: установив статические IP-адреса /etc/network/interfaces, которые я начал делать, пытаясь заставить ncработать, исправил все мои проблемы с NFS и возродил мою любовь к NFS.

Точная конфигурация, которую я использовал ( 192.168.1.1конечно, для первого нетбука):

auto eth0
iface eth0 inet static
address 192.168.1.2
netmask 255.255.255.0

С этими настройками два нетбука смогут пинговать друг друга сразу после загрузки, даже без ifup.

Во всяком случае, я все еще очень хотел бы увидеть ncв действии, поэтому я надеюсь, что кто-нибудь поможет мне отладить этот процесс.

ixtmixilix
источник
Если оба каталога являются локальными, лучше использовать просто старый /bin/cpили вообще не использовать NFS
Карлсон
1
Запуск rsync для файла, доступ к которому осуществляется через NFS, означает, что все содержимое файла необходимо скопировать по сети хотя бы один раз. Вам не нужен демон для вызова rsync клиент / сервер - просто запустите его через ssh. (теоретически возможно вызывать удаленный конец через telnet / rsh - но довольно глупо запускать такой сервис на практике - ssh не добавляет много накладных расходов).
Symcbean
NFSv2 довольно старый. Какую ОС вы используете?
Нильс
последний Debian и последний Ubuntu, соответственно. я получил все эти команды (включая nfsvers=2) из этого урока ( michaelminn.com/linux/home_network )
ixtmixilix
5
на самом деле, ssh добавляет довольно много накладных расходов, криптография не из дешевых. При нормальных скоростях интернета это не имеет значения, но вы можете заметить это через локальную сеть (или в данном случае прямое кросс-соединение). За гигабит, за исключением очень быстрых машин (или машин с инструкциями AES-NI, если SSH их использует), я почти уверен, что это будет заметно.
Дероберт

Ответы:

43

Быстрый способ

Самый быстрый способ передачи файлов по локальной сети, скорее всего, не rsync, если только не было изменений. rsync тратит немало времени на выполнение контрольных сумм, вычисление различий и т. д. Если вы знаете, что в любом случае собираетесь передавать большую часть данных, просто сделайте что-то вроде этого (примечание: существует несколько реализаций netcat; обратитесь к руководству для правильные варианты. В частности, ваш может не захотеть -p)

user@dest:/target$ nc -q 1 -l -p 1234 | tar xv

user@source:/source$ tar cv . | nc -q 1 dest-ip 1234

Это использует netcat ( nc) для отправки tar через необработанное TCP-соединение через порт 1234. Шифрование, проверка подлинности не выполняется, и т. Д., Поэтому это очень быстро. Если ваша кросс-коммутация работает на гигабитах или меньше, вы подключитесь к сети; если его больше, вы будете привязывать диск (если у вас нет массива хранения или быстрого диска). В vфлаги дегтя сделать его напечатать имена файлов , как она идет (многословный режим). С большими файлами это практически не накладные расходы. Если бы вы делали тонны маленьких файлов, вы бы это отключили. Кроме того, вы можете вставить что-то вроде pvв конвейер, чтобы получить индикатор прогресса:

user@dest:/target$ nc -q 1 -l -p 1234 | pv -pterb -s 100G | tar xv

Конечно, вы можете вставить и другие вещи, например gzip -1(и добавить zфлаг на принимающей стороне - zфлаг на отправляющей стороне будет использовать более высокий уровень сжатия, чем 1, если, конечно, вы не установите переменную среды GZIP). Хотя, вероятно, gzip будет работать медленнее, если только ваши данные не сжимаются.

Если вам действительно нужен rsync

Если вы действительно передаете только небольшую часть измененных данных, rsync может быть быстрее. Вы также можете захотеть взглянуть на параметр -W/ --whole-file, как в случае очень быстрой сети (например, перекрестного соединения), которая может быть быстрее.

Самый простой способ запустить rsync - использовать ssh. Возможно, вы захотите поэкспериментировать с ssh-шифрами, чтобы увидеть, какие из них самые быстрые, это будут AES, ChaCha20 или Blowfish (хотя существуют некоторые проблемы безопасности с размером 64-битных блоков Blowfish), в зависимости от того, имеет ли ваш чип AES от Intel -NI инструкции (и ваш OpenSSL использует их). На новом достаточно ssh, rsync-over-ssh выглядит так:

user@source:~$ rsync -e 'ssh -c aes128-gcm@openssh.com' -avP /source/ user@dest-ip:/target

Для старых ssh / sshd попробуйте aes128-ctrили aes128-cbcвместо aes128-gcm@openssh.com.

ChaCha20 будет chacha20-poly1305@openssh.com(также требуется достаточно новый ssh ​​/ sshd), а Blowfish будет blowfish-cbc. OpenSSH не позволяет работать без шифра. Вы, конечно, можете использовать любые параметры rsync, которые вам нравятся -avP. И, конечно, вы можете пойти в другом направлении и запустить rsync с конечного компьютера (pull) вместо исходного компьютера (push).

Сделать rsync быстрее

Если вы запустили демон rsync, вы можете избавиться от служебных данных криптографии. Во-первых, вы должны создать файл конфигурации демона ( /etc/rsyncd.conf), например, на исходном компьютере (подробнее см. Справочную страницу rsyncd.conf):

[big-archive]
    path = /source
    read only = yes
    uid = someuser
    gid = somegroup

Затем на целевом компьютере вы запустите:

user@dest:~$ rsync -avP source-ip::big-archive/ /target

Вы можете сделать это и наоборот (но, конечно, вам нужно будет установить только чтение). Существуют варианты аутентификации и т. Д., Обратитесь к man-странице за подробностями.

derobert
источник
2
Это отличный ответ. Другой тоже великолепен. Разве нет принятого ответа только потому, что спрашивающий не может выбирать между ними?
Судо
Насколько надежен netcatподход? Если сеть отбрасывает пакеты, кажется, что она потеряет случайные части файлов.
Судо
1
@sudo использует TCP, который будет передавать по мере необходимости. Так что это должно быть хорошо против потери пакетов, случайного повреждения (в той мере, в какой контрольные суммы TCP и Ethernet его улавливают) и т. Д. Конечно, он не защищен от атак, таких как туннелирование по ssh.
Дероберт
1
@sudo, вы можете сделать все сразу, вставьте несколько teeкоманд в канал с обеих сторон, чтобы вычислить контрольные суммы.
Дероберт
1
@TheStoryCoder Точка в tarчасти говорит ей, чтобы она делала текущий каталог. На самом деле это не часть ncкоманды, tar используется для создания архива tar, который передается в netcat (а с другой стороны, netcat передается в tar для извлечения архива). Боюсь, что комментария недостаточно для объяснения каналов, но, надеюсь, этого достаточно, чтобы вы начали ...
Дероберт,
17

Как? Или TL; DR

Самый быстрый метод , который я нашел это сочетание tar, mbufferи ssh.

Например:

tar zcf - bigfile.m4p | mbuffer -s 1K -m 512 | ssh otherhost "tar zxf -"

Благодаря этому я добился устойчивой передачи по локальной сети со скоростью более 950 Мбит / с по каналам 1 Гбит. Замените пути в каждой команде tar, чтобы они соответствовали тому, что вы переносите.

Зачем? mbuffer!

Самым большим узким местом в передаче больших файлов по сети является, безусловно, дисковый ввод-вывод. Ответ на это mbufferили buffer. Они во многом похожи, но mbufferимеют некоторые преимущества. Размер буфера по умолчанию составляет 2 МБ для mbufferи 1 МБ для buffer. Большие буферы с большей вероятностью никогда не будут пустыми. Выбор размера блока, который является наименьшим общим кратным собственного размера блока как в целевой, так и в целевой файловой системе, даст наилучшую производительность.

Буферизация это то , что делает все различия! Используйте это, если у вас есть это! Если у вас его нет, получите! Использование (m}?bufferплюс что-либо лучше чем что-либо само по себе. это почти буквально панацея для медленной передачи файлов по сети.

Если вы передаете несколько файлов, используйте tarих для объединения их в один поток данных. Если это один файл, который вы можете использовать catили перенаправление ввода / вывода. Накладные расходы на tarvs. catстатистически незначимы, поэтому я всегда использую tar(или zfs -sendтам, где могу), если это уже не тарбол . Ни один из них не гарантирует вам метаданные (и, в частности cat, не даст). Если вы хотите метаданные, я оставлю это в качестве упражнения для вас.

Наконец, использование sshдля транспортного механизма является безопасным и несет очень мало накладных расходов. Опять же, накладные расходы по sshсравнению ncстатистически незначимы.

bahamat
источник
4
openssl speedна i7-3770 дает ~ 126–146 МБ / с для CBC Blowfish и ~ 138–157 МБ / с для CES AES (этот чип имеет инструкции AES-NI). Тогда ~ 200–300 МБ / с для ша256. Таким образом, он может едва выдвинуть 1 гигабит. С OpenSSH 6.1+ вы можете использовать AES GCM, что он может делать со скоростью ослепления (370–1320 МБ / с, в зависимости от размера сообщения). Поэтому я думаю, что верно только то, что OpenSSH имеет небольшие накладные расходы, если вы используете 6.1+ на чипе с AES-NI и используете AES-GCM.
Дероберт
1
Тьфу, я изменил это на 6.1+ вместо 6.2+ в последнюю минуту, быстро перепроверив. Конечно, это было ошибкой, это изменения с 6.1. Так что OpenSSH 6.2+ - это правильная версия. И это не позволит мне редактировать комментарий больше. Комментарии старше 5 минут должны оставаться неверными. Конечно, если OpenSSH версии ниже 6.4, см. Openssh.com/txt/gcmrekey.adv, как без патча, в реализации OpenESH AES-GCM есть уязвимый недостаток.
Дероберт
Затраты на ssh(или rsync поверх ssh) очень, ОЧЕНЬ важны. У меня есть NAS, который использует процессор Intel Atom. Шифрование SSH АБСОЛЮТНО РЕГУЛИРУЕТ скорость передачи. Я получаю постоянно <400 Мбит / с для RSA, ручное переопределение его для RC4 дает мне ~ 600 Мбит / с, и если я использую rsync в качестве демона, он работает с собственной скоростью соединения (> 900 Мбит / с, на гигабитном уровне) подключение).
Фальшивое имя
Несмотря на то, что во многих ситуациях транспортировка не является критически важной, это абсолютно важно учитывать, особенно если вы не работаете на высокопроизводительном оборудовании. В моем случае, Atom (это D525, двухъядерный 1,8 ГГц) делает NAS полностью отличным, с большой скоростью для SMB, но шифрование абсолютно убивает его.
Фальшивое имя
2
Я получаю фатальную ошибку из-за параметризации mbuffer: 'mbuffer: fatal: общая память должна быть больше, чем размер блока \ n Завершено'. Чтобы исправить, я подозреваю, что он должен читать что-то вроде 'mbuffer -s 1K -m 512M', а последняя буква 'M' обозначает MByte (источник: man mbuffer)
Питер Люстиг
1

Вам даже не нужно использовать TCP. AoE - это реализация ATA через Ethernet, а на втором уровне это подход с меньшими издержками, без знания стека TCP / IP. Это обеспечит вам максимально быстрый перевод с наименьшими накладными расходами. ***

https://en.wikipedia.org/wiki/ATA_over_Ethernet

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

Уильям Динс
источник
Вау, это жесткое ядро! :) Интересно, есть ли какие-нибудь тесты ...
rogerdpack