Какой самый быстрый способ отправки огромных объемов данных между двумя компьютерами? [закрыто]

111

Это ситуация, в которой я часто бываю:

  • У меня есть исходный сервер с жестким диском на 320 ГБ и 16 ГБ оперативной памяти ( точные спецификации доступны здесь , но, поскольку я часто сталкиваюсь с этой проблемой на других машинах, я бы предпочел, чтобы ответ работал на любом «разумная» машинка Linux)
  • У меня есть резервный сервер с несколькими терабайтами пространства на жестком диске ( точные спецификации здесь , см. Отказ от ответственности выше)

Я хочу передать 320 ГБ данных с исходного сервера на целевой сервер (в частности, данные с /dev/sda).

  1. Два компьютера находятся рядом друг с другом, поэтому я могу проложить кабели между ними.
  2. Я нахожусь в локальной сети, и я использую новый маршрутизатор , что означает, что скорость моей сети должна «в идеале» быть 1000 Мбит, верно?
  3. Безопасность не проблема. Я нахожусь в локальной сети, и я доверяю всем машинам в сети, включая маршрутизатор.
  4. (необязательно). Мне не обязательно нужна подписанная контрольная сумма данных, но базовая проверка ошибок (например, пропущенные пакеты или невозможность чтения диска) должна обнаруживаться, а не просто исчезать в выводе.

Я искал этот вопрос в Интернете и проверил несколько команд. Наиболее часто встречается следующее:

ssh user@192.168.1.100 'dd bs=16M if=/dev/sda | gzip' > backup_sda.gz

Эта команда оказалась слишком медленной (она выполнялась в течение часа, получая только около 80 ГБ через данные). Для тестового пакета объемом 1 ГБ потребовалось около 1 минуты и 22 секунд, и в итоге он оказался вдвое быстрее, когда не был сжат. Результаты также могут быть искажены из-за того, что переданный файл меньше, чем объем ОЗУ в исходной системе.

Кроме того (и это было проверено на 1ГБ тестовых образцах), у меня возникают проблемы, если я использую gzipкоманду и dd; Полученный файл имеет другую контрольную сумму при извлечении на целевом объекте, чем при прямой передаче. Я все еще пытаюсь понять, почему это происходит.

IQAndreas
источник
54
Не забывайте sneakernet
Гвилли
4
Вы хотите передать /dev/sdaкак изображение или просто файлы. Почему Rsync не вариант? Является ли /dev/sdaустановлен , пока вы ddэд?
Йодка Лемон
15
Ваши данные о производительности (1 ГБ / 80 с, 80 ГБ / 1 ч) полностью соответствуют ожиданиям на 100 Мбит. Проверьте ваше оборудование. ... и все правильно, 320ГБ может быть большим, но «огромное количество данных» порождает неверные ожидания.
Blafasel
8
«Никогда не стоит недооценивать пропускную способность грузового поезда, полного дисков». .. Вы спрашиваете о пропускной способности, задержке или некоторой комбинации этих двух?
Кешлам
8
Мой друг всегда говорил: «Никогда не стоит недооценивать пропускную способность кучи жестких дисков на грузовике».
AMADANON Inc.

Ответы:

139

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

BlueRaja - Дэнни Пфлугхофт
источник
15
+1: передача по физическому каналу кажется самым быстрым путем, даже если это означает получение большого внешнего жесткого диска откуда-то. Это около 40 фунтов стерлингов, и вы, вероятно, уже потратили столько времени,
deworde
3
Я полностью не согласен с этой идеей, если вы получаете полную скорость через гигабитную сеть. Тестирование по NFS / SMB с помощью гигабитного коммутатора Zyxel между микросервером HP Gen 7 и машиной Pentium G630 дает мне скорость передачи ~ 100 МБ / с. (Пока я не покину внешний край пластин привода.) Так что я думаю, что это было бы реально сделано менее чем за 3 часа. Если вы не используете SSD или чрезвычайно высокопроизводительные накопители / хранилища, я не думаю, что 2 копии могут обеспечить пропускную способность 100 МБ / с, что потребует 200 МБ / с для каждой операции копирования, чтобы обеспечить безубыточность.
Фазы
3
@Phizes: очевидно, вы не копируете во временный. Это была плохая идея Дворда, а не то, о чем все остальные говорят. Точка подключения исходного диска к целевому компьютеру состоит в том, чтобы использовать SATA-> SATA dd(или копию дерева файловой системы).
Питер Кордес
10
«Никогда не стоит недооценивать пропускную способность грузовика, заполненного жесткими дисками. Впрочем, одна адская задержка»
Кевин
3
@Kevin: да, моя точка зрения заключалась в том, что прямое копирование между дисками на одном компьютере происходит по крайней мере так же быстро, как и любой другой возможный метод. Я привел реальные цифры пропускной способности, чтобы подтвердить точку зрения Phize, что переход на gigE - это хорошо для старого диска OP, но является узким местом для новых дисков. (Один из случаев, когда оба диска на одном компьютере - не самый лучший вариант, - это когда отдельные компьютеры, использующие свою оперативную память для кэширования метаданных источника и dest, важны, например, для rsync из миллиардов файлов.)
Peter Cordes
69

netcat отлично подходит для таких ситуаций, когда безопасность не является проблемой:

# on destination machine, create listener on port 9999
nc -l 9999 > /path/to/outfile

# on source machine, send to destination:9999
nc destination_host_or_ip 9999 < /dev/sda
# or dd if=/dev/sda | nc destination_host_or_ip 9999

