Checklista för NFS-migrering av omdöpta dataset och stabila filhandtag

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

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

Det säkra tillvägagångssättet är att behandla en pausad exportmigrering som bevarar klienternas namnrymd där det är möjligt och medvetet monterar om klienter när handtagsidentiteten ändras som en serie observerbara kontrollpunkter, inte som ett enda kommando.

På en Linux-NFS-server som migrerar en NAS-datauppsättning som används av hemserverklienter är den praktiska risken att ett namnbyte eller en flytt av en exporterad datauppsättning kan lämna klienterna med inaktuella NFS-filhandtag eller misslyckade ommonteringar. Dokumentera den aktuella identiteten och återställningspunkten, börja med den minst ingripande särskiljaren, tolka godkända och underkända resultat innan du ändrar ytterligare en variabel och avbryt om lagringen blir instabil eller den enda återställningsbara kopian skulle exponeras. Arbetsflödet nedan är inte avslutat förrän den ursprungliga arbetsbelastningen fungerar eller bevisläget når en eskaleringsgräns.

Inventera exporten och filhandtagsberoendena

Dokumentera källfilsystemets eller datauppsättningens identitet, sökvägen på servern, NFSv4:s pseudorot, exportalternativen, uttryckliga fsid-värden, klienternas monteringssökvägar, autofs- eller systemd-enheter och varje container eller program som använder monteringen. Samla in aktiva monteringar och öppna filer innan du planerar driftstopp.

NFS-filhandtag kodar servervald objektidentitet, så en oförändrad sökvägssträng garanterar inte ett stabilt handtag efter en flytt av ett filsystem. En fristående förklaring av NFS-mekanismer för inaktuella filhandtag beskriver hur borttagna, återskapade eller ommappade exporter ger upphov till inaktuella handtag även när katalogen fortfarande synligt finns kvar.

Bestäm om målet är stabil namnrymd eller kontinuitet för aktiva handtag. Att bevara klienternas sökväg minskar konfigurationsändringarna, men en flytt av data till ett annat filsystem kan fortfarande kräva att alla klienter avmonterar och hämtar nya handtag.

Förbered målet medan klienterna fortfarande använder källan

Skapa måldatauppsättningen, kopiera data med ACL:er, ägare, utökade attribut, hårda länkar, glesa filer och tidsstämplar bevarade och jämför antal samt representativa hashvärden. Anpassa exportsäkerhet och identitetsmappning innan målet exponeras för produktionsklienter.

Använd ZimaSpace-guiden om guiden för NFSv4-identitetsmappning för att anpassa NFSv4-identiteter mellan Linux-servrar. Stabila filhandtag löser inte problem med numeriskt ägarskap eller namnrymdsmissmatchningar, så validera både filidentitetslagret och användaridentitetslagret separat.

Gör en första synkronisering medan källan är aktiv endast om kopieringsmetoden stöder det och planera därefter en slutlig deltaöverföring efter stopp. Exportera inte båda kopiorna med läs- och skrivåtkomst under samma klientnamnrymd, eftersom skrivningar då kan divergera utan ett tydligt fel.

Pausa klienterna och växla exporten

Stoppa program som skriver, containrar och schemalagda jobb på varje klient och verifiera sedan att ingen viktig process har filer öppna under monteringen. Avmontera klienterna korrekt. Efter den slutliga synkroniseringen avexporterar du källan eller gör den skrivskyddad, växlar serverns montering eller export till målet och läser in exporter på nytt.

En redogörelse från GitLabs ingenjörsteam om ett fall med NFS-namnbyte och inaktuellt tillstånd visar att namnbytes- och delegeringsbeteende kan leda till inaktuella eller inkonsekventa klientobservationer. Det säkra operativa svaret är planerad paus och ommontering, inte upprepade kommandon för att rensa cache medan program fortsätter skriva.

Om målet ändrar filsystemets identitet ska du räkna med nya handtag och montera klienterna på nytt. Behåll den ursprungliga exporten tillgänglig under ett icke-produktionsnamn för återställning, men låt aldrig gamla och nya träd ta emot konkurrerande skrivningar.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

Montera om varje klient och verifiera den nya identiteten

Montera först om en klient som testklient och testa listning, läsning, skapande, namnbyte, borttagning, fillåsning och ägarskap. Starta om dess beroende program och verifiera den ursprungliga arbetsbelastningen. Gå sedan igenom återstående klienter och dokumentera monteringskälla, NFS-version och att inga fel om inaktuella handtag förekommer.

Starta om eller starta om automount på en testklient för att bevisa att den beständiga konfigurationen pekar på den stabila klientnamnrymden. Kontrollera serverloggar, klientkärnor, säkerhetskopieringsjobb och containrar efter dolda gamla sökvägar. En lyckad manuell montering bevisar inte att startordning eller tjänsteberoenden är korrekta.

Avveckla källan först när alla klienter har monterats om, normala jobb fungerar, en säkerhetskopiering har lyckats och en återställning har testats. Rulla tillbaka innan nya skrivningar accepteras om testklienten misslyckas. När skrivningar till målet har börjat ska du stoppa och förena ändringarna medvetet i stället för att växla exporter fram och tillbaka.