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

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

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

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

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

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

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

91 голос | спросил Paul Hinett 4 +04002011-10-04T00:03:56+04:00312011bEurope/MoscowTue, 04 Oct 2011 00:03:56 +0400 2011, 00:03:56

12 ответов


171

Отправляйте жесткие диски через океан.

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


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

10240 GB /116.015 GB /day = ~ 88.3 days .

ответил Shane Madden 4 +04002011-10-04T00:14:38+04:00312011bEurope/MoscowTue, 04 Oct 2011 00:14:38 +0400 2011, 00:14:38
25

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

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

ответил Lucas Kauffman 4 +04002011-10-04T02:00:55+04:00312011bEurope/MoscowTue, 04 Oct 2011 02:00:55 +0400 2011, 02:00:55
14

Rsync, конечно.

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

ответил Korjavin Ivan 4 +04002011-10-04T00:07:43+04:00312011bEurope/MoscowTue, 04 Oct 2011 00:07:43 +0400 2011, 00:07:43
11

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

- Trad.

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

ответил ConcernedOfTunbridgeWells 4 +04002011-10-04T15:32:33+04:00312011bEurope/MoscowTue, 04 Oct 2011 15:32:33 +0400 2011, 15:32:33
9

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

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

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

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

ответил Will 4 +04002011-10-04T12:02:34+04:00312011bEurope/MoscowTue, 04 Oct 2011 12:02:34 +0400 2011, 12:02:34
5

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

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

ответил Asken 4 +04002011-10-04T11:13:20+04:00312011bEurope/MoscowTue, 04 Oct 2011 11:13:20 +0400 2011, 11:13:20
4

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

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

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

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

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

ответил Coyote 4 +04002011-10-04T04:15:50+04:00312011bEurope/MoscowTue, 04 Oct 2011 04:15:50 +0400 2011, 04:15:50
3

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

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

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

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

ответил Martin Scharrer 4 +04002011-10-04T11:36:01+04:00312011bEurope/MoscowTue, 04 Oct 2011 11:36:01 +0400 2011, 11:36:01
2

Вы считали IPoAC ?

  

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

ответил wim 4 +04002011-10-04T06:08:34+04:00312011bEurope/MoscowTue, 04 Oct 2011 06:08:34 +0400 2011, 06:08:34
2

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

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

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

ответил sjbotha 5 +04002011-10-05T06:17:02+04:00312011bEurope/MoscowWed, 05 Oct 2011 06:17:02 +0400 2011, 06:17:02
1

Вы упомянули, что серверы работают под управлением Windows 2008. Будет ли Microsoft DFS подходящее? В нижней части есть какая-то магия, которая пытается получить как можно большую пропускную способность из соединения, а также имеет сжатие и дедупликацию (IIRC).

Имейте в виду, что жесткие диски, DVD-диски или BluRays будут быстрее ... Мой расчет составляет 11 дней на полных 11 МБ /с ...

ответил TiernanO 5 +04002011-10-05T15:47:43+04:00312011bEurope/MoscowWed, 05 Oct 2011 15:47:43 +0400 2011, 15:47:43
0

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

Создайте частный торрент на одном конце и используйте клиент на другом.

Хотя есть шифрование, вы должны проверить свои требования.

ответил Dragos 5 +04002011-10-05T11:44:26+04:00312011bEurope/MoscowWed, 05 Oct 2011 11:44:26 +0400 2011, 11:44:26

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132