Вопрос: Передача 10 ТБ файлов из США в центр данных в Великобритании


Я переношу свой сервер из США в Великобританию из одного центра обработки данных в другой. Мой хост сказал, что я смогу достичь 11 мегабайт в секунду.

Операционная система - Windows Server 2008 с обоих концов.

Мой средний размер файла составляет около 100 МБ, и данные разделены на пять приводов с 2 ТБ.

Каким будет рекомендуемый способ передачи этих файлов?

  • FTP
  • SMB
  • Rsync / Robocopy
  • Другие?

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


91
2017-10-03 20:03


Источник


11 МБ / с или 11 Мбит / с? - wim
перенести данные на бинарную перфокарту и использовать голубь-перевозчик :) - enterzero
Вы должны предоставить подробную информацию. Сколько голубей-носителей вы думаете, что это займет? Показать свою работу. - Evik James
@Evik европейская или африканская? - wim
В стороне, Wolfram Alpha - самый удобный способ расчета: «10 ТБ при 11 МБ / с». wolframalpha.com/input/?i=10+TB+at+11MB%2Fs - pufferfish


Ответы:


Вместо этого отправляйте жесткие диски через океан.

При 11 Мбит / с при полном использовании вы смотрите на стеснение 90 дней на передачу 10 ТБ.


11 Мбит / с = 1,375 Мбит / с = 116,015 ГБ / день,

10240 ГБ / 116,015 ГБ / день = ~ 88,3 дня,


171
2017-10-03 20:14



+1 для Sneakernet, Кроме того, вы потеряли издержки TCP / IP. Это больше похоже на ~ 100 дней при идеальных обстоятельствах. - Chris S
Мудрый человек однажды сказал: «Никогда не недооценивайте пропускную способность универсала, заполненного лентами, мчащимися по шоссе». Это уравнение очень верно и существенно не изменено путем замены универсала для лодки. (bpfh.net/sysadmin/never-underestimate-bandwidth.html) - Rob Moir
Лучше отправлять ленты, или диски Blueray, а не диски. Если вы идете с дисками, убедитесь, что оригиналы хранятся в безопасности и доступны на всякий случай. Я сам поехал бы на диски (если бы у меня не было дисков Ultrium 4), потому что 10 TB = 410 однослойных blueray дисков! - Allen
Просто понял, что я набрал 11 Мбит / с, однако это то, что я на самом деле имел в виду - 11 МБ / с. Полагаю, это имеет большое значение, мои расчеты имеют примерно около 11-14 дней ... это правильно? - Paul Hinett
все еще верю, что отправка человека контролируется резервной копией 10TB, пока официальный диск все еще работает, после того как настройка будет выполнена, вы можете обедать rsync, чтобы обновить новый сервер для любых изменений. У вас будет машина около часа. - Loïc Faure-Lacroix


Я бы сказал, rsync, со скоростью 11 МБ / с вы будете смотреть 10-14 дней, и даже если вы прерваетесь, rsync легко начнет работу там, где он был остановлен в последний раз.

При скорости 11 Мбит / с я отправлял жесткие диски, как предлагалось выше :)


25
2017-10-03 22:00



Ваша оценка значительно отличается от того, что опубликовали другие (и я не знаю, кто прав). Можете ли вы предоставить свою методологию для достижения этих цифр? - John Gardeniers
Разница возникает из-за ошибочной ошибки OP 11 Мбит / с, когда на самом деле он имел в виду 11 Мбит / с - что в 8 раз быстрее. Кстати, перезапуск 10-кратного rsync в случае прерывания, вероятно, займет некоторое время, не так ли? Часы или дольше? - Frank Farmer
@FrankFarmer: я бы не беспокоился о перезапуске rsync; Я сохраняю внешнюю копию ~ 20 ТБ по беспроводной линии 30 Мбит / с, а перезапуск находится в диапазоне секунд. первоначальная копия заняла пару недель, но ночное обновление обычно занимает пару часов. - Javier
@FrankFarmer - rsync, похоже, очень хорошо масштабируется. У меня есть 2TB по сельской ADSL1 линии, которая была инициализирована sneakernet, но занимает ~ 5 минут до rsync каждую ночь, если ничего не изменилось. - Flexo
Временные шкалы времени rsync с количеством файлов (в основном из stat время, по моему опыту), а не с полными данными. Я бы не ожидал значительного ожидания (максимум несколько минут). Хотя мой опыт с rsync вершинами чуть ниже 5 ТБ. - derobert


Rsync конечно.

По крайней мере, вы можете продолжить в любое время после перерыва, и это безболезненно.


14
2017-10-03 20:07



3+ месяца для копирования при 100% использовании. Извините, но это ужасный способ передачи большого количества данных. - Chris S
Я должен согласиться с @ChrisS, используя rsync просто копировать большие файлы неэффективно. Для моих вещей я в конечном итоге использовал tar над netcat или ssh для первоначальной передачи. Он намного быстрее и сразу же начинает передачу, в то время как rsync сначала сканирует все файлы, что требует времени. Если это прерывается, вы все равно можете использовать rsync после этого. На самом деле, я делаю это иногда после tar в любом случае, чтобы обеспечить правильность всех разрешений, файлов сокетов и т. д. - Martin Scharrer
После того, как OP исправил, что у него есть соединение ~ 100Mb, а не 11Mb, rsync имеет гораздо больше смысла. +1 для первого упомянуть об этом. - Chris S


Никогда не недооценивайте пропускную способность универсала, заполненного лентами

- Trad.

