Checklist di migrazione NFS per dataset rinominati e handle di file stabili

Eva Wong

IceWhale author

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

NFS Migration Checklist for Renamed Datasets and Stable File Handles - Zima Store Online

L’approccio sicuro consiste nel trattare una migrazione quiescente dell’esportazione, che preservi ove possibile lo spazio dei nomi visibile ai client e rimonti deliberatamente i client quando cambia l’identità degli handle, come una sequenza di fasi osservabili, non come un singolo comando.

Su un server NFS Linux che migra un dataset NAS utilizzato da client home-server, il rischio concreto è che la ridenominazione o lo spostamento di un dataset esportato lasci ai client handle di file NFS obsoleti o causi errori di rimontaggio. Registra l’identità attuale e il punto di ripristino, inizia con il discriminante meno invasivo, interpreta i risultati positivi e negativi prima di modificare un’altra variabile e fermati quando lo storage diventa instabile o l’unica copia recuperabile rischia di essere esposta. Il flusso di lavoro seguente termina solo quando il carico di lavoro originale ha esito positivo o le prove raggiungono una soglia di escalation.

Inventaria l’esportazione e le dipendenze degli handle di file

Registra l’identità del filesystem o del dataset di origine, il percorso lato server, la pseudo-root NFSv4, le opzioni di esportazione, gli eventuali valori fsid espliciti, i percorsi di mount dei client, le unità autofs o systemd e ogni container o applicazione che utilizza il mount. Acquisisci l’elenco dei mount attivi e dei file aperti prima di pianificare il downtime.

Gli handle di file NFS codificano l’identità dell’oggetto selezionata dal server, quindi una stringa di percorso invariata non garantisce un handle stabile dopo lo spostamento di un filesystem. Una spiegazione indipendente dei meccanismi degli handle di file NFS obsoleti illustra come esportazioni eliminate, ricreate o rimappate producano handle obsoleti anche quando la directory è visibilmente presente.

Decidi se l’obiettivo è la stabilità dello spazio dei nomi o la continuità degli handle attivi. Preservare il percorso visibile ai client riduce le modifiche alla configurazione, ma lo spostamento dei dati su un filesystem diverso può comunque richiedere lo smontaggio e l’acquisizione di nuovi handle da parte di ogni client.

Prepara la destinazione mentre i client restano sull’origine

Crea il dataset di destinazione, copia i dati preservando ACL, proprietari, attributi estesi, hard link, file sparsi e timestamp, quindi confronta i conteggi e gli hash rappresentativi. Allinea la sicurezza dell’esportazione e la mappatura delle identità prima di esporre la destinazione ai client di produzione.

Utilizza la guida di ZimaSpace sulla mappatura delle identità NFSv4 per allineare le identità NFSv4 tra i server Linux. Gli handle di file stabili non risolvono le discrepanze tra proprietari numerici o domini dei nomi, quindi convalida separatamente sia il livello dell’identità dei file sia quello dell’identità degli utenti.

Esegui una sincronizzazione iniziale mentre l’origine è attiva solo se il metodo di copia la supporta, quindi pianifica un delta finale a servizi arrestati. Non esportare entrambe le copie in lettura-scrittura nello stesso spazio dei nomi dei client, perché le scritture potrebbero divergere senza un errore evidente.

Metti in quiescenza i client e trasferisci l’esportazione

Arresta applicazioni che scrivono, container e attività pianificate su ogni client, quindi verifica che nessun processo importante mantenga file aperti sotto il mount. Smonta i client in modo pulito. Dopo la sincronizzazione finale, rimuovi l’esportazione dell’origine o rendila di sola lettura, trasferisci il mount o l’esportazione lato server alla destinazione e ricarica le esportazioni.

Un resoconto tecnico di GitLab relativo a un caso di ridenominazione NFS e stato obsoleto mostra che il comportamento di ridenominazioni e deleghe può produrre osservazioni obsolete o incoerenti sui client. La risposta operativa sicura consiste nel pianificare la quiescenza e il rimontaggio, non nel ripetere comandi per svuotare la cache mentre le applicazioni continuano a scrivere.

Se la destinazione cambia identità del filesystem, prevedi nuovi handle e rimonta i client da zero. Mantieni l’esportazione originale disponibile con un nome di ripristino non produttivo, ma non consentire mai a entrambi gli alberi, vecchio e nuovo, di accettare scritture concorrenti.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

Rimonta ogni client e verifica la nuova identità

Rimonta prima un client di test e verifica elenchi, lettura, creazione, ridenominazione, eliminazione, blocco dei file e proprietari. Riavvia l’applicazione dipendente e verifica il carico di lavoro originale. Procedi quindi con gli altri client, registrando l’origine del mount, la versione NFS e l’assenza di errori relativi a handle obsoleti.

Riavvia il sistema o il servizio di automount sul client di test per dimostrare che la configurazione persistente punta allo spazio dei nomi stabile visibile al client. Controlla i log del server, i kernel dei client, i processi di backup e i container alla ricerca di vecchi percorsi nascosti. Un mount manuale riuscito non dimostra che l’ordine di avvio o le dipendenze dei servizi siano corretti.

Dismetti l’origine solo dopo che tutti i client hanno eseguito il rimontaggio, i normali processi sono completati correttamente, un backup è riuscito e un ripristino è stato testato. Esegui il rollback prima di accettare nuove scritture se il client di test non funziona; dopo l’inizio delle scritture sulla destinazione, fermati e riconcilia deliberatamente i dati invece di alternare le esportazioni.