Скопируйте большой файл с одного сервера Linux на другой

Я пытаюсь скопировать 75-гигабайтный tgz (снимок mysql lvm) с сервера Linux в нашем центре обработки данных в Лос-Анджелесе на другой сервер Linux в нашем центре обработки данных в Нью-Йорке по каналу связи 10 МБ.

Я получаю около 20-30 Кбит / с с rsync или scp, который колеблется между 200-300 часами.

На данный момент это относительно тихая ссылка, так как второй центр обработки данных еще не активен, и я получил отличную скорость от небольшой передачи файлов.

Я следовал различным руководствам по настройке tcp, которые нашел через google, но безрезультатно (может, я читаю не те руководства, есть хорошие?).

Я видел туннельный наконечник tar + netcat, но, насколько я понимаю, он полезен только для МНОЖЕСТВА небольших файлов и не обновляет вас, когда передача файла завершена.

Прежде чем я прибегну к отправке жесткого диска, есть ли у кого-нибудь хороший вход?

ОБНОВЛЕНИЕ: Ну ... это может быть ссылка в конце концов :( Смотрите мои тесты ниже ...

Трансферы из Нью-Йорка в Лос-Анджелес:

Получение пустого файла.

[nathan@laobnas test]$ dd if=/dev/zero of=FROM_LA_TEST bs=1k count=4700000
4700000+0 records in
4700000+0 records out
4812800000 bytes (4.8 GB) copied, 29.412 seconds, 164 MB/s
[nathan@laobnas test]$ scp -C obnas:/obbkup/test/FROM_NY_TEST .
FROM_NY_TEST                                    3%  146MB   9.4MB/s   07:52 ETA

Получение снимка тарбола.

[nathan@obnas db_backup]$ ls -la db_dump.08120922.tar.gz
-rw-r--r-- 1 root root 30428904033 Aug 12 22:42 db_dump.08120922.tar.gz

[nathan@laobnas test]$ scp -C obnas:/obbkup/db_backup/db_dump.08120922.tar.gz .
db_dump.08120922.tar.gz            0%   56MB 574.3KB/s 14:20:40 ET

Трансферы из Лос-Анджелеса в Нью-Йорк:

Получение пустого файла.

[nathan@obnas test]$ dd if=/dev/zero of=FROM_NY_TEST bs=1k count=4700000
4700000+0 records in
4700000+0 records out
4812800000 bytes (4.8 GB) copied, 29.2501 seconds, 165 MB/s
[nathan@obnas test]$ scp -C laobnas:/obbkup/test/FROM_LA_TEST .
FROM_LA_TEST                                    0% 6008KB 497.1KB/s 2:37:22 ETA

Получение снимка тарбола.

[nathan@laobnas db_backup]$ ls -la db_dump_08120901.tar.gz
-rw-r--r-- 1 root root 31090827509 Aug 12 21:21 db_dump_08120901.tar.gz

[nathan@obnas test]$ scp -C laobnas:/obbkup/db_backup/db_dump_08120901.tar.gz .
db_dump_08120901.tar.gz                0%  324KB  26.8KB/s 314:11:38 ETA

Я полагаю, что я подберусь с людьми, которые управляют нашими объектами, канал помечен как канал MPLS / Ethernet 10 МБ. (Развести руки)

Sneakernet Кто-нибудь?

Предполагая, что это однократная копия, я не предполагаю, что можно просто скопировать файл на компакт-диск (или другой носитель) и перенести его в место назначения в течение ночи?

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

Rsync

Моим вторым выбором / попыткой будет rsync, поскольку он обнаруживает неудачные передачи, частичные передачи и т. Д. И может принимать их с того места, где остановился.

rsync --progress file1 file2 user@remotemachine:/destination/directory

Флаг --progress даст вам некоторую обратную связь, вместо того, чтобы просто сидеть и позволять себе догадываться. :-)

Вузе (битторрент)

Третий вариант, вероятно, состоит в том, чтобы попытаться использовать Vuze в качестве торрент-сервера, а затем попросить удаленное местоположение использовать стандартный битторрент-клиент для его загрузки. Я знаю других, которые сделали это, но вы знаете ... к тому времени, когда они все это настроили и т. Д. ... я мог бы не заметить данные ...

Зависит от вашей ситуации, я думаю.

Удачи!

ОБНОВИТЬ:

Знаешь, я немного подумала о твоей проблеме. Почему файл должен быть одним огромным архивом? Tar прекрасно способен разбивать большие файлы на более мелкие (например, на медиафайлы), так почему бы не разбить этот огромный тарболл на более управляемые куски, а затем перенести их вместо этого?

Я делал это в прошлом, с файлом 60 ГБ tbz2. У меня больше нет сценария, но его должно быть легко переписать.

