NVMe som arbetslager jämfört med en pool med enbart hårddiskar för virtuella maskinavbildningar och databaser: Vilket ger förutsägbar latens?

Välj en dedikerad NVMe-arbetsnivå när VM-avbildningar och databaser skapar ihållande slumpmässiga läsningar, synkrona skrivningar, ögonblicksbilder eller samtidiga I/O-operationer som får en hårddiskpool att köa förfrågningar. Välj en pool med enbart hårddiskar när de virtuella maskinerna används sparsamt, databaserna är små och ryms i minnet, och kapacitet är viktigare än förutsägbar latens. De flesta lagringstunga hemservrar gynnas av att aktiva och kalla data separeras i stället för att båda tvingas använda samma medieklass.

Börja med lagringsrollen, inte enhetens etikett

En NVMe-arbetsnivå är inte bara en snabbare plats för alla filer. Det är en avsiktligt mindre pool för aktiva virtuella diskar, databasfiler, loggar, index och andra latenskänsliga data. Hårddiskpoolen ansvarar fortfarande för säkerhetskopior, installationsavbildningar, mallar, media, exporter och inaktiva VM-volymer.

En design med enbart hårddiskar håller kapacitet och administration enkel, men kombinerar arbetsbelastningar med mycket olika I/O-beteende. Ett enda säkerhetskopieringsjobb, en borttagning av ögonblicksbilder, en scrub eller en stor medieöverföring kan öka sökbelastningen samtidigt som en databas väntar på små synkrona operationer. Den centrala frågan är om dessa interaktioner märks i applikationens latens.

När en pool med enbart hårddiskar fortfarande räcker

Hårddisklagring kan vara ett rimligt alternativ för ett litet labb med en eller två virtuella maskiner med låg aktivitet, sällsynta starter och databaser vars aktiva sidor ligger kvar i RAM. En virtuell maskin för hemautomation, en testgäst med Linux eller en sparsamt använd tjänst kanske inte genererar tillräckligt många samtidiga slumpmässiga I/O-operationer för att motivera en separat flashnivå.

Alternativet med enbart hårddiskar är också enklare när huvudmålet är kapacitet och ägaren vill ha en skyddad pool, en ögonblicksbildspolicy och en säkerhetskopieringsväg. Att flytta data mellan nivåer skapar ytterligare en klassificeringsuppgift. Om applikationens svarstid redan uppfyller målet under säkerhetskopieringar och scrubbar har den enklare poolen varit det rätta valet.

Detta är den första stoppunkten: lägg inte till NVMe enbart för att VM-avbildningar och databasfiler låter krävande. Lägg till det när lagringsväntan, ködjupet eller svanslatensen ökar under den faktiska tjänstens arbetsbelastning.

Varför VM-avbildningar och databaser kan bryta mot HDD-modellen

Flera virtuella maskiner omvandlar en fysisk lagringspool till många oberoende I/O-strömmar. Gästoperativsystem uppdaterar paket, roterar loggar, växlar minne, genomsöker filsystem och skriver programdata utan att samordna sig med varandra. HDD-läs/skrivhuvuden måste söka mellan dessa förfrågningar, så den genomsnittliga genomströmningen kan verka acceptabel medan enskilda gäster gör uppehåll.

Databaser ställer högre krav. Små slumpmässiga uppslagningar, journaler, skrivningsloggar, index och synkrona bekräftelser bryr sig mer om svarstid än om hastigheten för storskalig överföring. En aktuell jämförelse av lagringsmediers arbetsbelastningar identifierar databaser, virtuella maskiner och containrar som arbetsbelastningar där slumpmässig I/O och latens är viktigare än sekventiell kapacitet.

Jämförelsen bör återigen avbrytas om konkurrens om CPU:n, otillräckligt RAM-minne eller låsningar i programmen fortfarande är den främsta orsaken till fördröjningen efter att den virtuella disken flyttats till NVMe. En arbetsnivå kan inte lösa problem med schemaläggning av beräkningar, minnestryck eller ineffektiva frågor.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Vad NVMe-arbetsnivån förändrar

Den främsta vinsten är isolering. Aktiva VM-diskar och databasfiler konkurrerar inte längre med mediesökningar, säkerhetskopieringsströmmar eller stora arkivskrivningar i samma mekaniska lagringspool. Systemet kan behålla data med hög kapacitet på HDD och reservera flashlagring med låg latens för åtgärder som annars skulle blockera programmets fortsatta körning.

NVMe förkortar också klonings-, ögonblicksbilds-, start-, patchnings- och indexunderhållsuppgifter. Det kan minska tiden som ett hemlabb befinner sig i ett degraderat eller underhållskrävande tillstånd. Melbicoms vägledning om lagringsroller för NVMe och HDD placerar på liknande sätt latenskänsliga virtuella maskiner och OLTP-liknande data på NVMe, samtidigt som HDD behålls för stor kapacitet.

