Який найкращий спосіб перенести один великий файл по високошвидкісному затримці WAN?

21

Це схоже на це , але дещо інакше.

Існує посилання WAN між двома сайтами компанії, і нам потрібно перенести один дуже великий файл (дамп Oracle, ~ 160 ГБ).

Ми отримали повну пропускну здатність 100 Мбіт / с (протестовано), але схоже, що одне TCP-з'єднання просто не може його досягти через те, як працює TCP (ACK та ін.). Ми перевірили зв'язок з iperf , і результати різко змінюються при збільшенні розміру вікна TCP: за базових налаштувань ми отримуємо пропускну здатність ~ 5 Мбіт / с, при великій WS ми можемо отримати до ~ 45 Мбіт / с, але не більше ніж це. Затримка в мережі становить близько 10 мс.

З цікавості ми запустили iperf, використовуючи більш ніж одне з'єднання, і ми виявили, що при запуску чотирьох з них вони дійсно досягають швидкості ~ 25 Мбіт / с кожен, заповнюючи всю наявну пропускну здатність; тому ключ виглядає у виконанні декількох одночасних передач.

З FTP все погіршується: навіть при оптимізованих налаштуваннях TCP (високий розмір вікна, максимум MTU тощо) ми не можемо отримати більше 20 Мбіт / с за одну передачу. Ми спробували FTPing кілька великих файлів одночасно, і дійсно все стало набагато краще, ніж при передачі одного; але тоді винуватим став введення / виведення диска, адже дуже скоро читати та записувати чотири великих файли з тих самих вузьких дисків; Крім того, ми, здається, не в змозі розділити цей один великий файл на більш дрібні, а потім об'єднати його, принаймні, не в прийнятні часи (очевидно, ми не можемо витратити сплайсування / злиття файлу часу, порівнянного з часом перенесення його).

Ідеальним рішенням тут був би багатопоточний інструмент, який міг би одночасно переносити різні фрагменти файлу; на зразок подібних однорангових програм, таких як eMule або BitTorrent, вже є, але з одного джерела до одного пункту призначення. В ідеалі, інструмент дозволив би нам вибрати, скільки паралельних з'єднань використовувати, і, звичайно, оптимізувати введення / виведення диска, щоб не переходити (занадто) шалено між різними розділами файлу.

Хтось знає про такий інструмент?

Або хтось може запропонувати краще рішення та / або щось, що ми вже не пробували?

PS Ми вже думали створити резервну копію на стрічку / диск і фізично відправити її до місця призначення; це було б нашим крайнім заходом, якби WAN просто не перерізав це, але, як сказав А.С. Таненбаум, "ніколи не занижуйте пропускну здатність вагона станції, повного стрічок, що хитаються вниз по шосе".

— Массімо
джерело

1

Чи не цікаво, чи це час, який потрібно, дійсно такий критичний? Також, чи не наситивши посилання тривалість 160Gb передачі не вплине на решту вашої мережі?

— Брайан

6

Я пам’ятаю, що доставив декілька автонавантажувачів DLT і пару сотень картриджів Клієнту ще у 1999 році. Ми обчислили необмежену ємність мого автомобіля з близько 200 картриджів DLT IV, завантажених у нього (35 ГБ ємності) в приблизно 6,3 ТБ. Я проїхав від нашого офісу до сайту замовника приблизно за 55 хвилин, що дало "Евану в геометрії, що їхав, як скажений по Междержавному" механізму резервного транспорту, ефективну пропускну здатність близько 118 ГБ / хв. Хороша пропускна здатність, але затримка була вбивчою ...> усмішка <

— Еван Андерсон

Брайан: так, час є критичним (це займає близько ДВАДИХ ЧАСІВ із стандартними FTP та стандартними мережевими налаштуваннями), і ні, не буде проблем із насиченням посилання, оскільки передача буде запланована у позаробочий час.

— Массімо

Еван: саме так я і мав на увазі ;-)

— Массімо

Я мав справу з подібною ситуацією, з ~ 200 ГБ SQL .bak, за винятком єдиного способу, який мені вдалося отримати посилання WAN до насичення, - це FTP. Я в кінцевому підсумку використовував 7-zip з нульовою компресією, щоб розбити його на 512 МБ. "Стиснення" та "декомпресія" часи були приємно короткими; все-у-все набагато краще, ніж лопата фізичних засобів масової інформації по всій країні. (Сайти розташовані на протилежних узбережжях США)

— Адрієн

15

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

Кілька комерційних пропозицій, які, як видається, відповідають законопроекту:

FileCatalyst має продукти, які можуть передавати дані по мережах з високою затримкою або за допомогою UDP або декількох потоків TCP. Вони також мають багато інших функцій (стиснення на льоту, дельта передачі тощо).
ФАСП передачі файлів «технології» від Aspera , як видається , відповідає законопроект за те , що ви шукаєте, а також.

