SAN vs S2D vs Azure Local: Choosing Hyper-V Storage in 2026
Most marketing in 2026 tells you hyperconverged is the answer. Microsoft promotes Azure Local, vendors promote their HCI stack, and at conferences you hear that SAN-attached Hyper-V clusters are "legacy". In practice that narrative does not match reality for a significant group of customers. SAN-attached Hyper-V in 2026 is a rational, supported, and in many scenarios financially sensible choice.
This article is the honest comparison between the three storage architectures you can choose for a Hyper-V cluster in 2026. SAN-attached (FC, iSCSI, or Shared SAS), Storage Spaces Direct (S2D) on Windows Server, and Azure Local. Which fits which situation, and what trade-offs do you implicitly take when picking one of the three.
- The three architectures at a glance
- When SAN is still the right choice
- When S2D on Windows Server fits
- When Azure Local is the right jump
- Cost comparison, honestly across the full lifecycle
- Performance, not just IOPS but latency profiles too
- Operational reality, what management actually demands
- Migration paths between the three
- Decision matrix per scenario
1. The three architectures at a glance
SAN-attached Hyper-V. Classic model with separate compute and storage layers. A dedicated storage array (Dell PowerStore, HPE Alletra, NetApp AFF, Pure Storage, IBM FlashSystem, or similar) delivers block storage over Fibre Channel, iSCSI, or Shared SAS. Hyper-V hosts see the LUNs as CSVs. Compute and storage scale independently.
Storage Spaces Direct (S2D). Hyperconverged on Windows Server 2019, 2022, or 2025. Local NVMe or SSD per node, pooled across an RDMA network into shared storage. No external array required, compute and storage scale together per node.
Azure Local. Microsoft's modern hyperconverged platform (previously Azure Stack HCI), built on S2D technology but with Azure management, per-core licensing through an Azure subscription, and integration with Azure services like Site Recovery and Update Manager. See Azure Local migration readiness checklist for the full approach.
At the hardware level, the difference between S2D and Azure Local lives in the Solutions Catalog and the licensing form, not in fundamental architecture. Operationally however, they are two distinct products with distinct toolchains.
2. When SAN is still the right choice
SAN-attached Hyper-V gets little attention in trade press anymore, but in 2026 we treat it as the right choice for specific scenarios. None of them are exotic.
Scenario 1: existing SAN investment with years of depreciation left. A customer placed a Pure Storage FlashArray or an HPE Alletra three years ago with a seven-year depreciation. Replacing it with HCI means writing off four remaining years. The financial case for migration is typically weak in this scenario unless other drivers exist (vendor support ending, hardware defects).
Scenario 2: separate compute and storage scaling. When storage growth and compute growth do not move in sync, SAN is more flexible. A database cluster with 200 TB of storage and 12 cores per node can be sized on SAN without paying for cores you do not use. On HCI you have to add nodes that bring both compute and storage, or accept overpaying on cores.
Scenario 3: shared storage across multiple clusters. A SAN array can deliver LUNs to a Hyper-V cluster, a SQL Server failover cluster, and a fileserver cluster simultaneously. HCI is by definition storage-coupled to one cluster. For organisations with multiple small clusters sharing storage resources, SAN is operationally simpler.
Scenario 4: regulatory or compliance requirements for data location. Some compliance frameworks require physically separable storage with explicit encryption-at-rest controls at storage level. SAN arrays deliver that in mature form with decades of tooling. HCI provides comparable features but auditability is organised differently.
Scenario 5: specialised storage features HCI cannot match. Synchronous replication between sites with sub-millisecond RTO (Dell PowerStore Metro, HPE Alletra Peer Persistence), array-level snapshots with VMware VAAI-equivalent integration for Hyper-V (ODX), and array-level deduplication spanning all hosts. HCI provides software equivalents but not always with the same performance characteristics.
What SAN in 2026 does NOT do well:
- Edge deployments and small sites. A SAN for two Hyper-V nodes is operational overkill. HCI or a third option (a single shared SAS-DAS) fits better.
- Fast hardware-refresh cycles. Replacing a SAN array is a big project. Replacing HCI nodes can be done rolling.
- Cloud-native integration. SAN storage does not integrate seamlessly with Azure services like Site Recovery, Azure Backup for block storage, or Arc. All of that has to be configured separately.
3. When S2D on Windows Server fits
S2D without Azure Local has a specific niche in 2026. Microsoft directs strategic investment toward Azure Local, but S2D on Windows Server 2022 or 2025 remains fully supported.
Right fit for S2D on Windows Server:
- Customer wants hyperconverged without the per-core Azure license of Azure Local. Existing Datacenter SA covers Windows Server, and S2D is included without additional OS license.
- Customer has no Azure connectivity or rejects it on principle. Strict air-gapped environments, or organisations with strong sovereignty requirements that reject Azure integration.
- Customer already manages multiple S2D clusters with existing operational expertise and sees no reason to move to a new toolchain for one new cluster.
What makes S2D on Windows Server harder in 2026:
Hardware choice is less standardised than for Azure Local. The Windows Server HCL is broader, but validation is less strict. Not every "Windows Server compatible" config is genuinely well-validated for S2D, and the consequences of a wrong choice (wear on wrong NVMe types, RDMA issues on unvalidated NICs) are painful.
We recommend customers choosing S2D on Windows Server to still buy through an OEM solution (Dell Ready Nodes for S2D, HPE Solution for Microsoft Azure Stack HCI on Windows Server, Lenovo ThinkAgile MX). That delivers the same validation properties as Azure Local without the license shift.
Microsoft's strategic focus has moved to Azure Local. Feature investments in S2D-on-Windows-Server are dropping. For customers wanting to stay on S2D long term, this is a signal to seriously consider Azure Local, even if the per-core license is initially higher.
4. When Azure Local is the right jump
Azure Local in 2026 is the recommended route for new hyperconverged deployments where Azure connectivity is an option. That is not the same as "always Azure Local", but the threshold for considering it is low.
Good fit for Azure Local:
- Three or more nodes, with workloads benefiting from S2D storage and software-defined networking.
- Organisation already runs other workloads in Azure, or has a hybrid strategy where Azure Arc, Site Recovery, or Backup add value.
- Central operations team managing multiple clusters through the same Azure tooling, with centralised audit trail and update management.
- Greenfield deployment without an existing SAN investment to protect.
Bad fit:
- Two-node deployments with workloads that do not justify per-core licensing. Economics work poorly below a certain scale threshold.
- Strict air-gapped or disconnected-only environments. Azure Local requires Azure connectivity for billing and management.
- Customers wanting to stay on SAN for strategic reasons and explicitly choosing not to make the hyperconverged shift.
For the full readiness assessment specific to Azure Local, see the Azure Local migration readiness checklist article.
5. Cost comparison, honestly across the full lifecycle
Marketing comparisons between storage architectures are notoriously skewed. The table below is what we use in CloudLabs assessments as a first-order estimate for a typical four-node Hyper-V cluster with 128 cores total and 200 TB usable storage. Numbers are relative indication, exact amounts vary widely by region and vendor.
| Cost component | SAN-attached | S2D on WS | Azure Local |
|---|---|---|---|
| OS license (Datacenter) | Included with Datacenter SA | Included with Datacenter SA | Per-core/month on top of Datacenter SA |
| Compute hardware (4 nodes) | Lower (no local storage) | Higher (local NVMe per node) | Higher (local NVMe per node) |
| Storage hardware | Separate, high CapEx, long lifecycle | Included in node price | Included in node price |
| Switches | 2× standard datacenter switches | 2× DCB-capable switches | 2× DCB-capable switches |
| Software (replication, snapshots) | Often licensed on array | Included, software-defined | Included, plus Azure services |
| Operational complexity | Higher, two management planes | Lower, one management plane | Lower, centralised through Azure |
| Power and cooling | Higher due to array | Lower, no separate array | Lower, no separate array |
| Azure service consumption | N/A | N/A | Material, must be modelled |
What this does not show:
- The value of existing hardware. A SAN with five more years of depreciation makes the SAN choice financially much more favourable than greenfield. HCI gives no credit for existing hardware unless you can negotiate a trade-in programme.
- The value of operational expertise. A team that has worked with Fibre Channel and MPIO for years runs SAN operations cheaper than a team that has to learn it from scratch. The same applies in reverse for S2D and Azure Local.
- Lifecycle events. Replacing a SAN array after seven years is a project of hundreds of thousands of euros. Replacing four HCI nodes after five years is a rolling refresh distributable over a year.
- Risk costs. A SAN controller failure not absorbed by proper HA-path configuration can take a cluster down. An HCI node failure only affects the capacity of that node. Both architectures have failure modes, but the blast radius differs.
6. Performance, not just IOPS but latency profiles too
Performance comparisons between storage architectures often revolve around IOPS, but for Hyper-V workloads that is rarely the relevant metric. Latency and latency stability matter more.
SAN-attached, performance characteristics:
- Latency is consistent over time. A well-configured FC SAN delivers microsecond latency stably under load, because the SAN array is a dedicated device with dedicated cache and no workload interference.
- IOPS peak is high, especially on modern all-NVMe arrays (Pure FlashArray, Dell PowerStore, HPE Alletra MP). Millions of IOPS per array are standard.
- Latency during N-1 evacuation (one host out) is identical to steady state. The SAN does not notice a host is gone.
S2D and Azure Local, performance characteristics:
- Latency is good in steady state on all-NVMe deployments, but less consistent than SAN. Saturation of the RDMA network or NVMe wear levelling can cause latency spikes that do not occur on SAN.
- IOPS peak is high per node, but scales linearly with node count. For extreme IOPS requirements (high-transaction databases) a dedicated SAN is often still more favourable per euro.
- Latency during N-1 evacuation can rise noticeably, because remaining nodes must process more reads and writes. Plan capacity for steady state plus 30% headroom for N-1.
Where HCI clearly wins:
- Mixed read/write workloads with cache locality. S2D's NVMe tier caching works extremely well for VDI and general-purpose VM workloads. P99 latency is often better than on a SAN because write hits land directly in local NVMe.
- Workloads benefiting from data tiering. S2D automatically places frequently-accessed data on the fast tier. SAN arrays do this too, but with different algorithms and tuning requirements.
Where SAN still wins:
- Sequential I/O-heavy workloads. Large backups, file server workloads with sequential reads, and data warehouse loads often perform better on SAN, because the array has a large write cache and sequential-optimised firmware.
- Storage features at the array level. Synchronous replication with sub-millisecond RPO, array-level snapshots with VSS integration, and specific compression algorithms validated at vendor level.
7. Operational reality, what management actually demands
Each architecture has its own operational quirks. What we find in Hyper-V Cluster Health Checks per architecture as typical findings:
SAN-attached operational reality:
- MPIO configuration often gets forgotten or set incorrectly after NIC replacement. Round Robin on an active/passive array is a classic.
- Firmware updates on the SAN array require separate change windows, separate from Hyper-V cluster patching. Two management planes, two maintenance schedules.
- Zoning (for FC) or CHAP (for iSCSI) is statically configured and maintained over years by different administrators. Documentation drift is a recurring problem.
S2D operational reality:
- Drive failures are more frequent than on SAN, simply because there are more physical drives per cluster. S2D handles this autonomously, but replacement procedures must be well documented.
- Storage Spaces health requires active monitoring. A degraded storage pool not noticed does not self-heal and can lead to data loss on a second drive failure.
- Cluster rebalancing during node maintenance can generate storage traffic that saturates the RDMA network. Schedule maintenance outside peak hours.
Azure Local operational reality:
- Two management planes: Azure Portal for primary orchestration, plus PowerShell and Failover Cluster Manager for operational tasks. Teams have to learn both.
- Azure Update Manager for patching is comfortable, but requires disciplined change management for update runs now triggered from cloud.
- Cost monitoring is a continuous activity. Azure Monitor, Log Analytics, and Defender consumption can surprise if not actively watched.
The right storage choice for your Hyper-V cluster depends on factors not all visible in a marketing comparison: existing investments, team expertise, compliance requirements, and fit with your broader infrastructure strategy.
A CloudLabs storage assessment for Hyper-V maps these factors per workload group and delivers a reasoned recommendation with explicit trade-offs in a customer-facing .docx report.
8. Migration paths between the three
Moving between architectures is not a small operation. Practical options:
- From SAN to S2D on Windows Server. Build a new S2D cluster alongside the existing SAN cluster. Migrate VMs through Live Migration (if both are in the same domain) or Hyper-V Replica followed by failover. Decommission the SAN after verification. No in-place upgrade possible.
- From SAN to Azure Local. Similar path to S2D, with the additional Azure Local readiness steps. See Azure Local migration readiness checklist for the full procedure.
- From S2D on Windows Server to Azure Local. From Azure Stack HCI 22H2 there is an in-place upgrade path. From S2D on Windows Server 2022 the path is more complex and we recommend building a new Azure Local cluster alongside the existing one and migrating VMs. Hardware validation against the Azure Local Solutions Catalog is a mandatory intermediate step.
- From HCI back to SAN. This happens rarely but it can. Build a SAN cluster, migrate VMs through Live Migration or restore. Arguments are usually financial (HCI cost more than expected) or operational (HCI skills proved too scarce).
What we plan as standard in all migration paths:
- Capacity modelling on the target cluster (see the VMware to Hyper-V pre-migration assessment methodology, comparable for cross-storage migrations).
- Backup strategy revalidation. Backup tooling must correctly support the target architecture, and CSV backup modes differ between SAN and S2D.
- Cutover window planning with explicit rollback criteria. No migration without a clear "when do we stop" trigger.
9. Decision matrix per scenario
| Scenario | Recommended | Acceptable alternative | Avoid |
|---|---|---|---|
| New greenfield, 4+ nodes, Azure-suitable | Azure Local | S2D on WS 2025 | New SAN unless specific driver |
| Existing cluster, SAN 3+ years of depreciation left | Keep SAN | N/A this cycle | Early replacement without business case |
| Two-node deployment, edge site | SAN with Shared SAS or S2D | Azure Local if per-core ok | Full HCI without validation |
| High-transaction database, sub-ms latency required | SAN with dedicated array | Azure Local with all-NVMe + RDMA | S2D on unvalidated hardware |
| VDI with strong read-cache benefit | S2D or Azure Local | SAN with SSD cache | Non-NVMe SAN |
| Mixed workload, 8+ nodes, central ops | Azure Local | S2D on WS 2025 | SAN unless existing investment |
| Disconnected / air-gapped | SAN or S2D on WS | N/A | Azure Local |
| VMware migration, preserve SAN investment | SAN-attached Hyper-V | Azure Local if hardware refresh | Forcing HCI without reason |
The CloudLabs storage assessment
We run storage architecture assessments as fixed-scope engagements, three to five working days for environments up to 300 VMs. The deliverable includes a reasoned recommendation per workload group, a five-year cost model for each candidate architecture, a migration path analysis if the choice shifts, and a risk assessment of the existing infrastructure.
For customers weighing SAN retention, S2D transition, or Azure Local migration, the assessment provides the information to make a substantiated choice. Not ideological, but fitting the specific situation.
Schedule a Hyper-V storage architecture assessment →
Frequently asked questions
Yes, fully. Microsoft supports Hyper-V on SAN-attached storage without restriction, and most SAN vendors have current certifications for Windows Server 2022 and 2025. The marketing suggestion that SAN is "legacy" does not translate to product support reality.
Technically it is possible to present both kinds of storage to the same hosts, but for one cluster it is not recommended and rarely supported. Cluster validation expects consistent storage. For customers wanting both SAN and HCI, we recommend running two separate clusters, each optimised for one storage architecture.
Under the hood the S2D technology is identical. The differences sit in: hardware validation (Azure Local Solutions Catalog is stricter), license form (Azure Local is per core per month, Windows Server S2D is through Datacenter SA), management plane (Azure Local has Azure Portal integration), update mechanism (Azure Local has Azure Update Manager), and strategic focus (Microsoft invests primarily in Azure Local).
For a four-node cluster with 32 cores per node, the Azure Local OS fee comes to several thousand euros per month. Over five years that is material, but typically still lower than the SAN hardware plus storage software licenses you would otherwise buy. The exact picture varies by region and workload profile; model it in a TCO comparison with realistic assumptions.
Yes, Hyper-V Replica is storage-agnostic and works on SAN, S2D, and Azure Local. Configuration and operational procedures differ slightly per architecture, but functionality is mature in all three cases. For stretched clusters with synchronous replication, considerations differ, and those work specifically with array-level features (SAN), Storage Replica (S2D), or Azure services (Azure Local).
SAN vs S2D vs Azure Local: storage-keuze voor Hyper-V in 2026
De meeste marketing in 2026 vertelt je dat hyperconverged het antwoord is. Microsoft promoot Azure Local, vendors promoten hun HCI-stack, en op conferenties hoor je dat SAN-gebaseerde Hyper-V clusters "legacy" zijn. In de praktijk klopt dat verhaal voor een aanzienlijke groep klanten niet. SAN-attached Hyper-V is in 2026 een rationele, ondersteunde, en in veel scenario's financieel verstandige keuze.
Dit artikel is de eerlijke vergelijking tussen de drie storage-architecturen die je in 2026 kunt kiezen voor een Hyper-V cluster. SAN-attached (FC, iSCSI of Shared SAS), Storage Spaces Direct (S2D) op Windows Server, en Azure Local. Welke past bij welke situatie, en welke trade-offs neem je impliciet wanneer je voor één van de drie kiest.
- De drie architecturen in vogelvlucht
- Wanneer SAN nog steeds de juiste keuze is
- Wanneer S2D op Windows Server past
- Wanneer Azure Local de juiste sprong is
- Kostenvergelijking, eerlijk over de hele lifecycle
- Performance, niet alleen IOPS maar ook latency-profielen
- Operationele realiteit, wat het beheer werkelijk vraagt
- Migratie-paden tussen de drie
- Beslissingsmatrix per scenario
1. De drie 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 moderne hyperconverged platform (voorheen Azure Stack HCI), gebouwd op S2D-technologie maar met Azure-management, per-core licentie via Azure-subscription, en integratie met Azure-diensten zoals Site Recovery en Update Manager. Zie Azure Local migratie readiness checklist voor de volledige aanvliegroute.
Op hardware-niveau zit het verschil tussen S2D en Azure Local in de Solutions Catalog en de licentievorm, niet in fundamentele architectuur. Maar operationeel zijn het twee verschillende producten met verschillende toolchains.
2. 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. SAN-storage integreert niet naadloos met Azure-diensten zoals Site Recovery, Azure Backup voor block-storage, of Arc. Dat moet allemaal apart.
3. 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.
4. Wanneer Azure Local de juiste sprong is
Azure Local is in 2026 de aanbevolen route voor nieuwe hyperconverged deployments waar Azure-connectivity een optie is. 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 deployment zonder bestaande SAN-investering om te beschermen.
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. Azure Local vereist Azure-connectivity voor billing en management.
- Klanten die op SAN willen blijven om strategische redenen, en de hyperconverged shift expliciet niet willen maken.
Voor de volledige readiness-assessment specifiek voor Azure Local, zie het Azure Local migratie readiness checklist artikel.
5. Kostenvergelijking, eerlijk over de hele lifecycle
Marketing-vergelijkingen tussen storage-architecturen zijn berucht ongelijk. Onderstaande tabel is wat wij in CloudLabs-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.
| Kostencomponent | SAN-attached | S2D op WS | Azure Local |
|---|---|---|---|
| OS-licentie (Datacenter) | Inbegrepen bij Datacenter SA | Inbegrepen bij Datacenter SA | Per-core/maand bovenop Datacenter SA |
| Hardware compute (4 nodes) | Lager (geen lokale storage) | Hoger (lokale NVMe per node) | Hoger (lokale NVMe per node) |
| Hardware storage | Apart, hoge CapEx, lange lifecycle | Inbegrepen in node-prijs | Inbegrepen in node-prijs |
| Switches | 2× standaard datacenter switches | 2× DCB-capable switches | 2× DCB-capable switches |
| Software (replicatie, snapshots) | Vaak licentie op array | Inbegrepen, software-defined | Inbegrepen, plus Azure-diensten |
| Operationele complexiteit | Hoger, twee management-planes | Lager, één management-plane | Lager, gecentraliseerd via Azure |
| Verbruik (energie, koeling) | Hoger door array | Lager, geen aparte array | Lager, geen aparte array |
| Azure-diensten consumptie | n.v.t. | n.v.t. | 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.
- 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.
6. 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.
7. Operationele realiteit, wat het beheer werkelijk vraagt
Iedere architectuur heeft eigen operationele eigenaardigheden. Wat we in Hyper-V Cluster Health Checks 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.
De juiste storage-keuze voor jouw Hyper-V cluster hangt af van factoren die niet allemaal zichtbaar zijn in een marketing-vergelijking: bestaande investeringen, team-expertise, compliance-eisen, en de fit met je bredere infrastructuur-strategie.
Een CloudLabs storage assessment voor Hyper-V brengt deze factoren in kaart per workload-groep, en levert een beargumenteerde aanbeveling met expliciete trade-offs in een .docx-rapport voor de klant.
8. Migratie-paden tussen de drie
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. 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. Bouw een SAN-cluster, migreer VM's via Live Migration of restore. 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.
9. 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 | n.v.t. tijdens deze cyclus | 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 | 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 | S2D op WS 2025 | SAN tenzij bestaande investering |
| Disconnected / air-gapped | SAN of S2D op WS | n.v.t. | Azure Local |
| Migratie van VMware, behoud SAN-investering | SAN-attached Hyper-V | Azure Local indien hardware-refresh | Forceren naar HCI zonder reden |
De CloudLabs storage-assessment
Wij voeren storage-architectuur-assessments uit als opdracht met vaste scope, drie tot vijf werkdagen voor omgevingen tot 300 VM's. 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 of Azure Local-migratie, 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 →
Veelgestelde vragen
Ja, volledig. Microsoft ondersteunt Hyper-V op SAN-attached storage onverkort, en de meeste SAN-vendors hebben actuele certificaten voor Windows Server 2022 en 2025. De marketing-suggestie dat SAN "legacy" zou zijn, vertaalt niet naar product-support-realiteit.
Technisch is het mogelijk om beide soorten storage te presenteren aan dezelfde hosts, maar voor één cluster wordt het niet aanbevolen en zelden ondersteund. De cluster-validatie verwacht consistente storage. Voor klanten die zowel SAN als HCI willen, raden wij aan om twee aparte clusters te draaien, elk geoptimaliseerd voor één storage-architectuur.
Onder de motorkap is de S2D-technologie identiek. Het verschil zit in: hardware-validatie (Azure Local Solutions Catalog is strikter), licentievorm (Azure Local is per core per maand, Windows Server S2D is via Datacenter SA), management-plane (Azure Local heeft Azure Portal-integratie), update-mechanisme (Azure Local heeft Azure Update Manager), en strategische focus (Microsoft investeert primair in Azure Local).
Voor een four-node cluster met 32 cores per node komt de Azure Local OS-fee uit op enkele duizenden euro's per maand. Over vijf jaar is dat materieel, maar typisch nog steeds lager dan de SAN-hardware plus storage-software-licenties die je anders zou kopen. Het exacte plaatje verschilt per regio en per workload-profiel; modelleer het in een TCO-vergelijking met realistische assumpties.
Ja, Hyper-V Replica is storage-agnostisch en werkt op SAN, S2D en Azure Local. De configuratie en operationele procedures verschillen iets per architectuur, maar de functionaliteit is in alle drie de gevallen volwassen. Voor stretched clusters met synchrone replicatie zijn de overwegingen anders, en die werken specifiek met array-level features (SAN), Storage Replica (S2D), of Azure-services (Azure Local).