Как использовать rsync вместо scp в моем нижеприведенном сценарии оболочки для копирования файлов?

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

Я не уверен, как я могу использовать rsync вместо scp в моем нижеприведенном сценарии оболочки. Я пытаюсь увидеть, будет ли rsync иметь лучшую производительность по сравнению с scp или нет с точки зрения скорости передачи.

Ниже описание моей проблемы -

Я копирую файлы из machineB и machineC в machineA, поскольку я запускаю свой сценарий оболочки ниже на machineA.

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

Я копирую файлы параллельно, используя библиотеку GNU Parallel, и она работает нормально. В настоящее время я параллельно копирую пять файлов как для ОСНОВНОГО, так и для ВТОРИЧНОГО.

Ниже приведен мой сценарий оболочки, который у меня есть -

#!/bin/bash

export PRIMARY=/test01/primary
export SECONDARY=/test02/secondary
readonly FILERS_LOCATION=(machineB machineC)
export FILERS_LOCATION_1=${FILERS_LOCATION[0]}
export FILERS_LOCATION_2=${FILERS_LOCATION[1]}
PRIMARY_PARTITION=(550 274 2 546 278) # this will have more file numbers
SECONDARY_PARTITION=(1643 1103 1372 1096 1369 1568) # this will have more file numbers

export dir3=/testing/snapshot/20140103

do_Copy() {
  el=$1
  PRIMSEC=$2
  scp david@$FILERS_LOCATION_1:$dir3/new_weekly_2014_"$el"_200003_5.data $PRIMSEC/. || scp david@$FILERS_LOCATION_2:$dir3/new_weekly_2014_"$el"_200003_5.data $PRIMSEC/.
}
export -f do_Copy

parallel --retries 10 -j 5 do_Copy {} $PRIMARY ::: "${PRIMARY_PARTITION[@]}" &
parallel --retries 10 -j 5 do_Copy {} $SECONDARY ::: "${SECONDARY_PARTITION[@]}" &
wait

echo "All files copied."

Есть ли способ заменить мою команду scp выше на rsync, но я все еще хочу копировать 5 файлов параллельно как для PRIMARY, так и для SECONDARY одновременно?


bash linux rsync scp gnu-parallel
person john    schedule 22.05.2014    source источник
comment
Это глупое требование. Ваша задача связана с вводом-выводом, а не с процессором; вы только вызываете перегрузку, добавляя параллелизм.   -  person tripleee    schedule 24.05.2014
comment
@tripleee Возможно, вы правы, но все же я хотел попробовать посмотреть - есть ли разница между scp и rsync при передаче файлов?   -  person john    schedule 24.05.2014
comment
Если какие-то файлы уже существуют в месте назначения, rsync, вероятно, будет более эффективным. В противном случае это просто добавляет накладные расходы.   -  person tripleee    schedule 24.05.2014
comment
Также весьма вероятно, что сеть может быть вашим узким местом. Это может по-прежнему ограничивать преимущества параллелизма, хотя я ожидаю, что вы увидите преимущества для небольшого числа параллельных процессов (возможно, около 3) или значительно выше, если ваш предел связан с задержкой и размером окна (например, если вы копируете между серверами в удаленных местах).   -  person mc0e    schedule 28.05.2014

Ответы (4)


arrow_upward
6
arrow_downward

rsync предназначен для эффективной синхронизации двух иерархий папок и файлов.

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

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

Вкратце: просто запустите один экземпляр rsync; любой прирост производительности, который вы получите от другого подхода, вряд ли будет стоить того.

person Zero Piraeus    schedule 24.05.2014
comment
Если ваше соединение разорвется, то rsync --partial продолжит работу с того места, где вы остановились, а scp начнет сначала. Вкратце: вы ничего не выиграете от использования scp вместо rsync, но rsync может избавить вас от большого количества передач. Несколько экземпляров могут повысить или не повысить производительность: это зависит от задержки в сети, потери пакетов, полосы пропускания, скорости дисков, скорости ЦП, размера файлов и количества файлов. С таким количеством переменных правильный ответ: Измерьте и выберите самое быстрое. - person Ole Tange; 19.06.2014

arrow_upward
2
arrow_downward

На самом деле вы не дали нам достаточно информации, чтобы понять, находитесь ли вы на разумном пути или нет, но я подозреваю, что вам следует взглянуть на lsyncd или, возможно, даже GlusterFS. Они отличаются от того, что вы делаете, тем, что они являются инструментами непрерывной синхронизации, а не периодически запускаемыми, хотя я подозреваю, что вы могли бы периодически запускать lsyncd, если это то, что вы действительно хотите. Я еще не пробовал lsyncd 2.x, но вижу, что они добавили параллельные процессы синхронизации. Если ваш реальный сценарий включает в себя больше, чем просто три машины, которые вы описали, возможно, имеет смысл взглянуть на некоторые протоколы обмена файлами в одноранговой сети.

В вашем текущем подходе, если ваши файлы не очень большие, большая часть задержки, вероятно, будет связана с накладными расходами на настройку соединений и их аутентификацию. Делать это отдельно для каждого отдельного файла дорого, особенно по протоколу на основе ssh. Вам лучше разбить список файлов на пакеты и передать эти пакеты вашему механизму копирования. Используете ли вы для этого rsync, скорее всего, имеет меньшее значение, но если вы сначала создадите список файлов для обработки процессом rsync, то вы можете передать его rsync с параметром --files-from.

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

Вероятно, также важно знать кое-что о характере изменений в файлах от одного запуска синхронизации к другому. Много ли осталось неизмененных файлов с предыдущего прогона? Изменяются ли существующие файлы? Оставляют ли эти изменения значительное количество блоков неизменными (например, файлы базы данных) или только добавляют (например, файлы журналов)? Можете ли вы безопасно рассчитывать метаданные, такие как время и размер изменения файла, чтобы определить, что изменилось, или вам нужно вычислить контрольную сумму всего содержимого?

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

person mc0e    schedule 28.05.2014

arrow_upward
0
arrow_downward

Вы можете загружать отдельные файлы с помощью rsync так же, как с помощью scp. Просто убедитесь, что вы не используете форматы rsync:// или hostname::path, которые вызывают демон.

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

person otus    schedule 31.05.2014

arrow_upward
0
arrow_downward

думаю можно просто заменить

scp david@$FILERS_LOCATION_1:$dir3/new_weekly_2014_"$el"_200003_5.data $PRIMSEC/. || scp david@$FILERS_LOCATION_2:$dir3/new_weekly_2014_"$el"_200003_5.data $PRIMSEC/.

by

rsync david@$FILERS_LOCATION_1:$dir3/new_weekly_2014_"$el"_200003_5.data $PRIMSEC/new_weekly_2014_"$el"_200003_5.data || rsync david@$FILERS_LOCATION_2:$dir3/new_weekly_2014_"$el"_200003_5.data $PRIMSEC/new_weekly_2014_"$el"_200003_5.data

(обратите внимание, что меняются не только команды)

Возможно, вы сможете получить дополнительную скорость, потому что rsync будет использовать алгоритм delta=transfer по сравнению с scp, который копирует вслепую.

person peschü    schedule 31.05.2014