Lagringslayout först eller NAS-operativsystem först: Vilket beslut bör tas först när du bygger en ny NAS?

Definiera lagringskraven innan du väljer NAS-operativsystem, men fastställ inte en irreversibel poolayout förrän du har kontrollerat att kandidatoperativsystemet uppfyller dessa krav. Börja med datavärde, användbar kapacitet, enhetsstorlekar, redundans, utbyggnad, arbetsbelastning och återställning. Kortlista sedan de operativsystem som stöder den modellen och lås den exakta array-, pool- eller vdev-strukturen i den plattform som du faktiskt kommer att underhålla.

Det verkliga valet är krav först kontra plattform först

”Lagringslayout först” kan betyda två olika saker. Det kan innebära att definiera hur mycket skydd, kapacitet, prestanda och utbyggnad servern behöver, eller att låsa specifika diskar till en spegling, RAIDZ-grupp, paritetsarray eller Btrfs-profil innan operativsystemet har valts. Endast den första tolkningen är konsekvent säker.

”NAS-operativsystem först” kan också betyda antingen att välja en hanteringsmodell som passar ägaren eller att låta ett polerat gränssnitt automatiskt bestämma lagringsarkitekturen. Det första kan vara rationellt; det andra riskerar att man senare upptäcker att den valda plattformen inte kan använda enheter med olika specifikationer, bygga ut på det förväntade sättet eller importera det önskade filsystemet.

Den befintliga jämförelsen på ZimaSpace av CasaOS, ZimaOS och Unraid för blandade enheter visar varför gränssnitt och lagring inte kan separeras helt. Den korrekta ordningen är krav, en kompatibilitetskortlista och därefter implementering.

Börja med data- och felmodellen

Lista vilka data som är oersättliga, vilka som kan laddas ned igen, vilka som ändras ofta och vilka program som inte klarar långa lagringsavbrott. Ett familjearkiv, ett säkerhetskopieringsarkiv, ett mediebibliotek, ett VM-datalager och en lagringspool för NVR-lagring kan använda samma diskar men kräver olika prioriteringar för redundans, ögonblicksbilder och återställning.

OpenZFS dokumenterar att en pool byggs av virtuella enheter på toppnivå vars struktur avgör redundans och feltålighet. Dess vdev-koncept gör planeringskonsekvensen tydlig: ett filsystemnamn beskriver inte skyddsnivån om den underliggande enhetskonfigurationen inte också är definierad.

Välj ett acceptabelt feltillstånd innan du väljer ett varumärkesgränssnitt. Bestäm om en trasig disk får lämna systemet i degraderat tillstånd, om två fel måste kunna tolereras, hur lång tid en återuppbyggnad får ta och om en oberoende säkerhetskopia kan återställa data om själva arrayen går förlorad.

Diskstorlekar och expansion kan tidigt avgöra vilket operativsystem som går bort

En matchad uppsättning nya enheter ger andra valmöjligheter än en samling återanvända diskar på 4 TB, 8 TB och 16 TB. Konventionella speglingar och paritetsgrupper kan offra kapacitet eller kräva gruppvis expansion, medan andra lagringsmodeller är utformade för att stegvis lägga till datadiskar i olika storlekar.

Unraids officiella vägledning för arrayer anger att ingen datadisk får vara större än paritetsdisken och rekommenderar att SSD-enheter reserveras för cachepooler i stället för den primära paritetsarrayen. Det är inte en mindre inställning; det påverkar vilka befintliga enheter som fortfarande är användbara och hur nästa expansion bör genomföras.

Om expansionsplanen säger ”lägg till en inkompatibel enhet när kapaciteten börjar ta slut” bör du välja bort plattformar som kräver att fasta grupper byggs om, såvida ägaren inte accepterar en senare migrering. Om planen säger ”ersätt speglade par med större matchande enheter” kan en lagringsmodell som är optimerad för stegvis expansion med blandade enheter innebära onödig komplexitet.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

NAS-operativsystemet avgör vilka layouter som är inbyggda

