Conformità POSIX

Di seguito sono riportate le eccezioni alla conformità POSIX di Google Cloud Managed Lustre:

  • Aggiornamenti atime: per impostazione predefinita, atime è abilitato in Lustre, ma per motivi di prestazioni, gli aggiornamenti potrebbero essere posticipati. Ciò significa che l'ora di accesso di un file potrebbe non essere aggiornata immediatamente dopo ogni operazione di lettura.

  • flock/lockf: si riferiscono a due API di blocco dei file principali: flock(2) e fcntl(2).

    • flock: si tratta di un blocco consultivo di file interi in stile BSD che non è definito da POSIX. Per impostazione predefinita, Lustre supporta completamente la semantica flock in stile BSD nel cluster.
    • fcntl: si tratta dell'API di blocco definita da POSIX, che supporta i blocchi di intervalli di byte. L'implementazione dei blocchi fcntl di Lustre è quasi conforme a POSIX e funziona come previsto per la maggior parte delle applicazioni. Tuttavia, poiché fcntl è stato originariamente progettato per i file system locali, nessun file system distribuito può soddisfare al 100% tutti i requisiti fcntl di POSIX, incluso Lustre. Ad esempio, fcntl() specifica che i blocchi devono essere rilasciati immediatamente quando il processo proprietario viene chiuso, ma il rilascio dei blocchi di Lustre potrebbe essere ritardato se il client si arresta in modo anomalo.

Per maggiori dettagli, consulta le Domande frequenti su Lustre.

Modifiche al numero di inode dovute alla migrazione dei metadati

Il numero di inode di un file in un file system Lustre non è un identificatore immutabile.

Un'operazione di ribilanciamento dei metadati, ad esempio quella avviata da lfs migrate, comporta la migrazione dei metadati di alcuni file da un MDT a un altro. Come conseguenza diretta di questa migrazione a un nuovo MDT, a questi file viene assegnato un nuovo numero di inode.

Sebbene questo comportamento sia conforme allo standard POSIX, può violare le ipotesi di molte applicazioni e servizi Unix/Linux comuni che sono progettati per prevedere un numero di inode persistente per la durata di un file. A titolo esemplificativo, non è consentito quanto segue:

  • Frontend NFS e SMB: questi servizi spesso derivano gli handle dei file dai numeri di inode. Una modifica può causare errori Stale file handle per i client.

  • Utilità di archiviazione e backup: gli strumenti come tar che tengono traccia dei file in base al numero di dispositivo + inode possono trattare un file migrato come un nuovo file, con conseguenti backup incrementali inefficienti.

  • Anche gli aggregatori di log, i sistemi di rilevamento delle intrusioni e le applicazioni personalizzate che utilizzano stat() e memorizzano st_ino potrebbero essere interessati.

Prima di avviare qualsiasi ribilanciamento manuale dei metadati, gli amministratori devono essere a conoscenza di questo comportamento e del suo potenziale impatto sulle applicazioni.

Strategie di mitigazione

Il ribilanciamento dei metadati deve essere trattato come un evento di manutenzione pianificato e dirompente.

  1. Pianifica un periodo di manutenzione. Comunica un'interruzione pianificata a tutti gli utenti e ai proprietari delle applicazioni. Se possibile, non eseguire operazioni lfs migrate su larga scala su un sistema di produzione live.

  2. Se necessario, smonta e rimonta il file system dopo la migrazione.

  3. Alcune applicazioni potrebbero dover essere scaricate o riavviate dopo una migrazione.