Пытаюсь передать около 100к файлов общим объемом 90гб. Прямо сейчас я использую демон rsync, но он медленный - 3,4 МБ / с, и мне нужно сделать это несколько раз. Мне интересно, какие у меня есть варианты, которые позволили бы максимизировать 100-мегабитное соединение через Интернет и быть очень надежными.
Вы считали Сникернет? При больших объемах данных доставка в ночное время часто оказывается быстрее и дешевле, чем передача через Интернет.
Самый быстрый метод, который я нашел, - это комбинация tar, mbuffer и ssh.
Например.:
tar zcf - bigfile.m4p | mbuffer -s 1K -m 512 | ssh otherhost "tar zxf -"
Используя это, я добился устойчивой передачи по локальной сети со скоростью более 950 Мбит / с по каналам 1 ГБ. Замените пути в каждой команде tar, чтобы они соответствовали тому, что вы переносите.
Самым узким местом при передаче больших файлов по сети, безусловно, является дисковый ввод-вывод. Ответ на это mbuffer или buffer. Они во многом похожи, но mbuffer имеет ряд преимуществ. Размер буфера по умолчанию составляет 2 МБ для mbuffer и 1 МБ для buffer. Буферы большего размера с большей вероятностью никогда не будут пустыми. Выбор размера блока, который является наименьшим общим кратным собственному размеру блока как в целевой, так и в целевой файловой системе, даст лучшую производительность.
Буферизация - это то, что делает все различия! Используйте это, если оно у вас есть! Если у вас его нет, получите! С помощью (m}?buffer плюс что-нибудь лучше, чем что-либо само по себе. это практически панацея от медленной передачи файлов по сети.
Если вы передаете несколько файлов, используйте tar «объединить» их в единый поток данных. Если это один файл, вы можете использовать cat или перенаправление ввода / вывода. Накладные расходы tar vs. cat статистически незначимо, поэтому я всегда использую tar (или zfs -send где я могу), если это уже не tarball. Ни один из них не гарантирует получение метаданных (и, в частности, cat не буду). Если вам нужны метаданные, я оставлю это вам в качестве упражнения.
Наконец, используя ssh поскольку транспортный механизм безопасен и несет очень небольшие накладные расходы. Опять же, накладные расходы ssh vs. nc статистически незначимо.
Вы упомянули "rsync", поэтому я предполагаю, что вы используете Linux:
Почему бы вам не создать файл tar или tar.gz? Время сетевой передачи одного большого файла быстрее, чем множества маленьких. Вы можете даже сжать его, если хотите ...
Деготь без сжатия:
На исходном сервере:
tar -cf file.tar /path/to/files/
Затем на принимающей стороне:
cd /path/to/files/
tar -xf /path/to/file.tar
Деготь со сжатием:
На исходном сервере:
tar -czf file.tar.gz /path/to/files/
Затем на принимающей стороне:
cd /path/to/files/
tar -xzf /path/to/file.tar.gz
Вы просто использовали бы rsync для фактической передачи файлов (tar | tar.gz).
Вы можете попробовать tar и ssh описанный трюк Вот:
tar cvzf - /wwwdata | ssh root@192.168.1.201 "dd of=/backup/wwwdata.tar.gz"
этот должен быть перезаписанным на следующий:
tar cvzf - /wwwdata | ssh root@192.168.1.201 "tar xvf -"
Вы потеряете --partial особенности rsync в процессе, однако. Если файлы меняются не очень часто, живя с медленным начальным rsync может быть очень полезным, так как это будет много быстрее в будущем.
Вы можете использовать различные параметры сжатия rsync.
-z, --compress compress file data during the transfer
--compress-level=NUM explicitly set compression level
--skip-compress=LIST skip compressing files with suffix in LIST
степень сжатия для двоичных файлов очень низкая, поэтому вы можете пропустить эти файлы с помощью --skip-compress, например. iso, уже заархивированные и сжатые архивы и т. д.
Я большой поклонник SFTP. Я использую SFTP для передачи мультимедиа с основного компьютера на сервер. Я получаю хорошие скорости по локальной сети.
SFTP надежен, я бы попробовал, так как его легко настроить, а в некоторых случаях он может быть быстрее.