Hur många extra enhetsplatser bör ett växande hemmalabb köpa?
För ett växande hemmalabb är två tomma platser för datadiskar bara ett bra standardval när lagringsdesignen faktiskt kan utnyttja dem. En tom plats räcker när nästa planerade utbyggnad är en enskild disk som stöds; två är rimligt när du räknar med två stegvisa tillägg eller en utbyggnad med ett speglat par; noll är rationellt när du i stället planerar att byta ut diskar eller migrera lagringspoolen. Reservera platser utifrån den minsta utbyggnadsenhet som din valda lagringslayout kräver, inte som ett vagt framtidssäkert val.
Skilj mellan en tom utbyggnadsplats och en reservdisk
En oanvänd diskplats är inte samma sak som en reservdisk. En tom plats bevarar en framtida plats för mer kapacitet, en annan pool eller en ny lagringsroll. En kall reservdisk är en ersättningsdisk som förvaras utanför systemet, medan en varm reservdisk upptar en plats men vanligtvis inte ökar den normalt tillgängliga kapaciteten. Om dessa begrepp blandas ihop kan ett chassi med sex platser se mer utbyggbart ut än vad den faktiska layouten tillåter.
ZimaSpaces guide till dimensionering av diskplatser i NAS för familjer visar varför antalet platser bör kopplas till användbar kapacitet och utbyggnad, snarare än enbart hushållets storlek. Ett hemmalabb följer samma princip men har fler lagringsroller, till exempel virtuella maskiner, programdata, säkerhetskopior, media och arbetsutrymme.
Rita upp layouten från dag ett innan du köper. Markera datadiskar, paritets- eller redundansdiskar, SSD-diskar för appar, eventuella varma reservdiskar och genuint oanvända platser. Märk sedan vilka tomma platser som är avsedda för kapacitet och vilka som sparas för en separat framtida pool. Då undviker du att ”sex platser” i praktiken tyst blir fyra användbara dataplatser när resten av designen räknas in.
Om en trasig disk måste ersättas omedelbart bör du köpa ersättningsdisken som en kall reservdisk i stället för att som standard reservera en tom plats för den. Behåll en varm reservdisk endast när fördelen med automatisk återuppbyggnad är värd att permanent förbruka en plats. Utbyggnadsutrymme och ersättning vid fel bör budgeteras separat.
Prognostisera de två nästa lagringstilläggen, inte hela det slutliga labbet
Ett växande hemmalabb behöver inte tillräckligt många tomma platser för varje tjänst du kanske kör om fem år. Det behöver en trovärdig väg genom de närmaste en eller två kapacitetsökningarna. Mät nuvarande användbara lagring, årlig datatillväxt, kvarhållning av ögonblicksbilder eller säkerhetskopior, tillväxten för virtuella maskiner och den punkt där ledigt utrymme börjar bli operativt obekvämt.
ZimaSpaces befintliga tillväxtguide för förstagångsköpare av NAS rekommenderar att du väljer antal platser utifrån nästa uppgradering i stället för ett slutligt drömsystem. Den här artikeln begränsar regeln till beslutet om tomma platser: bevara det antal platser som krävs av nästa kända utbyggnadsenhet.
Om nästa kapacitetssteg kan hanteras genom att ersätta två befintliga diskar med betydligt större diskar och du accepterar arbetet med återuppbyggnad eller migrering, kan det ha begränsat värde att betala för flera oanvända platser nu. Om labbet tillför data kontinuerligt och du vill bygga ut utan att ersätta friska diskar har tomma platser ett tydligare ekonomiskt syfte.
Skriv in två daterade utbyggnadshändelser i planen, till exempel ”lägg till en datadisk när mediapoolen når 70 %” och ”lägg till ett speglat SSD-par när VM-lagringen överstiger den nuvarande poolen”. Om du inte ens kan ange en sannolik händelse är det mindre chassit fortfarande en rationell utgångspunkt.
Kontrollera poolens utbyggnadsenhet innan du räknar tomma platser
En tom fysisk plats är bara användbar när lagringsprogramvaran och redundanslayouten kan integrera den nya disken på det sätt du förväntar dig. Olika plattformar byggs ut på olika sätt, så samma utrymme för en extra disk kan vara värdefullt i ett hemmalabb och oanvändbart i ett annat utan återuppbyggnad eller migrering.
Synology dokumenterar att utbyggnad av SHR har specifika storleksregler för diskar som läggs till i en befintlig pool. Unraid dokumenterar däremot ett arbetsflöde för att lägga till enskilda datadiskar i en array. Det här är exempel på varför ”en reservplats” inte kan bedömas utan att den faktiska lagringsplattformen beaktas.
Även moderna TrueNAS stöder arbetsflöden för RAIDZ-utökning som kan bygga ut en RAIDZ-vdev stegvis. Dess dokumentation om RAIDZ-utökning ger köpare ytterligare ett skäl att kontrollera de aktuella poolreglerna i stället för att förlita sig på äldre antaganden om arrayer med fast bredd.
Översätt den valda topologin till en minsta användbar utbyggnadsenhet. Om den planerade poolen byggs ut med en disk i taget kan en tom plats skapa ett verkligt nästa steg. Om designen kräver att ett speglat par läggs till bör du bevara två platser. Om utbyggnad kräver att poolen ersätts eller återskapas kanske extra fysiska platser inte löser den faktiska migreringsbegränsningen.
Reservera platser för lagringsroller som bör hållas separata
Hemmabland växer ofta ur en enda odifferentierad pool innan de växer ur det totala antalet terabyte. Virtuella maskiner och containrar kan dra nytta av SSD-lagring med låg latens, medan media, säkerhetskopior och arkiv föredrar större HDD-kapacitet. Ett chassi som ser rymligt ut på papperet kan snabbt förlora sitt utbyggnadsutrymme när dessa roller separeras.
ZimaSpaces guide till NVMe-kapacitet för app-pooler hemma förklarar varför bestående programdata förtjänar en egen dimensionering. Om ett särskilt SSD-lager redan ingår i planen ska du inte räkna de enhetsplatserna som framtida utrymme för bulk-lagring.
Lista de lagringsroller som är säkra från dag ett: primärdata, mål för säkerhetskopior, applikationspool, VM-pool, media, övervakning, arbetsutrymme eller testlagring. Kombinera roller endast när deras prestanda- och återställningskrav är kompatibla. I annat fall bör du reservera tillräckligt många enhetsplatser för det separata lager som du redan vet att du kommer att använda.
Det är här två tomma platser ofta blir mer användbara än en. De kan stödja ett framtida parat lager eller två stegvisa datatillägg utan att friska diskar behöver bytas ut direkt. Men om plattformen redan har separata NVMe-platser för applagring kan dessa två HDD-platser vara onödiga för samma ändamål.
Jämför kostnaden för tomma platser med större diskar och framtida migrering
Oanvända platser har en alternativkostnad: ett större chassi kostar mer, tar mer plats och kan uppmuntra till att köpa extra diskar innan de behövs. Alternativet är att börja med färre men större diskar och acceptera diskbyten eller migrering senare. Ingen strategi är alltid billigast, eftersom resultatet beror på datatillväxt, diskpriser, redundans och hur störande en migrering skulle vara.
| Tomma dataplatser | Passar bäst för | Gräns |
|---|---|---|
| 0 | Stabil datamängd; större ersättningsdiskar eller migrering är acceptabla | Tillväxt blir besvärlig om varje utbyggnad kräver att friska diskar byts ut |
| 1 | En stödd utbyggnad med en disk väntas snart | Inte tillräckligt för ett framtida lager som kräver ett par |
| 2 | Två stegvisa tillägg eller en utbyggnad med ett par är redan tänkbara | Kan vara bortkastade om poolen inte kan använda dem oberoende av varandra |
| 3+ | Snabb uppmätt tillväxt, flera pooler eller flera definierade lagringsroller | Överdimensionering när framtida arbetsbelastningar fortfarande är hypotetiska |
Kontrollera också att styrenhet, portar, nätaggregat, kylning och operativsystem stöder de diskar som chassit fysiskt kan rymma. En synlig tom plats är inte användbar framtida kapacitet om resten av plattformen inte kan adressera eller driva den planerade enheten.
Jämförelsen bör därför omfatta kostnaden för oanvänd chassikapacitet i dag mot kostnaden för större ersättningsdiskar, extra återuppbyggnadscykler och en framtida migrering. Betala för tomma platser när de undanröjer en sannolik migrering inom den närmaste tiden, inte bara för att ”fler platser” låter säkrare.
Anpassa chassit efter utbyggnadsgränsen
En ZimaBoard 2 har två inbyggda SATA 3.0-anslutningar, så en tvådiskarskonfiguration som fyller båda från dag ett har avsiktligt inget ledigt utrymme för fler inbyggda SATA-diskar. Det är ett rimligt kompakt val när köparen accepterar att byta ut diskar, migrera senare eller använda en separat utbyggnadsväg i stället för att nu betala för ett större chassi med flera platser.
En ZimaCube 2 Standard passar bättre när sex HDD-platser gör att köparen kan börja med färre installerade diskar och samtidigt bevara en eller två platser för definierade framtida tillägg. Den separata höghastighetsvägen för SSD-utbyggnad gör det också lättare att undvika att använda HDD-platser för tillväxt enbart för att skapa ett applager.
Byt inte från ZimaCube 2 Standard till Pro enbart för att få fler HDD-platser; båda använder samma chassi med sex diskplatser. Pro-nivån är bara rimlig när labbet dessutom har ett uppmätt behov av kraftfullare nätverk, större beräkningsmarginaler eller snabbare aktiv lagring. Enbart fler platser motiverar inte den högre prestandanivån.
Den slutliga regeln är att reservera den minsta användbara utbyggnadsenheten för de närmaste en eller två lagringsförändringarna. Köp noll tomma platser när byte eller migrering är acceptabelt, en när nästa stödda tillägg är en disk, två när ett par eller två stegvisa tillägg är sannolika, och fler endast när snabb tillväxt eller flera lagringsnivåer redan är konkreta. Då kopplas utbyggnadsutrymmet till en verklig plan för hemmalabbet i stället för till obestämd framtidssäkring.
Rekommenderade produkter
Köpguide
Mer att läsa
Så översätter du CPU-, RAM- och IOPS-specifikationer till Plex-prestanda
En köpguide för att omvandla mätningar av Plex-belastning till minimikrav på CPU, RAM, lagring och nätverk utan att köpa mer än nödvändigt.
Så väljer du ut hemservrar för Plex med hjälp av viktade kriterier
En reproducerbar Plex-köpmatris som skiljer obligatoriska krav från preferenser och synliggör osäkerheter före köp.
Vilken support- och uppgraderingslivscykel bör en Plex-server erbjuda?
Ett godkänt-eller-underkänt-ramverk för köp med fokus på Plex-serverstöd, uppdateringshistorik, kompatibilitet, reparerbarhet, kostnader och beredskap för migrering.
