Я переношу свой сервер из США в Великобританию из одного центра обработки данных в другой. Мой хозяин сказал, что я смогу достичь 11 мегабайт в секунду.
На обоих концах установлена операционная система Windows Server 2008.
Мой средний размер файла составляет около 100 МБ, а данные разделены на пять дисков по 2 ТБ.
Каким будет рекомендуемый способ передачи этих файлов?
Я не слишком беспокоюсь о безопасности, так как это все равно общедоступные файлы, но мне просто нужно решение, которое может увеличить скорость передачи до 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 делают примерно то же самое.
Я знаю, что это уже принято, но рассматривали ли вы возможность переноса дисков в центр обработки данных / провайдера / хоста, где вы можете увеличить пропускную способность? Это, вероятно, будет стоить вам немного денег, но копирование 10240 ГБ на резервные диски и отправка также будут стоить как времени, так и денег (2 x деньги).
Также вы будете уверены, что ваши диски не сломаются при транспортировке.
11 Мбит / с? Это настоящее ограничение, которое у вас здесь. В вашей ситуации я бы просто:
Если у вас действительно нет решения для увеличения пропускной способности ... Тогда доставка физического диска будет намного быстрее.
Судя по моему болезненному опыту, жесткие диски ломаются при отправке почты ... 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 МБ / с ...
Для этого можно использовать торрент.
Создайте частный торрент на одном конце и используйте клиент на другом.
Хотя есть шифрование, вы должны проверить свои требования.