Обратите внимание: если вы используете ddиз GNU coreutils, вы можете отправить SIGUSR1процессу, и он отправит прогресс в stderr. Для BSD ddиспользуйте SIGINFO.

pv еще более полезен в сообщении о прогрессе во время копирования:

# on destination
nc -l 9999 | pv > /path/to/outfile

# on source
pv /dev/sda | nc destination_host_or_ip 9999
# or dd if=/dev/sda | pv | nc destination_host_or_ip 9999
zackse
источник
2
Для второго примера, это ddдаже требуется, или можно pv/ просто хорошо ncлечить /dev/sda? (Я заметил, что некоторые команды «выбрасывают» при попытке прочитать специальные файлы, подобные этому, или файлы с 0x00байтами)
IQAndreas
5
@ user1794469 Поможет ли сжатие? Я думаю, что сеть не там, где есть узкое место.
IQAndreas
17
Не забывайте, что в bashодном можно использовать перенаправление > /dev/tcp/IP- /портов и < /dev/tcp/IP- /портов вместо передачи в и из netcat соответственно.
Иннис Мрси
5
Хороший ответ. Гигабитный Ethernet часто быстрее скорости жесткого диска, поэтому сжатие бесполезно. Для передачи нескольких файлов рассмотрим tar cv sourcedir | pv | nc dest_host_or_ip 9999и cd destdir ; nc -l 9999 | pv | tar xv. Возможны многие варианты, например, вы можете захотеть сохранить .tar.gzна стороне назначения, а не копии. Если вы копируете каталог в каталог, для дополнительной безопасности вы можете впоследствии выполнить rsync, например, из dest rsync --inplace -avP user@192.168.1.100:/path/to/source/. /path/to/destination/.это будет гарантировать, что все файлы действительно являются точными копиями.
Стефан Гурихон
3
Вместо использования IPv4 вы можете добиться лучшей пропускной способности с помощью IPv6, поскольку он имеет большую полезную нагрузку. Вы даже не настраиваете это, если машины поддерживают IPv6, они, вероятно, уже имеют локальный IPv6-адрес
Дэвид Коста
33
  1. Как использовать быстрое сжатие.

    • Независимо от вашего носителя передачи данных - особенно для сети или USB - вы будете работать с пакетами данных для чтения, кэширования и записи, и они точно не будут синхронизированы.
    • Помимо встроенного программного обеспечения диска, дискового кэша и кэша ядра / оперативной памяти, если вы также можете каким-либо образом использовать ЦП системы, чтобы сконцентрировать объем данных, передаваемых за пакет, то вам следует это сделать .
    • Любой алгоритм сжатия будет автоматически обрабатывать разреженные входные данные максимально быстро, но очень немногие будут обрабатывать все остальное при пропускной способности сети.
    • lz4 Ваш лучший вариант здесь:

      LZ4 - это очень быстрый алгоритм сжатия без потерь, обеспечивающий скорость сжатия 400 МБ / с на ядро, масштабируемую с помощью многоядерного процессора. Он также имеет чрезвычайно быстрый декодер со скоростью в несколько ГБ / с на ядро, что обычно достигает предела скорости ОЗУ в многоядерных системах.

  2. Желательно не искать без необходимости.

    • Это может быть трудно измерить.
    • Если на устройстве, с которого вы копируете, много свободного места, и устройство не было недавно обнулено, но все исходные файловые системы должны быть скопированы, то, вероятно, стоит сначала сделать это. что-то вроде:

      </dev/zero tee >empty empty1 empty2; sync; rm empty*
    • Но это зависит от того, на каком уровне вы должны читать источник. Обычно желательно прочитать устройство от начала до конца из его /dev/some_diskфайла устройства, потому что чтение на уровне файловой системы обычно включает в себя поиск вперед и назад и вокруг диска не последовательно. И поэтому ваша команда чтения должна выглядеть примерно так:

      </dev/source_device lz4 | ...
    • Однако, если ваша исходная файловая система не должна передаваться целиком, тогда чтение на уровне файловой системы довольно неизбежно, и поэтому вы должны объединить входное содержимое в поток. paxкак правило, является лучшим и наиболее простым решением в этом случае, но вы также можете подумать mksquashfs.

      pax -r /source/tree[12] | lz4 | ...
      mksquashfs /source/tree[12] /dev/fd/1 -comp lz4 | ...
  3. Вы не шифровать ssh.

    • Добавлять служебные данные шифрования на доверенный носитель не нужно, и это может серьезно повлиять на скорость устойчивой передачи, поскольку считываемые данные должны быть прочитаны дважды .
    • ПГСЧ нужны чтения данных или , по крайней мере , некоторые из них, чтобы поддерживать случайности.
    • И, конечно же, вам необходимо передать данные.
    • Вам также необходимо перенести сами издержки на шифрование, что означает больше работы для меньшего количества данных, передаваемых за пакет .
    • И поэтому скорее вы должны использовать netcat( или, как я предпочитаю, nmapпроект более способныйncat ) для простой сетевой копии, как было предложено в другом месте:

      ###  on tgt machine...
      nc -l 9999 > out.lz4
      ###  then on src machine...
      ... lz4 | nc tgt.local 9999