Сначала разделите ваш файл на части по ~ 2 ГБ:

split --bytes=2000000000 your_file.tgz

Для каждого фрагмента вычислите хеш MD5 (это нужно для проверки целостности) и сохраните его где-нибудь, затем начните копировать фрагменты и их md5 на удаленный сайт с помощью выбранного вами инструмента (меня: netcat-tar-pipe на экране). сессия).

Через некоторое время уточните у md5, все ли у вас в порядке, тогда:

cat your_file* > your_remote_file.tgz

Если вы также сделали MD5 исходного файла, проверьте его тоже. Если все в порядке, вы можете распаковать свой файл, все должно быть в порядке.

(Если найду время, перепишу скрипт)

Обычно я большой сторонник rsync, но при первой передаче отдельного файла это не имеет особого смысла. Однако, если вы повторно переносите файл с небольшими отличиями, победителем станет rsync. Если вы все равно решите использовать rsync, я настоятельно рекомендую запустить один конец в --daemonрежиме, чтобы устранить ssh-туннель, снижающий производительность. Страница man описывает этот режим довольно подробно.

Моя рекомендация? FTP или HTTP с серверами и клиентами, которые поддерживают возобновление прерванных загрузок. Оба протокола быстрые и легкие, избегая штрафа ssh-туннеля. Apache + wget будет кричать быстро.

Трюк с Netcat-трубкой тоже подойдет. Tar не требуется при передаче одного большого файла. И причина, по которой он не уведомляет вас, когда это сделано, заключается в том, что вы не сказали это. Добавьте -q0флаг на стороне сервера, и он будет вести себя точно так, как вы ожидаете.

сервер $ nc -l -p 5000> outfile.tgz

client $ nc -q0 server.example.com 5000 <infile.tgz

Недостатком подхода netcat является то, что он не позволит вам возобновить работу, если ваш перевод умирает 74GB в ...

Дайте netcat (иногда называемый nc) выстрел. Следующее работает с каталогом, но его достаточно легко настроить для простого копирования одного файла.

На поле назначения:

netcat -l -p 2342 | tar -C /target/dir -xzf -

На коробке источника:

tar czf * | netcat target_box 2342

Вы можете попытаться удалить опцию 'z' в обеих командах tar для большей скорости, поскольку файл уже сжат.

SCP по умолчанию и Rsync (который использует SCP) работают очень медленно для больших файлов. Я думаю, я бы хотел использовать протокол с меньшими издержками. Вы пытались использовать более простой шифровальный шифр или вообще не использовать его? Попробуйте найти --rshвариант для rsync, чтобы изменить способ передачи.

Почему не FTP или HTTP?

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

Такая программа, как Azureus [теперь известная как Vuze], содержит все части, которые вам понадобятся для создания, сервера и загрузки торрентов в одном приложении. Помните, что Azureus - не самое простое из доступных решений для BitTorrent, и я думаю, что для него тоже нужен графический интерфейс - хотя для linux существует множество торрент-инструментов, управляемых из командной строки.

Лично, 20-30 Кбит / с кажется довольно низким для 10 МБ (при условии 10 МБ, а не 10 МБ) канала.

Если бы я был тобой, я бы сделал одну из двух вещей (если физический доступ не доступен) -

Либо один, я советую вам разбить большой файл на более мелкие куски, около 500 МБ. Просто в случае повреждения при передаче.

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

В обсуждениях могут помочь несколько вопросов: насколько важны данные, подлежащие передаче? Это для аварийного восстановления, горячего резервного копирования, автономного хранения или как? Вы намереваетесь сделать резервную копию базы данных, когда она включена или выключена? Как насчет настройки базы данных на удаленной системе и поддержания их синхронизации с помощью кластеризации или обновления через журналы изменений (я не совсем разбираюсь в возможностях системы баз данных MySql). Это может помочь уменьшить объем данных, которые необходимо передать по ссылке.

bbcp создаст для вас файл чанка и скопирует его несколькими потоками.

Поздний ответ для Google:

При передаче больших наборов данных rsync можно использовать для сравнения источника и места назначения, а затем записать пакетный файл на локальный съемный носитель, используя флаг --only-write-batch. Затем вы отправляете локальный носитель в удаленное местоположение, подключаете его и снова запускаете rsync, используя --read-batch для включения изменений в удаленный набор данных.

Если исходные файлы изменяются во время физической передачи или если транспортный носитель заполняется, вы можете просто продолжать повторять --only-write-batch | корабль | - цикл обработки до тех пор, пока пункт назначения не будет полностью занят.

(Ссылка: я был одним из авторов этой функции в rsync. Дополнительные сведения и примеры использования см. В этом обсуждении реализации прототипа: https://lists.samba.org/archive/rsync/2005-March/011964. .html )