SAN vs S2D vs Azure Local: storage-keuze voor Hyper-V in 2026

1. De architecturen in vogelvlucht

SAN-attached Hyper-V. Klassiek model met aparte compute- en storage-lagen. Een dedicated storage-array (Dell PowerStore, HPE Alletra, NetApp AFF, Pure Storage, IBM FlashSystem, of een vergelijkbaar product) levert block-storage via Fibre Channel, iSCSI of Shared SAS. Hyper-V hosts zien de LUN's als CSV's. Compute en storage schalen onafhankelijk.

Storage Spaces Direct (S2D). Hyperconverged op Windows Server 2019, 2022 of 2025. Lokale NVMe of SSD per node, samengevoegd over RDMA-netwerk tot een gedeelde storage-pool. Geen externe array nodig, compute en storage schalen samen per node.

Azure Local. Microsofts hybride platform (voorheen Azure Stack HCI), beheerd vanuit Azure, gelicenseerd per fysieke core via een Azure-subscription, en geïntegreerd met Azure-diensten zoals Site Recovery en Update Manager. Het begon strikt hyperconverged op S2D. Sinds 2026 kan het ook een externe SAN gebruiken, naast S2D of in plaats daarvan (zie paragraaf 2). Zie Azure Local migratie readiness checklist voor de volledige aanvliegroute.

Op hardware-niveau zit het verschil tussen S2D op Windows Server en hyperconverged Azure Local in de Solutions Catalog en de licentievorm, niet in fundamentele architectuur. Maar operationeel zijn het twee verschillende producten met verschillende toolchains.

Daarom dekt een driedeling het niet meer. In 2026 beantwoord je twee vragen. Waar staat de data, op een array of op lokale disks in de nodes? En welk platform draait op de hosts, Windows Server of Azure Local? Elke combinatie van die twee antwoorden bestaat nu als ondersteunde optie.

2. Wat er in 2026 veranderde: Azure Local op SAN

Ondersteuning voor externe SAN ging in november 2025 in public preview. Release 2604 (april 2026) maakte Fibre Channel generally available, samen met clusters die alleen op SAN draaien. Release 2605 voegde iSCSI toe als preview, en release 2607 (juli 2026) maakte ook iSCSI generally available. Sinds mei 2026 kan Azure Migrate bovendien VM's migreren naar Azure Local-omgevingen die SAN-storage gebruiken.

Twee deployment-modellen:

• Hybride. Een hyperconverged cluster met S2D dat daarnaast SAN-LUN's als Cluster Shared Volumes gebruikt. Je registreert elke SAN-CSV als storage path in de Azure portal en kiest per VM waar die staat. Dit kan ook achteraf bij een cluster dat al draait.
• Disaggregated. Geen lokale storage-pool, alleen SAN. Compute en storage schalen onafhankelijk, en één omgeving kan groeien van één machine tot 64, ruim voorbij de grens van 16 nodes van hyperconverged Azure Local.

Ondersteunde arrays. Microsoft publiceert een lijst met ondersteunde SAN-oplossingen: Dell PowerStore T en Q (PowerStoreOS 3.0 of later), Everpure (voorheen Pure Storage) FlashArray X, C, XL, E en RC20, de Hitachi VSP One- en VSP-families, HPE Alletra MP 10000, Lenovo ThinkSystem DS, DM en DG, en NetApp ONTAP-systemen zoals AFF en ASA, allemaal via FC of iSCSI. Dell PowerFlex wordt apart ondersteund via een eigen software-initiator. Sinds 2607 faalt de deployment-validatie van een disaggregated cluster op een array van een niet-ondersteunde vendor. Een oudere array die niet op de lijst staat, is dus geen kandidaat voor Azure Local, hoe goed hij vandaag ook draait.

De regels die erbij horen:

• Alleen block-storage, via FC of iSCSI. CSV's op SAN moeten NTFS zijn; ReFS wordt op SAN-volumes niet ondersteund.
• Elke LUN is zichtbaar op elke node, met identieke HBA-configuratie en zoning op alle nodes. Een LUN hoort bij één CSV en wordt niet gedeeld met een ander cluster.
• MPIO staat vanaf 2604 standaard aan, met Round Robin als standaardbeleid, en moet op elke node identiek zijn ingesteld. Sommige vendors schrijven eigen timerwaarden voor.
• iSCSI in een hybride cluster vraagt eigen fysieke poorten. Virtuele NIC's worden niet ondersteund, en de iSCSI-adapters blijven buiten Network ATC.
• Rack aware clustering wordt niet ondersteund in combinatie met externe SAN bij hyperconverged deployments.