mikeserv
источник
1
Фантастический ответ. Одна небольшая грамматическая точка - «уменьшить объем данных, которые необходимо обменивать за пакет» - я думаю, что вы используете сжатие для увеличения плотности информации, так как «пакеты» имеют фиксированную ширину и, следовательно, количество обмениваемых данных остается постоянным хотя информация, передаваемая за пакет, может отличаться.
инженер Доллери
@EngineerDollery - да, это было глупо. Я думаю, что это лучше,
Mikeserv
@ IQAndreas - я бы серьезно обдумал этот ответ. Лично я использую pigz, и прирост скорости потрясающий . Параллелизм - это огромная победа; Процессоры намного быстрее, чем любая другая часть конвейера данных, поэтому я сомневаюсь, что параллельное сжатие замедлит вас (gzip не распараллеливается). Вы можете найти это достаточно быстро, чтобы не было стимула манипулировать жесткими дисками; Я не удивлюсь, если это в целом быстрее (включая время подкачки диска). Вы можете сравнить с и без сжатия. В любом случае, либо ответ BlueWaja, либо этот ответ должен быть вашим принятым ответом.
Майк С
Быстрое сжатие - отличный совет. Следует отметить, однако, что это помогает, только если данные достаточно сжимаемы, что означает, например, что они уже не должны быть в сжатом формате.
Уолтер Тросс
@WalterTross - это поможет, если какой-либо вход является сжимаемым, независимо от отношения, пока задание сжатия превосходит задание передачи. В современной четырехъядерной системе lz4работа должна легко развиваться даже с широко открытым GIGe, и у USB 2.0 нет шансов. Кроме того, он lz4был разработан, чтобы работать только тогда, когда он должен - он отчасти так быстр, потому что он знает, когда следует пытаться выполнить сжатие, а когда - нет. И если это передаваемый файл устройства, то даже предварительно сжатый ввод может все равно сжиматься, если в исходной файловой системе есть какая-либо фрагментация.
mikeserv
25

Есть несколько ограничений, которые могут ограничивать скорость передачи.

  1. В канале с пропускной способностью 1 Гбит / с присутствуют сетевые издержки. Обычно это снижает фактическую пропускную способность до 900 Мбит / с или менее. Тогда вы должны помнить, что это двунаправленный трафик, и вы должны ожидать значительно меньше, чем 900 Мбит / с.

  2. Даже если вы используете «новый маршрутизатор», вы уверены, что маршрутизатор поддерживает 1 Гбит / с? Не все новые маршрутизаторы поддерживают 1 Гбит / с. Кроме того, если это не маршрутизатор корпоративного уровня, вы, скорее всего, потеряете дополнительную пропускную способность, так как маршрутизатор будет неэффективным. Хотя, исходя из того, что я нашел ниже, похоже, что вы получаете скорость выше 100 Мбит / с.

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

  4. Какой объем дискового ввода-вывода вы используете? Вероятно, вы ограничены не сетью, а дисководом. Большинство жестких дисков со скоростью 7200 об / мин получат только около 40 МБ / с. Вы используете рейд вообще? Вы используете SSD? Что вы используете на удаленном конце?

Я предлагаю использовать rsync, если ожидается, что это будет выполнено повторно для резервных копий. Вы также можете использовать scp, ftp (s) или http, используя загрузчик, такой как filezilla, на другом конце, поскольку он будет распараллеливать соединения ssh / http / https / ftp. Это может увеличить пропускную способность, так как другие решения находятся на одной трубе. Один канал / поток все еще ограничен тем фактом, что он является однопоточным, что означает, что он может быть даже связан с процессором.

С rsync вы избавляетесь от сложности вашего решения, а также разрешаете сжатие, сохранение разрешений и частичную передачу. Есть несколько других причин, но, как правило, это предпочтительный метод резервного копирования (или запуска систем резервного копирования) крупных предприятий. Commvault фактически использует rsync под своим программным обеспечением в качестве механизма доставки резервных копий.

Исходя из приведенного вами примера 80 ГБ / ч, вы получаете около 177 Мбит / с (22,2 МБ / с). Я чувствую, что вы можете легко удвоить это с помощью rsync на выделенной линии Ethernet между двумя блоками, поскольку мне удалось получить это в моих собственных тестах с rsync поверх гигабит.

Khrystoph
источник
12
+1 за rsync. Возможно, он не будет быстрее при первом запуске, но, безусловно, так будет и во все последующие времена.
Скррп
4
> Большинство жестких дисков со скоростью 7200 об / мин будут получать скорость около 40 МБ / с. IME, вы, скорее всего, будете видеть более 100 МБ / с последовательным с современным диском (и это включает ~ 5 КБ дисков). Хотя, это может быть старый диск.
Боб
2
@Bob: Эти современные все еще могут читать только 5400 круговых дорожек в минуту. Эти диски все еще быстрые, потому что каждая дорожка содержит более мегабайта. Это означает, что они также довольно большие диски. Маленький диск объемом 320 ГБ не может содержать слишком много килобайт на дорожку, что обязательно ограничивает их скорость.
MSalters
1
40 МБ / с определенно очень пессимистичны для последовательного чтения для любого накопителя, созданного за последнее десятилетие. По словам Боба, текущие скорости 7200 об / мин могут превышать 100 МБ / с.
Хоббс
3
Gigabit Ethernet - это полнодуплексный режим 1000 Мбит / с . Вы получаете 1000 Мбит / с (или, как вы говорите, около 900 Мбит / с в реальности) в каждом направлении . Во-вторых ... жесткие диски теперь обычно получают 100 МБ / с. 40 МБ / с - это медленно, если это не десятилетний накопитель.
Дероберт
16

