Я отправил большое количество данных с одной машины на другую. Если я отправлю с rsync (или любым другим способом), он будет работать со стабильными 320kb / sec. Если я инициирую две или три передачи одновременно, каждая будет идти по 320, а если я делаю четыре одновременно, они будут максимально использовать ссылку.
Мне нужно иметь возможность отправлять данные как можно быстрее, поэтому мне нужен инструмент, который может выполнять обратное мультиплексирование с передачей файлов. Мне нужно общее решение, так что запускать split на исходном компьютере и объединять их на другом конце нецелесообразно. Мне нужно, чтобы это работало в автоматическом режиме.
Есть ли инструмент, который делает это, или мне нужно сделать свой собственный? Отправитель - CentOS, получатель - FreeBSD.
Доказательство всего складывается - я представляю «Святой Грааль» команд удаленного зеркала. Спасибо Давру за lftpпредложение.
lftp -c "mirror --use-pget-n=10 --verbose sftp://username:password@server.com/directory" Выше будет рекурсивно зеркально отражать удаленный каталог, разбивая каждый файл на 10 потоков по мере его передачи!
Есть пара инструментов, которые могут работать.
LFTP - поддерживает FTP, HTTP и SFTP. Поддерживает использование нескольких соединений для загрузки одного файла. Предполагая, что вы хотите перенести файл с удаленного сервера на локальный сервер, установите LFTP на локальный сервер и запустите:
lftp -e 'pget -n 4 sftp://userName@remoteServer.com/some/dir/file.ext'
«-N 4» - это количество подключений для параллельного использования.
Кроме того, существует множество инструментов «ускорителя загрузки», но они обычно поддерживают только HTTP или FTP, которые вы, возможно, не захотите устанавливать на удаленном сервере. Вот некоторые примеры: Axel, aria2 и ProZilla
Если у вас есть несколько файлов большого размера, используйте lftp -e 'mirror --parallel=2 --use-pget-n=10 <remote_dir> <local_dir>' <ftp_server>: вы загрузите 2 файла, каждый из которых будет разбит на 10 сегментов с общим количеством соединений 20 ftp <ftp_server>;
Если у вас есть большое количество маленьких файлов, тогда используйте lftp -e 'mirror --parallel=100 <remote_dir> <local_dir>' <ftp_server>: вы будете загружать 100 файлов параллельно без сегментации, тогда. Всего будет открыто 100 соединений. Это может привести к исчерпанию доступных клиентов на сервере или может заблокировать вас на некоторых серверах.
Вы можете использовать --continueдля возобновления работы :) и -Rвозможность загрузки вместо загрузки (затем переключение порядка аргументов в <local_dir> <remote_dir>).
Как структурированы ваши данные? Несколько больших файлов? Несколько больших каталогов? Вы можете создать несколько экземпляров rsync в определенных ветвях дерева каталогов.
Все зависит от того, как структурированы ваши исходные данные. Существует множество инструментов Unix для нарезки, нарезки кубиками и повторной сборки файлов.
Вы можете изменить настройки TCP, чтобы избежать этой проблемы, в зависимости от того, что вызывает ограничение в 320 КБ / с на соединение. Я предполагаю, что это не является явным ограничением скорости соединения для интернет-провайдера. Есть два вероятных виновника регулирования:
В первом случае каждое TCP-соединение эффективно конкурирует в равной степени при стандартном контроле перегрузки TCP. Вы также можете улучшить это, изменив алгоритмы управления перегрузкой или уменьшив величину отката.
Во втором случае вы не ограничены потерей пакетов. Добавление дополнительных соединений - грубый способ увеличения общего размера окна. Если вы можете вручную увеличить размеры окна, проблема исчезнет. (Это может потребовать масштабирования окна TCP, если задержка соединения достаточно высока.)
Вы можете приблизительно определить, насколько большим должно быть окно, умножив время пинга в обоих направлениях на общую скорость соединения. Для 1280 КБ / с требуется 1280 (1311 для 1024 = 1 КБ) байтов на миллисекунду прохождения сигнала в обоих направлениях. Максимальный размер буфера в 64 КБ составляет около 50 мс, что довольно типично. Затем буфер 16 КБ насыщался бы до 320 КБ / с.
Если вы можете настроить ssh-вход без пароля, то откроются 4 одновременных scp-соединения (-n) с каждым соединением, обрабатывающим 4 файла (-L):
находить . тип F | xargs -L 4 -n 4 /tmp/scp.sh user @ host: путь
Файл /tmp/scp.sh:
#!/bin/bash #Display the help page function showHelp() { echo "Usage: $0 <destination> <file1 [file2 ... ]>" } #No arguments? if [ -z "$1" ] || [ -z "$2" ]; then showHelp exit 1 fi #Display help? if [ "$1" = "--help" ] || [ "$1" = "-h" ]; then showHelp exit 0 fi #Programs and options SCP='scp' SCP_OPTS='-B' DESTINATION="$1";shift; #Check other parameters if [ -z "$DESTINATION" ]; then showHelp exit 1 fi echo "$@" #Run scp in the background with the remaining parameters. $SCP $SCP_OPTS $@ $DESTINATION & Попробуйте отсортировать все файлы в inode (find / mydir -type f -print | xargs ls -i | sort -n) и перенести их, например, с помощью cpio поверх ssh. Это максимально увеличит ваш диск и сделает сеть узким местом. Быстрее этого трудно пройти при переходе по сети.
Я знаю инструмент, который может передавать файлы кусками. Инструмент называется «пакет / порт rtorrent», который доступен на обоих хостах;) Клиенты BitTorrent часто резервируют дисковое пространство перед передачей, и чанки записываются непосредственно из сокетов на диск. Кроме того, вы сможете просматривать ВСЕ состояния переводов на удобном экране ncurses.
Вы можете создавать простые bash-скрипты, чтобы автоматизировать создание файла "* .torrent" и выполнить команду ssh на удаленной машине, чтобы она загружала его. Это выглядит немного уродливо, но я не думаю, что вы найдете какое-либо простое решение без разработки :)
FTP использует несколько подключений для загрузки. Если вы можете настроить безопасный канал для FTP через VPN или FTP через SSH, вы сможете максимально использовать свое сетевое соединение. (Обратите внимание, что для FTP через SSH требуются особые соображения - см. Ссылку.)
FTPS (FTP через SSL) также может делать то, что вам нужно.
Вы также можете использовать SFTP-клиент, который поддерживает несколько соединений, но я не уверен, поддерживает ли SFTP несколько соединений для одного файла. Это должно делать то, что вам нужно в большинстве случаев, но может не дать вам максимальной пропускной способности, когда вам нужно передать только один большой файл.
Решение 1. Я не уверен, что это целесообразно в вашем случае, но вы можете создать составной архив (например, tarfile, разбитый на куски или составной архив 7zip), а затем использовать несколько экземпляров rsync для их отправки сеть и собрать / извлечь их на другой стороне. Вы могли бы написать сценарий общего назначения, аргументами которого являются каталог, который нужно передать, и количество используемых соединений. Очевидным недостатком является то, что вам понадобится вдвое больше свободного пространства с обеих сторон, и у вас будет дополнительная нагрузка на архивирование / извлечение файлов на обоих концах.
Решение 2: лучшее решение было бы написать скрипт или программу, которая делит большое дерево каталогов на поддеревья в зависимости от размера, а затем копирует эти поддеревья параллельно. Это может упростить ситуацию, если вы сначала скопируете всю структуру каталогов (без файлов).