В вашем случае диски или ленты, отправленные курьером, но принцип по-прежнему применяется. Если вас не интересует латентность, это будет значительно дешевле, чем пропускная способность сети, чтобы передавать 10 ТБ данных за любой разумный промежуток времени.


11
2017-10-04 11:32



Джефф Этвуд запустил номера в одном из своих старых сообщений Coding Horror. codinghorror.com/blog/2007/02/the-economics-of-bandwidth.html - tardate


Вы должны использовать rsync. Это будет компресс данные и де-дубликат перед отправкой. Он также может возобновлять частичные передачи, что очень важно для любых крупных передач.

Вероятно, он не переносит 10 ТБ; если это журналы и текст, и это может быть менее 1 ТБ; возможно, ниже 1 ТБ.

Есть инструменты, которые лучше справляются с сжатием, чем rsync, и, вероятно, найдут больше совпадений. Вы можете использовать lrzip, и т.д.

Существуют конкретные типы данных, которые не сжимаются хорошо и не содержат буквальных дубликатов - например, видео и другие носители. В этих случаях FTP и rsync предпринимают те же усилия.


9
2017-10-04 08:02



RSync дедуплицирует данные? Я думаю, что это только на уровне файла, что означает, что дедупликация в этом случае бесполезна. - devicenull


Я знаю, что это уже принято, но вы считаете, что принимаете свои диски в дата-центр / провайдер / хост, где вы можете увеличить пропускную способность? Это, вероятно, будет стоить вам денег, но копирование 10240Gb на резервные диски и отправка также будут стоить как времени, так и денег (2 x денег).

Также вы убедитесь, что ваши диски не ломаются в транспорте.


5
2017-10-04 07:13



Как этот ответ отличается от принятого ответа? - Chris S
@Chris Этот ответ предполагает перенос дисков на более крупную трубу на том же континенте. - Alexandre Jasmin


11Мб? Это ограничение, которое вы имеете здесь. В вашей ситуации я бы просто:

  • Клонировать данные
  • Сжатие
  • Аренда серверов на обоих концах с пропускной способностью не менее 10 раз (в тех же центрах обработки данных или на вашем конце в рядом с вами дата-центр).
  • Перенос файлов
  • Примените данные к новому серверу.

Если у вас действительно нет решения для увеличения полосы пропускания ... Тогда доставка физического диска будет быстрее.

Из-за моего болезненного опыта жесткие диски имеют тенденцию ломаться по почте ... USB-флеш-накопители - лучшее решение для частой передачи данных. В вашем случае это потребует нескольких из них :) Поэтому отправьте 2 копии ваших данных на несколько жестких дисков.

Учитывая объем данных, которые у вас есть, вы также можете отправлять диски из массива RAID 5 или RAID 6, если у вас есть одно и то же оборудование / программное обеспечение с другой стороны, чтобы подключать ваши диски. Но в этом случае не забудьте отметить порядок ваших дисков и их серийные номера, поэтому при реконфигурации они не смешиваются.


4
2017-10-04 00:15



извините, 11Mbps был ошибкой, это 11MB / s ... я упомянул в одном из приведенных выше комментариев. - Paul Hinett


В то время как я должен согласиться на «корабль с использованием жестких дисков», ответьте в этом случае, вот копия, которую я использую, когда мне приходится копировать большое количество файлов в первый раз:

В то время как rsync хорошо сохранять синхронизацию двух хранилищ данных, она вводит довольно много лишних накладных расходов для начальной передачи. Я понял, что самый быстрый способ - tar который получает netcat, На сайте получателя вы также можете использовать netcat в Слушать режим, который передает входящие данные в извлечение tar, Преимуществом является то, что tar начинает отправку немедленно и netcat отправляет его как обычный поток TCP без дополнительных надбавок на уровне более высокого уровня. Это должно быть так же быстро, как и получается. Тем не менее, не удается перезапустить прерванный перенос в последней позиции.

Также легко сжимать данные для передачи, используя правую tar варианты или добавить инструмент сжатия в трубах. Обратите внимание, что netcat отправляет дату незашифрованной. В случаях, когда это не вариант, зашифрованный ssh вместо этого можно использовать соединение (tar <options> | ssh <target> -c 'tar -x <options>').

Если все данные переданы rsync могут быть использованы для обеспечения синхронизации всех файлов, которые были обновлены в то же время. Также IIRC tar не создает сокеты, которые в противном случае теряются, но в любом случае они не используются для данных центра данных.


3
2017-10-04 07:36



Недостатком является то, что он не терпит к прерываниям - Joel Coel


Вы считали IPoAC?

Один голубь может переносить десятки гигабайт данных примерно за час, что на основе средней полосы пропускания очень выгодно сравнивается с существующими стандартами ADSL, даже при учете потерянных дисков.


2
2017-10-04 02:08



Голуби пострадали бы от потери сигнала на расстоянии, описанном ОП. - Roy Tinker
@RoyTinker Очищенный IPoAC необходимо реализовать с помощью процесса окон. - JamesBarnett


Опять же, первое предложение - отправить диски.

Второе предложение - использовать rsync для rsyncd, а не SSH. Я пробовал много вещей, и это, как правило, самый быстрый. Не забудьте включить сжатие. Кроме того, посмотрите увеличение или уменьшение размера буфера rsync для получения оптимальной скорости передачи. Это также может помочь увеличить размер MTU, Это помогает только в том случае, если маршрутизаторы на маршруте не фрагментируют ваши пакеты. Есть способы определить, действуют ли они.

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


2
2017-10-05 02:17