Descripción de cómo funciona la sincronización

Los archivos de S3 mantienen sincronizados automáticamente el sistema de archivos y el bucket de S3 vinculado. Los datos utilizados de forma activa se copian en el sistema de archivos, por lo que puede realizar lecturas y escrituras mediante operaciones de archivo estándar de Linux de baja latencia. Los archivos de S3 requieren que el control de versiones de S3 esté habilitado en el bucket de S3 vinculado. Al editar archivos en el sistema de archivos, los archivos de S3 copian los cambios en el bucket de S3 como nuevas versiones de los objetos correspondientes, asegurándose de que se conservan las versiones anteriores. Cuando otras aplicaciones agregan, modifican o eliminan objetos del bucket de S3, los archivos de S3 reflejan automáticamente esos cambios en el sistema de archivos. Cuando se produce un conflicto debido a cambios simultáneos en los mismos datos en el sistema de archivos y en el bucket de S3, los archivos de S3 tratan el bucket de S3 como el origen de información verdadera en caso de conflictos.

Para optimizar los costos de almacenamiento, los archivos de S3 eliminan los datos que no ha utilizado recientemente del sistema de archivos. Los datos permanecen almacenados de forma duradera en el bucket de S3 vinculado y se recuperan en el sistema de archivos la próxima vez que acceda a ellos.

Se puede acceder al bucket de S3 a través del sistema de archivos

Tras crear un sistema de archivos de S3, puede montar los buckets de S3 en los recursos informáticos y empezar a acceder a los datos del bucket de S3 de forma inmediata. De forma predeterminada, cuando accede por primera vez a un directorio mostrando su contenido o abriendo un archivo en él, los archivos de S3 importan los metadatos de todos los archivos de ese directorio, junto con los datos de los archivos con un tamaño inferior al límite de importación (128 KB predeterminados) desde el bucket de S3. Es posible que el primer acceso a un directorio tenga una latencia mayor, pero las lecturas y escrituras posteriores son considerablemente más rápidas. Al importar los metadatos por adelantado, los archivos de S3 permiten explorar el contenido del directorio, ver el tamaño de los archivos y comprobar los permisos con una latencia baja.

Por ejemplo, supongamos que el bucket de S3 contiene un prefijo data/images/ con 1000 objetos. La primera vez que ejecuta ls /mnt/s3files/data/images/, los archivos de S3 importan los metadatos de los 1000 archivos y copian datos de forma asíncrona para archivos por debajo del límite de tamaño de importación en el sistema de archivos. Esta lista inicial puede tardar varios segundos, pero los comandos posteriores, como ls -la, stat o cat en archivos individuales de ese directorio regresan con una latencia baja.

En el caso de los archivos con un tamaño superior al límite de importación, los archivos de S3 solo importan metadatos, mientras que los datos no se copian en el sistema de archivos, sino que se leen directamente desde el bucket de S3 cuando se accede a él. Puede ajustar este límite para que se adapte mejor a la carga de trabajo. Por ejemplo, puede aumentarlo para importar más datos por adelantado para las cargas de trabajo que acceden repetidamente a los mismos archivos y aprovechar las lecturas de baja latencia. En el caso de las cargas de trabajo que transmiten datos de forma secuencial, un límite más bajo puede resultar más rentable, ya que el beneficio de latencia que supone importar datos por adelantado es menos significativo cuando los datos se leen secuencialmente en fragmentos grandes en lugar de hacerlo en lecturas pequeñas y aleatorias. Para obtener más información, consulte Personalización de la sincronización de archivos de S3.

Los cambios en el sistema de archivos se reflejan automáticamente en el bucket de S3

Al crear, modificar o eliminar archivos en el sistema de archivos, los archivos de S3 copian automáticamente esos cambios en el bucket de S3. Los archivos nuevos se convierten en nuevos objetos de S3, los cambios en los archivos existentes se convierten en nuevas versiones de objetos y los archivos eliminados se convierten en marcadores de eliminación de S3.

Los permisos POSIX que se establecen en los archivos y directorios a través del sistema de archivos, como el propietario (UID), el grupo (GID) y los bits de permiso, se almacenan como metadatos de objetos de S3 definidos por el usuario en los objetos de S3 correspondientes. Cuando cambia los permisos mediante chmod, chown o chgrp, los archivos de S3 exportan esos cambios al bucket de S3 junto con cualquier cambio en los datos. Cuando los archivos de S3 importan objetos del bucket de S3, lee estos metadatos y aplica los permisos POSIX correspondientes al sistema de archivos. A los objetos que no tienen metadatos de permisos POSIX se les asignan los permisos predeterminados.

