Cumplimiento de POSIX

Las siguientes son excepciones al cumplimiento de POSIX de Google Cloud Managed Lustre:

  • Actualizaciones de atime: De forma predeterminada, atime está habilitado en Lustre, pero, por motivos de rendimiento, es posible que se pospongan sus actualizaciones. Esto significa que es posible que la hora de acceso de un archivo no se actualice inmediatamente después de cada operación de lectura.

  • flock/lockf: Hacen referencia a dos APIs principales de bloqueo de archivos: flock(2) y fcntl(2).

    • flock: Es un bloqueo asesor de archivo completo de estilo BSD que no está definido por POSIX. De forma predeterminada, Lustre admite por completo la semántica de flock al estilo de BSD en todo el clúster.
    • fcntl: Esta es la API de bloqueo definida por POSIX, que admite bloqueos de rangos de bytes. La implementación de los bloqueos de fcntl de Lustre es casi compatible con POSIX y funciona según lo esperado para la mayoría de las aplicaciones. Sin embargo, dado que fcntl se diseñó originalmente para sistemas de archivos locales, ningún sistema de archivos distribuido puede cumplir al 100% todos los requisitos de fcntl de POSIX, incluido Lustre. Por ejemplo, fcntl() especifica que los bloqueos se deben liberar inmediatamente cuando finaliza el proceso propietario, pero la liberación del bloqueo de Lustre puede retrasarse si el cliente falla.

Para obtener más detalles, consulta las Preguntas frecuentes sobre Lustre.

El número de inode cambia debido a la migración de metadatos

El número de inodo de un archivo en un sistema de archivos Lustre no es un identificador inmutable.

Una operación de reequilibrio de metadatos, como la que inicia lfs migrate, implica migrar los metadatos de algunos archivos de un MDT a otro. Como consecuencia directa de esta migración a un nuevo MDT, a esos archivos se les asigna un nuevo número de i-nodo.

Si bien este comportamiento cumple con el estándar POSIX, puede incumplir las suposiciones de muchas aplicaciones y servicios comunes de Unix/Linux que se compilan para esperar un número de inode persistente durante la vida útil de un archivo. Esto incluye, sin limitaciones, lo siguiente:

  • Front-ends de NFS y SMB: Estos servicios suelen derivar identificadores de archivos de números de i-nodo. Un cambio puede generar errores Stale file handle para los clientes.

  • Utilidades de copia de seguridad y archivado: Las herramientas como tar que hacen un seguimiento de los archivos por su dispositivo y número de inode pueden tratar un archivo migrado como un archivo nuevo, lo que genera copias de seguridad incrementales ineficientes.

  • También se pueden ver afectados los agregadores de registros, los sistemas de detección de intrusiones y las aplicaciones personalizadas que usan stat() y almacenan st_ino.

Los administradores deben tener en cuenta este comportamiento y su posible impacto en las aplicaciones antes de iniciar cualquier reequilibrio manual de metadatos.

Estrategias de mitigación

El rebalanceo de metadatos debe considerarse como un evento de mantenimiento planificado y disruptivo.

  1. Programa un período de mantenimiento. Comunica una interrupción planificada a todos los usuarios y propietarios de aplicaciones. Si es posible, no realices operaciones lfs migrate a gran escala en un sistema de producción activo.

  2. Si es necesario, desmonta y vuelve a montar el sistema de archivos después de la migración.

  3. Es posible que algunas aplicaciones deban vaciarse o reiniciarse después de una migración.