Il 15 dicembre 2025, Microsoft ha annunciato che Windows Server 2025 avrebbe finalmente adottato nativamente lo standard NVMe nella sua architettura di storage. Tuttavia, lo storage NVMe è un formato di storage diffuso su server, workstation aziendali e PC consumer da molti anni, con compatibilità con il sistema operativo integrata fin da Windows Server 2012 R2 e Windows 8.1. Considerando ciò, un annuncio sul supporto "nativo" di NVMe potrebbe non sembrare importante o addirittura degno di nota, ma vi assicuriamo che c'è di più di quanto sembri a prima vista.
Che cosa significa esattamente "NVMe nativo"?
Nelle precedenti versioni degli stack di archiviazione di Windows, sia per utenti privati che per server, i comandi utilizzati per leggere e scrivere dati, indipendentemente dai protocolli hardware sottostanti, venivano sempre tradotti in comandi SCSI. Lo standard Small Computer System Interface (SCSI) risale ai primi anni '1980 ed è stato progettato per connettere periferiche e unità di archiviazione ai computer (Storage Networking Industry Association, n.d.). È alla base di diversi protocolli di archiviazione moderni utilizzati per vari carichi di lavoro, inclusi protocolli di rete come iSCSI (Internet Small Computer System Interface) e FCP (Fibre Channel Protocol), e interfacce di archiviazione locali come SAS (Serial Attached SCSI) e UASP (USB Attached SCSI).
La vecchia via
Convertendo diversi protocolli in comandi SCSI, Microsoft ha unificato i comandi di archiviazione a livelli superiori del sistema operativo. Tuttavia, ha sacrificato molti dei miglioramenti in termini di scalabilità e prestazioni delle moderne architetture di archiviazione. Il vecchio percorso per le operazioni di I/O era il seguente:
- Le operazioni di lettura e scrittura avvengono nello stack di memoria superiore, a livello del filesystem.
- I comandi vengono trasmessi al driver Disk.sys.
- Disk.sys traduce i comandi generici di archiviazione in comandi SCSI.
- Storport riceve i comandi SCSI e li invia al driver Miniport appropriato (ad esempio, StorAHCI.sys per le unità SATA).
- Il driver Miniport corrispondente comunica direttamente con il dispositivo di archiviazione, traducendo poi i dati nel formato di comando appropriato per l'archiviazione.
Altre convenzioni SCSI, come i LUN (Logical Unit Number) utilizzati per identificare le partizioni di dati su un dispositivo di archiviazione, sono state mantenute nello stack di archiviazione di Windows, anche se concetti più recenti come i namespace NVMe esistono già da tempo (Hands, Worley e Lakhveer Kaur, nd).
Il nuovo standard
La più recente architettura di storage di Microsoft per Windows Server 2025 abilita nuove funzionalità in Storport e sostituisce Disk.sys con NVMeDisk.sys, fornendo un framework scalabile, pronto per il futuro e ad alte prestazioni.
- Le operazioni di lettura e scrittura avvengono nello stack di memoria superiore, a livello del filesystem.
- I comandi vengono passati direttamente da NVMeDisk.sys al nuovo codice StorMQ all'interno di Storport.
- StorMQ genera i comandi NVMe (o di altro tipo di storage) appropriati per ogni operazione di lettura e scrittura e li invia direttamente all'hardware.
(Immagine tratta dalla presentazione di Scott Lee alla SNIA Developer Conference del 16 settembre 2025)
Questo nuovo standard per le operazioni sulle unità su Windows Server 2025 elimina un livello di traduzione e si integra completamente con le code di comandi di archiviazione sui dispositivi NVMe, RAID e HBA. La semplificazione del sistema di archiviazione di Windows offre anche ulteriori vantaggi, come la riduzione dell'utilizzo delle risorse della CPU grazie all'eliminazione delle traduzioni di comandi di archiviazione non necessarie e un migliore utilizzo dei processori logici. La nuova architettura adotta altre specifiche NVMe, come i namespace NVMe e il supporto plug-and-play. Consente la creazione di driver Miniport di archiviazione specifici per fornitore o tipo di dispositivo e la loro "integrazione" in Windows per una maggiore compatibilità e prestazioni con le nuove classi di dispositivi di archiviazione (Lee, SNIA SDC 2025 – Storage Multi-Queue on Windows, 2025).
Pronti per il test?
Nella sua presentazione alla SNIA Developer Conference del 16 settembre 2025, Scott Lee ha rivelato che Microsoft stava già collaborando a stretto contatto con i fornitori per sviluppare nuovi driver per dispositivi come schede RAID e HBA. Ciò suggerisce che i miglioramenti a StorMQ arriveranno presto o potrebbero essere già abilitati su molti dispositivi di archiviazione. La funzionalità è stata annunciata come generalmente disponibile lo scorso dicembre, ma il nuovo stack di archiviazione è abilitato solo su richiesta, richiedendo l'aggiunta di una chiave di registro. È possibile consultare i passaggi per abilitarlo nell'articolo di Microsoft relativo all'annuncio di NVMe nativo.
Attenzione: la modifica errata del registro di sistema può causare gravi problemi, quindi assicuratevi di testare prima questa operazione su un server non critico. Diversi utenti che hanno abilitato questa funzione hanno segnalato problemi con le unità NVMe con la deduplicazione attiva. Sebbene Microsoft rilascerà presto una correzione ufficiale, procedete a vostro rischio e pericolo!
Test di NVMe nativo su Windows Server 2025
La nostra piattaforma di test per la valutazione di NVMe nativo su Windows Server 2025 (build del sistema operativo 26100.32370) era composta da un server con doppio socket SP5 dotato di due CPU AMD EPYC 9754 a 128 core. Accanto ai processori multi-core, era presente un'altrettanto notevole quantità di memoria DDR5 da 768 GB con una velocità di 4800 MT/s.
Nota: secondo Yash Shekar di Microsoft, un miglioramento provvisorio non correlato a NVMe nativo è già stato rilasciato per Windows Server 2025, il che potrebbe aver fornito un ulteriore incremento per lo stack di storage non nativo, riducendo la potenziale differenza tra i risultati.
Per valutare il potenziale del nuovo stack di storage, abbiamo utilizzato quindici SSD NVMe Solidigm P5316 da 30.72 TB con PCIe 4.0 in una configurazione JBOD. È importante notare che il Solidigm P5316 ha un'unità di indirezione di 64 kilobyte, il che significa che i risultati di scrittura per dimensioni inferiori (come i test a 4K) sono spesso peggiori del previsto. Considerando questa unità di indirezione più grande, abbiamo eseguito benchmark FIO con test di lettura e scrittura per blocchi casuali da 4K, casuali e sequenziali da 64K e sequenziali da 128K per confrontare la velocità complessiva su diverse dimensioni di blocco. Abbiamo anche monitorato l'utilizzo della CPU durante i test per valutare le affermazioni di Microsoft in merito a una maggiore efficienza.
Punti Salienti
- Larghezza di banda e IOPS di lettura casuale 4K e 64K notevolmente aumentate.
- Latenza di lettura casuale inferiore per 4K e 64K
- Diminuzione significativa dell'utilizzo della CPU per letture e scritture sequenziali con diverse dimensioni dei blocchi.
| Metrico | 4K casuali | 64K casuali | Sequenziale 64K | Sequenziale 128K | ||||
|---|---|---|---|---|---|---|---|---|
| Non nativo | Native | Non nativo | Native | Non nativo | Native | Non nativo | Native | |
| Leggi | ||||||||
| Larghezza di banda (GiB/s) | 6.1 | 10.058 | 74.291 | 91.165 | 35.596 | 35.623 | 86.791 | 92.562 |
| IOPS | 1,598,959 | 2,636,516 | 1,217,176 | 1,493,637 | 583,192 | 583,638 | 710,978 | 758,252 |
| Latenza media (ms) | 0.169 | 0.104 | 0.239 | 0.207 | 0.809 | 0.812 | 0.613 | 0.608 |
| Utilizzo totale della CPU (%) | 72.67 | 74.22 | 68.44 | 65.11 | 44.89 | 37.11 | 61.56 | 49.56 |
| Metrico | 4K casuali | 64K casuali | Sequenziale 64K | Sequenziale 128K | ||||
|---|---|---|---|---|---|---|---|---|
| Non nativo | Native | Non nativo | Native | Non nativo | Native | Non nativo | Native | |
| Scrivi | ||||||||
| Larghezza di banda (GiB/s) | 1.803 | 1.756 | 7.654 | 7.655 | 44.67 | 50.087 | 50.477 | 50.079 |
| IOPS | 472,725 | 460,383 | 125,391 | 125,406 | 731,859 | 820,603 | 413,495 | 410,232 |
| Latenza media (ms) | 0.992 | 1.028 | 3.814 | 3.816 | 0.399 | 0.558 | 1.022 | 1.149 |
| Utilizzo totale della CPU (%) | 26.00 | 20.67 | 12.22 | 9.33 | 70.44 | 57.78 | 58.44 | 47.33 |
Analisi dei risultati
Partendo dai benchmark di lettura casuale da 4K e 64K, abbiamo osservato velocità di lettura significativamente più elevate, con una differenza di quasi 4 GiB/s tra gli stack di storage nativi e non nativi (rispettivamente) nel test di lettura casuale da 4K e un incremento di quasi 16.9 GiB/s nella lettura casuale da 64K. Abbiamo anche riscontrato un discreto aumento nelle operazioni di lettura sequenziale da 128K, con i nostri test che mostrano un incremento di larghezza di banda di circa 5.8 GiB/s.
Curiosamente, non abbiamo riscontrato aumenti significativi nei nostri test di larghezza di banda di scrittura casuale o sequenziale, con l'unica differenza degna di nota rappresentata da un incremento di circa 5.4 GiB/s nelle scritture sequenziali a 64K. La maggior parte dei nostri risultati si è discostata di non più di 100 MiB/s l'uno dall'altro, il che suggerisce che le prestazioni del nuovo stack di storage sono quantomeno coerenti con quelle del precedente nei casi in cui non si sono registrati miglioramenti.
Poiché la velocità di trasmissione è tipicamente correlata alla latenza, abbiamo anche osservato un calo significativo della latenza media di lettura casuale sia per i test da 4K che per quelli da 64K. Abbiamo riscontrato una diminuzione del 38.46% nella lettura casuale non nativa da 4K, da 0.169 millisecondi a 0.104. I test di lettura casuale da 64K hanno mostrato una diminuzione minore, pari a circa il 13.39%. La latenza non è cambiata drasticamente con le operazioni di lettura sequenziale, ma le operazioni di scrittura casuale e sequenziale hanno mostrato aumenti generalizzati, nonostante una velocità di trasmissione simile o superiore.
Oltre all'aumento delle velocità di lettura casuale, un'altra tendenza interessante emersa dai nostri test FIO è stata una sostanziale diminuzione dell'utilizzo totale della CPU per le operazioni di lettura e scrittura sequenziali a 64K e 128K. I test di scrittura sequenziale hanno mostrato le differenze più significative, con un calo medio del 12.66% dell'utilizzo della CPU per 64K e un calo quasi identico dell'11.11% per 128K. Anche il test di lettura sequenziale a 128K che abbiamo eseguito ha mostrato una corrispondente diminuzione dell'utilizzo del 12%, ma solo una diminuzione del 7.78% per la lettura sequenziale a 64K. Un fattore da considerare è che, con una CPU sufficientemente veloce, potrebbero esserci casi in cui entrambi gli stack possono raggiungere il pieno potenziale di un dispositivo di archiviazione; pertanto, il throughput potrebbe non aumentare, ma l'utilizzo delle risorse della CPU diminuirebbe.
Takeaways
Sebbene molti dei nostri risultati rientrassero nella variabilità tra le diverse esecuzioni dopo l'attivazione del nuovo stack di storage, siamo stati in grado di confermare molte delle affermazioni di Microsoft, tra cui una maggiore larghezza di banda in lettura con latenza inferiore e una riduzione dell'utilizzo della CPU in generale. Poiché si tratta di un cambiamento piuttosto radicale rispetto allo stack di storage di Windows Server, in uso da decenni, Microsoft abiliterà inizialmente NVMe nativo per impostazione predefinita in Windows Server vNext. Fortunatamente, la funzionalità può essere abilitata su Windows Server 2025 con una semplice modifica del registro di sistema o tramite criteri di gruppo, consentendo agli amministratori di server più audaci di sfruttare il nuovo stack già da oggi (dopo aver preso atto dei rischi connessi alla sua implementazione).
Non vediamo l'ora di vedere NVMe abilitato di default sulla piattaforma Windows Server e speriamo nel supporto dei produttori di SSD NVMe, schede RAID e HBA, che dovrebbero essere in grado di portare i miglioramenti di Microsoft a un livello superiore!
Referenze
Hands, J., Worley, D., & Lakhveer Kaur. (nd). Spazi dei nomi NVMe. Estratto il 30 dicembre 2025 da NVM Express: https://nvmexpress.org/resource/nvme-namespaces/
Lee, S. (2025, 15 settembre). SNIA SDC 2025 – Multi-coda di archiviazione su Windows. San Tomas, CA, Stati Uniti d'America: Storage Networking Industry Association. Estratto il 29 dicembre 2025 da https://www.youtube.com/watch?v=dR-DWrmCba0&t
Lee, S. (2025, 16 settembre). Storage Multi-Queue su Windows: un nuovo stack per hardware di storage ad alte prestazioni. Estratto il 29 dicembre 2025 da SNIA Developer Conference: https://www.snia.org/sites/default/files/2025-10/SNIA-SDC25-Lee-Storage-Multi-Queue-On-Windows.pdf
Shekar, Y. (15 dicembre 2025). Annuncio di NVMe nativo in Windows Server 2025: l'inizio di una nuova era per le prestazioni di archiviazione. (Microsoft) Estratto il 29 dicembre 2025 da Windows Server News and Best Practices: https://techcommunity.microsoft.com/blog/windowsservernewsandbestpractices/announcing-native-nvme-in-windows-server-2025-ushering-in-a-new-era-of-storage-p/4477353
Storage Networking Industry Association. (nd). Cos'è SCSI? Estratto il 30 dicembre 2025 da Storage Networking Industry Association: https://www.snia.org/education/what-is-scsi
Amazon