När kraven har definierats bör du välja ut operativsystem utifrån de lagringsmodeller som de hanterar inbyggt och synligt. Ett operativsystem kan tekniskt sett stödja ett filsystem utan att ha integrerade aviseringar, arbetsflöden för byte, kapacitetsuppskattningar eller konfigurationsåterställning för det sätt du tänker använda det.

TrueNAS har ett arbetsflöde för att skapa pooler där användaren väljer layout, diskstorlekar, dataenheter och antal vdev-enheter. Den aktuella dokumentationen om hur TrueNAS-pooler skapas visar att plattformen förväntar sig att lagringsarkitekturen färdigställs genom dess stödda ZFS-modell, snarare än att sättas samman oberoende.

Anta inte att installation av ett webbgränssnitt ovanpå Linux gör alla underliggande pooler lika lätthanterliga. Plattformen kanske bara visar lagring som den själv har skapat eller registrerat, medan avancerad återställning fortfarande är beroende av kommandoradsverktygen och dokumentationen för det underliggande filsystemet.

Skapa inte den slutliga poolen innan du har kontrollerat operativsystemets kompatibilitet

En för tidigt skapad pool kan låsa in data i en implementation som det föredragna NAS-operativsystemet inte kan importera, övervaka, utöka eller reparera genom sitt normala arbetsflöde. Även när två system stöder samma filsystemsfamilj kan funktionsflaggor, kryptering, enhetssökvägar, startmiljöer och applikationsdatamängder försvåra migreringen.

OpenMediaVault dokumenterar att filsystem som monteras utanför dess gränssnitt inte automatiskt registreras i backend-databasen för att skapa delade mappar. Dess modell för filsystemsintegration visar varför ”Linux kan montera det” inte är samma sak som att ”NAS-plattformen kan hantera det på ett smidigt sätt”.

Använd lediga diskar eller virtuella diskar för att först prova den tänkta installationen av operativsystemet. Bekräfta skapande av pooler och utdelningar, ögonblicksbilder, aviseringar, byte, utökning, export och import innan du flyttar primärdata. Testet bör validera hanteringsvägen, inte bara bevisa att installationsprogrammet kan se enheterna.

Placering av arbetsbelastningar kommer efter att plattformsgränsen har fastställts

Kravsfasen bör identifiera arbetsbelastningar, men exakt placering bör vänta tills operativsystem och lagringsverktyg har valts. En VM-datamängd, ett metadatalager, en applikationspool, ett tillfälligt nedladdningsutrymme och ett mediearkiv kan behöva olika enheter, men tillgängliga funktioner för nivåindelning och datamängdskontroll varierar mellan plattformar.

Btrfs gör det möjligt att lägga till, ta bort eller ersätta enheter samt konvertera data- och metadataprofiler när det finns tillräckligt med arbetsutrymme. Den officiella dokumentationen om volymhantering visar en mer föränderlig modell än planering med fasta vdev:ar, men denna flexibilitet kräver fortfarande övervakning och kunskap om drift.

ZimaSpace-analysen av NVMe-arbetsnivåer för virtuella maskiner och databaser tillhandahåller arbetsbelastningstestet. Definiera behovet före operativsystemet och implementera sedan nivån med den lagringsmodell som den valda plattformen stöder på ett säkert sätt.

Återställning bör utformas innan något av de slutliga valen görs

En NAS-installation är inte färdig när poolen monteras. Ägaren bör veta hur man installerar om startenheten, återställer NAS-konfigurationen, importerar överlevande lagring, återställer krypteringsnycklar, byter ut en trasig disk och återställer data när poolen inte kan importeras.

Lagringslayouten avgör vad som överlever ett diskfel, medan NAS-operativsystemet avgör hur tydligt det överlevande tillståndet presenteras och hur mycket konfiguration som kan exporteras. En motståndskraftig pool med odokumenterade sökvägar för applikationer kan fortfarande vara svår att återställa; ett välutformat operativsystem kan inte återställa data som endast fanns på en trasig disk utan redundans.

