Så konfigurerar du lagringscachar för virtuella maskiner på en NAS-datalagring hemma

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.

How to Configure VM Storage Caches for a Home NAS Datastore - Zima Store Online

Använd cache=none eller I/O-vänliga standardvärden utan direktcachning som utgångspunkt, och ändra sedan endast när gästens, värdens och NAS:ens hållbarhetssökväg är förstådd.

Beslutet är viktigt när VM-diskar ligger på NFS, iSCSI, ZFS eller en annan NAS-baserad datalagring och värden annars kan cachelagra skrivningar två gånger. De två konkurrerande tillstånden är säker cachelagring på värd och gäst samt duplicerad eller osäker skrivcachelagring. Börja med en sparad konfiguration och data som kan kastas, observera en gren i taget och avbryt om testet ökar risken för dataförlust, behörighetsproblem eller otillgänglighet.

Ange en säker baslinje för cachelägen för VM-lagring

Dokumentera miljön innan du ändrar något: programvaru- och firmwareversioner, enhetsidentiteter, monterings- eller nätverkssökväg, ledigt utrymme, behörigheter och det observerbara symptomet. Baslinjen måste innehålla tillräckligt med detaljer för att återskapa situationen där VM-diskar ligger på NFS, iSCSI, ZFS eller en annan NAS-baserad datalagring och värden annars kan cachelagra skrivningar två gånger.

Den första kandidaten är säker cachelagring på värd och gäst. Den andra är duplicerad eller osäker skrivcachelagring. De aktuella Proxmox-cachealternativen för virtuella maskiner definierar mekanismen eller kommandogränsen som används i testet; de ersätter inte observationer från just den här hemservern.

Skriv ned godkännandekriteriet och stoppkriteriet innan du kör särskiljningstestet. Ett godkänt resultat måste ändra de bevis som förutsägs av en gren, samtidigt som orelaterade tjänster förblir oförändrade. Ett underkänt resultat måste återställa systemet till det sparade tillståndet i stället för att utlösa en kedja av spekulativa korrigeringar.

Tillämpa konfigurationen i reversibla steg

Använd detta särskiljningstest: kör samma synkrona skriv- och återställningstest med ett cacheläge i taget. Håll arbetsbelastning, klient, sökväg, filuppsättning och tidsintervall konstanta så att resultatet kan hänföras till den ändrade variabeln.

Använd QEMU-cachelägen för att välja det fält som faktiskt kan skilja grenarna åt, och fånga dess tidsstämpel, avslutningsstatus, feltext, enhets- eller ögonblicksbildsidentitet, fördröjning, överförda byte, behörigheter och återställningstillstånd. En lyckad kommandokörning räcker inte när identitet, hållbarhet eller applikationstillstånd är det som testas.

Upprepa testet en gång efter en omstart, återanslutning, ominstallering eller kall cache när den händelsen ingår i det ursprungliga tillståndet. Om den första körningen är destruktiv eller om miljön inte kan återställas, avbryt och återskapa den på en kopia som kan kastas.

scsi0: nas:vm-101-disk-0,cache=none,iothread=1

Tolka gränserna för slutförande och fel

GODKÄNT: fördröjningen förbättras utan att bekräftade skrivningar går förlorade efter en tvingad omstart av gästen. Dokumentera exakt version, identitet och arbetsbelastning för det godkända testet så att slutsatsen förblir villkorad i stället för att bli ett universellt påstående.

UNDERKÄNT: fsync-fördröjningen försämras, värdens RAM-användning växer oförutsägbart eller bekräftade data försvinner. Ett underkänt resultat bevisar inte automatiskt den motsatta grenen när nätverk, minne, behörigheter eller källans konsekvens kan påverka båda. Isolera de gemensamma beroendena innan du går vidare.

UNDANTAG ELLER TVETYDIGT RESULTAT: återställ det senaste läget och verifiera gästens filsystem innan ett nytt försök. Bevara loggarna och kör inte reparations-, rensnings-, förstörings-, ompartitionerings- eller rekursiva ägarändringskommandon förrän en återställningsbar kopia finns.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

Verifiera beständighet under den ursprungliga belastningen

Tillämpa åtgärden som motsvarar den observerade grenen och upprepa sedan det ursprungliga tillståndet i stället för en förenklad ersättning. Beslutet gäller endast när fördröjningen förbättras utan att bekräftade skrivningar går förlorade efter en tvingad omstart av gästen under två cykler eller den relevanta omstarten, viloläget, avbrottet eller belastningsövergången.

Använd Proxmox-säkerhetskopieringslägen för att kontrollera det närmaste beroende arbetsflödet, men behåll den ursprungliga utlösaren oförändrad. Orelaterade datamängder, utdelningar, containrar, användare och återställningspunkter måste behålla sin tidigare åtkomst och tidsåtgång.

Stoppgränsen är uttrycklig: om fsync-fördröjningen försämras, värdens RAM-användning växer oförutsägbart eller bekräftade data försvinner, återgå till den senast verifierade konfigurationen, behåll bevisen och gå vidare till ett djupare plattforms- eller hårdvarutest endast när grenen kan upprepas.

Efter att målresultatet kvarstår, jämför det med tidsgränserna för NFS-montering så att korrigeringen inte flyttar risken till en närliggande tjänst. Ett lyckat måltest med ett nytt fel i säkerhetskopiering, identitet, tidsgräns eller tillgänglighet är fortfarande en misslyckad ändring.

Vanliga frågor

För cachelägen för VM-lagring gäller de återstående sökningarna vanligtvis om writeback är säkert på en UPS-säkrad NAS, om cache=none innebär att ingen cachelagring sker någonstans och om databaser bör använda samma läge som skrivbordsmiljöer. Svaren nedan håller dessa specialfall åtskilda från huvudbeslutet.

Godkännandegränsen ändras inte: fördröjningen förbättras utan att bekräftade skrivningar går förlorade efter en tvingad omstart av gästen. Om ett uppföljande villkor ändrar filsystemet, identiteten, nätverkssökvägen eller applikationsversionen ska du upprepa endast det särskiljningstest som påverkas av ändringen.

Sluta bredda experimentet när fsync-fördröjningen försämras, värdens RAM-användning växer oförutsägbart eller bekräftade data försvinner. Återställ då det senaste läget och verifiera gästens filsystem innan ett nytt försök. Bevara bevisen innan du eskalerar till plattforms-, lagrings- eller hårdvaruansvarig.

Är writeback säkert på en UPS-säkrad NAS?

En UPS minskar risken vid strömavbrott men bevisar inte att varje värd, nätverk, styrenhet och datalager respekterar flush-anrop.

Innebär cache=none att ingen cachelagring sker någonstans?

Nej. Gästen och NAS:en använder fortfarande cachelagring. Det undviker främst ytterligare ett sidcachelager på värden.

Bör databaser använda samma läge som skrivbordsmiljöer?

Inte automatiskt. Databasers dataintegritet och mönster för synkrona skrivningar kräver ett eget återställningstest.

Betrakta ändringen av cachelägen för VM-lagring som slutförd först när fördröjningen förbättras utan att bekräftade skrivningar går förlorade efter en tvingad omstart av gästen. Om fsync-fördröjningen försämras, värdens RAM-användning växer oförutsägbart eller bekräftade data försvinner, återställ det senaste läget och verifiera gästens filsystem innan ett nytt försök. Behåll den tidigare konfigurationen tillgänglig tills resultatet överlever den relevanta omstarten, det relevanta avbrottet eller den relevanta belastningsövergången.