Мы занимаемся этим регулярно.

Мы используем два основных метода:

  1. SATA / ESATA / Sneakernet
  2. Прямое монтирование NFS, затем локальное cpилиrsync

Первое зависит от того, можно ли физически переместить привод. Это не всегда так.

Второй работает на удивление хорошо. Как правило, мы максимально легко подключаемся к соединению в 1 Гбит / с с помощью прямых подключений NFS. Вы не приблизитесь к этому с помощью scp, dd over ssh или чего-либо подобного (вы часто получаете максимальную скорость, подозрительно близкую к 100mpbs). Даже на очень быстрых многоядерных процессорах вы столкнетесь с узким местом при максимальной пропускной способности шифрования одного из ядер на самой медленной из двух машин, что удручающе медленно по сравнению с полнопроцессорным процессором cp или rsync при незашифрованном монтировании сети. Изредка вы можете ненадолго ударить по стене iops и застревать со скоростью ~ 53 МБ / с вместо более типичных ~ 110 МБ / с, но обычно это недолгое время, если источник или пункт назначения на самом деле не являютсяодин диск, тогда вы можете быть ограничены постоянной скоростью самого диска (который достаточно варьируется по случайным причинам, о которых вы не узнаете, пока не попробуете его) - ме.

NFS может немного раздражать в настройке, если он находится в незнакомом дистрибутиве, но, вообще говоря, это был самый быстрый способ заполнить трубы максимально полно. В прошлый раз, когда я делал это со скоростью 10 Гбит / с, я так и не узнал, превысило ли это соединение, потому что передача была закончена еще до того, как я вернулся, чтобы взять немного кофе - так что, возможно, у вас есть какой-то естественный предел. Если у вас есть несколько сетевых устройств между источником и назначением, вы можете столкнуться с некоторыми небольшими задержками или сбоями из-за эффекта слияния в сети, но обычно это будет работать через офис (без другого трафика, который его портит) или от одного конца центра обработки данных до другой (если у вас нет какой-либо фильтрации / проверки, происходящей внутри, в этом случае все ставки отключены ).

РЕДАКТИРОВАТЬ

Я заметил некоторую болтовню о сжатии ... не сжимайте соединение. Это замедлит вас так же, как и криптослой. Узким местом всегда будет одно ядро, если вы сожмете соединение (и вы даже не получите особенно хорошего использования шины этого ядра). Самое медленное, что вы можете сделать в вашей ситуации, - это использовать зашифрованный сжатый канал между двумя компьютерами, расположенными рядом друг с другом при скорости соединения 1 Гбит / с или выше.

БУДУЩАЯ ЗАЩИТА

Этот совет действует с середины 2015 года. Это почти наверняка не будет иметь место в течение слишком многих лет. Так что принимайте все с большой долей соли, и если вы регулярно сталкиваетесь с этой задачей, то попробуйте различные методы на реальных нагрузках вместо того, чтобы представить, что вы получите что-то близкое к теоретическим оптимумам или даже к наблюдаемым скоростям сжатия / криптографии, типичным для таких вещей, как веб трафик, большая часть которого является текстовой (protip: массовые передачи обычно состоят в основном из изображений, аудио, видео, файлов базы данных, двоичного кода, форматов офисных файлов и т. д., которые уже сжатыпо-своему и очень мало выигрывают от выполнения еще одной процедуры сжатия, размер блока сжатия которой почти гарантированно не будет соответствовать вашим уже сжатым двоичным данным ...).

Я полагаю, что в будущем такие концепции, как SCTP, будут перенесены в более интересное место, где типичные связанные соединения (или внутренние волоконно-оптические соединения с привязкой по спектру) являются типичными, и каждый канал может принимать поток независимо от других, и каждый поток может быть сжат / зашифрован параллельно и т. д. Это было бы замечательно! Но это не так сегодня в 2015 году, и хотя фантазии и теоретизирование - это хорошо, у большинства из нас нет собственных кластеров хранения, работающих в криокамере, которые подают данные непосредственно во внутреннюю часть Blue Gene / Q, генерируя ответы для Watson. Это просто не реальность. Также у нас нет времени на тщательный анализ полезных данных, чтобы выяснить, является ли сжатие хорошей идеей или нет - сама передача была бы закончена до того, как мы закончили анализ,

Но...

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

