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

20

Я пытаюсь скопировать 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 МБ. (Развести руки)

Натан Милфорд
источник
Просто комментарий, я недавно получил релиз от поставщика программного обеспечения на Seagate FreeAgent (USB-диск), который был около 50 Гбайт. Компания, о которой идет речь, действительно присутствовала в Интернете и обычно просила клиентов просто загрузить их со своего сайта. Думал, что это было интересное решение и думал, что это может добавить некоторую информацию, чтобы помочь в вашем решении.
MDPC
Какую задержку вы видите?
откат
Около 80 мс по ссылке.
Натан Милфорд
Да, теперь я просто растерялся и разочарован. Я разделил его на куски по 50 Мб, и он все еще идет медленно! Но при пересылке других данных получается 500kb / s ... должно быть, что-то ужасно не так, как я скучаю ...
Натан Милфорд
Проверьте ваш трафик с tcpdump. Это может помочь вам выяснить, что замедляет передачу.
lexsys

Ответы:

16

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

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

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


Rsync

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

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

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


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

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

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

Удачи!


ОБНОВИТЬ:

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

KPWINC
источник
3
+1, хотя, вероятно, не выгодно в этом случае. Никогда не стоит недооценивать пропускную способность 747, заполненных жесткими дисками :)
Чад Хьюникутт
2
Я не смог найти ссылку, но пару лет назад Google рассматривал доставку ящиков с дисками. Если вы можете переместить ящик с дисками общим объемом 500 ТБ из точки А в точку Б, любой способ сократить его - это очень хорошая пропускная способность
STW
2
Может быть , вы имеете в виду эту статью: arstechnica.com/science/news/2007/03/...
KPWINC
1
Да, в итоге я отправил жесткий диск. Реальная проблема, или, как мне сказали, было управление потоком на коммутаторе (ах).
Натан Милфорд
Bittorrent работает лучше, чем прямая передача, если у вас несколько сеялок. Даже если OP устанавливает bt на нескольких машинах, у него только одно соединение. И он уже определил, что несколько маленьких файлов не идут быстрее, чем один большой, который указывает пальцем на сетевое соединение.
Ксалори
7

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

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

split --bytes=2000000000 your_file.tgz

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

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

cat your_file* > your_remote_file.tgz

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

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

edomaur
источник
5

Обычно я большой сторонник 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 в ...

Insyte
источник
+1 за rsyncd. Я на самом деле использую его для передачи по локальной сети, потому что вижу более высокую пропускную способность по сравнению с CIFS или NFS.
Офидиан
1
Хотя FTP и HTTP избегают «штрафа по ssh-туннелю», необходимо учитывать «штраф» за отсутствие шифрования данных.
J.Money
3

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

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

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

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

tar czf * | netcat target_box 2342

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

Дэвид
источник
1

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

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

cmcginty
источник
1
я сделал "python -m SimpleHTTPServer" из командной строки в исходном коде и wget'd файл в месте назначения. Я все еще получаю «18.5K / s eta 15d 3h»
Натан Милфорд
1

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

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

DisabledLeopard
источник
bt идет быстрее, чем прямой перевод, если есть несколько семян. У него единственный источник. Что еще более важно, он имеет единственную исходную сеть с плохим сетевым соединением. Даже копирование файла в несколько мест локально, а затем установка bt с несколькими начальными значениями приводит к обратным результатам из-за плохого соединения. Кроме того, создание нескольких копий и установка их в качестве начальных значений увеличивает время копирования, а не сокращает его. BT может быть приемлемым решением, если OP пытается сделать большой файл доступным для нескольких получателей.
Ксалори
0

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

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

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

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

Уильям Хилсум
источник
0

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

Якорь,
источник
Это снимок LVM другой реплики MYSQL (нашего основного экземпляра MYSQL в другом месте). После передачи и размещения целевой экземпляр mysql может просто обновить разницу между этим снимком (используйте его как дельту) и тем, где сейчас находится мастер. То, что это резервная копия MYSQL, не имеет значения, это просто большой кусок данных, который мне нужно переместить только один раз.
Натан Милфорд
0

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

Заур
источник
0

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

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

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

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

stevegt
источник