Передача 10 ТБ файлов из США в датацентр Великобритании
Я перевожу свой сервер из США в Великобританию из одного центра обработки данных в другой. Мой хозяин сказал, что я должен достичь 11 мегабайт в секунду.
Операционная система Windows Server 2008 на обоих концах.
Мой средний размер файла составляет около 100 МБ, а данные разбиты на пять дисков по 2 ТБ.
Каков будет рекомендуемый способ передачи этих файлов?
- FTP
- SMB
- Rsync / Robocopy
- Другой?
Меня не слишком беспокоит безопасность, так как в любом случае это публичные файлы, но я просто хочу решение, которое может увеличить скорость передачи 11 МБ / с, чтобы минимизировать общее время передачи.
12 ответов
Вместо этого отправляйте жесткие диски через океан.
На скорости 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 МБ / с...
Вы можете использовать торрент для этого.
Создайте приватный торрент на одном конце и используйте клиент на другом.
Несмотря на наличие шифрования, вы должны проверить свои требования.