Я пытаюсь скопировать 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 Anyone?
Предполагая, что это одноразовая копия, я не думаю, что можно просто скопировать файл на компакт-диск (или другой носитель) и в одночасье отправить его по назначению?
На самом деле это может быть вашим самым быстрым вариантом, поскольку передача файла такого размера через это соединение может не копироваться правильно ... и в этом случае вы можете начать все сначала.
rsync
Моим вторым выбором / попыткой будет rsync, поскольку он обнаруживает неудачные передачи, частичные передачи и т. Д. И может продолжить с того места, где остановился.
rsync --progress file1 file2 user@remotemachine:/destination/directory
Флаг --progress даст вам некоторую обратную связь, вместо того, чтобы просто сидеть и оставлять вас на размышления. :-)
Vuze (битторент)
Третий вариант, вероятно, заключался бы в том, чтобы попробовать использовать Vuze в качестве торрент-сервера, а затем использовать в удаленном месте стандартный клиент bitorrent для его загрузки. Я знаю других, кто делал это, но вы знаете ... к тому времени, когда они все это настроили, и т.д ... Я мог бы пересмотреть данные ...
Думаю, это зависит от вашей ситуации.
Удачи!
ОБНОВИТЬ:
Знаешь, я еще немного подумал о твоей проблеме. Почему файл должен быть одним огромным архивом? Tar прекрасно способен разбивать большие файлы на более мелкие (например, для охвата носителей), так почему бы не разделить этот огромный архив на более управляемые части, а затем вместо этого перенести их?
Я делал это раньше с файлом tbz2 объемом 60 ГБ. У меня больше нет сценария, но его будет легко переписать.
Сначала разделите файл на части размером ~ 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. На странице руководства этот режим описывается достаточно подробно.
Моя рекомендация? FTP или HTTP с серверами и клиентами, поддерживающими возобновление прерванных загрузок. Оба протокола быстрые и легкие, что позволяет избежать штрафов за ssh-туннель. Apache + wget будет кричать быстро.
Трюк с netcat pipe тоже подойдет. Tar не нужен при передаче одного большого файла. И причина, по которой он не уведомляет вас, когда это сделано, заключается в том, что вы этого не сказали. Добавить -q0 flag на стороне сервера, и он будет вести себя именно так, как вы ожидаете.
server$ nc -l -p 5000 > outfile.tgz client$ nc -q0 server.example.com 5000 < infile.tgz
Обратной стороной подхода netcat является то, что он не позволит вам возобновить работу, если ваша передача умирает 74 ГБ в ...
Попробуйте 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 будет фрагментировать файл и копировать его с помощью нескольких потоков.
Поздний ответ для гуглеров:
При передаче больших наборов данных rsync можно использовать для сравнения источника и назначения, а затем записать пакетный файл на локальный съемный носитель с помощью флага --only-write-batch. Затем вы отправляете локальный носитель в удаленное место, подключаете его и снова запускаете rsync, используя --read-batch, чтобы включить изменения в удаленный набор данных.
Если исходные файлы меняются во время физической транспортировки или если транспортный носитель заполняется, вы можете просто повторять --only-write-batch | корабль | - читать-пакетный цикл до тех пор, пока место назначения не будет достигнуто.
(Ссылка: я был одним из авторов этой функции в rsync - дополнительные сведения и примеры использования см. В этом обсуждении реализации прототипа: https://lists.samba.org/archive/rsync/2005-March/011964.html)