Скопіюйте великий файл з одного сервера Linux на інший

Я намагаюся скопіювати 75-гігабайтний tgz (MySQL lvm-знімок) з сервера Linux в нашому центрі обробки даних LA на інший сервер Linux в нашому центрі обробки даних NY через посилання 10 Мб.

Я отримую приблизно 20-30Kb / s з rsync або scp, який коливається між 200-300 годин.

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

Я дотримувався різних посібників з налаштування tcp, які я знайшов через Google, безрезультатно (можливо, я читаю неправильні посібники, отримав хороший?).

Я бачив наконечник тунелю tar + netcat, але я розумію, що для МОЛЬШІ маленьких файлів це корисно, але не оновлює вас, коли файл фактично закінчує передачу.

Перш ніж вдатися до доставки жорсткого диска, чи має хтось хороший внесок?

ОНОВЛЕННЯ: Ну ... це може бути посилання після :( Дивіться мої тести нижче ...

Трансфери з Нью-Йорку в Лос-Анджелес:

Отримання порожнього файлу.

[nathan@laobnas test]$ dd if=/dev/zero of=FROM_LA_TEST bs=1k count=4700000
4700000+0 records in
4700000+0 records out
4812800000 bytes (4.8 GB) copied, 29.412 seconds, 164 MB/s
[nathan@laobnas test]$ scp -C obnas:/obbkup/test/FROM_NY_TEST .
FROM_NY_TEST                                    3%  146MB   9.4MB/s   07:52 ETA

Отримання знімка тарболу.

[nathan@obnas db_backup]$ ls -la db_dump.08120922.tar.gz
-rw-r--r-- 1 root root 30428904033 Aug 12 22:42 db_dump.08120922.tar.gz

[nathan@laobnas test]$ scp -C obnas:/obbkup/db_backup/db_dump.08120922.tar.gz .
db_dump.08120922.tar.gz            0%   56MB 574.3KB/s 14:20:40 ET

Трансфери з LA в Нью-Йорк:

Отримання порожнього файлу.

[nathan@obnas test]$ dd if=/dev/zero of=FROM_NY_TEST bs=1k count=4700000
4700000+0 records in
4700000+0 records out
4812800000 bytes (4.8 GB) copied, 29.2501 seconds, 165 MB/s
[nathan@obnas test]$ scp -C laobnas:/obbkup/test/FROM_LA_TEST .
FROM_LA_TEST                                    0% 6008KB 497.1KB/s 2:37:22 ETA

Отримання знімка тарболу.

[nathan@laobnas db_backup]$ ls -la db_dump_08120901.tar.gz
-rw-r--r-- 1 root root 31090827509 Aug 12 21:21 db_dump_08120901.tar.gz

[nathan@obnas test]$ scp -C laobnas:/obbkup/db_backup/db_dump_08120901.tar.gz .
db_dump_08120901.tar.gz                0%  324KB  26.8KB/s 314:11:38 ETA

Я думаю, я прийму це з людьми, які керують нашими установами, посилання позначене як MPLS / Ethernet посиланням 10 Мб. (знизує плечима)

Хтось кросівок?

Якщо припустити, що це одноразова копія, я не вважаю, що можливо просто скопіювати файл на компакт-диск (або інший носій) і перенести його до місця призначення?

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

rsync

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

rsync --progress file1 file2 user@remotemachine:/destination/directory

Прапор --progress дасть вам деякий відгук, а не просто сидіти там і залишає вас вдруге здогадуватися. :-)

Vuze (bittorrent)

Третім вибором, мабуть, буде спробувати використовувати Vuze як торент-сервер, а потім дозволити ваше віддалене місце розташування використовувати стандартний клієнт-bitorrent, щоб завантажити його. Я знаю про інших, хто це зробив, але ви знаєте ... до того моменту, коли вони все це налаштували на роботу, і т. Д. ... Я міг би переоцінити дані ...

Я думаю, залежить від вашої ситуації.

Удачі!

ОНОВЛЕННЯ:

Знаєте, я трохи більше задумався над вашою проблемою. Чому у файлі повинен бути один величезний тарбол? Дьоготь цілком здатний розділяти великі файли на менші (наприклад, на медіа), то чому б не розділити цей величезний тарбол на більш керовані фрагменти, а потім замість цього перенести шматки?

Я це робив раніше з файлом tbz2 об'ємом 60 Гб. У мене вже немає сценарію, але його слід легко переписати.

Спочатку розділіть свій файл на шматки ~ 2 Гб:

split --bytes=2000000000 your_file.tgz

