Contexto: estamos trabajando en un proyecto de migración de datos que implica la sincronización de datos entre un sistema de archivos NFS local y un recurso compartido de archivos basado en Azure NFS. El objetivo es garantizar una transición fluida del entorno local a Azure manteniendo al mismo tiempo la integridad y la eficiencia de los datos.
Fondo:
Fuente: sistema de archivos NFS local.
Destino: recurso compartido de archivos basado en Azure NFS.
Tamaño de datos: aproximadamente 350 GB.
Uso de herramientas:
AzCopy (no compatible): inicialmente intentamos utilizar AzCopy para la migración de datos, pero descubrimos que no es compatible con los sistemas de archivos Azure NFS.
Rsync (problema de crecimiento del almacenamiento): luego recurrimos a Rsync para la sincronización de datos. Sin embargo, encontramos un crecimiento significativo del almacenamiento en el destino de Azure y el proceso nunca se completó. El almacenamiento siguió aumentando sin motivo aparente, lo que nos obligó a abandonar el proceso Rsync.
Fpsync (primer intento exitoso): para abordar el problema del crecimiento del almacenamiento, hicimos la transición a Fpsync para la sincronización de datos. En el primer intento, se mostró prometedor ya que completó con éxito la sincronización inicial.
El problema: crecimiento inexplicable del almacenamiento: nuestro principal desafío es el crecimiento inexplicable en la utilización del almacenamiento en el destino Azure NFS, especialmente con Rsync. Incluso cuando el tamaño de los datos de origen sigue siendo el mismo, el almacenamiento de destino aumenta significativamente, lo que hace que el proceso sea inmanejable.
Objetivo: Buscamos ideas, consejos o soluciones de la comunidad para ayudar a solucionar y resolver este problema de crecimiento del almacenamiento. Nuestro objetivo es garantizar una sincronización de datos eficiente y un uso mínimo de almacenamiento en el destino de Azure.
Información adicional: Los datos de origen, incluidos los archivos y directorios ocultos, tienen el formato y el nombre correctos.
Los permisos se conservan durante la sincronización.
Si bien tuvimos éxito inicial con Fpsync para la primera sincronización, las sincronizaciones posteriores aún mostraron problemas de crecimiento del almacenamiento. Cualquier sugerencia, idea o experiencia relacionada con este tema será muy apreciada. Buscamos resolver este desafío y garantizar una migración de datos exitosa a Azure NFS.
Actualizar:
Ahora he usado la utilidad rclone y tuve el mismo problema.
Respuesta1
Lea man rsynccuidadosamente. Pruebe algunas opciones para --dry-run --itemize-changes ver qué se haría exactamente.
No proporcionar ninguna opción de eliminación significa que una eliminación en el origen no se reflejará en el destino. Excelente para casos de uso de archivo, no tan bueno para algo con una retención limitada como archivos de registro con fecha estampada. Además, evite los comodines * si desea eliminar archivos, por página de manual:
--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.
"El comportamiento predeterminado es crear cada archivo temporal en el mismo directorio que el archivo de destino asociado". Estos archivos temporales permiten cancelar la transferencia, pero requieren un espacio adicional significativo. De manera conservadora, asuma el doble del tamaño de la fuente, en el peor de los casos, en el que sea necesario actualizar todo. De las formas de cambiar este comportamiento, quizás la más agresiva sea --inplacela que sobrescribe los archivos directamente. Peligro: esto dañará los archivos en uso en el destino, no es para casos de uso activo/activo.
En cuanto al rendimiento, encuentre cuáles son los factores limitantes tanto de los sistemas locales como de los remotos. Si invento los números del peor de los casos, un millón de archivos en ejes lentos de 100 IOPS podrían llevar horas simplemente para enumerar y comparar la lista de archivos. Sin embargo, cuando se trata de copiar datos de archivos, los cuellos de botella pueden pasar al ancho de banda de la red y a la CPU para ssh y compresión.
Piense en planes alternativos para una copia inicial que no sean herramientas de sincronización de archivos. Por ejemplo, realice una copia de seguridad local del recurso compartido y restáurela en un host en Azure con ese NFS montado. Es más rápido y sencillo copiar un archivo (.tar o lo que sea) a través de la red y extraerlo todo, en comparación con la sincronización incremental de archivos.
Hablando de eso, rsync podría ser útil como incremental para ponerse al día después de la copia inicial. Todavía llevará algún tiempo comparar, pero mucho más rápido si la tasa de cambio es baja y no hay mucho que copiar.