zxq9
источник
1
@jofel Только тогда, когда скорость сети ниже, чем скорость сжатия процессора - что никогда не справедливо для соединений 1 Гбит / с или выше. Однако в типичном случае узким местом является сеть, и сжатие эффективно ускоряет процесс, но это не тот случай, который описывает OP.
zxq9
2
lz4достаточно быстрый, чтобы не мешать работе, но в зависимости от того, что вы хотите сделать с копией, вам может понадобиться распаковать ее. lzop тоже довольно быстрый. На моем i5-2500k Sandybridge (3,8 ГГц) lz4 < /dev/raid0 | pv -a > /dev/nullидет на входе ~ 180 МБ / с, на выходе ~ 105 МБ / с, как раз для GIGE. Распаковка на приемной стороне еще проще в процессоре.
Питер Кордес
1
Кроме того, 3,8 ГГц - это чуть-чуть быстрее, чем работает большинство серверных процессоров (или многие системы бизнес-класса любого типа, по крайней мере, которые я привык видеть). Чаще встречается в центрах обработки данных гораздо большее количество ядер с гораздо меньшей тактовой частотой. Распараллеливание нагрузок передачи не было проблемой для долгого времени, так что мы застряли с максимальной скоростью одного ядра в большинстве случаев - но я надеюсь , что это изменится теперь, тактовая частота , как правило , увеличившаяся но скорость сети еще есть Долгий путь, прежде чем достичь своих максимумов.
zxq9
2
Я полностью не согласен с вашими комментариями по поводу сжатия. Это полностью зависит от сжимаемости данных. Если бы вы могли получить степень сжатия 99,9%, было бы глупо этого не делать - зачем передавать 100 ГБ, если вы можете избежать 100 МБ? Я не предполагаю, что этот уровень сжатия имеет место для этого вопроса, просто показываю, что это должно рассматриваться в каждом конкретном случае и что нет никаких абсолютных правил.
Инженер Доллери
1
@EngineerDollery В реальном мире массовая передача не работает . Я делаю это почти каждый день и проверил различные методы и настройки. В общем случае большие объемные передачи неизвестных данных (все, на что у вас нет времени для запуска тестов настройки сжатия - что означает практически все в любом центре обработки данных, корпоративной инфраструктуре, сервере малого бизнеса или домашней сети), очень много быстрее через соединение 1 Гбит / с или выше. Иди попробуй. Текст обычно лучше всего подходит для сжатия. Текст содержит крошечную долю типичной массовой загрузки.
zxq9
6

Отличный инструмент, который я использовал в прошлом bbcp. Как видно здесь: https://www.slac.stanford.edu/~abh/bbcp/ .

Смотрите также http://pcbunn.cithep.caltech.edu/bbcp/using_bbcp.htm

У меня были очень высокие скорости передачи с этим инструментом.

Темное сердце
источник
1
Вторая ссылка этого ответа объясняет, как настроить параметры ядра для достижения более высоких скоростей. Автор получил 800 мегабайт в секунду в каналах 10G, и некоторые вещи, кажется, применимы к ссылкам 1Gbps.
Стефан Гурихон
5

Если вы получили первый проход каким-либо образом (через провод / sneakernet / что угодно), вы можете изучить rsyncнекоторые параметры, которые могут значительно ускорить последующие передачи. Очень хороший путь будет:

rsync -varzP sourceFiles destination

Варианты: подробный, режим архива, рекурсивный, сжатие, частичный прогресс

Прыгающий кролик
источник
2
Rsync более надежен, чем netcat, но архив подразумевает рекурсивность, поэтому r избыточна.
Танат
Кроме того, -zможет быть невероятно медленным в зависимости от вашего процессора и данных, которые вы обрабатываете. При отключении сжатия у меня возникали скорости передачи от 30 МБ / с до 125 МБ / с.
Линд
4

Добавлен по настоянию оригинального постера в комментариях к ответу Зацзе, хотя я не уверен, что он самый быстрый в типичных обстоятельствах.

bashимеет специальный синтаксис перенаправления:
Для вывода:      > /dev/tcp/IP- /порт.
Для ввода:       < /dev/tcp/IP- /порт.
IP- запрет должен быть либо десятичным, либо десятичным, либо именем хоста; Запрет порта может быть либо десятичным числом, либо именем порта из /etc/services.

Там нет актуального /dev/tcp/каталога. Это специальный синтаксический kludge, который отправляет команду bashна создание TCP-сокета, подключает его к указанному месту назначения, а затем делает то же самое, что и обычное перенаправление файлов (а именно, заменяет соответствующий стандартный поток на сокет с помощью dup2 (2)).

Следовательно, можно передавать данные с ddили tarна исходный компьютер напрямую через TCP. Или, наоборот, для потоковой передачи данных tarили чего-то подобного напрямую через TCP. В любом случае один лишний netcat исключается.

Заметки о netcat

Существует несоответствие в синтаксисе между классическим netcat и GNU netcat . Я буду использовать классический синтаксис, к которому я привык. Заменить -lpс -lГНУ Netcat.

Кроме того, я не уверен, принимает ли GNU netcat -qпереключатель.

Передача образа диска

(По линии ответа Заксе.)
По назначению:

nc -lp 9999 >disk_image

По источнику:

dd if=/dev/sda >/dev/tcp/destination/9999
 

Создание архива tar.gz, с tar

По назначению:

nc -lp 9999 >backup.tgz

По источнику:

tar cz files or directories to be transferred >/dev/tcp/destination/9999

Заменить .tgzс .tbzи czс , cjчтобы получить bzip2-сжатый архив.

Перенос с немедленным расширением в файловую систему

Также с tar.
По назначению:

cd backups
tar x </dev/tcp/destination/9999

По источнику:

tar c files or directories to be transferred |nc -q 1 -lp 9999

Это будет работать без -q 1, но netcat застрянет, когда данные закончились. См. Tar (1) для объяснения синтаксиса и предостережений tar. Если существует много файлов с высокой избыточностью (низкой энтропией), то можно попробовать сжатие (например, czа xzне cи x), но если файлы типичные и сеть достаточно быстрая, это только замедлит процесс. Посмотрите ответ mikeserv для деталей о сжатии.

Альтернативный стиль (порт назначения слушает)

По назначению:

cd backups
nc -lp 9999 |tar x

По источнику:

tar c files or directories to be transferred >/dev/tcp/destination/9999
Incnis Mrsi
источник
bash не может «прослушивать» сокет, по-видимому, для ожидания и получения файла: unix.stackexchange.com/questions/49936/… так что вам придется использовать что-то еще как минимум для половины соединения ...
rogerdpack
3

