Så omorganiserar du NFS-datauppsättningar utan att ändra de exportsökvägar som klienterna ser
NFS-datamängder kan omorganiseras utan inaktuella klienthandtag när det klientsynliga exportnamnområdet förblir stabilt medan lagringen flyttas bakom den gränsen.
Den förebyggande designen är att skilja sökvägen som klienterna monterar från namnet på den fysiska datamängd som du senare kan ändra. Bygg ett stabilt exportträd, mappa datamängder till det på ett genomtänkt sätt, bevara filsystemets identitet när det är möjligt, töm klienterna innan destruktiva ersättningar och verifiera samma exportsökväg efter övergången. Om servern måste radera och återskapa det bakomliggande filsystemet ska du behandla det som en identitetsändring och planera en samordnad ominmontering av klienterna i stället för att lova osynlig kontinuitet.
Skapa ett stabilt exportnamnområde ovanför datamängderna
Använd en dedikerad NFS-exportrot vars klientsynliga namn inte speglar varje internt ZFS- eller Btrfs-datamängdsnamn. Då kan lagringsadministratörer omorganisera backend-datamängder utan att behöva lära varje klient en ny monteringssökväg.
En diskussion om NFSv4 förklarar hur bind-monteringar skapar stabila exporter under ett medvetet hanterat pseudofilsystem.
Dokumentera klientsökvägen som kompatibilitetskontraktet. Interna datamängdsnamn kan ändras senare, men endast efter att exportlagret har mappats om och testats mot samma sökväg.
Lås exportidentiteten i stället för att förlita dig på upptäcktsordning
Registrera filsystemets UUID, exportsökvägen, NFS-versionen och de explicita fsid-inställningar som används av den aktuella servern. Samma synliga katalognamn räcker inte när NFS-servern identifierar det underliggande filsystemet annorlunda efter en flytt.
SUSE påpekar att NFS identifierar varje exporterat filsystem i stället för att behandla en export som ett enkelt alias för en sökväg.
Använd explicita identifierare endast där din NFS-implementation stöder dem och se till att varje värde är unikt. Kopiera inte ett fsid till två samtidigt exporterade filsystem bara för att få dem att se identiska ut.
Förbered den nya datamängden bakom samma exportsökväg
Skapa eller ta emot ersättningsdatamängden på en tillfällig sökväg på servern, kopiera eller replikera innehållet, verifiera behörigheterna och mappa den sedan till det stabila exportträdet under ett underhållsfönster. Behåll den gamla datamängden tillgänglig för återställning, men inte aktiv med samma exportidentitet.
Ett NFS-exportexempel visar hur monterade underträd kräver medvetna exporter när flera filsystem förekommer under ett NFS-namnområde.
Övergången bör ändra en enda mappning på serversidan, inte klientens monteringsdefinition och datamängdens identitet samtidigt. Då förblir felsökningsunderlaget intakt om det nya trädet är felaktigt.
Töm skrivande klienter innan du ersätter det bakomliggande filsystemet
Stoppa eller pausa tjänster som aktivt skriver via NFS-monteringen och bekräfta sedan att ingen viktig klient har en långvarig filoperation som sträcker sig över övergången. Slutför den sista synkroniseringen först när skrivande tjänster har satts i vänteläge.
IBM beskriver att NFSv4-tillstånd kräver stabil lagring eftersom klienttillstånd är en del av kontinuiteten, inte bara filinnehållet på serversidan.
För en hemmaserver är målet enklare än klustrad redundans: undvik att ändra filidentiteten medan aktiva program använder den. En kort, kontrollerad paus är säkrare än att tvinga databas-, medie- eller säkerhetskopieringsklienter att klara ett aktivt filsystemsbyte.
Vet när en ominmontering av klienten är oundviklig
Om omorganisationen raderar och återskapar filsystemet, återställer en ögonblicksbild som ett nytt filsystem eller ändrar filhandtagsidentiteten på serversidan ska du planera en samordnad avmontering och ominmontering efter att serversökvägen har stabiliserats.
En aktuell felsökningsguide för NFS anger att ändringar av serveridentiteten gör handtag inaktuella och rekommenderar att man kontrollerar serverns stabila identitet när felet återkommer.
Marknadsför inte underhåll som ”utan ominmontering” när den underliggande identiteten faktiskt ändras. Ett dokumenterat ominmonteringsfönster är bättre än att låta program upptäcka ESTALE under normala skrivningar.
Testa klientsökvägen innan du avvecklar den gamla datamängden
Montera exporten från en ny klient och från en befintlig, icke-kritisk klient. Jämför sedan katalogidentitet, behörigheter, representativa läsningar, en reversibel skrivning och programmets förväntade sökväg. Starta om en klient för att bevisa att den beständiga monteringskonfigurationen inte har ändrats.
Ett fall i Arch Linux visade att en stabil NFS-rot förhindrar ESTALE efter ändringar av backend-filsystemet.
Omorganisationen är klar när klienterna fortfarande använder den ursprungliga exporterade sökvägen och den gamla datamängden kan avvecklas utan dolda referenser. Den relaterade ZimaSpace-artikeln om inaktuella handtag efter ett namnbyte på en datamängd är återställningsalternativet om ESTALE redan har uppstått.
Rekommenderade produkter
Support och tips
Mer att läsa
Kan Plex dela ett GPU-kort med en annan Docker-container?
Plex och en annan container kan ofta använda samma GPU, men du måste testa drivrutinsstöd, enhetsmappning, belastningen på videoenheten, minne och återställningsbeteende.
Så avgör du om ett Plex-fel kommer från klienten eller servern
Återskapa samma objekt på en annan klient, jämför sessionsvägen och samla sedan in serverbevis först efter att scope har visat var felet faktiskt finns.
Så konfigurerar du Plex-cache och tillfällig lagring för omkodning
Skydda beständigt Plex-tillstånd genom att placera temporära transkodningsfiler på lämplig lokal lagring och verifiera rensning, ledigt utrymme samt omstartsfunktionssätt.