Al modificar un archivo en el sistema de archivos, los archivos de S3 esperan hasta 60 segundos y, durante ese tiempo, se agregan los cambios sucesivos al archivo antes de copiarlos en el bucket de S3. Esto significa que las escrituras rápidas y sucesivas en el mismo archivo se capturan en una sola solicitud PUT de S3, en lugar de generar una nueva versión del objeto para cada cambio individual, lo que reduce los costos de almacenamiento y las solicitudes de S3. Si continúa modificando el archivo después de que los archivos de S3 hayan copiado los cambios en el bucket de S3, copiará los cambios posteriores según sea necesario.

Por ejemplo, si una aplicación abre un archivo de registro y lo anexa 50 veces en 30 segundos, los archivos de S3 agrupan los 50 archivos adjuntos en una sola solicitud PUT de S3. Si la aplicación sigue escribiendo después de la primera sincronización, los archivos de S3 copian los cambios adicionales en una sincronización posterior.

Los cambios en el bucket de S3 aparecen automáticamente en el sistema de archivos

Los archivos de S3 supervisan los cambios en el bucket de S3 mediante las notificaciones de eventos de S3. Cuando otra aplicación que trabaja con la API de S3 agrega, modifica o elimina objetos del bucket de S3, los archivos de S3 reflejan automáticamente esos cambios en el sistema de archivos para los archivos cuyos datos están actualmente almacenados en el almacenamiento de alto rendimiento del sistema de archivos. Los archivos del sistema de archivos cuyos datos hayan caducado no se actualizarán hasta la próxima vez que acceda a ellos, momento en el que los archivos de S3 recuperan la última versión del bucket de S3.

Descripción del impacto de las operaciones de cambio de nombre y traslado

Amazon S3 utiliza una estructura de almacenamiento plana en la que los objetos se identifican por los nombres de clave. Aunque los archivos de S3 permiten organizar los datos en directorios, S3 no tiene un concepto nativo de directorios. Lo que aparece como un directorio en el sistema de archivos es un prefijo común que comparten las claves de los objetos del bucket de S3. Además, los objetos de S3 son inmutables y no admiten cambios de nombre atómicos. Como resultado, cuando cambia el nombre de un archivo o lo mueve, los archivos de S3 deben escribir los datos en un objeto nuevo con la clave actualizada y eliminar el original. Al cambiar el nombre o mover un directorio, los archivos de S3 deben repetir este proceso para cada objeto que comparta ese prefijo. Por lo tanto, al cambiar el nombre o mover un directorio que contiene decenas de millones de archivos, los costos de las solicitudes de S3 y el tiempo de sincronización aumentan considerablemente.

Los archivos de S3 devuelven un error al intentar crear un sistema de archivos basado en un prefijo con más de 125 millones de objetos. Este error avisa de que las operaciones de cambio de nombre o traslado recursivas de gran tamaño pueden afectar al rendimiento del sistema de archivos, ya que cada archivo requiere solicitudes independientes de escritura y eliminación en el bucket de S3. Si aún desea crear un sistema de archivos con ese prefijo, puede agregar el parámetro --AcceptBucketWarning.

Como los archivos de S3 cambian el nombre de los objetos de forma individual en el bucket de S3, ambos directorios estarán visibles en el bucket de S3 hasta que se complete el cambio de nombre. Los objetos escritos después de cambiar el nombre del directorio, pero antes de que el cambio de nombre esté completamente sincronizado, no se moverán. Para simplificar el trabajo de reorganización de los datos, recomendamos que no cree nuevos objetos a través del bucket de S3 mientras cambia el nombre de un directorio coincidente.

Por ejemplo, si ejecuta mv /mnt/s3files/projects/alpha /mnt/s3files/projects/beta, el cambio de nombre se realiza al instante en el sistema de archivos. En el bucket de S3, los archivos de S3 comienzan a copiar y eliminar cada objeto hasta su nueva clave dentro del bucket de S3 (sustituyendo el prefijo projects/alpha/ por projects/beta/) y a eliminar el original. Durante este proceso, el bucket de S3 contiene temporalmente objetos situados debajo de projects/alpha/ y projects/beta/. Una vez que se han movido todos los objetos, solo queda projects/beta/.

Los datos no utilizados del sistema de archivos caducan para optimizar el almacenamiento

