Datavolymer växer inte längre linjärt. De exploderar. AI-träningsdata, vektorindex, videoövervakning i 4K, CAD-modeller med hundratals revisioner och backupkedjor som växer för varje ny säkerhetsincident landar till slut i samma verklighet: er lagringsinfrastruktur.
Och just där uppstår ofta problemet. Lagringsplattformen ni använder i dag valdes sannolikt utifrån helt andra krav än de ni står inför nu. Det som fungerade väl för tre till fem år sedan behöver inte vara rätt val när arbetslaster förändras, datamängder växer snabbare och nya AI-initiativ ställer helt andra krav på prestanda, skalbarhet, samtidighet och dataåtkomst.
Det knepiga med lagringsarkitektur är att fel beslut sällan märks direkt. De visar sig i stället gradvis: stigande latens, GPU-resurser som väntar på data, användare som upplever att filåtkomst går trögt, checkpoints som tar för lång tid eller oväntat höga kostnader när molnlagring skalats upp utan tydlig styrning. Rätt arkitektur skapar handlingsutrymme. Fel arkitektur blir ett hinder för nästa steg.
I den här artikeln går vi igenom fyra centrala lagringsmodeller: NAS, SAN, objektlagring och hyperkonvergerad infrastruktur (HCI). Vi tittar på vad de faktiskt är bra på, var deras begränsningar finns och hur beslutsbilden ser ut 2026 när AI-arbetslaster förändrar kraven på lagring.
Grunderna: vad skiljer de olika lagringsmodellerna åt?
Innan vi går in på användningsområden och beslutskriterier behöver vi ha en gemensam bild av vad de olika arkitekturerna faktiskt gör, och hur de exponerar data mot servrar och applikationer.
NAS, Network Attached Storage
NAS är filbaserad lagring som nås via nätverket, vanligtvis via NFS i Linux- och Unix-miljöer och SMB i Windows-miljöer. En NAS presenterar data som filer och kataloger, vilket gör den naturlig för miljöer där många användare eller system behöver komma åt samma delade innehåll samtidigt. SMB är den moderna termen här. CIFS används fortfarande ibland i vardagligt språk, men är egentligen ett äldre SMB-begrepp.
Den traditionella NAS-modellen är ofta en scale-up-arkitektur, där kapacitet och prestanda växer inom ramen för ett begränsat system. Modern scale-out NAS bygger i stället på flera noder som tillsammans kan ge högre kapacitet och bättre throughput. Det gör NAS till ett mycket relevant val för klassisk fildelning, samarbetsytor, projektfiler och annan ostrukturerad data.
Samtidigt finns det begränsningar. Många klassiska NAS-arkitekturer är byggda för bred kompatibilitet och enkel filåtkomst, inte för extrem småfilsparallellism, mycket hög metadataintensitet eller GPU-kluster som läser enorma datamängder med mycket hög samtidighet. Det betyder inte att NAS är ”fel” för AI, men det betyder att klassisk enterprise-NAS ofta får problem när arbetslasten skiftar från användardriven filåtkomst till massiv parallell datamatning.
Styrkor:
Enkel att förstå och drifta, brett stöd i operativsystem och applikationer, kostnadseffektiv för delade filer och ostrukturerad data.
Begränsningar:
Kan bli en flaskhals vid mycket hög samtidighet, småfilsintensiva arbetslaster eller när både metadatahantering och throughput måste skala aggressivt.
SAN, Storage Area Network
SAN är blockbaserad lagring som levereras över ett separat lagringsnätverk eller via dedikerad blockåtkomst. Servrar ser SAN-lagring som lokala diskar och lägger själva filsystem ovanpå, exempelvis NTFS, XFS eller VMFS.
Vanliga tekniker inom SAN är Fibre Channel, iSCSI och i mer moderna miljöer NVMe over Fabrics. Det här gör SAN särskilt attraktivt för arbetslaster där låg och förutsägbar latens är viktig, till exempel databaser, virtualisering och transaktionstunga applikationer. NVMe-oF finns just för att föra ut NVMe-liknande blockåtkomst över nätverk med låg latens och hög parallellism.
Eftersom SAN arbetar på blocknivå är det inte ett naturligt val för delad filåtkomst mellan många användare, men det kan leverera mycket hög IOPS och låg latens i rätt design. För databaser, journaling-intensiva arbetslaster, VM-datastores och system där konsistens och svarstider måste vara förutsägbara är block ofta fortfarande det mest rationella valet.
Styrkor:
Mycket låg latens, hög IOPS, bra för databaser, virtualisering och andra affärskritiska arbetslaster med tydliga prestandakrav.
Begränsningar:
Högre komplexitet, särskilt i Fibre Channel-miljöer, mindre naturligt för delad filåtkomst och ofta högre krav på specialistkompetens.
Objektlagring
Objektlagring skiljer sig från både fil- och blocklagring. Här lagras data som objekt, där varje objekt består av själva datan, ett unikt ID och metadata. I stället för en traditionell katalogstruktur används en platt namespace, och åtkomsten sker vanligtvis via HTTP-baserade API:er, ofta med S3-kompatibilitet.
Objektlagring är inte primärt byggd för låg latens, utan för massiv skala, hållbarhet och kostnadseffektiv lagring av stora datamängder. Den används därför ofta för backup, arkiv, datalakes, mediebibliotek och moderna applikationer som är byggda för objektbaserad åtkomst.
Objektlagring lämpar sig mindre väl för arbetslaster som kräver traditionell filsemantik eller mycket snabb, finmaskig och transaktionell I/O. Men i AI-sammanhang får objektlagring en allt viktigare roll som ingest-lager, träningsdataarkiv och del av multimodala datapipelines, särskilt när data kommer in som filer, bilder, video eller loggströmmar från många källor samtidigt.
Styrkor:
Mycket god skalbarhet, låg kostnad per TB, stark hållbarhet, passar väl för backup, arkiv och stora datamängder.
Begränsningar:
Högre latens än blocklagring och många filsystem, kräver applikationsstöd eller integrationslager, inte optimalt för klassiska filarbetslaster eller latency-kritiska transaktioner.
Hyperkonvergerad infrastruktur, HCI
HCI är inte i första hand en egen lagringstyp, utan en arkitektur där compute och lagring kombineras i samma kluster. Ett mjukvarudefinierat lager distribuerar sedan data över noderna, vilket förenklar design, drift och skalning.
Två av de mest etablerade plattformarna inom området är Nutanix och VMware vSAN. HCI passar ofta mycket bra i virtualiserade miljöer där enkelhet, snabb driftsättning och enhetlig hantering väger tungt. VMwares vSAN-dokumentation speglar också den klassiska HCI-logiken: lagringskapacitet och driftmodell knyts nära klustrets värdnoder, även om det numera finns varianter som försöker bryta upp detta.
Utmaningen är att kapacitet och beräkningskraft i många fall växer tillsammans. Om behovet främst är mer lagring kan det innebära att man också behöver köpa CPU och minne som egentligen inte efterfrågas. För klassisk virtualisering kan det vara ett acceptabelt pris för enkelhet. För lagringstunga eller AI-tunga miljöer kan det bli ekonomiskt skevt.
Styrkor:
Enkel drift, snabb implementation, färre separata infrastrukturlager och ofta en tydlig operationsmodell.
Begränsningar:
Kopplad skalning mellan compute och lagring kan påverka kostnadsbilden i lagringstunga miljöer.
Vad passar till vad?
Olika lagringsarkitekturer är bra på olika saker. Det viktigaste är därför inte att välja den ”modernaste” plattformen, utan den som bäst matchar arbetslast, tillväxt och driftmodell.
Databaser och affärskritiska applikationer
För ERP, SQL-databaser, transaktionssystem och virtualiserade produktionsmiljöer är blocklagring via SAN ofta det naturliga valet. Här är förutsägbar latens, hög IOPS och stabil prestanda viktigare än delad filåtkomst eller extrem skala i antal filer.
Det här är också ett område där moderna all-flash-arrayer fortfarande är mycket starka. De ger inte bara låg latens utan också snapshot-, replikations- och failover-funktioner som är centrala i verksamhetskritisk drift.
Fildelning, CAD och samarbetsytor
För delade filer, projektkataloger, användarhemkataloger, CAD-miljöer och medieproduktion är NAS ofta rätt väg. Filprotokoll som NFS och SMB är etablerade, välstödda och naturliga för arbetslaster där flera användare eller system behöver arbeta mot samma innehåll.
Modern scale-out NAS kan dessutom hantera mycket stora volymer data och mycket stora filbestånd. Men när många klienter gör små, intensiva metadataoperationer samtidigt, eller när datasetet ska matas till många GPU-processer parallellt, räcker inte alltid klassisk enterprise-NAS till.
Backup, arkiv och långtidsbevarande
För backup, arkiv, datalakes och längre retentionstider är objektlagring ofta mycket attraktivt. Särskilt när man vill kombinera skala, kostnadseffektivitet och funktioner som immutability eller WORM-liknande skydd. Pure beskriver exempelvis immutabla SafeMode-snapshots som ett skydd där ransomware inte kan radera, modifiera eller kryptera snapshotkopiorna. Samma tänk återkommer brett i moderna cyberresilience-arkitekturer.
Det är dock viktigt att skilja mellan teknisk möjlighet att lagra länge och faktisk regelstyrning. För personuppgifter måste retention alltid styras av verksamhetskrav, gallringsregler och tillämpliga dataskyddskrav.
Virtualiserade standardmiljöer
För många företag som vill förenkla sin infrastruktur och minska antalet separata system kan HCI vara ett starkt alternativ, särskilt i klassiska virtualiseringsmiljöer med blandade arbetslaster och behov av enkel drift.
AI förändrar spelplanen
Det är när AI kommer in i bilden som många traditionella antaganden om lagring börjar skaka.
AI-arbetslaster skiljer sig ofta från klassisk IT på tre sätt:
de kräver mer throughput, högre samtidighet och betydligt bättre hantering av metadata och små filer.
När GPU-resurser väntar på data
Moderna GPU-kluster ställer mycket höga krav på hur snabbt data kan läsas in, matas vidare och tillgängliggöras parallellt. NVIDIA:s GPUDirect Storage-ekosystem finns just för att minska CPU-overhead i datapathen och skapa en mer direkt väg mellan lagring och GPU-minne. NVIDIA:s release notes listar stöd för bland annat WEKA och VAST, vilket är ett tydligt tecken på att dessa plattformar används i miljöer där klassisk CPU-medierad I/O blir en begränsning.
Det betyder inte att all AI kräver specialiserad lagring, men det betyder att lagringsdesignen får en mycket mer direkt påverkan på faktisk nyttjandegrad och ekonomi. När GPU-kluster kostar stora pengar per timme blir väntetid på data inte ett tekniskt irritationsmoment utan en affärskostnad.
Metadata blir plötsligt en huvudfråga
Många AI- och HPC-arbetslaster arbetar med mycket stora mängder små filer eller ett mycket stort antal samtidiga filoperationer. Det gör att metadatahantering blir lika viktig som rå throughput.
Många klassiska scale-up-arkitekturer fungerar utmärkt för traditionell filåtkomst, men kan få det kämpigt när mycket stora småfilsmiljöer och hög parallellism möts. Det är också här moderna parallella filplattformar försöker skilja ut sig: inte bara genom fler diskhyllor eller snabbare nätverk, utan genom att distribuera metadatahantering bredare i arkitekturen. WEKA beskriver till exempel en arkitektur där data- och metadata-tjänster distribueras över systemets resurser, i stället för att koncentreras till en separat metadataflaskhals.
Checkpointing ställer egna krav
Vid AI-träning sparas ofta regelbundet checkpoints för att det ska gå att återuppta träning efter avbrott eller fel. Det skapar korta perioder med mycket intensiv skrivbelastning, ibland parallellt med höga läskrav under träning eller inferens.
Det gör att AI-lagring inte bara handlar om hög prestanda i största allmänhet, utan om att klara mycket specifika mönster av läsning, skrivning och samtidighet. Det är därför diskussionen i dag ofta handlar mindre om ”hur många TB” och mer om kombinationen av metadata IOPS, parallell läsning, nätverksdesign, snapshotmekanik och protokollflexibilitet.
Moderna plattformar för dataintensiva miljöer
Här blir det intressant på riktigt. För tekniskt kunniga organisationer räcker det inte att veta att en plattform är ”snabb”. Frågan är varför den är snabb, hur den skalar och vilka kompromisser som byggts bort eller bara flyttats.
VAST Data: disaggregated shared-everything med en gemensam namespace
VAST:s mest centrala arkitekturidé är DASE, Disaggregated Shared-Everything Architecture. Den bygger på att lagringsmedia separeras från de CPU-resurser som levererar lagringstjänster. Kapacitet och prestanda kan därmed skalas oberoende av varandra genom att man lägger till enclosures för kapacitet och servrar för prestanda. Det är en konkret teknisk fördel i miljöer där traditionell scale-out annars riskerar att dra med sig onödiga CPU-resurser varje gång lagringsvolymen ökar.
Det andra stora värdet i VAST är den gemensamma namespace-modellen. VAST beskriver en global namespace inom klustret och även vidare mellan kluster via DataSpace. Poängen är inte bara att ”allt syns på ett ställe”, utan att samma dataset kan exponeras över flera protokoll utan att man bygger separata datasilos. Officiell dokumentation beskriver stöd för NFS, SMB och S3, och VAST lyfter även stöd för GPUDirect Storage i AI-sammanhang. Det gör plattformen intressant när data exempelvis ska landa via S3, preprocessas via filprotokoll och sedan användas av GPU-arbetslaster utan att kopieras mellan separata system.
En tredje tekniskt viktig egenskap är hur snapshots och metadata hanteras. VAST:s white paper beskriver snapshotmekanik som är djupt integrerad i metadata-strukturen i stället för att byggas som tunga, separata operationer ovanpå systemet. VAST lyfter också mycket hög snapshotskala per kluster och fin granularitet i hur snapshots kan tas. Det är relevant i praktiken eftersom snapshots då inte bara blir ett backupverktyg utan en byggsten för replication, test/dev, återställning och datapipelines.
För tekniska team är den verkliga poängen med VAST alltså inte bara ”AI-lagring”, utan kombinationen av:
- Disaggregation mellan kapacitet och prestanda
- Multiprotokoll mot en gemensam namespace
- Metadata- och snapshotarkitektur som är designad för stor skala
- Möjlighet att undvika dataförflyttning mellan olika åtkomstmodeller
Det gör VAST särskilt intressant för AI-fabriker, dataplattformar, medieproduktion, backupkonsolidering och miljöer där många olika arbetslaster ska dela samma datafundament.
WEKA: distribuerad metadata, parallell filåtkomst och tiering mot objekt
WEKA:s styrka ligger i att plattformen är byggd för högpresterande parallell filåtkomst där både data och metadata distribueras över klustret. I deras arkitekturmaterial beskriver de en modell där metadata inte vilar på en isolerad central tjänst, utan där metadata- och datatjänster sprids över systemets resurser. Det är just detta som gör WEKA intressant i småfilsintensiva miljöer och i AI/HPC-scenarier där många klienter öppnar, läser och skriver samtidigt.
WEKA har också en tydlig operativ styrka i att plattformen kan användas via flera åtkomstsätt. Officiell dokumentation beskriver stöd och överväganden för POSIX, NFS, SMB och S3 mot samma filsystemdata. För team som kör blandade miljöer, till exempel Linux-baserad träning, Windows-baserade arbetsflöden och S3-baserade pipelines, är detta en praktisk styrka snarare än ett marknadsord.
En annan verifierad styrka är tiering och snapshots mot objektlagring. WEKA-dokumentationen beskriver objektbutiker som används för tiering och snapshots, vilket gör att heta dataset kan ligga i högpresterande lagring medan kallare data eller snapshotdata kan flyttas till billigare objektlager. Det här är en av de mer intressanta egenskaperna i verkliga AI-miljöer, eftersom träningsdataset sällan är homogena. Vissa delar
finnas tillgängliga för senare iterationer, återträning eller revision.
WEKA har dessutom en tydlig position i NVIDIA-ekosystemet. NVIDIA:s GPUDirect Storage-material nämner WekaFS som stödd plattform. Det är tekniskt viktigt eftersom GDS minskar antalet kopieringssteg via CPU-minne och därmed hjälper till att reducera datapath-overhead mellan lagring och GPU. För GPU-tunga tränings- och inferensmiljöer är det en mycket konkret fördel.
För tekniskt kunniga läsare är WEKA därför mest intressant i scenarier där man behöver:
- mycket hög metadata- och småfilsprestanda
- parallell filåtkomst till GPU- eller HPC-kluster
- multiprotokoll i samma plattform
- hybridarkitektur där aktiv data ligger snabbt och kallare data tieras till objekt
Det är mindre en ”modern NAS” och mer en data plane för arbetslaster där klassisk NAS eller traditionella parallella filsystem börjar knaka.
Pure Storage: stark blockgrund, modern cyberresiliens och växande AI-relevans
Pure bör egentligen förstås i två spår: FlashArray för blockcentriska, verksamhetskritiska arbetslaster och FlashBlade för fil, objekt och dataintensiva plattformar.
På blocksidan är Pures stora tekniska styrka inte bara låg latens utan kombinationen av enkel drift, stark snapshotmekanik, hög tillgänglighet och replikationsfunktioner. Pure dokumenterar exempelvis ActiveCluster som en symmetrisk active/active-lösning med synkron replikering för RPO 0 och automatisk failover i rätt design. För verksamhetskritiska databaser, VMware-miljöer och andra blocktunga plattformar är det här mycket mer relevant än generella superlativ om prestanda.
Cyberresiliens är ett annat område där Pure har tydligt verifierade styrkor. SafeMode-snapshots beskrivs av Pure som immutabla snapshots som inte kan raderas, modifieras eller krypteras av ransomware. Det gör att snapshotlagret får en mycket viktig roll i återställningsstrategin, särskilt i miljöer där lagringen bär både primärdata och kritiska VM- eller databasvolymer.
På fil- och objektsidan handlar Pure framför allt om FlashBlade. Pure beskriver FlashBlade som en plattform för Unified Fast File and Object, med stöd för fil- och objektåtkomst i samma system. Det är en relevant styrka i organisationer som vill undvika att bygga separata silos för fil, S3 och analysdata. Pure lyfter också FlashBlade som en skala-ut-arkitektur för AI, HPC, analytics, modern apps och backup.
Det som gör Pure särskilt relevant i AI-sammanhang är att FlashBlade har NVIDIA-certifieringar och referensarkitekturer kopplade till DGX SuperPOD och närliggande AI-designs. Pures officiella material beskriver certifiering för DGX SuperPOD, och NVIDIA:s planeringsmaterial betonar att certifierad lagring ska kunna leverera den prestanda som krävs för att mata GPU-noder i enterprise-AI-arkitekturer. Pure lyfter även GDS-readiness och vidareutveckling mot AI-optimerad objektåtkomst, inklusive S3 over RDMA i FlashBlade-spåret.
Det innebär att Pure i praktiken ofta är starkast i två typer av arkitekturer:
- när blocklagring för verksamhetskritiska system måste vara väldigt enkel att drifta, robust och återställningsbar
- när fil- och objektdata behöver samlas i en snabbare, mer AI-relevant plattform än klassisk NAS eller traditionell backupstorage
Pure är däremot inte samma sak som WEKA eller VAST arkitektoniskt. Där VAST fokuserar på disaggregated shared-everything och där WEKA fokuserar på distribuerad parallell filprestanda, kommer Pure ofta in med styrkor kring blockmognad, operativ enkelhet, snapshot/cyberresiliens och en konsoliderad fil-/objektplattform med NVIDIA-nära validering.
Fem frågor som bör styra ert val
Det finns ingen universallösning. Rätt lagringsarkitektur beror på vilka krav som faktiskt gäller i er miljö.
- Hur känsliga är era arbetslaster för latens?
Behöver ni mycket låg och förutsägbar latens, eller räcker det med god generell prestanda?
- Hur ser åtkomstmönstret ut?
Är det blocktransaktioner, delad filåtkomst, objektbaserade API-anrop eller massiv parallell dataåtkomst?
- Hur behöver ni skala?
Är det främst kapacitet, prestanda eller båda två? Måste de kunna växa oberoende av varandra?
- Har ni homogena eller blandade arbetslaster?
En isolerad databas, ett virtuellt standardkluster och en AI-miljö kräver sällan exakt samma lagringsmodell.
- Hur mycket komplexitet vill ni bära själva?
Det tekniskt mest kraftfulla alternativet är inte alltid det bästa om driftmodellen inte passar organisationens kompetens eller bemanning.
En pragmatisk strategi för 2026
För många verksamheter är det bästa svaret inte att välja en enda lagringstyp, utan att kombinera flera.
En vanlig och sund modell kan se ut så här:
- Tier 0, ultra-snabb blocklagring
För de mest kritiska databaserna och de arbetslaster där latens verkligen är affärskritisk.
- Tier 1, högpresterande aktiv lagring
För AI-data, inferens, analys och andra aktiva applikationer med höga krav på throughput, samtidighet och metadatahantering.
- Tier 2, filbaserad standardlagring
För daglig fildelning, projektdata, CAD och användarnära arbetslaster.
- Tier 3, objektlagring för backup och arkiv
För retention, återställning, datalake-scenarier och långtidsbevarande där kostnad per TB spelar stor roll.
Var bör ni börja?
Innan ni går in i en upphandling eller en större omdesign av er lagringsmiljö finns det tre frågor som nästan alltid är viktigare än själva produktvalet:
- Vad är vår verkliga I/O-profil?
Mät i stället för att gissa. Många miljöer är överdimensionerade på ett område och underdimensionerade på ett annat.
- Hur ser tillväxten faktiskt ut?
Inte bara i TB, utan i antal filer, samtidighet, protokollkrav, snapshotvolym och nya typer av arbetslaster.
- Vilka arbetslaster är på väg in?
Planera inte bara för det ni kör i dag. Titta på vad verksamheten vill kunna göra inom de kommande tre till fem åren.
Rätt lagringsarkitektur börjar i verkligheten, inte i produktbladet
Lagring har länge betraktats som en ganska statisk del av infrastrukturen. 2026 är det inte längre hållbart. När AI, analys, backup, filer, virtualisering och regulatoriska krav möts blir lagringsarkitekturen en strategisk fråga.
NAS är fortfarande rätt val i många miljöer. SAN är fortfarande avgörande för andra. Objektlagring är ofta överlägset för backup och arkiv. HCI kan vara exakt rätt väg för den som vill förenkla sin driftmodell. Men allt oftare behöver organisationer tänka i flera lager samtidigt.
Det viktigaste är inte att välja den mest avancerade plattformen. Det viktigaste är att välja en arkitektur som matchar era arbetslaster, er tillväxt och ert sätt att arbeta.
Aixia genomför tekniska workshops där vi kartlägger nuläge, arbetslaster och målbild för att kunna ge konkreta rekommendationer baserade på verkliga behov.
Kontakta oss för en teknisk dialog om vilken lagringsarkitektur som faktiskt passar er miljö.
