Guide för migrering av ZFS-dataset: flytta data utan att ändra sökvägarna till containrarna

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.

ZFS Dataset Migration Guide: Move Data Without Changing Container Paths - Zima Store Online

Det säkra tillvägagångssättet är att behandla replikering, verifiering och atomärt byte av den ursprungliga monteringspunkten med en bevarad återställningsdataset som en serie observerbara kontrollpunkter, inte som ett enda kommando.

På ZFS-dataset som stöder en containerstack för en hemmaserver är den praktiska risken att behöva flytta ett ZFS-dataset samtidigt som bind-monteringssökvägarna som används av containrarna bevaras. Dokumentera den aktuella identiteten och återställningspunkten, börja med den minst ingripande särskiljande kontrollen, tolka godkänt- och underkäntresultat innan du ändrar en annan variabel och avbryt när lagringen blir instabil eller den enda återställningsbara kopian skulle exponeras. Arbetsflödet nedan avslutas först när den ursprungliga arbetsbelastningen fungerar eller bevisläget når en eskaleringsgräns.

Inventera datasetet och sökvägskontraktet

Dokumentera källdatasetet, underordnade dataset, ögonblicksbilder, monteringspunkt, värdet för canmount, krypteringsrot, kvoter, reservationer, ACL-beteende och varje containerbindmontering som hamnar inuti det. Kontraktet är värdsökvägen som containrarna ser; pool- och datasetnamnet kan ändras bakom den sökvägen.

ZFS-replikering kan bevara ögonblicksbilder och egenskaper, så en rekursiv ström kräver en medveten granskning av egenskaper i stället för en blind mottagning. En fristående migrering med ZFS send och receive visar hur send och receive används för intern datasetmigrering och varför målhierarkin bör inspekteras före bytet.

Skapa en aktuell extern säkerhetskopia eller bekräfta en befintlig återställning innan migreringen. Avbryt om källan har dolda underordnade dataset, ett okänt beroende av en krypteringsnyckel eller en monteringspunkt som överlappar ett annat aktivt dataset; sådana förhållanden kan göra att en korrekt ström monteras på fel plats.

Ta emot den första kopian utan att montera den över produktionen

Skapa en rekursiv ögonblicksbild, till exempel zfs snapshot -r oldpool/apps@move-0, och skicka den till ett måldataset som tas emot med montering inaktiverad eller med en tillfällig monteringspunkt. Använd de flaggor som passar dina krav på kryptering och egenskaper; anta inte att en rå krypterad ström och en dekrypterad mottagning har samma nyckelbeteende.

Efter mottagningen jämför du zfs list -r -t filesystem,snapshot och zfs get -r mountpoint,canmount,encryptionroot,quota,reservation på båda träden. En forumdiskussion om replikerade monteringspunktsegenskaper visar varför replikerade monteringspunktsegenskaper kan överraska vid en annars lyckad migrering.

Den första kopian är godkänd när dataset- och ögonblicksbildshierarkin överensstämmer och målet förblir isolerat från produktionssökvägen. Om den monteras över källan eller ändrar filer som syns för containrarna ska du exportera eller avmontera målet och korrigera egenskaperna innan någon inkrementell sändning görs.

Stäng skrivgapet och byt monteringspunkt

Ta ytterligare en ögonblicksbild av källan och skicka den inkrementella skillnaden medan appen fortfarande körs. Inför det slutliga bytet stoppar du alla skrivare, bekräftar att ingen process har öppna filer under bind-monteringssökvägen, tar en slutlig ögonblicksbild och skickar endast den deltat. Håll driftstoppet begränsat till den slutliga synkroniseringen och bytet av sökväg.

Ställ in källan på en monteringspunkt utanför produktion eller canmount=noauto, tilldela sedan den ursprungliga värdsökvägen till målet och montera det. Låt aldrig två dataset göra anspråk på samma monteringspunkt. Starta databasen och de beroende tjänsterna innan applikationens gränssnitt, så att fel pekar på rätt lager.

Om den slutliga sändningen misslyckas monterar du om källan på den ursprungliga sökvägen och startar om stacken; blanda inte nya skrivningar mellan de båda kopiorna. Återställningsvillkoret är uttryckligt: källan förblir intakt och inga produktionsskrivningar accepteras på målet förrän den slutliga strömmen och egenskapskontrollerna har godkänts.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

Validera containrar på den oförändrade sökvägen

Inspektera bindmonteringarna från containerruntime-miljön, öppna representativa filer, skapa och ta bort en temporär fil genom appen och bekräfta ägarskap, ACL:er, utökade attribut och rapportering av ledigt utrymme. Starta om stacken två gånger och verifiera att ZFS monteras innan containrarna startar.

Kör en scrub eller annan kontroll av poolhälsan enligt din underhållsplan, men använd den inte som det enda beviset på en lyckad migrering. Jämför ögonblicksbilds-GUID:er eller ett representativt hashmanifest, återställ ett litet objekt och använd ZimaSpace-testet för att verifiera om ZFS-replikering kan återupptas efter ett avbrott innan källans historik tas ur bruk.

Behåll källan skrivskyddad tills minst en normal säkerhetskopierings- och applikationscykel har lyckats. Ta den ur bruk först när containrarna använder de ursprungliga sökvägarna, schemalagda jobb riktar sig mot det nya datasetet, replikeringen fortsätter från den avsedda historiken och återställning inte längre behövs; annars återställer du monteringspunkten och bevarar båda historikerna.