Compartir a través de


Comportamiento del sistema de archivos

En última instancia, Azure Container Storage habilitado por Azure Arc proporciona una interfaz de sistema de archivos a las aplicaciones. Los sistemas de archivos tienen comportamientos específicos que las aplicaciones deben diseñarse para controlar. En este artículo se explica cómo se propagan los cambios del sistema de archivos compartido y qué ocurre con un sistema de archivos espejo durante la sincronización del espejo.

¿Qué queremos decir con una interfaz del sistema de archivos?

Una aplicación puede acceder a muchos sistemas de archivos en su estructura de carpetas a través de puntos de montaje. En Kubernetes, las aplicaciones (pods) configuran montajes mediante PVC. Cuando un pod se monta con un PVC EdgeVolume, obtiene acceso a un sistema de archivos en común a través de una carpeta montada.

Consulte esta guía, por ejemplo, para configurar PVC para la extensión del volumen respaldado por la nube. Un sistema de archivos montado con un PVC EdgeVolume tiene un componente local y remoto. El sistema de archivos local recibe operaciones del sistema de archivos de aplicación. Reenvía las operaciones del sistema de archivos al componente remoto que tiene acceso al almacenamiento subyacente.

Propagación de cambios y almacenamiento en caché local

Desde cualquier nodo del clúster, muchos pods pueden montar la misma carpeta de EdgeVolume compartida. Dentro de esta carpeta, los datos de un pod son legibles desde otros pods. Si hay pods en nodos independientes que están montando la misma carpeta compartida, los cambios pueden tardar algún tiempo en propagarse. Los archivos y carpetas nuevos o eliminados pueden tardar hasta 60 segundos en propagarse. Las escrituras de archivos pueden tardar hasta 30 segundos en propagarse.

El motivo de estos retrasos se debe a tiempos de invalidación de caché del lado cliente. Cuando el pod realiza una operación de lectura en el sistema de archivos local, podría usar una caché local y nunca realizar una llamada de red. Las entradas de caché que utiliza finalmente expiran, por lo que, cuando el caché relevante caduca, el sistema de archivos del pod vuelve a leer la información a través de la red. En este momento, el sistema de archivos local extrae los metadatos y el contenido más recientes del archivo.

Las secuencias de operación de archivo que implican abrir el archivo, leer y, a continuación, cerrar el archivo (en lugar de archivos abiertos de larga duración) siempre leen el contenido más reciente del archivo. Cuando el sistema de archivos del pod local procesa una llamada abierta, se dirige directamente al servidor para comprobar si el archivo ha cambiado.

Comportamiento del sistema de archivos espejado

Cuando se produce una sincronización reflejada, una aplicación interna se ejecuta para detectar y realizar operaciones del sistema de archivos para sincronizar el sistema de archivos perimetral para que coincida con un destino de blob. La configuración de subvolumen reflejado se describe en este artículo.

Las operaciones que se pueden realizar para completar una sincronización reflejada se dividen en las siguientes categorías:

  • Crear nuevos archivos o carpetas para que coincidan con blobs recién creados.
  • Quitar archivos o carpetas existentes para que coincidan con blobs eliminados.
  • Modificar los archivos existentes para que coincidan con los blobs modificados, mediante la descarga del nuevo blob y su renombrado por encima del archivo anterior.
  • Modificar metadatos de archivo o carpeta: propietario, grupo, permisos y xattrs en función de los cambios de metadatos en el blob.

Cuando la aplicación interna realiza estas operaciones, lo hace directamente en el sistema de archivos subyacente. Finalmente, los cambios llegan a los pods de clientes que leen el sistema de archivos. Una vez realizado un cambio en el sistema de archivos interno, puede tardar hasta 30 segundos en realizar cambios de archivo o 60 segundos en archivos creados o eliminados para propagarse a los pods del cliente.

Dado que las sincronizaciones de modificación de blobs se implementan mediante cambios de nombre con contenido completo del archivo, las aplicaciones nunca ven archivos sincronizados parcialmente. Pueden ver el contenido del archivo antiguo o el contenido del nuevo archivo.

Sin embargo, los cambios de metadatos se aplican directamente al archivo o carpeta visibles del cliente. Esto significa que es posible ver metadatos sincronizados parcialmente (propietario, grupo, permisos o xattrs).