Vinsten är inte obegränsad. En enda NVMe-enhet för konsumentbruk utan redundans kan skapa ett snabbare men känsligare tjänstelager. Termisk strypning, begränsad uthållighet, plötsligt strömavbrott eller en enda trasig enhet kan slå ut flera aktiva tjänster samtidigt.

Återställning och migrering kan vända på prestandavalet

En pool med enbart hårddiskar håller alla VM-data inom samma skydds- och återställningsmodell, men den större kapaciteten kan leda till långa ombyggnads- och återställningsfönster. En pool som har drabbats av fel kan påverka aktiva gäster, säkerhetskopior, mallar och arkiv samtidigt eftersom de delar samma lagringsgräns.

Ett separat NVMe-lager begränsar den aktiva datamängden, vilket kan göra replikering och återställning snabbare. Det kräver också att ägaren vet exakt vilka VM-diskar, databaskataloger, loggar och programtillstånd som hör till det lagret. Om endast den virtuella disken skyddas medan en extern databassökväg eller hemlighet finns någon annanstans blir återställningen ofullständig.

Den befintliga ZimaSpace-jämförelsen av lagringstopologi för lagringstunga virtuella maskiner förstärker denna poäng: snabbare lagring är värdefull endast när felhanteringen förblir begriplig och reproducerbar.

Använd fyra mätningar för att avgöra om poolen ska delas upp

1. Registrera lagringsfördröjning och ködjup under normal aktivitet i virtuella maskiner och databaser.
2. Upprepa mätningen under säkerhetskopiering, scrub, borttagning av ögonblicksbilder och stora filöverföringar.
3. Mät programmets svarstid, inte bara poolens genomströmning eller syntetiska IOPS.
4. Kontrollera om RAM-minnet redan innehåller de aktiva databassidorna och filsystemets cache.
5. Flytta en representativ VM eller databaskopia till NVMe och upprepa samma arbetsbelastning.
6. Bekräfta att förbättringen fortfarande är märkbar efter att begränsningar i processor, minne och nätverk har beaktats.
7. Beräkna den skyddade NVMe-kapacitet som behövs för aktiva data samt ögonblicksbilder och tillväxt.

ZimaSpace-guiden till NAS-arbetsbelastningar som drar nytta av NVMe innehåller det kompletterande medietestet. Den här artikeln har ett snävare fokus: om dessa aktiva arbetsbelastningar motiverar ett separat lager i stället för att ligga kvar i en pool med enbart hårddiskar.

Vilken lagringslayout passar servern?

Välj en NVMe-arbetsnivå när

Välj NVMe när flera VM:er eller databaser uppvisar tydlig lagringsväntan, bakgrundsarbete på HDD orsakar pauser eller ögonblicksbilder och kloner stör aktiva tjänster. Skydda nivån med lämplig redundans eller replikering och lämna tillräckligt med ledigt utrymme för ögonblicksbilder, databasens tillväxt och underhåll.

Välj en pool med enbart HDD när

Välj en HDD-pool när gästerna används sparsamt, svarstiden förblir acceptabel under underhåll och enkel kapacitetshantering är huvudmålet. Investera först i RAM, säkerhetskopior och en genomtänkt poolayout om mätningar inte visar en arbetsbelastning som är känslig för flashlagring.

Använd en hybridlayout när

För de flesta växande hemservrar bör aktiva VM-diskar, databasfiler, index och loggar ligga på skyddad NVMe. Behåll säkerhetskopior, mallar, ISO-avbildningar, exporter, media och inaktiva VM-volymer på HDD. Definiera migreringsregler så att en arbetsbelastning flyttas mellan nivåer för att dess beteende har förändrats, inte för att ett mappnamn låter viktigt.

Vanliga frågor

Bör alla VM:er ligga på NVMe?

Nej. Infrastruktur-gäster som sällan skriver, avstängda mallar, testapplikationer och kalla virtuella diskar kan ligga kvar på HDD. Prioritera de gäster vars lagringsväntan påverkar en verklig tjänst eller flera beroende applikationer.

Kan SSD-cache ersätta en dedikerad NVMe-nivå?

Ibland, när de aktiva blocken återkommer på ett förutsägbart sätt och cachen förblir varm. En dedikerad nivå är mer deterministisk för VM-diskar och databasfiler som alltid måste få flash-latens, även efter omstart eller förändringar i arbetsbelastningen.

Behöver en databas alltid NVMe?

Nej. En liten databas med en arbetsmängd som ryms i minnet och låg skrivfrekvens kan fungera bra på HDD. NVMe blir värdefullt när lagringsväntetider uppstår vid commits, loggskrivningar, indexaktivitet, kontrollpunkter eller samtidiga förfrågningar.

Slutligt omdöme

Använd en NVMe-arbetsnivå när VM-avbildningar och databaser skapar mätbara köer för slumpmässig I/O eller latensspikar i HDD-poolen. Behåll en lösning med enbart HDD när tjänsterna förblir lätta och enkel kapacitetshantering är viktigare än lägre latens. Den starkaste långsiktiga layouten separerar aktivt applikationstillstånd från bulk lagring och ger båda nivåerna oberoende skydds- och återställningsplaner.