Detta är stoppgränsen: om återställningsplanen är beroende av en funktion som är unik för ett operativsystem måste den plattformen väljas före den slutliga layouten. Om återställningen huvudsakligen bygger på portabla filsystem och deklarativ konfiguration finns fortfarande större flexibilitet i valet av operativsystem.

Använd en urvalsprocess i tre steg

1. Skriv ner kraven på kapacitet, diskförteckning, arbetsbelastning, feltålighet, tillväxt och återställning utan att nämna något operativsystem.
2. Eliminera operativsystem som inte kan stödja dessa krav genom en dokumenterad och underhållbar lagringsmodell.
3. Prototypa de återstående plattformarna med reservdiskar eller virtuella diskar och testa skapande, fel, ersättning, utökning, export och import.
4. Välj det operativsystem vars normala arbetsflöde motsvarar ägarens kunskaper och tolerans för underhåll.
5. Fastställ den exakta layouten för arrayer, pooler, vdev:ar, filsystem, dataset, cache och applikationslagring i den plattformen.
6. Dokumentera designen och återställ den en gång innan du flyttar oersättlig data.

Ordningen förhindrar två vanliga misstag: att välja ett tilltalande gränssnitt som inte kan stödja de planerade enheterna och att bygga en tekniskt elegant pool som det slutliga NAS-operativsystemet inte kan hantera utan metoder som saknar officiellt stöd.

Vilket beslut bör styra?

Låt lagringskraven styra när

Låt kraven styra när enheternas storlekar, redundans, tillväxt eller arbetsbelastningens beteende medför hårda begränsningar. Detta är särskilt viktigt för blandade enheter, stora RAIDZ-grupper, lagring av övervakningsdata, VM-lagring eller system där expansion måste kunna ske utan en fullständig migrering.

Låt NAS-operativsystemets kortlista styra den slutliga layouten när

Låt plattformens kortlista styra implementationen när ägaren värdesätter integrerat byte, aviseringar, applagring, export av konfiguration och vägledd återställning. Välj endast layouter som det valda operativsystemet stöder via sin normala hanteringsväg.

Överväg att ändra hårdvaran när inget av alternativen passar

Ändra enhetsuppsättningen, lägg till ett separat SSD-skikt, dela upp lagring och beräkning eller skjut upp bygget när inget operativsystem kan uppfylla kraven på ett tillförlitligt sätt. Att tvinga fram en inkompatibel kombination skapar framtida migreringsarbete när datan är som svårast att flytta.

Vanliga frågor

Kan man välja NAS-operativsystem innan man köper diskar?

Ja, förutsatt att kraven på arbetsbelastning och expansion redan är kända. Använd dokumentationen för operativsystemet för att fastställa vilka layouter, minsta antal diskar, paritetsstorlekar, SSD-roller, styrenhetskrav och ersättningsprocedurer som stöds innan du köper den slutliga uppsättningen enheter.

Kan samma ZFS-pool flyttas mellan olika NAS-operativsystem?

Ibland, men kompatibiliteten beror på vilka poolfunktioner, kryptering, importbeteende, enhetsåtkomst, systemdatauppsättningar och programkonfigurationer som stöds. Betrakta import mellan plattformar som en testad migreringsväg snarare än som ett antagande.

Bör nybörjare acceptera den föreslagna pool-layouten?

Först efter att du har kontrollerat användbar kapacitet, feltålighet, expansion, arbetsbelastning och säkerhetskopieringskrav. En föreslagen layout kan vara en säker utgångspunkt, men den kan inte känna till datans värde eller ägarens framtida plan för byte av enheter.

Slutligt omdöme

Välj lagringskraven först, inte en helt fastställd lagringsimplementation. Ta sedan fram en kortlista över NAS-operativsystem som stöder dessa krav och fastställ den exakta layouten i den valda plattformen. Denna ordning bevarar arkitektonisk disciplin utan att låtsas att operativsystemet är oberoende av den array, pool, det filsystem, den expansion och de återställningsarbetsflöden som det måste hantera.