Conformità POSIX

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

  • Aggiornamenti di atime: per impostazione predefinita, atime è abilitato in Lustre, ma per motivi di prestazioni, i suoi 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 principali per il blocco dei file: flock(2) e fcntl(2).

    • flock: Si tratta di un blocco di tipo BSD per l'intero file che non è definito da POSIX. Lustre supporta completamente la semantica flock in stile BSD in tutto il cluster per impostazione predefinita.
    • 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 di fcntl di POSIX, incluso Lustre. Ad esempio, fcntl() specifica che i blocchi devono essere rilasciati immediatamente quando il processo proprietario termina, ma il rilascio del blocco 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 inode di un file in un file system Lustre non è un identificatore immutabile.

Un'operazione di ribilanciamento dei metadati, ad esempio una 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 molti servizi e applicazioni Unix/Linux comuni, creati per prevedere un numero inode persistente per la durata di un file. Ciò include, a titolo esemplificativo:

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

  • Utilità di archiviazione e backup: strumenti come tar che monitorano i file in base al numero di dispositivo + inode potrebbero trattare un file migrato come un nuovo file, con conseguenti backup incrementali inefficienti.

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

Gli amministratori devono essere consapevoli di questo comportamento e del suo potenziale impatto sulle applicazioni prima di avviare qualsiasi ribilanciamento manuale dei metadati.

Strategie di mitigazione

Il ribilanciamento dei metadati deve essere considerato come un evento di manutenzione pianificata e distruttiva.

  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 attivo.

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

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