De prijs. Azure Local kent nu prijsniveaus. L1 geldt voor hyperconverged clusters op lokale storage tot 16 nodes. L2 geldt zodra een cluster externe SAN-storage gebruikt, hybride of disaggregated, of bij een multi-rack deployment. L3 is voor disconnected operations. Tegen de lijstprijzen van juni 2026 is dat 10 dollar per fysieke core per maand voor L1 en 20,10 dollar voor L2. Voeg je SAN toe aan een bestaand cluster, dan start een proefperiode van 30 dagen, waarna het hele cluster op L2 wordt afgerekend. Kortingen in je contract veranderen de bedragen, niet de verhouding.

Wat dit betekent voor de keuze. Een bestaande SAN-investering is geen reden meer om Azure Local te laten liggen, en wie Azure Local wil, hoeft geen array meer af te schrijven. Twee dingen veranderen niet. De array houdt zijn eigen beheer, firmware-cyclus en fabric, en die beheert Azure Local niet voor je. En de host fee verdubbelt. Azure Local op SAN loont als je het Azure-beheer toch al wilt, of als je meer dan 16 nodes in één omgeving nodig hebt. Is het enige doel de array blijven gebruiken, dan blijft Windows Server met SAN de goedkopere route.

3. Wanneer SAN nog steeds de juiste keuze is

SAN-attached Hyper-V krijgt in vakliteratuur weinig aandacht meer, maar wij zien het in 2026 als de juiste keuze voor specifieke scenario's. Niet één daarvan is exotisch.

Scenario 1: bestaande SAN-investering met afschrijving die nog jaren loopt. Een klant heeft drie jaar geleden een Pure Storage FlashArray of een HPE Alletra geplaatst, met een afschrijvingstermijn van zeven jaar. Vervangen door HCI betekent vier jaar resterende afschrijving wegschrijven. De financiële case voor migratie is in dit scenario meestal slecht, tenzij er andere drivers zijn (vendor support eindigt, hardware-defecten).

Scenario 2: separate compute- en storage-schaling. Wanneer storage-groei en compute-groei niet synchroon lopen, is SAN flexibeler. Een database-cluster met 200 TB storage en 12 cores per node kun je op SAN dimensioneren zonder cores te betalen die je niet gebruikt. Op HCI moet je nodes toevoegen die zowel compute als storage leveren, of accepteren dat je in cores overbetaalt.

Scenario 3: shared storage tussen meerdere clusters. Een SAN-array kan LUN's leveren aan een Hyper-V cluster, een SQL Server failover cluster, en een fileserver-cluster tegelijk. HCI is per definitie storage-gekoppeld aan één cluster. Voor organisaties met meerdere kleine clusters die storage-resources delen, is SAN operationeel eenvoudiger.

Scenario 4: wettelijke of compliance-eisen voor data-locatie. Sommige compliance-frameworks vereisen dat storage fysiek isoleerbaar is, met expliciete encryption-at-rest controls aan de storage-zijde. SAN-arrays leveren dat in mature vorm met decennia aan tooling. HCI levert vergelijkbare features maar de auditbaarheid is anders georganiseerd.

Scenario 5: gespecialiseerde storage-features die HCI niet kan evenaren. Synchrone replicatie tussen sites met sub-millisecond RTO (Dell PowerStore Metro, HPE Alletra Peer Persistence), array-level snapshots geïntegreerd met VMware-VAAI-equivalenten voor Hyper-V (ODX), en deduplication op array-niveau die over alle hosts geldt. HCI levert software-equivalenten maar niet altijd met dezelfde performance-eigenschappen.

Wat SAN in 2026 NIET goed doet:

• Edge-deployments en kleine sites. Een SAN voor twee Hyper-V nodes is operationeel overkill. Voor die scenario's is HCI of een derde optie (een single shared SAS-DAS) beter.
• Snelle hardware-refresh-cycli. Een SAN-array vervangen is een groot project. HCI nodes vervangen kun je rolling doen.
• Cloud-native integratie op kale Windows Server. Een Windows Server cluster op SAN krijgt uit zichzelf geen Azure-beheer; Arc, Site Recovery en Azure Backup moeten elk apart worden ingericht. Sinds 2026 is het geïntegreerde alternatief Azure Local op dezelfde SAN, tegen het L2-tarief.

4. Wanneer S2D op Windows Server past