Для кожного фрагмента обчисліть хеш MD5 (це перевірити цілісність) і зберігайте його десь, а потім починайте копіювати шматки та їх md5 на віддалений сайт за допомогою обраного вами інструменту (мені: netcat-tar-pipe на екрані сесія).

Через деякий час уточніть у md5, чи добре у вас шматки, тоді:

cat your_file* > your_remote_file.tgz

Якщо ви також зробили MD5 вихідного файлу, перевірте і його. Якщо це добре, ви можете зняти файл, все має бути нормально.

(Якщо знайду час, перепишу сценарій)

Зазвичай я є великим прихильником rsync, але при передачі одного файлу вперше це, здається, не має особливого сенсу. Якщо, однак, ви повторно передавали файл лише з невеликими відмінностями, rsync був би явним переможцем. Якщо ви все-таки вирішите використовувати rsync, настійно рекомендую запустити один кінець у --daemonрежимі, щоб усунути ssh-тунель, що вбиває продуктивність. Сторінка man описує цей режим досить ретельно.

Моя рекомендація? FTP або HTTP з серверами та клієнтами, які підтримують відновлення перерваних завантажень. Обидва протоколи швидкі та легкі, що дозволяє уникнути штрафу ssh-tunnel. Apache + wget би кричав швидко.

Трюк з мережевою трубкою також добре би працював. Тар не потрібен при передачі одного великого файлу. І причина, по якій він не повідомляє вас, коли це зроблено, - це тому, що ви цього не сказали. Додайте -q0прапор на сторону сервера, і він буде вести себе так, як ви очікували.

сервер $ nc -l -p 5000> outfile.tgz

клієнт $ nc -q0 server.example.com 5000 <infile.tgz

Недоліком підходу netcat є те, що він не дозволить вам відновитись, якщо ваш переказ помре 74 Гб у ...

Дайте netcat (іноді його називають nc). Далі працює над каталогом, але його слід досить легко налаштувати, щоб просто скопіювати один файл.

У полі призначення:

netcat -l -p 2342 | tar -C /target/dir -xzf -

У вихідному полі:

tar czf * | netcat target_box 2342

Ви можете спробувати видалити опцію 'z' в обох командах tar для трохи більшої швидкості, побачивши, що файл уже стиснуто.

SCP і Rsync за замовчуванням для великих файлів дуже повільні. Я думаю, я б розглядав використання протоколу з нижчими накладними витратами. Ви спробували використати простіший шифр-шифр, або взагалі не використовується? Спробуйте розглянути --rshможливість для rsync змінити спосіб передачі.

Чому б не FTP чи HTTP?

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

Така програма, як Azureus [тепер відомий як Vuze], містить усі фрагменти, які вам знадобляться для створення, сервера та завантаження торрентів в одному додатку. Маємо на увазі, Azureus - це не найвищий варіант, доступний для BitTorrent, і я думаю, що він також вимагає свого графічного інтерфейсу - є багато інструментів торрент-файлів, керованих командним рядком.

Ну, особисто, 20-30Kb / s здається досить низьким для 10Mb (якщо вважати 10Mb, а не 10MB).

Якби я був ти, я би зробив одну з двох речей (за умови, що фізичний доступ недоступний) -

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

Коли у вас є менші фрагменти, використовуйте або rsync ще раз, або я особисто вважаю за краще використовувати приватний сеанс Secure ftp, а потім CRC-файли після завершення.

У дискусіях може допомогти декілька питань: Наскільки критично важливі дані для передачі? Це для відновлення після аварій, гарячої резервної копії, зберігання в режимі офлайн чи що? Ви маєте намір створити резервну копію бази даних, поки вона вгору чи вниз? Як щодо налаштування бази даних у віддаленій системі та синхронізації з використанням кластеризації чи оновлення за допомогою змінних журналів (я не повністю розбираюся в можливостях системи баз даних MySql). Це може допомогти зменшити кількість даних, які потрібно передати через посилання.

bbcp буде скидати файл для вас і копіювати з декількох потоків.

Пізня відповідь для googlers:

Під час передачі великих наборів даних rsync можна використовувати для порівняння джерела та пункту призначення, а потім записати пакетний файл на локальний знімний носій, використовуючи прапор --only-write-batch. Потім ви доставляєте локальний носій у віддалене місце, підключаєте його та запускаєте знову rsync, використовуючи --read-batch для включення змін у віддалений набір даних.

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

(Ref: Я був один з авторів цієї функції в Rsync - для більш фону і використання випадків побачити це обговорення реалізації прототипу: https://lists.samba.org/archive/rsync/2005-March/011964 .html )