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

Я надсилаю велику кількість даних з однієї машини на іншу. Якщо я надішлю rsync (або будь-який інший метод), він піде зі стійкими 320 кбіт / сек. Якщо я ініціюю два або три передачі одночасно, кожен піде на 320, а якщо я зробить чотири одночасно, вони позначають максимум посилання.

Мені потрібно мати можливість якомога швидше надсилати дані, тому мені потрібен інструмент, який може робити зворотне мультиплексування з передачею файлів. Мені потрібно загальне рішення, тому виконувати розбиття на вихідній машині та спільне використання їх на іншому кінці не є практичним. Мені це потрібно для автоматизованої роботи.

Чи є інструмент, який це робить, чи мені потрібно зробити своє? Відправник - CentOS, одержувач - FreeBSD.

Це підтверджує все - я представляю "святий грааль" віддалених дзеркальних команд. Дякую davr за 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_server>;

Якщо у вас є велика кількість невеликих файлів, тоді використовуйте lftp -e 'mirror --parallel=100 <remote_dir> <local_dir>' <ftp_server>: ви завантажуєте 100 файлів паралельно без сегментації. Всього буде відкрито 100 підключень. Це може перешкодити доступним клієнтам на сервері або заборонити вас на деяких серверах.

Ви можете використовувати --continueдля відновлення завдання :) та -Rопцію завантажувати замість завантаження (потім перемикаючи порядок аргументів на <local_dir> <remote_dir>).

Можливо, ви зможете змінити налаштування TCP, щоб уникнути цієї проблеми, залежно від того, що спричиняє 320 КБ / с на обмеження з'єднання. Я здогадуюсь, що це не явне обмеження швидкості на з'єднання через Інтернет-провайдера. Є два ймовірних винуватця випаду:

1. Деякий зв’язок між двома машинами - це насичені та випадаючі пакети.
2. Вікна TCP насичені, оскільки продукт затримки пропускної здатності занадто великий.

У першому випадку кожен TCP-з'єднання фактично би конкурував однаково у стандартному контролі заторів TCP. Ви також можете покращити це, змінивши алгоритми управління конгестированием або зменшивши кількість викидів.

У другому випадку ви не обмежені втратою пакетів. Додавання додаткових з'єднань - це непростий спосіб збільшення загального розміру вікна. Якщо ви можете вручну збільшити розміри вікон, проблема усунеться. (Це може потребувати масштабування вікна TCP, якщо затримка підключення є достатньо високою.)

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

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

Все залежить від того, як структуровані ваші вихідні дані. Існує багато інструментів Unix для нарізки, кубиків та збирання файлів.

Якщо ви можете встановити без паролів вхід в ssh, це відкриє 4 паралельних з'єднання scp (-n) з кожним з'єднанням, що обробляє 4 файли (-L):

знайти. -типу f | xargs -L 4 -n 4 /tmp/scp.sh user @ host: path

Файл /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: кращим рішенням було б написати скрипт або програму, яка розділяє велике дерево каталогів на підтрупки на основі розміру, а потім копіює ці підрядки паралельно. Це може спростити речі, якщо спершу скопіювати всю структуру каталогів (без файлів).

Ви дві машини, які працюють у надійному середовищі? Ви можете спробувати 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 має хорошу сторінку з прикладами .