Каковы лучшие методы для улучшения зеркалирования rsync по ssh между модулями unix, предполагая, что одна система всегда будет иметь главную копию, а другая система всегда будет иметь последнюю копию (менее 48 часов назад)
Кроме того, что нужно сделать, чтобы масштабировать этот подход, чтобы обрабатывать десятки машин, получивших эти изменения?
Если :
Ты можешь использовать find -ctime или file -cnewer для составления списка измененных файлов с момента последнего выполнения и копирования только измененных файлов (просто прославленный дифференциальный толчок).
Это очень хорошо транслировалось для нескольких хостов: просто создайте дифференциальный tar на источнике и распакуйте его на всех хостах.
Это дает вам что-то вроде этого:
find -type f -cnewer /tmp/files_to_send.tar.gz > /tmp/files_to_send.txt
tar zcf /tmp/files_to_send.tar.gz --files-from /tmp/files_to_send.txt
for HOST in host1 host2 host3 ...
do
cat /tmp/files_to_send.tar.gz | ssh $HOST "tar xpf -"
done
Сценарий нужно доработать, но идею вы поняли.
Предполагая, что данные, которые вы синхронизируете, еще не сжаты, включение сжатия (-z), вероятно, повысит скорость передачи за счет некоторого количества ЦП на обоих концах.
Другая стратегия - сделать ssh и rsync быстрее. Если вы используете надежную сеть (читай: частную), шифрование фактической полезной нагрузки не требуется. Ты можешь использовать HPN ssh. Эта версия ssh шифрует только аутентификацию. Кроме того, rsync версии 3 начинает передачу файлов при построении списка файлов. Это, конечно, огромная экономия времени по сравнению с rsync версии 2. Не знаю, искали ли вы это, но надеюсь, что это поможет. Кроме того, rsync каким-то образом поддерживает многоадресную рассылку, хотя я не буду делать вид, что понимаю, как это сделать.
Если вы переносите очень большие файлы с большим количеством изменений, используйте параметры --inplace и --whole-file, я использую их для своих образов виртуальных машин 2 ГБ, и это очень помогло (в основном, потому что протокол rsync мало что делал. с передачей инкрементных данных с этими файлами). Я не рекомендую эти варианты в большинстве случаев.
используйте --stats, чтобы увидеть, насколько хорошо ваши файлы передаются с использованием инкрементного протокола rsync.
Когда вы используете rsyncing в качестве метода резервного копирования, самая большая проблема, с которой вы столкнетесь, будет, если у вас есть много файлов, которые вы копируете. Rsync может обрабатывать большие файлы без проблем, но если количество файлов, для которых вы создаете резервную копию, станет слишком большим, вы заметите, что rsync не будет завершен за разумное время. Если это произойдет, вам нужно будет разбить резервную копию на более мелкие части, а затем перебрать эти части, например
find /home -mindepth 1 -maxdepth 1 -print0 | xargs -0 -n 1 -I {} -- rsync -a -e ssh {} backup@mybackupserver:/backup/
или архивировать набор файлов, чтобы уменьшить количество файлов.
Что касается того, чтобы десятки машин получали зеркало этих изменений, это зависит от того, насколько свежей должна быть резервная копия. Один из подходов - отразить изменения с основного сервера на резервный сервер, а затем заставить другие серверы снимать свои изменения с резервного сервера либо с помощью демона rsync на начальном резервном сервере, а затем либо планировать другие серверы, чтобы в разное время или с помощью сценария, использующего беспарольный ssh для подключения к каждому из серверов и сообщая им, чтобы они вытащили новую копию резервной копии, которая поможет предотвратить перегрузку вашего исходного сервера резервного копирования - но будет ли у вас такая большая проблема, будет зависеть на скольких других машинах у вас есть копия резервной копии.
rsync умеет делать отключен копии. Другими словами, rsync может (концептуально) разница дерево каталогов и создать патч файл, который вы потом можете подать заявление на любом количестве файлов, идентичных исходному источнику.
Это требует, чтобы вы вызывали rsync с мастером и зеркало с помощью --write-batch; он производит файл. Затем вы передаете этот файл любому количеству других целей, а затем применить пакет для каждой из этих целей, используя --read-batch.
Если вы храните локальную копию последнего rsynced состояния (т. Е. Копию того, как выглядят зеркала прямо сейчас) на том же компьютере, что и мастер, вы можете сгенерировать этот «патч» на мастере, даже не связываясь с каким-либо зеркалом:
О мастере:
rsync --write-batch=my-batch.rsync /master/data /current/mirror
Добавьте любые другие варианты, которые хотите. Это сделает две вещи:
/current/mirror изменить, чтобы отразить /master/datamy-batch.rsync для дальнейшего использования.Перенести my-batch.rsync файл с мастера на все зеркала, а затем на зеркала, применить патч так сказать:
rsync --read-batch=my-batch.rsync /local/mirror
Преимущества такого подхода:
--read-batch только cpu / io интенсивно на самом зеркале)