Попробуйте предложения относительно прямых соединений и избегания зашифрованных протоколов, таких как ssh. Затем, если вы все еще хотите добиться максимальной производительности, прочитайте этот сайт: https://fasterdata.es.net/host-tuning/linux/, чтобы получить советы по оптимизации окон TCP.

Брэндон Ксавье
источник
2

Я хотел бы использовать этот скрипт, который я написал, который нуждается в socatпакете.

На исходном компьютере:

tarnet -d wherefilesaretosend pass=none 12345 .

На целевой машине:

tarnet -d wherefilesaretogo pass=none sourceip/12345

Если vbufпакет (Debian, Ubuntu) присутствует, отправитель файла покажет ход данных. Приемник файлов покажет, какие файлы получены. Опция pass = может использоваться там, где данные могут быть представлены (медленнее).

Редактировать:

Используйте -nопцию, чтобы отключить сжатие, если процессор - горлышко бутылки.

Skaperen
источник
2

Если бюджет не является основной проблемой, вы можете попробовать подключить диски с 12-ядерным разъемом Intel Xeon E5. Этот разъем, как правило, настолько мощный, что на нем даже можно запустить текущее серверное программное обеспечение. С обоих серверов!

Это может показаться забавным ответом, но вы должны подумать, почему вы перемещаете данные между серверами, и если больший объем с общей памятью и хранилищем может иметь больше смысла.

Не уверен насчет текущих характеристик, но медленная передача может быть ограничена скоростью диска, а не сети?

user133111
источник
1

Если вы заботитесь только о резервных копиях, а не о байтовой копии жесткого диска, я бы порекомендовал backupPC. http://backuppc.sourceforge.net/faq/BackupPC.html Это немного затрудняет настройку, но переносится очень быстро.

Мое начальное время передачи около 500G данных было около 3 часов. Последующие резервные копии происходят примерно через 20 секунд.

Если вы не заинтересованы в резервном копировании, но пытаетесь синхронизировать данные, тогда rsync или unison будут лучше соответствовать вашим потребностям.

