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

Question

Я отправил большое количество данных с одной машины на другую. Если я отправлю с rsync (или любым другим способом), он будет работать со стабильными 320kb/sec. Если я инициирую две или три передачи одновременно, каждая будет идти по 320, а если я делаю четыре одновременно, они будут максимально использовать ссылку.

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

Есть ли инструмент, который делает это, или мне нужно сделать свой собственный? Отправитель - CentOS, получатель - FreeBSD.

Answer 1

Доказательство всего складывается - я представляю «Святой Грааль» команд удаленного зеркала. Спасибо davr за предложение lftp .

lftp -c "mirror --use-pget-n=10 --verbose sftp://username:password@server.com/directory" 

Выше будет рекурсивно зеркально отражать удаленный каталог, разбивая каждый файл на 10 потоков по мере его передачи!

Answer 2

Есть пара инструментов, которые могут работать.

• 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

Answer 3

Если у вас мало и большие файлы, используйте 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>).

Answer 4

Вы можете изменить настройки TCP, чтобы избежать этой проблемы, в зависимости от того, что вызывает ограничение в 320 КБ / с на соединение. Я предполагаю, что это не является явным ограничением скорости соединения для интернет-провайдера. Есть два вероятных виновника регулирования:

1. Некоторая связь между двумя машинами насыщена и отбрасывает пакеты.
2. Окна TCP насыщены, потому что произведение задержки полосы пропускания слишком велико.

В первом случае каждое TCP-соединение эффективно конкурирует в равной степени при стандартном контроле перегрузки TCP. Вы также можете улучшить это, изменив алгоритмы управления перегрузкой или уменьшив величину отката.

Во втором случае вы не ограничены потерей пакетов. Добавление дополнительных соединений - грубый способ увеличения общего размера окна. Если вы можете вручную увеличить размеры окна, проблема исчезнет. (Это может потребовать масштабирования окна TCP, если задержка соединения достаточно высока.)

Вы можете приблизительно определить, насколько большим должно быть окно, умножив время пинга в обоих направлениях на общую скорость соединения. Для 1280 КБ / с требуется 1280 (1311 для 1024 = 1 КБ) байтов на миллисекунду прохождения сигнала в обоих направлениях. Максимальный размер буфера в 64 КБ составляет около 50 мс, что довольно типично. Затем буфер 16 КБ насыщался бы до 320 КБ / с.

Answer 5

Как структурированы ваши данные? Несколько больших файлов? Несколько больших каталогов? Вы можете создать несколько экземпляров rsync в определенных ветвях дерева каталогов.

Все зависит от того, как структурированы ваши исходные данные. Существует множество инструментов Unix для нарезки, нарезки кубиками и повторной сборки файлов.

Answer 6

Если вы можете настроить 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 &

Answer 7

FTP использует несколько подключений для загрузки. Если вы можете настроить безопасный канал для FTP через VPN или FTP через SSH, вы сможете максимально использовать свое сетевое соединение. (Обратите внимание, что для FTP через SSH требуются особые соображения - см. Ссылку.)

FTPS (FTP через SSL) также может делать то, что вам нужно.

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

Answer 8

Попробуйте отсортировать все файлы в inode (find /mydir -type f -print | xargs ls -i | sort -n) и перенести их, например, с помощью cpio поверх ssh. Это максимально увеличит ваш диск и сделает сеть узким местом. Быстрее этого трудно пройти при переходе по сети.

Answer 9

Я знаю инструмент, который может передавать файлы кусками. Инструмент называется «пакет / порт rtorrent», который доступен на обоих хостах;) Клиенты BitTorrent часто резервируют дисковое пространство перед передачей, и чанки записываются непосредственно из сокетов на диск. Кроме того, вы сможете просматривать ВСЕ состояния переводов на удобном экране ncurses.

Вы можете создавать простые bash-скрипты, чтобы автоматизировать создание файла "* .torrent" и выполнить команду ssh на удаленной машине, чтобы она загружала его. Это выглядит немного уродливо, но я не думаю, что вы найдете какое-либо простое решение без разработки :)

Answer 10

Решение 1. Я не уверен, что это целесообразно в вашем случае, но вы можете создать составной архив (например, tarfile, разбитый на куски или составной архив 7zip), а затем использовать несколько экземпляров rsync для их отправки сеть и собрать / извлечь их на другой стороне. Вы могли бы написать сценарий общего назначения, аргументами которого являются каталог, который нужно передать, и количество используемых соединений. Очевидным недостатком является то, что вам понадобится вдвое больше свободного пространства с обеих сторон, и у вас будет дополнительная нагрузка на архивирование / извлечение файлов на обоих концах.

Решение 2: лучшее решение было бы написать скрипт или программу, которая делит большое дерево каталогов на поддеревья в зависимости от размера, а затем копирует эти поддеревья параллельно. Это может упростить ситуацию, если вы сначала скопируете всю структуру каталогов (без файлов).

Answer 11

Вы две машины в надежной среде? Вы можете попробовать netcat. На стороне сервера:

tar -czf - ./yourdir | nc -l 9999

и на клиенте:

nc your.server.net 9999 > yourdir.tar.gz

Вы можете настроить клиентское соединение на использование ssh-туннеля:

ssh -f -L 23333:127.0.0.1:9999 foo@your.server.net sleep 10; \
    nc 127.0.0.1 23333 > yourdir.tar.gz

Таким образом можно переместить даже весь раздел:

dd if=/dev/sda1 | gzip -9 | nc -l 9999

и на клиенте:

nc your.server.net 9999 > mysda1.img.gz

,

Заметка

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

HowtoForge имеет хорошую страницу с примерами.