Conformité POSIX

Voici quelques exceptions à la conformité POSIX de Google Cloud Managed Lustre :

  • Mises à jour atime : atime est activé par défaut dans Lustre, mais ses mises à jour peuvent être différées pour des raisons de performances. Cela signifie que l'heure d'accès à un fichier peut ne pas être mise à jour immédiatement après chaque opération de lecture.

  • flock/lockf : fait référence à deux API de verrouillage de fichiers principales : flock(2) et fcntl(2).

    • flock : il s'agit d'un verrou consultatif de type BSD pour l'ensemble du fichier, qui n'est pas défini par POSIX. Par défaut, Lustre est entièrement compatible avec la sémantique flock de style BSD dans l'ensemble du cluster.
    • fcntl : il s'agit de l'API de verrouillage définie par POSIX, qui prend en charge les verrous de plage d'octets. L'implémentation des verrous fcntl par Lustre est presque conforme à la norme POSIX et fonctionne comme prévu pour la plupart des applications. Toutefois, comme fcntl a été conçu à l'origine pour les systèmes de fichiers locaux, aucun système de fichiers distribué ne peut répondre à 100 % à toutes les exigences fcntl de POSIX, y compris Lustre. Par exemple, fcntl() spécifie que les verrous doivent être libérés immédiatement lorsque le processus propriétaire se termine, mais la libération des verrous Lustre peut être retardée si le client plante.

Pour en savoir plus, consultez les questions fréquentes sur Lustre.

Le numéro d'inode change en raison de la migration des métadonnées

Le numéro d'inode d'un fichier dans un système de fichiers Lustre n'est pas un identifiant immuable.

Une opération de rééquilibrage des métadonnées, telle que celle initiée par lfs migrate, implique la migration des métadonnées de certains fichiers d'une MDT à une autre. En conséquence directe de cette migration vers un nouveau MDT, ces fichiers se voient attribuer un nouveau numéro d'inode.

Bien que ce comportement soit conforme à la norme POSIX, il peut enfreindre les hypothèses de nombreuses applications et services Unix/Linux courants qui sont conçus pour s'attendre à un numéro d'inode persistant pendant toute la durée de vie d'un fichier. Cela inclut, sans s'y limiter :

  • Interfaces NFS et SMB : ces services dérivent souvent les descripteurs de fichiers des numéros d'inode. Une modification peut entraîner des erreurs Stale file handle pour les clients.

  • Utilitaires d'archivage et de sauvegarde : les outils tels que tar qui suivent les fichiers par leur numéro d'appareil et d'inode peuvent traiter un fichier migré comme un nouveau fichier, ce qui entraîne des sauvegardes incrémentielles inefficaces.

  • Les agrégateurs de journaux, les systèmes de détection d'intrusion et les applications personnalisées utilisant stat() et stockant st_ino peuvent également être affectés.

Les administrateurs doivent être conscients de ce comportement et de son impact potentiel sur les applications avant de lancer un rééquilibrage manuel des métadonnées.

Stratégies d'atténuation

Le rééquilibrage des métadonnées doit être considéré comme un événement de maintenance planifié et perturbateur.

  1. Planifiez un intervalle de maintenance. Communiquez une indisponibilité planifiée à tous les utilisateurs et propriétaires d'applications. Si possible, n'effectuez pas d'opérations lfs migrate à grande échelle sur un système de production en direct.

  2. Si nécessaire, démontez et remontez le système de fichiers après la migration.

  3. Il peut être nécessaire de vider le cache ou de redémarrer certaines applications après une migration.