Байт для байт-копии жесткого диска, как правило, является ужасной идеей для целей резервного копирования (без приращений, без экономии места, диск не может быть использован, вам нужно сделать резервную копию «пустого места», и вам нужно создать резервную копию мусора (например, файл подкачки 16 ГБ или 200 ГБ дампов ядра или что-то подобное.) Используя rsync (или backuppc или другие), вы можете создавать «моментальные снимки» во времени, чтобы вы могли перейти к «тому, как ваша файловая система выглядела 30 минут назад» с помощью очень мало накладных расходов.

Тем не менее, если вы действительно хотите перенести байт за байтовую копию, ваша проблема будет заключаться в передаче, а не в получении данных с диска. При отсутствии 400 ГБ ОЗУ передача файлов 320 ГБ займет очень много времени. Использование протоколов, которые не зашифрованы, является опцией, но, несмотря ни на что, вам просто придется сидеть там и ждать несколько часов (по сети).

coteyr
источник
1
Как 400G оперативной памяти ускоряет передачу данных?
Skaperen
Не уверен, что это было намерением, но я читал это как «любая среда, более медленная, чем передача из ОЗУ в ОЗУ, займет некоторое время», а не «купите 400 ГБ ОЗУ, и ваша передача с жесткого диска на жесткий диск пройдет быстрее».
MichaelS
Да, баран будет буфер для вас, и это будет казаться быстрее. Вы можете выполнить передачу HD на HD с буферизацией ОЗУ полностью, и это будет казаться очень быстрым. Также потребуется немало усилий, чтобы выполнить сброс на диск, но HD с RAM на RAM на HD быстрее, чем HD на HD. (Имейте в виду, что вы все равно должны делать HD-RAM-RAM-HD-HD, но если у вас меньше, чем весь объем передаваемой оперативной памяти, вам придется «сбрасывать» сегменты.)
coteyr
Другой способ - это сжать или даже просто отправить весь исходный диск в оперативную память. Если он не подходит всем сразу, он должен прочитать сегмент, отправить, отбросить сегмент, искать, прочитать сегмент и т. Д. Если он подходит всем сразу, он просто должен прочитать все за один раз. То же самое в пункте назначения.
Coteyr
1
HD к RAM к RAM к HD быстрее, чем HD к HD Как это может быть быстрее?
AL
1

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

Кроме того, если вы собираетесь использовать промежуточный диск, учтите следующее: получите внешний диск (либо в виде пакета, либо отдельный диск, подключенный к док-станции), который использует eSATA, а не USB. Затем на каждом из двух компьютеров либо установите карту с портом eSATA, либо подключите простой переходной кабель, который подключает один из внутренних портов SATA к внешнему разъему eSATA. Затем подключите диск к исходному компьютеру, включите диск и дождитесь его автоматического монтирования (вы можете монтировать его вручную, но если вы делаете это несколько раз, вы можете также поместить его в файл fstab). Затем скопируйте; вы будете писать с той же скоростью, что и на внутренний диск. Затем отключите диск, выключите его, подключите к другому компьютеру, включите питание, дождитесь автоматического подключения и прочитайте.

Майк Кьяральди
источник
2
Можете ли вы указать особенности того, как вы «вытягиваете» файлы? Какие утилиты вы используете, и можете ли вы предоставить какой-либо образец, показывающий этот эффект?
STW
Я не уверен, что это будет более полный ответ, но рассмотрим следующий сценарий: предположим, у вас есть два компьютера, foo и bar, и вы хотите скопировать данные из foo в bar. (1) Вы входите в foo, затем монтируете диск, который физически подключен к шине. Затем вы копируете с диска foo в удаленно смонтированный каталог (который физически находится на панели). Я назвал это перенаправлением данных на другой компьютер. (2) Сравните это с другим способом копирования тех же данных. Войдите в bar, смонтируйте удаленно каталог, прикрепленный к foo, и прочитайте foo на диск bar. Это тянет.
Майк Сиаральди
Это копирование можно выполнить с помощью команды Linux cp, из файлового менеджера с графическим интерфейсом пользователя или любым другим способом копирования файлов. Я думаю, что вытягивание оказывается быстрее, потому что запись медленнее, чем чтение, и больше решений о том, как записать на целевой диск, принимаются на том же компьютере, к которому подключен диск, так что меньше накладных расходов. Но, возможно, это больше не относится к более современным системам.
Майк Кьяральди,
1

Я собираюсь рекомендовать вам взглянуть на NIC-teaming. Это предполагает использование нескольких сетевых подключений, работающих параллельно. Предполагая, что вам действительно требуется передача более 1 ГБ, и что 10 ГБ являются чрезмерно дорогостоящими, 2 ГБ, предоставляемые объединением сетевых карт, будут незначительными, и ваши компьютеры уже могут иметь дополнительные порты.

Байрон Джонс
источник
Если вы имеете в виду LACP (протокол управления агрегацией каналов), то вы не увидите увеличения скорости. Это обеспечило избыточность и некоторую возможность обслуживать более параллельные соединения, но не обеспечит повышение скорости для этого типа передачи.
STW
@STW: Требуется поддержка коммутатора для объединения двух ссылок на одну машину в 2-гигабитную ссылку, но это возможно. Полезно, только если обе машины имеют 2-хбитную ссылку на коммутатор. Если у вас два кабеля с сетевым адаптером <-> NIC, без коммутатора, это тоже должно работать, но это не очень полезно (если только у вас нет 3-го сетевого адаптера на одной машине, чтобы держать их подключенными к Интернету).
Питер Кордес
есть ли конкретное имя для этой функции в коммутаторах?
STW
Существует несколько разновидностей NIC-teaming, EtherChannel и т. Д. STW подходит для определенных конфигураций, это не поможет, но для некоторых конфигураций это будет полезно. Это сводится к тому, ускоряет ли связанный канал производительность для одного IP-сокета или нет. Вам нужно будет изучить особенности, чтобы определить, является ли это жизнеспособным решением для вас.
Байрон Джонс
802.3ad - это открытый стандарт, который вы ищете на своих коммутаторах. Однако для быстрого взлома вы можете просто подключить дополнительные сетевые карты к сети и назначить им соответствующие IP-адреса в отдельных подсетях в частном адресном пространстве. (порт хоста 1 и порт хоста 2 получают одну подсеть, порт хоста 1 и порт хоста 2 получают другую подсеть). Затем просто запустите два параллельных задания, чтобы выполнить перенос. Это будет намного проще, чем изучение входов и выходов Etherchannel, 802.3ad и т. Д.
Дэн Притц
1

FWIW, я всегда использовал это:

tar -cpf - <source path> | ssh user@destserver "cd /; tar xf -"

Суть этого метода заключается в том, что он будет поддерживать права доступа к файлам / папкам между компьютерами (при условии, что на обоих компьютерах существуют одни и те же пользователи / группы) (также я обычно делаю это для копирования образов виртуальных дисков, поскольку могу использовать параметр -S для обработки разреженных файлов. )

Только что проверил это между двумя занятыми серверами и управлял ~ 14 ГБ за 216 с (около 64 МБ / с) - может быть лучше для выделенных машин и / или сжатия ... YMMV

$ date; tar -cpf - Installers | ssh elvis "cd /home/elvis/tst; tar xf -"; date
Wed Sep  9 15:23:37 EDT 2015
Wed Sep  9 15:27:13 EDT 2015

$ du -s Installers
14211072   Installers
ttstooge
источник
1

Если вы не хотите выполнять экспертизу файловой системы, используйте программу dump / restore для вашей файловой системы, чтобы избежать копирования свободного места, которое не использует FS. В зависимости от того, какая у вас файловая система, обычно сохраняются все метаданные, в том числе ctime. номера инодов могут измениться, опять же, в зависимости от того, какая файловая система (xfs, ext4, ufs ...).

Целью восстановления может быть файл в целевой системе.

Если вам нужен полный образ диска с таблицей разделов, вы можете ddсначала 1M диска получить таблицу разделов / загрузчики / вещи, но затем xfsdumpразделы.

Я не могу сказать из твоего информационного дампа, какая у тебя файловая система. Если это BSD UFS, то я думаю, что есть программа дампа / восстановления. Если это ZFS, ну IDK, может быть что-то.

Обычно полное копирование дисков слишком медленное для чего-либо, кроме ситуаций восстановления. Вы также не можете делать инкрементные резервные копии таким образом.

Питер Кордес
источник
1

Вы также можете настроить системы для общего хранилища!

Я считаю, что они рядом друг с другом, и вы, вероятно, будете делать это снова и снова ....

user133526
источник
1

Как насчет кабеля кроссовера Ethernet? Вместо того, чтобы полагаться на беспроводные скорости, вы ограничены скоростью проводной сети вашего сетевого адаптера.

Вот похожий вопрос с некоторыми примерами такого решения.

Видимо, в настоящее время достаточно обычного Ethernet-кабеля. Очевидно, что чем лучше ваша сетевая карта, тем быстрее передача.

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

Удачи!

Редактировать:

@Khrystoph затронул это в своем ответе


источник
Как это улучшит скорость? Не могли бы вы объяснить это своим ответом?
AL
1
Это потенциально повысит скорость, потому что вам не придется беспокоиться о замедлении работы промежуточной сети. Что касается «типичных» и «кроссоверных» Ethernet-кабелей - 1-гигабитная сеть Ethernet будет автоматически пересекаться при необходимости. Ethernet-коммутаторы HP будут делать это на скорости 100 Мб. Других брендов, как правило, нет, и вам понадобится кроссовер, если вы застряли на 100 МБ.
Дэн Притц
1

Некоторые люди рекомендуют пропустить ssh, потому что шифрование замедлит вас. Современные процессоры могут на самом деле быть достаточно быстрыми в 1 Гб, но у OpenSSH есть проблемы с его внутренней реализацией окон, которая может существенно замедлить вас.

Если вы хотите сделать это с помощью ssh, взгляните на HPN SSH . Это решает проблемы окон и добавляет многопоточное шифрование. К сожалению, вам нужно пересобрать ssh как на клиенте, так и на сервере.

Дэн Приттс
источник
0

Хорошо, я попытался ответить на этот вопрос для двух компьютеров с «очень большими трубами» (10Gbe), которые «близки» друг к другу.

Проблема, с которой вы здесь сталкиваетесь: большая часть сжатия будет узким местом в процессоре, поскольку каналы очень большие.

производительность для передачи файла 10 ГБ (сетевое соединение 6 ГБ [linode], несжимаемые данные):

$  time bbcp 10G root@$dest_ip:/dev/null
0m16.5s 

iperf:

server: $ iperf3 -s -F /dev/null
client:
$ time iperf3 -c $dest_ip -F 10G -t 20 # -t needs to be greater than time to transfer complete file
0m13.44s
(30% cpu)

netcat (1.187 openbsd):

server: $ nc -l 1234 > /dev/null
client: $ time nc $dest_ip 1234 -q 0 < 10G 
0m13.311s
(58% cpu)

scp:

$ time /usr/local/bin/scp 10G root@$dest_ip:/dev/null
1m31.616s
scp with hpn ssh patch (scp -- hpn patch on client only, so not a good test possibly): 
1m32.707s

socat:

server:
$ socat -u TCP-LISTEN:9876,reuseaddr OPEN:/dev/null,creat,trunc
client:
$ time socat -u FILE:10G TCP:$dest_ip:9876
0m15.989s

И две коробки по 10 Gbe, немного более старые версии netcat (CentOs 6.7), файл 10GB:

nc: 0m18.706s (100% cpu, v1.84, no -q option
iperf3: 0m10.013s (100% cpu, but can go up to at least 20Gbe with 100% cpu so not sure it matters)
socat: 0m10.293s (88% cpu, possibly maxed out)

Так что в одном случае netcat использовал меньше процессоров, а в другом socat, так что YMMV.

С netcat, если у него нет опции «-N -q 0», он может передавать усеченные файлы, будьте осторожны ... другие опции, такие как «-w 10», также могут привести к усеченным файлам.

Практически во всех этих случаях происходит максимальная загрузка процессора, а не сети. scpМаксимальная скорость около 230 МБ / с, привязка одного ядра при 100% загрузке.

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

Различные заклинания "gzip as pipe to netcat" или "mbuffer" также, похоже, максимально загружали процессор с помощью gzip или mbuffer, поэтому не приводили к более быстрой передаче с такими большими каналами. lz4 может помочь. Кроме того, некоторые из попыток gzip pipe, которые я пытался сделать, привели к поврежденным передачам для очень больших (> 4 ГБ) файлов, поэтому будьте осторожны там :)

Еще одна вещь, которая может работать особенно для более высокой задержки (?), Это настроить параметры tcp. Вот руководство, в котором упоминаются рекомендуемые значения:

http://pcbunn.cithep.caltech.edu/bbcp/using_bbcp.htm и https://fasterdata.es.net/host-tuning/linux/ (из другого ответа) возможно настройки IRQ: https://fasterdata.es .net / хост-тюнинг / 100г настройка /

предложения от linode, добавьте в /etc/sysctl.conf:

net.core.rmem_max = 268435456 
net.core.wmem_max = 268435456 
net.ipv4.tcp_rmem = 4096 87380 134217728
net.ipv4.tcp_wmem = 4096 65536 134217728
net.core.netdev_max_backlog = 250000
net.ipv4.tcp_no_metrics_save = 1
net.core.default_qdisc = fq 

Кроме того, они хотели бы, чтобы вы запустили:

 /sbin/ifconfig eth0 txqueuelen 10000 

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

Также может стоить настроить размер окна: https://iperf.fr/iperf-doc.php#tuningtcp

С медленными (er) соединениями сжатие может определенно помочь. Если у вас большие каналы, очень быстрое сжатие может помочь с легко сжимаемыми данными, не пробуйте.

Стандартный ответ для «синхронизации жестких дисков» - rsync файлы, что позволяет избежать передачи, где это возможно.

Другой вариант: использовать «параллельный scp» (так или иначе), тогда он будет использовать больше ядер ...

rogerdpack
источник