☰

Фон

tag-icon • tag-icon linux backup nas rsync
Фон

Фон

У меня есть один сервер, на котором размещены виртуальные машины, и один старый NAS Synology DS1512+, используемый в качестве цели резервного копирования для этих виртуальных машин. Сервер использует ZFS, создает моментальные снимки и передает файлы моментальных снимков на NAS. NAS использует BTRFS с включенным сжатием и также поддерживает моментальные снимки. Конечной целью было бы, чтобы сервер действительно отправлял только DELTA с помощью RSYNC, чтобы минимизировать объем измененных данных, полученных NAS, и эффективно использовать моментальные снимки на нем.

Проблема

Однако использование RSYNC с DELTA в моем случае не работает, поскольку передача данных занимает всего лишьслишком много времени. При использовании RSYNC с --inplace --whole-file, передача данных занимает ~2 часа. При удалении --whole-fileдля использования DELTA тот же процесс резервного копирования занимает гораздо больше времени, я часто убивал процесс после того, как он уже работал 12+ часов. По историческим причинам мне нужно вписывать разные резервные копии в гораздо меньшие временные окна.

Единственное узкое место, которое имеет смысл, — это NAS, потому что сервер гораздо мощнее и большую часть времени простаивает. NAS OTOH имеет довольно высокую нагрузку на ЦП и ввод-вывод во время резервного копирования. Хотя цифры тоже не так уж плохи, просто они хуже, чем при использовании --whole-file. При этом NAS просто записывает ~100+ МБ/с, в то время как с DELTA он читает медленнее большую часть времени, охватывая от ~50 до 100 МБ/с. Я думал, что объем данных, которые НЕ нужно записывать из-за DELTA, легко превзойдет тот факт, что NAS медленнее, но, похоже, это не так. И измененный объем данных на виртуальных машинах в основном не слишком велик.

Наблюдение

Что я узнал на NAS, так это то, что RSYNC, похоже, обрабатывает два файла одновременно в какой-то момент. Это похоже на опережающее чтение или что-то в этом роде:

root@amds1512-01:~# lsof | grep [d]asi_
rsync   6883   root  cwd    DIR   0,33        290   259 /volume1/[...]
rsync   6883   root    0r   REG   0,33 2142633984   580 /volume1/[...]/[...]-s024.vmdk
rsync   6884   root  cwd    DIR   0,33        290   259 /volume1/[...]
rsync   6884   root    1r   REG   0,33 2143748096   579 /volume1/[...]/[...]-s023.vmdk
rsync   6884   root    3w   REG   0,33 2143748096   579 /volume1/[...]/[...]-s023.vmdk

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

Скриншот HTOP

Вопросы

Так в чем же смысл этих двух запущенных RSYNC с разными файлами на резервной копии? Есть ли способ заставить RSYNC обрабатывать только один файл за другим?

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

--owner \
--numeric-ids \
--compress-level=0 \
--group \
--perms \
--rsh=rsh \
--devices \
--hard-links \
--inplace \
--links \
--recursive \
--times \
--delete \
--delete-during \
--delete-excluded \
--rsync-path=[...] \
--specials

Спасибо!

решение1

Взгляни наКак работает Rsync. В частности, есть процесс-генератор и процесс-отправитель, которые работают как конвейер. Отправитель считывает файл для отправки на удаленный компьютер. Генератор отвечает за генерацию списка файлов для отправки, а также «контрольные суммы блоков создаются для базового файла и отправляются отправителю сразу после индексного номера файла».

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

В качестве теста вы можете попробовать передать отдельные файлы с помощью rsync --inpaceи посмотреть, значительно ли улучшится производительность. (Что-то вроде for i in *.vmdk; do rsync [...]; done.) Это должно помочь определить, действительно ли наличие двух отдельных считывателей является причиной вашей проблемы с производительностью.

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

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

Связанный контент