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

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

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

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

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

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

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

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

На скорости 11 Мбит / с с полной загрузкой вам потребуется всего лишь 90 дней для передачи 10 ТБ.

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

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

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

На скорости 11 Мбит / с я отправляю жесткие диски, как указано выше :)

Rsync конечно.

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

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

- Трад.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вы рассматривали IPoAC ?

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

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

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

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

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

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

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

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

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