S2D zonder Azure Local heeft een specifieke niche in 2026. Microsoft stuurt strategische investering richting Azure Local, maar S2D op Windows Server 2022 of 2025 blijft volledig ondersteund.

De juiste fit voor S2D op Windows Server:

• Klant wil hyperconverged maar niet de per-core Azure-licentie van Azure Local. Bestaande Datacenter SA dekt Windows Server, en daarmee is S2D zonder additionele OS-licentie inbegrepen.
• Klant heeft geen Azure-connectivity of wil die principieel niet. Strikt air-gapped omgevingen, of organisaties met sterke soevereiniteitseisen die Azure-integratie afwijzen.
• Klant beheert al meerdere S2D-clusters met bestaande operationele expertise, en heeft geen aanleiding om naar een nieuwe toolchain te bewegen voor één nieuw cluster.

Wat S2D op Windows Server in 2026 lastiger maakt:

Hardware-keuze is minder gestandaardiseerd dan voor Azure Local. De Windows Server HCL is breder, maar de validatie minder strikt. Niet elke "Windows Server-compatibele" config is daadwerkelijk goed gevalideerd voor S2D, en de gevolgen van een verkeerde keuze (slijtage op verkeerde NVMe-types, RDMA-issues op niet-gevalideerde NIC's) zijn pijnlijk.

Wij raden klanten die voor S2D op Windows Server kiezen aan om alsnog te kopen via een OEM-solution (Dell Ready Nodes for S2D, HPE Solution for Microsoft Azure Stack HCI op Windows Server, Lenovo ThinkAgile MX). Dat geeft dezelfde validatie-eigenschappen als Azure Local, zonder de licentie-shift.

Microsoft's strategische focus is verschoven naar Azure Local. Feature-investeringen in S2D-op-Windows-Server worden minder. Voor klanten die op de lange termijn op S2D willen blijven, is dit een signaal om Azure Local serieus te overwegen, ook al is de per-core licentie initieel hoger.

5. Wanneer Azure Local de juiste sprong is

Azure Local is in 2026 de aanbevolen route voor nieuwe deployments waar Azure-connectivity een optie is, hyperconverged of, sinds release 2604, op een SAN. Dat is niet hetzelfde als "altijd Azure Local", maar de drempel om te overwegen is laag.

Goede fit voor Azure Local:

• Drie of meer nodes, met workloads die baat hebben bij S2D-storage en software-defined networking.
• Organisatie draait al andere workloads in Azure, of heeft een hybride strategie waar Azure Arc, Site Recovery of Backup waarde toevoegen.
• Centraal operations-team dat meerdere clusters beheert via dezelfde Azure-tooling, met centralised audit-trail en update-management.
• Greenfield hyperconverged deployment, die op het L1-tarief blijft.
• Een bestaande, ondersteunde SAN-array met nog jaren afschrijving, in een organisatie die het Azure-beheer toch al wil. Azure Local op die array, hybride of disaggregated, voorkomt zowel een afschrijving als een grote storage-migratie.
• Omgevingen die meer dan 16 nodes onder één beheer nodig hebben. Disaggregated deployments op SAN gaan tot 64 machines.

Slechte fit:

• Twee-node deployments met workloads die per-core licensing niet rechtvaardigen. De economics werken slecht onder een bepaalde scale-drempel.
• Strikt air-gapped of disconnected-only omgevingen. Standaard Azure Local vereist Azure-connectivity voor billing en management. Disconnected operations bestaan, maar vragen een geschikt contract, goedkeuring door Microsoft, een apart management-cluster en het L3-niveau. Voor de meeste organisaties is dat geen realistische route.
• Klanten van wie de array niet op de ondersteuningslijst staat, of die afhangen van zaken die Azure Local op SAN niet biedt, zoals ReFS-volumes of rack aware clustering.
• Klanten die alleen hun SAN willen blijven gebruiken en geen waarde zien in Azure-beheer. Voor hen koopt het L2-tarief niets wat Windows Server niet al doet.

Voor de volledige readiness-assessment specifiek voor Azure Local, zie het Azure Local migratie readiness checklist artikel.

6. Kostenvergelijking over de hele lifecycle

Marketing-vergelijkingen tussen storage-architecturen zijn berucht ongelijk. Onderstaande tabel is wat wij in onze assessments hanteren als eerste-orde schatting voor een typische four-node Hyper-V cluster met 128 cores totaal en 200 TB usable storage. Cijfers zijn relatieve indicatie, exacte bedragen variëren sterk per regio en per vendor. Azure Local op SAN heeft nu een eigen kolom, omdat het kostenprofiel van beide ouders afwijkt.

Kostencomponent	SAN-attached	S2D op WS	Azure Local (S2D)	Azure Local op SAN
OS-licentie (Datacenter)	Inbegrepen bij Datacenter SA	Inbegrepen bij Datacenter SA	Per-core/maand bovenop Datacenter SA (L1)	Per-core/maand op L2, ongeveer het dubbele van L1
Hardware compute (4 nodes)	Lager (geen lokale storage)	Hoger (lokale NVMe per node)	Hoger (lokale NVMe per node)	Lager (catalogus-nodes met HBA's, weinig lokale storage)
Hardware storage	Apart, hoge CapEx, lange lifecycle	Inbegrepen in node-prijs	Inbegrepen in node-prijs	Aparte array, een bestaande is herbruikbaar
Switches	2× standaard datacenter switches	2× DCB-capable switches	2× DCB-capable switches	Datacenter switches plus FC-fabric of iSCSI-netwerk
Software (replicatie, snapshots)	Vaak licentie op array	Inbegrepen, software-defined	Inbegrepen, plus Azure-diensten	Op de array, plus Azure-diensten
Operationele complexiteit	Hoger, twee management-planes	Lager, één management-plane	Lager, gecentraliseerd via Azure	Hoger, array plus Azure
Verbruik (energie, koeling)	Hoger door array	Lager, geen aparte array	Lager, geen aparte array	Hoger door array
Azure-diensten consumptie	n.v.t.	n.v.t.	Materieel, modelleren vereist	Materieel, modelleren vereist

Wat dit niet laat zien:

• De waarde van bestaande hardware. Een SAN die nog vijf jaar afschrijft, drukt de SAN-keuze financieel veel gunstiger dan greenfield. HCI levert geen credit voor bestaande hardware tenzij je een trade-in-programma kunt onderhandelen. Azure Local op SAN is nu de enige route die een bestaande array volledig laat meetellen en toch naar Azure-beheer gaat; de prijs daarvoor is het L2-tarief op elke core.
• De waarde van operationele expertise. Een team dat al jaren met Fibre Channel en MPIO werkt, levert SAN-operatie goedkoper dan een team dat dat opnieuw moet leren. Andersom geldt hetzelfde voor S2D en Azure Local.
• Lifecycle-events. Een SAN-array vervangen na zeven jaar is een project van honderdduizenden euro's. Vier HCI-nodes vervangen na vijf jaar is een rolling refresh die gedistribueerd kan over een jaar.
• Risicokosten. Een SAN-controller-failure die niet goed wordt opgevangen door HA-pad-configuratie kan een cluster downen. Een HCI-node-failure raakt alleen de capaciteit van die node. Beide architecturen hebben failure-modes, maar de blast-radius is anders.

7. Performance, niet alleen IOPS maar ook latency-profielen

Performance-vergelijkingen tussen storage-architecturen draaien vaak om IOPS, maar dat is voor Hyper-V workloads zelden de relevante metric. Latency en latency-stabiliteit zijn vaak belangrijker.

SAN-attached, performance-karakteristieken:

• Latency is consistent over tijd. Een goed geconfigureerde FC-SAN levert microseconde-latency stabiel onder load, omdat de SAN-array een dedicated apparaat is met dedicated cache en geen workload-interferentie.
• IOPS-piek is hoog, vooral bij moderne all-NVMe arrays (Pure FlashArray, Dell PowerStore, HPE Alletra MP). Miljoenen IOPS per array zijn standaard.
• Latency bij N-1 evacuatie (één host weg) is identiek aan steady state. De SAN merkt niet dat een host weg is.

S2D en Azure Local, performance-karakteristieken:

• Latency is goed in steady state op all-NVMe deployments, maar minder consistent dan SAN. Verzadiging van het RDMA-netwerk of NVMe-wear levelling kan latency-spikes veroorzaken die zich op SAN niet voordoen.
• IOPS-piek is hoog per node, maar schaalt lineair met aantal nodes. Voor extreme IOPS-vereisten (hoge-transactie databases) is een dedicated SAN nog steeds vaak gunstiger per euro.
• Latency tijdens N-1 evacuatie kan merkbaar oplopen, omdat de overgebleven nodes meer reads en writes moeten verwerken. Plan capaciteit voor steady-state plus 30% headroom voor N-1.

Waar HCI duidelijk wint:

• Mixed read/write workloads met cache-locality. S2D's NVMe-tier caching werkt extreem goed voor VDI en general-purpose VM workloads. Latency P99 is vaak beter dan op een SAN, omdat de write hits direct in lokale NVMe landen.
• Workloads die van data-tiering profiteren. S2D plaatst frequent-accessed data automatisch op snelle tier. SAN-arrays doen dit ook, maar met andere algoritmes en tuning-vereisten.

Waar SAN nog wint:

• Sequential I/O-zware workloads. Grote backups, file-server-workloads met sequential reads, en data warehouse-loads doen het op SAN vaak beter, omdat de array een grote write-cache en sequential-optimised firmware heeft.
• Storage features op array-niveau. Synchrone replicatie met sub-millisecond RPO, array-level snapshots met VSS-integratie, en specifieke compressie-algoritmes die op vendor-niveau zijn gevalideerd.

8. Operationele realiteit, wat het beheer werkelijk vraagt

Iedere architectuur heeft eigen operationele eigenaardigheden. Wat we in Hyper-V cluster assessments per architectuur als typische bevindingen vinden:

SAN-attached operationele realiteit:

• MPIO-configuratie wordt vaak vergeten of fout ingesteld na NIC-vervanging. Round Robin op een active/passive array is een klassieker.
• Firmware-updates op de SAN-array vereisen aparte change-windows, los van de Hyper-V cluster-patching. Twee management-planes, twee onderhouds-schema's.
• Zoning (voor FC) of CHAP (voor iSCSI) is statisch geconfigureerd en wordt over jaren onderhouden door verschillende beheerders. Documentatie-drift is een terugkerend probleem.

S2D operationele realiteit:

• Drive failures zijn frequenter dan op SAN, simpelweg omdat er meer fysieke drives per cluster zijn. S2D handelt dit autonoom af, maar replacement-procedures moeten goed gedocumenteerd zijn.
• Storage Spaces health vereist actieve monitoring. Een degraded storage pool die niet wordt opgemerkt, herstelt zich niet vanzelf en kan tot data-verlies leiden bij een tweede drive-failure.
• Cluster rebalancing tijdens node-onderhoud kan storage-traffic genereren die het RDMA-netwerk verzadigt. Plan onderhoud buiten piek-uren.

Azure Local operationele realiteit:

• Twee management-planes: Azure Portal voor primaire orchestratie, plus PowerShell en Failover Cluster Manager voor operationele taken. Teams moeten beide leren.
• Azure Update Manager voor patching is comfortabel, maar vereist gedisciplineerd change-management voor update-runs die nu vanuit cloud worden getriggerd.
• Kosten-monitoring is een continue activiteit. Azure Monitor, Log Analytics en Defender-consumptie kunnen verrassen als ze niet actief worden bewaakt.

Azure Local op SAN, wat we verwachten te vinden:

• Alle SAN-bevindingen hierboven blijven gelden. MPIO, zoning en LUN-presentatie zijn net zo makkelijk fout te zetten, en de cluster-validatie faalt nog steeds als één node een LUN anders ziet dan de rest.
• Drie wijzigingskalenders in plaats van twee: de maandelijkse Azure Local solution update, de firmware van de array, en het FC-fabric of iSCSI-netwerk. HBA-drivers en -firmware moeten passen bij zowel de Azure Local release als de interoperabiliteitsmatrix van de array-vendor.
• SAN-CSV's worden pas zichtbaar als VM-storage wanneer iemand ze als storage path registreert in de Azure portal. Wat de array aanbiedt en wat Azure kent, kan uit elkaar lopen.
• Twee teams, één resultaat. Het storage-team zoned en maskeert, het platform-team deployt en update. Microsoft adviseert zelfs de WWN's van de hosts pas na de Azure Local deployment te zonen, dus de volgorde van werken doet ertoe.

9. Migratie-paden tussen de opties

Bewegen tussen architecturen is geen kleine operatie. De praktische opties:

• Van SAN naar S2D op Windows Server. Bouw een nieuw S2D-cluster naast het bestaande SAN-cluster. Migreer VM's via Live Migration (als beide in hetzelfde domein zitten) of via Hyper-V Replica gevolgd door failover. Decommissioneer de SAN na verificatie. Geen in-place upgrade mogelijk.
• Van SAN naar Azure Local op dezelfde array. Nieuw sinds 2026. Deploy Azure Local op catalogus-hardware met ondersteunde HBA's of NIC's, presenteer nieuwe LUN's vanaf de bestaande array (een LUN hoort bij één cluster, dus oud en nieuw cluster kunnen ze niet delen), en migreer VM's met Azure Migrate, dat sinds mei 2026 Azure Local op SAN als doel ondersteunt. Let op: het pad vanaf Hyper-V is nog preview en neemt alleen VM's mee waarvan de disks op CSV's staan; het VMware-pad is generally available. Ruim daarna de oude LUN's op. Geen afschrijving van de array en geen grote datamigratie naar lokale disks.
• Van SAN naar hyperconverged Azure Local. Vergelijkbaar pad als naar S2D, maar met de aanvullende Azure Local readiness-stappen. Zie Azure Local migratie readiness checklist voor de volledige procedure.
• Van S2D op Windows Server naar Azure Local. Vanaf Azure Stack HCI 22H2 bestaat er een in-place upgrade-pad. Vanaf S2D op Windows Server 2022 is het pad ingewikkelder en wij adviseren een nieuw Azure Local cluster te bouwen naast het bestaande, en VM's te migreren. Hardware-validatie tegen de Azure Local Solutions Catalog is een verplichte tussenstap.
• Van HCI terug naar SAN. Dit gebeurt zelden maar het kan. Op Windows Server bouw je een SAN-cluster en migreer je VM's via Live Migration of restore. Op Azure Local koppel je SAN aan het bestaande cluster en verplaats je VM's naar de SAN-volumes, met als kanttekening dat het cluster dan naar het L2-tarief gaat. Argumenten zijn meestal financieel (HCI kwam duurder uit dan verwacht) of operationeel (HCI-skills bleken te schaars).

Wat we in alle migratie-paden standaard plannen:

• Capaciteits-modellering op het doel-cluster (zie de VMware-naar-Hyper-V pre-migration assessment methodiek, vergelijkbaar voor cross-storage migraties).
• Backup-strategie revalidatie. Backup-tooling moet de doel-architectuur correct ondersteunen, en CSV-backup-modi verschillen tussen SAN en S2D.
• Cutover-window planning met expliciete rollback-criteria. Geen migratie zonder duidelijke "wanneer stoppen we" trigger.

10. Beslissingsmatrix per scenario

Scenario	Aanbevolen	Acceptabel alternatief	Vermijden
Nieuwe greenfield, 4+ nodes, Azure-geschikt	Azure Local	S2D op WS 2025	Nieuwe SAN tenzij specifieke driver
Bestaand cluster, SAN nog 3+ jaar in afschrijving	SAN behouden, op Windows Server	Azure Local op dezelfde SAN als Azure-beheer gewenst is	Vroegtijdig vervangen zonder business case
Twee-node deployment, edge site	SAN met Shared SAS of S2D	Azure Local indien per-core ok	Volledig HCI zonder validatie
Hoge transactie database, sub-ms latency vereist	SAN met dedicated array, op WS of Azure Local	Azure Local met all-NVMe + RDMA	S2D op niet-gevalideerde hardware
VDI met sterke read-cache benefit	S2D of Azure Local	SAN met SSD-cache	Niet-NVMe SAN
Mixed workload, 8+ nodes, centrale ops	Azure Local	Azure Local op SAN als er al een array staat	Een nieuwe array kopen alleen om S2D te ontlopen
Meer dan 16 nodes onder één beheer	Azure Local disaggregated op SAN	Meerdere kleinere clusters	Eén hyperconverged cluster op zijn limiet
Disconnected / air-gapped	SAN of S2D op WS	Azure Local met disconnected operations, indien goedgekeurd	Standaard Azure Local met cloudverbinding
Migratie van VMware, behoud SAN-investering	SAN-attached Hyper-V of Azure Local op SAN	Hyperconverged Azure Local bij hardware-refresh	Forceren naar HCI zonder reden

Het cluster assessment als startpunt

Een storage-architectuurkeuze bouwt op de gemeten baseline van het huidige cluster. De oplevering bevat een beargumenteerde aanbeveling per workload-groep, een kostenmodel over vijf jaar voor elke kandidaat-architectuur, een migratiepad-analyse als de keuze verschuift, en een risicobeoordeling van de bestaande infrastructuur.

Voor klanten die overwegen tussen SAN-behoud, S2D-overstap, Azure Local-migratie of Azure Local op hun bestaande SAN, geeft de assessment de informatie om een onderbouwde keuze te maken. Niet ideologisch, maar passend bij de specifieke situatie.

Plan een Hyper-V storage architectuur assessment →