У світі з відкритим кодом проект uftp виглядає багатообіцяючим. Вам особливо не потрібні його можливості багатоадресної передачі, але основна ідея вибуху файлу в приймачі, отримання NAK-адрес за пропущені блоки в кінці передачі, а потім вибуху блоків NAK'd (піна, промивання, повторення) звучить так, що це зробить все, що вам потрібно, оскільки від приймача ACK'ing (або NAK'ing) не відбувається до того моменту, коли передача файлів завершиться один раз. Якщо припустити, що мережа є просто прихованою, а не збитковою, це також може зробити все, що вам потрібно.

— Еван Андерсон
джерело

uftp виглядає по-справжньому перспективно, мені вдалося досягти 30 Мбіт / с між двома настільними комп'ютерами (які, безумовно, не дуже великі при продуктивності диска); Я незабаром тестую його на "справжніх" серверах. Мені не вдалося отримати демо-ліцензію FileCatalyst через деяку помилку в реєстраційній формі (він постійно говорить про те, що число запиту вже використано), і fasp просто не пропонує їх.

— Массімо

60 Мбіт / с між двома комп'ютерами з належними дисками та великим буфером прийому. Чудово!

— Массімо

Я люблю безкоштовне / відкрите програмне забезпечення! > посмішка <Я обов'язково спробую uftp спробувати деякі речі, які я роблю. Мені цікаво, як би це було зроблено в базі Linux-дисків для багатодискантного вирішення зображень, який я зібрав пару років тому, використовуючи "udpcast".

— Еван Андерсон

деякий час назад я запитав serverfault.com/questions/173358/multicast-file-transfers Зрештою я дійшов висновку, що uftp та mrsync - це інструменти вибору. Будь ласка, опублікуйте в коментарях там, якщо ви робите щось корисне з uftp, оскільки я буду використовувати те чи інше в цьому році (підготовка до конференції).

— Джед Даніельс

2

Коли я працював з UFTP, UDT та Цунамі UDP, UFTP мав найгірші показники з усіх трьох. Звичайно, це, мабуть, найзріліший протокол. UDT надає лише простий протокол передачі, і він був розроблений як бібліотека для розробки спеціального програмного забезпечення, і автор Цунамі насправді вказав нам на УДТ, оскільки Цунамі останнім часом не активно розвивався через брак часу.

— Томас Оуенс

9

Насправді дивна пропозиція цього .. Налаштуйте простий веб-сервер для розміщення файлу у вашій мережі (я пропоную, до речі, nginx), а потім встановіть ПК з firefox на іншому кінці та встановіть розширення DownThemAll .

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

(застереження: я ніколи не пробував його на чому-небудь великому, як 160 Гб, але він добре працює з ізо-файлами 20 ГБ)

— Том О'Коннор
джерело

40 Мбіт / с між тими ж комп’ютерами. Дуже добре теж виглядає.

— Массімо

1

замініть firefox на axel.alioth.debian.org, і це не так вже й погано.

— Джастін

7

Транспорт УДТ , мабуть, найпопулярніший транспорт для зв'язку з високою затримкою. Це призводить до їх іншого програмного забезпечення під назвою Sector / Sphere - "Високопродуктивна розподілена файлова система та паралельний механізм обробки даних", на що, можливо, варто ознайомитися.

— Стів-о
джерело

1

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

— Томас Оуенс

Навіть є версія rsync з вбудованою UDT, вона називається "UDR". github.com/LabAdvComp/UDR

— Макс

5

Моя відповідь трохи пізно, але я просто знайшов це питання, шукаючи fasp. Під час цього пошуку я також виявив це: http://tsunami-udp.sourceforge.net/ , "Протокол UDP Цунамі".

З їх веб-сайту:

Швидкий протокол передачі файлів у просторі користувача, який використовує TCP-контроль та дані UDP для передачі через дуже швидкі міжміські мережі (≥ 1 Гбіт / с і навіть 10 GE), розроблений, щоб забезпечити більше пропускної здатності, ніж можливо, за допомогою TCP через ті самі мережі. мереж.

Що стосується швидкості, сторінка згадує цей результат (використовуючи посилання між Гельсінкі, Фінляндія та Бонн, Німеччина через посилання 1 ГБ:

Рисунок 1 - міжнародна передача через Інтернет, в середньому 800 Мбіт / с

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

— Ян ван Хаарст
джерело

1

У проекті, який я коментував раніше у відповіді Стіва-о, ми орієнтувались на UDT, UDP Tsunami та UFTP. Ми виявили, що затримка має величезний вплив на продуктивність, тоді як втрата пакетів не робить (всупереч документації Цунамі). Додавання 100-ми затримки до тестової мережі знизило продуктивність Цунамі з приблизно 250Мбіт / секунду до приблизно 50Мбіт / секунду (я вважаю, що я маю свої цифри та одиниці правильно - минув час, але це було величезне падіння). Додавання 10% втрат пакетів без мінімальної затримки в мережі, з іншого боку, лише знизила продуктивність з 250Мбіт / с до приблизно 90Мбіт / секунду.

— Томас Оуенс

4

Bbcp утиліта від дуже відповідної сторінки «Як передавати великі обсяги даних через мережу» , здається, найпростіше рішення.

— Роберт Полсон
джерело

Я не думаю, що bbcp оптимізовано для високої затримки. На даний момент я отримую ~ 20 Мб / сек через трансатлантичне посилання з налаштуваннями за замовчуванням.

— Макс