Los archivos de S3 optimizan los costos de almacenamiento al eliminar automáticamente del sistema de archivos los datos de archivos que no se hayan leído recientemente. Los datos permanecen almacenados de forma segura en el bucket de S3. Los archivos de S3 solo eliminan la copia del sistema de archivos. Los metadatos de los archivos, como los nombres, los tamaños y los permisos, nunca se eliminan del sistema de archivos, por lo que puede seguir navegando por el sistema de archivos con una latencia baja.

Si un archivo del sistema de archivos no se ha leído durante 30 días (configurable) y sus cambios ya se han sincronizado con el bucket de S3, los archivos de S3 eliminan los datos del archivo del sistema de archivos. La próxima vez que lea ese archivo, los archivos de S3 recuperarán la última versión del objeto correspondiente del bucket de S3 y la volverán a copiar en el sistema de archivos.

Por ejemplo, supongamos que procesa un conjunto de datos en /mnt/s3files/data/batch-jan.parquet en enero y no vuelve a acceder a él. Transcurridos 30 días, los archivos de S3 eliminan los datos del archivo del sistema de archivos. El archivo sigue apareciendo en las listas de directorios con el tamaño y los permisos correctos, pero los datos ya no se encuentran en el sistema de archivos. Cuando vuelva a leer el archivo en abril, los archivos de S3 lo recuperarán del bucket de S3 y lo volverán a copiar en el sistema de archivos. La primera lectura puede tener una latencia más alta, pero las lecturas posteriores son rápidas.

El bucket de S3 es el origen de información verdadera en caso de conflictos

Se produce un conflicto cuando el mismo archivo se ha modificado en el sistema de archivos y el objeto de S3 correspondiente también ha cambiado antes de que los archivos de S3 hayan sincronizado los cambios del sistema de archivos con el bucket de S3. Por ejemplo, es posible que edite un archivo a través del sistema de archivos montado mientras otra aplicación carga una nueva versión del objeto correspondiente, o la elimina, directamente en el bucket de S3 vinculado.

Los archivos de S3 detectan conflictos cuando intentan volver a sincronizar los cambios del sistema de archivos con el bucket de S3 o cuando reciben una notificación de evento de S3 que indica que el objeto ha cambiado. El bucket de S3 sirve como almacén a largo plazo para los datos, por lo que los archivos de S3 tienen en cuenta que el bucket de S3 es el origen de información verdadera cuando se produce un conflicto. Esto proporciona una coherencia predecible, lo que garantiza que la versión del bucket de S3 siempre tenga prioridad. En caso de conflicto, los archivos de S3 mueven el archivo conflictivo de su ubicación actual en el sistema de archivos a un directorio de objetos perdidos e importa la última versión del bucket de S3 vinculado al sistema de archivos.

Por ejemplo, supongamos que edita /mnt/s3files/report.csv a través del sistema de archivos. Antes de que los archivos de S3 vuelvan a sincronizar los cambios con el bucket de S3, otra aplicación carga una nueva versión de report.csv directamente en el bucket de S3. Cuando los archivos de S3 detectan el conflicto, mueven la versión de report.csv al directorio de objetos perdidos y la reemplazan por la versión del bucket de S3.

El directorio de objetos perdidos se encuentra en el directorio raíz del sistema de archivos bajo el nombre .s3files-lost+found-file-system-id. Cuando los archivos de S3 mueven un archivo al directorio de objetos perdidos, agregan un identificador al nombre del archivo para distinguir varias versiones del mismo archivo que pueden moverse con el tiempo. Los archivos del directorio de objetos perdidos no se copian en el bucket de S3. Puede eliminar y copiar archivos de este directorio, pero no puede moverlos ni cambiarles el nombre ni eliminar el propio directorio. Si desea conservar los cambios del sistema de archivos en lugar de la última versión en el bucket de S3, copie el archivo del directorio de objetos perdidos en su ruta original. Puede recuperar la ruta original del archivo a partir de los atributos extendidos del archivo en el directorio de objetos perdidos. A continuación, los archivos de S3 lo copiarán en el bucket de S3 como una nueva versión del objeto. Para obtener más información, consulte Solución de problemas de archivos de S3.

La configuración de sincronización predeterminada funcionará para la mayoría de las cargas de trabajo para un acceso de baja latencia y basado en archivos a los datos de S3. Para obtener más información sobre cómo configurar estos parámetros, consulte Personalización de la sincronización de archivos de S3.