Контекст: Мы работаем над проектом миграции данных, включающим синхронизацию данных между локальной файловой системой NFS и файловым ресурсом Azure на основе NFS. Цель — обеспечить плавный переход из локальной среды в Azure, сохраняя при этом целостность и эффективность данных.
Фон:
Источник: Локальная файловая система NFS.
Место назначения: файловый ресурс на базе Azure NFS.
Размер данных: приблизительно 350 ГБ.
Использование инструмента:
AzCopy (не поддерживается): изначально мы пытались использовать AzCopy для миграции данных, но обнаружили, что он не поддерживается файловыми системами Azure NFS.
Rsync (проблема роста хранилища): Затем мы обратились к Rsync для синхронизации данных. Однако мы столкнулись со значительным ростом хранилища в месте назначения Azure, и процесс так и не был завершен. Хранилище продолжало увеличиваться без видимых причин, что заставило нас отказаться от процесса Rsync.
Fpsync (первая успешная попытка): Чтобы решить проблему роста хранилища, мы перешли на Fpsync для синхронизации данных. В первой попытке он показал себя многообещающим, поскольку успешно завершил начальную синхронизацию.
Проблема: Необъяснимый рост хранилища: Наша главная проблема — необъяснимый рост использования хранилища в месте назначения Azure NFS, особенно с Rsync. Даже если размер исходных данных остается прежним, хранилище назначения значительно увеличивается, что делает процесс неуправляемым.
Цель: Мы ищем идеи, советы или решения от сообщества, чтобы помочь устранить и решить эту проблему роста хранилища. Наша цель — обеспечить эффективную синхронизацию данных и минимальное использование хранилища в месте назначения Azure.
Дополнительная информация: Исходные данные, включая скрытые файлы и каталоги, правильно отформатированы и именованы.
Разрешения сохраняются во время синхронизации.
Хотя у нас был первоначальный успех с Fpsync для первой синхронизации, последующие синхронизации все еще демонстрировали проблемы роста хранилища. Любые предложения, идеи или опыт, связанные с этой проблемой, были бы высоко оценены. Мы хотим решить эту проблему и обеспечить успешную миграцию данных в Azure NFS.
Обновлять:
Теперь я воспользовался утилитой rclone и столкнулся с той же проблемой.
решение1
Внимательно прочитайте man rsync. Попробуйте несколько вариантов, чтобы --dry-run --itemize-changes увидеть, что именно будет сделано.
Отсутствие возможности удаления означает, что удаление на источнике не будет отражено на цели. Отлично подходит для архивных случаев использования, но не так хорошо для чего-то с ограниченным сроком хранения, например, для файлов журналов с отметкой даты. Также избегайте подстановочных знаков *, если вы хотите удалить файлы, согласно странице руководства:
--delete
This tells rsync to delete extraneous files from the receiving side (ones that aren't on the sending
side), but only for the directories that are being synchronized. You must have asked rsync to send
the whole directory (e.g. "dir" or "dir/") without using a wildcard for the directory's contents
(e.g. "dir/*") since the wildcard is expanded by the shell and rsync thus gets a request to transfer
individual files, not the files' parent directory.
"Поведение по умолчанию — создавать каждый временный файл в том же каталоге, что и связанный файл назначения". Эти временные файлы позволяют прерывать передачу, но требуют значительного дополнительного пространства. Консервативно предположим, что размер источника в два раза больше, для худших сценариев, когда нужно обновить все. Из способов изменения этого поведения, возможно, наиболее агрессивным является --inplaceпрямая перезапись файлов. Опасность: это повредит файлы, используемые в месте назначения, это не для случаев активного/активного использования.
Что касается производительности, найдите ограничивающие факторы как локальных, так и удаленных систем. Если я придумаю худшие цифры, миллион файлов на 100 IOPS медленных шпинделях могут занять часы только для перечисления и сравнения списка файлов. Однако когда дело дойдет до копирования данных файлов, узкие места могут перейти к пропускной способности сети и ЦП для ssh и сжатия.
Придумайте альтернативные планы для первоначальной копии, которые не являются инструментами синхронизации файлов. Например, сделайте локальную резервную копию общего ресурса и восстановите ее на хосте в Azure с подключенным NFS. Быстрее и проще скопировать архив (.tar или что-то еще) по сети и извлечь его все, по сравнению с инкрементной синхронизацией файлов.
Кстати, rsync может быть полезен как инкрементальный, чтобы наверстать упущенное после первоначального копирования. Сравнение все равно займет некоторое время, но гораздо быстрее, если скорость изменений низкая и копировать нечего.