Come riorganizzare i dataset NFS senza modificare i percorsi di esportazione visibili ai client

I dataset NFS possono essere riorganizzati senza lasciare handle obsoleti sui client, purché lo spazio dei nomi delle esportazioni visibile ai client rimanga stabile mentre lo storage viene spostato dietro quel confine.

La progettazione preventiva consiste nel separare il percorso montato dai client dal nome fisico del dataset, che potrebbe essere modificato in seguito. Crea un albero di esportazione stabile, associa deliberatamente i dataset, preserva ove possibile l'identità del filesystem, disconnetti i client prima delle sostituzioni distruttive e verifica lo stesso percorso di esportazione dopo il passaggio. Se il server deve distruggere e ricreare il filesystem di supporto, considera l'operazione come una modifica dell'identità e pianifica un remount coordinato dei client, invece di promettere una continuità invisibile.

Crea uno spazio dei nomi stabile per le esportazioni sopra i dataset

Usa una radice dedicata per le esportazioni NFS, i cui nomi visibili ai client non rispecchino ogni nome interno dei dataset ZFS o Btrfs. In questo modo gli amministratori dello storage possono riorganizzare i dataset sul backend senza dover insegnare a ogni client un nuovo percorso di mount.

Una discussione sulla progettazione di NFSv4 spiega come i bind mount creino esportazioni stabili sotto uno pseudo-filesystem gestito deliberatamente.

Documenta il percorso del client come contratto di compatibilità. I nomi interni dei dataset possono cambiare in seguito, ma solo dopo che il livello di esportazione è stato rimappato e testato usando lo stesso percorso.

Fissa l'identità dell'esportazione invece di affidarti all'ordine di rilevamento

Registra l'UUID del filesystem, il percorso di esportazione, la versione NFS e le impostazioni fsid esplicite usate dal server attuale. Lo stesso nome di directory visibile non è sufficiente quando il server NFS identifica diversamente il filesystem sottostante dopo uno spostamento.

SUSE osserva che NFS identifica ogni filesystem esportato, invece di trattare un'esportazione come un semplice alias di percorso.

Usa identificatori espliciti solo dove la tua implementazione NFS li supporta e mantieni univoco ogni valore. Non copiare un fsid su due filesystem esportati simultaneamente soltanto per farli apparire identici.

Prepara il nuovo dataset dietro lo stesso percorso di esportazione

Crea o ricevi il dataset sostitutivo in un percorso temporaneo sul server, copia o replica i contenuti, verifica i permessi, quindi collegalo all'albero di esportazione stabile durante una finestra di manutenzione. Mantieni disponibile il vecchio dataset per il rollback, ma non attivo con la stessa identità di esportazione.

Un esempio di esportazione NFS mostra come i sottoalberi montati richiedano esportazioni deliberate quando più filesystem compaiono sotto uno stesso spazio dei nomi NFS.

Il passaggio dovrebbe modificare una sola associazione lato server, non contemporaneamente la definizione di mount del client e l'identità del dataset. In questo modo gli elementi utili per la diagnosi rimangono intatti se il nuovo albero presenta problemi.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

$799.00 - $2,499.00

Buy Now

Arresta le scritture prima di sostituire il filesystem di supporto

Arresta o metti in pausa i servizi che scrivono attivamente attraverso il mount NFS, quindi verifica che nessun client importante mantenga un'operazione su file di lunga durata durante il passaggio. Completa la sincronizzazione finale solo dopo aver sospeso le scritture.

IBM descrive perché la persistenza dello stato NFSv4 richiede uno storage stabile: lo stato del client fa parte della continuità, non solo dei contenuti dei file lato server.

Su un home server, l'obiettivo è più semplice rispetto al failover in cluster: evita di modificare l'identità dei file mentre le applicazioni sono attive. Una breve pausa controllata è più sicura che costringere database, client multimediali o di backup a sopravvivere alla sostituzione di un filesystem in uso.

Riconosci quando il remount del client è inevitabile

Se la riorganizzazione distrugge e ricrea il filesystem, ripristina uno snapshot come nuovo filesystem o modifica l'identità del filehandle lato server, pianifica uno smontaggio e un remount coordinati dopo che il percorso del server è diventato stabile.

Una guida aggiornata alla risoluzione dei problemi NFS afferma che i cambiamenti dell'identità del server rendono obsoleti gli handle e raccomanda di verificare l'identità stabile del server quando il problema si ripresenta.

Non pubblicizzare una manutenzione “senza remount” quando l'identità sottostante cambia davvero. Una finestra di remount documentata è preferibile a lasciare che le applicazioni scoprano un errore ESTALE durante le normali scritture.

Testa il percorso del client prima di dismettere il vecchio dataset

Monta l'esportazione da un client nuovo e da un client esistente non critico, quindi confronta l'identità della directory, i permessi, alcune letture rappresentative, una scrittura reversibile e il percorso previsto dall'applicazione. Riavvia un client per verificare che la configurazione persistente del mount non sia cambiata.

Un caso su Arch Linux ha rilevato che una radice NFS stabile evita ESTALE dopo modifiche al filesystem sul backend.

La riorganizzazione è completa quando i client continuano a usare il percorso esportato originale e il vecchio dataset può essere dismesso senza riferimenti nascosti. L'articolo correlato di ZimaSpace sugli handle obsoleti dopo la ridenominazione di un dataset è il percorso di recupero da seguire se ESTALE è già comparso.