Dne 15. prosince 2025 společnost Microsoft oznámila, že systém Windows Server 2025 konečně nativně přijme standard NVMe ve své architektuře úložišť. Úložiště NVMe je však již mnoho let oblíbeným formátem úložiště na serverech, podnikových pracovních stanicích a spotřebitelských počítačích, přičemž kompatibilita s operačními systémy je integrována od systémů Windows Server 2012 R2 a Windows 8.1. S ohledem na to se oznámení o „nativní“ podpoře NVMe nemusí zdát důležité nebo dokonce zajímavé, ale slibujeme, že za tím je víc, než se na první pohled zdá.
Co vlastně znamená „nativní NVMe“?
V předchozích verzích úložných systémů Windows pro spotřebitele a servery byly příkazy používané ke čtení a zápisu dat, bez ohledu na protokoly podkladového hardwaru, vždy překládány do příkazů SCSI. Standard Small Computer System Interface (SCSI) pochází z počátku 80. let 20. století a byl navržen pro připojení periferií a úložných jednotek k počítačům (Storage Networking Industry Association, nd). Je základem několika moderních úložných protokolů používaných pro různé pracovní úlohy, včetně síťových protokolů, jako je iSCSI (Internet Small Computer System Interface) a FCP (Fibre Channel Protocol), a lokálních úložných rozhraní, jako je SAS (Serial Attached SCSI) a UASP (USB Attached SCSI).
Stará cesta
Převodem různých protokolů na příkazy SCSI společnost Microsoft sjednotila příkazy pro úložiště na vyšších úrovních operačního systému. Přesto obětovala mnoho vylepšení škálovatelnosti a výkonu moderních architektur úložišť. Stará cesta pro I/O operace vypadala takto:
- Operace čtení a zápisu probíhají v horním zásobníku úložiště na úrovni souborového systému.
- Příkazy se předávají ovladači Disk.sys.
- Soubor Disk.sys překládá obecné příkazy pro ukládání dat do příkazů SCSI.
- Storport přijímá příkazy SCSI a odesílá je do příslušného ovladače miniportu (např. StorAHCI.sys pro disky SATA).
- Odpovídající ovladač miniportu komunikuje přímo s úložným zařízením a převádí jej zpět do příslušného formátu úložného příkazu.
Další konvence SCSI, jako například LUN (Logical Unit Numbers) používané k identifikaci oddílů dat na úložném zařízení, byly přeneseny do úložného systému Windows, přestože novější koncepty, jako jsou jmenné prostory NVMe, existují již poměrně dlouho (Hands, Worley a Lakhveer Kaur, nd).
Nový standard
Nejnovější architektura úložiště od společnosti Microsoft pro Windows Server 2025 umožňuje nové funkce ve Storportu a nahrazuje soubor Disk.sys souborem NVMeDisk.sys, čímž poskytuje škálovatelný, vysoce výkonný framework připravený na budoucnost.
- Operace čtení a zápisu probíhají v horním zásobníku úložiště na úrovni souborového systému.
- Příkazy se předávají přímo z NVMeDisk.sys do nového kódu StorMQ v rámci Storportu.
- StorMQ generuje příslušné příkazy NVMe (nebo jiného typu úložiště) pro každou operaci čtení a zápisu a odesílá je přímo do hardwaru.
(Obrázek z prezentace Scotta Leeho na konferenci SNIA Developer Conference 16. září 2025)
Tento nový standard pro operace s disky v systému Windows Server 2025 eliminuje vrstvu překladu a plně se integruje s frontami příkazů úložiště na zařízeních NVMe, RAID a HBA. Zjednodušení úložného systému Windows nabízí také další výhody, jako je snížené využití zdrojů CPU díky eliminaci zbytečného překladu příkazů úložiště a lepší využití logických procesorů. Nová architektura přijímá další specifikace NVMe, jako jsou jmenné prostory NVMe a podpora plug-and-play. Umožňuje vytvářet ovladače miniportu úložiště specifické pro daného dodavatele nebo typ zařízení a „zapojovat“ je do systému Windows pro větší kompatibilitu a výkon s novými třídami úložných zařízení (Lee, SNIA SDC 2025 – Storage Multi-Queue on Windows, 2025).
Připraveni k testování?
Ve své prezentaci na konferenci SNIA Developer Conference 16. září 2025 Scott Lee prozradil, že Microsoft již úzce spolupracuje s dodavateli na vývoji nových ovladačů pro zařízení, jako jsou karty RAID a HBA. To naznačuje, že vylepšení StorMQ budou brzy k dispozici nebo již mohou být povolena na mnoha úložných zařízeních. Tato funkce byla oznámena jako obecně dostupná v prosinci loňského roku, ale nový úložný stack je povolen pouze na základě volby a vyžaduje přidání klíče registru. Postup povolení si můžete přečíst v článku o nativním NVMe od společnosti Microsoft.
Varování: Nesprávná úprava registru může způsobit vážné problémy, proto nejprve otestujte tuto funkci na méně důležitém serveru. Několik uživatelů, kteří tuto funkci povolili, hlásilo problémy s disky NVMe s povolenou deduplikací. Ačkoli se brzy chystá oficiální oprava od společnosti Microsoft, postupujete na vlastní nebezpečí!
Testování nativního NVMe na Windows Serveru 2025
Naše testovací platforma pro vyhodnocení nativního NVMe na Windows Serveru 2025 (build OS 26100.32370) obsahovala server s dvěma sockety SP5 a dvěma 128jádrovými procesory AMD EPYC 9754. Spolu s vícejádrovými procesory byl k dispozici stejně působivých 768 GB paměti DDR5 s rychlostí 4800 MT/s.
Poznámka: Podle Yashe Shekara ze společnosti Microsoft již bylo pro Windows Server 2025 vydáno prozatímní vylepšení nesouvisející s nativním NVMe, které mohlo poskytnout další vylepšení pro nenativní úložný stack a snížit tak potenciální rozdíl mezi výsledky.
Pro vyhodnocení potenciálu nového úložného stacku jsme použili patnáct 30.72 TB SSD disků Solidigm P5316 NVMe s PCIe 4.0 v konfiguraci JBOD. Důležité je, že Solidigm P5316 má velikost indirekční jednotky 64 kilobajtů, což znamená, že výsledky zápisu pro menší velikosti (například testy 4K) jsou často horší, než se očekávalo. Vzhledem k této větší indirekční jednotce jsme provedli benchmarky FIO s testy čtení a zápisu pro náhodné 4K, náhodné a sekvenční 64K a sekvenční 128K, abychom porovnali celkovou rychlost napříč různými velikostmi bloků. Během testování jsme také sledovali využití CPU, abychom vyhodnotili tvrzení společnosti Microsoft o vyšší efektivitě.
Podmínky-události
- Masivně zvýšená propustnost náhodného čtení 4K a 64K a počet IOPS
- Nižší latence náhodného čtení 4K a 64K
- Významné snížení využití CPU pro sekvenční čtení a zápisy napříč bloky různých velikostí
| metrický | Náhodných 4 tisíc | Náhodných 64 tisíc | Sekvenční 64K | Sekvenční 128K | ||||
|---|---|---|---|---|---|---|---|---|
| Nepůvodní | Domácí | Nepůvodní | Domácí | Nepůvodní | Domácí | Nepůvodní | Domácí | |
| číst | ||||||||
| Šířka pásma (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 |
| Průměrná latence (ms) | 0.169 | 0.104 | 0.239 | 0.207 | 0.809 | 0.812 | 0.613 | 0.608 |
| Celkové využití CPU (%) | 72.67 | 74.22 | 68.44 | 65.11 | 44.89 | 37.11 | 61.56 | 49.56 |
| metrický | Náhodných 4 tisíc | Náhodných 64 tisíc | Sekvenční 64K | Sekvenční 128K | ||||
|---|---|---|---|---|---|---|---|---|
| Nepůvodní | Domácí | Nepůvodní | Domácí | Nepůvodní | Domácí | Nepůvodní | Domácí | |
| Napsat | ||||||||
| Šířka pásma (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 |
| Průměrná latence (ms) | 0.992 | 1.028 | 3.814 | 3.816 | 0.399 | 0.558 | 1.022 | 1.149 |
| Celkové využití CPU (%) | 26.00 | 20.67 | 12.22 | 9.33 | 70.44 | 57.78 | 58.44 | 47.33 |
Analýza výsledků
Počínaje benchmarky pro náhodné čtení 4K a 64K jsme pozorovali výrazně vyšší rychlosti čtení, s rozdílem téměř 4 GiB/s mezi nativním a nenativním úložným zásobníkem v testu náhodného čtení 4K a nárůstem téměř 16.9 GiB/s při náhodném čtení 64K. Také jsme zaznamenali slušný nárůst sekvenčních operací čtení 128K, přičemž naše testy ukázaly nárůst šířky pásma přibližně o 5.8 GiB/s.
Je zajímavé, že jsme v našich testech náhodného ani sekvenčního zápisu nezaznamenali žádné významné zvýšení šířky pásma, jediným pozoruhodným rozdílem bylo přibližně 5.4 GiB/s zvýšení u sekvenčních zápisů o rychlosti 64K. Většina našich výsledků se od sebe lišila do 100 MiB/s, což naznačuje, že výkon nového úložného stacku je alespoň v případech, kdy se nezlepšil, srovnatelný se starým.
Vzhledem k tomu, že propustnost obvykle koreluje s latencí, pozorovali jsme také velké poklesy průměrné latence náhodného čtení u testů s rozlišením 4K i 64K. U nenativního náhodného čtení s rozlišením 4K jsme zaznamenali pokles o 38.46 %, z 0.169 milisekundy na 0.104. U testů náhodného čtení s rozlišením 64K došlo k menšímu poklesu, přibližně o 13.39 %. Latence se u sekvenčních operací čtení drasticky nezměnila, ale u operací náhodného a sekvenčního zápisu došlo k plošnému nárůstu, a to i přes podobnou nebo vyšší propustnost.
Kromě zvýšení rychlosti náhodného čtení odhalily naše testy FIO další zajímavý trend, a to podstatný pokles celkového využití CPU pro sekvenční operace čtení a zápisu s rychlostí 64K a 128K. Testy sekvenčního zápisu vykazovaly nejvýraznější rozdíly s průměrným poklesem využití CPU o 12.66 % pro 64K a téměř shodným poklesem o 11.11 % pro 128K. Sekvenční test čtení 128K, který jsme provedli, také zaznamenal odpovídající pokles využití o 12 %, ale pro sekvenční čtení 64K pouze pokles o 7.78 %. Jedním z faktorů, které je třeba zvážit, je, že s dostatečně rychlým CPU mohou nastat případy, kdy oba zásobníky dosáhnou plného potenciálu úložného zařízení; propustnost se proto nemusí zvýšit, ale využití zdrojů CPU by se snížilo.
Takeaways
Přestože se mnoho našich výsledků po aktivaci nového úložného stacku od sebe lišilo, byli jsme schopni potvrdit mnoho tvrzení společnosti Microsoft, včetně vyšší šířky pásma pro čtení s nižší latencí a sníženého využití CPU napříč všemi oblastmi. Vzhledem k tomu, že se jedná o poměrně radikální změnu oproti jejich desítky let starému úložnému stacku pro Windows Server, společnost Microsoft nejprve ve Windows Server vNext standardně povolí nativní NVMe. Naštěstí lze tuto funkci v systému Windows Server 2025 povolit rychlou úpravou registru nebo skupinovými zásadami, což odvážným správcům serverů umožní využít výhod nového stacku již dnes (po uznání rizik spojených s jeho nasazením).
Těšíme se, až bude nativní NVMe na platformě Windows Server standardně povoleno, a doufáme, že se k němu připojí výrobci NVMe SSD, RAID karet a HBA, kteří by měli být schopni posunout vylepšení od Microsoftu na další úroveň!
Reference
Hands, J., Worley, D. a Lakhveer Kaur. (nd). Jmenné prostory NVMe. Získáno 30. prosince 2025 z NVM Express: https://nvmexpress.org/resource/nvme-namespaces/
Lee, S. (15. září 2025). SNIA SDC 2025 – Storage Multi-Queue on Windows. San Tomas, CA, Spojené státy americké: Storage Networking Industry Association. Získáno 29. prosince 2025 z https://www.youtube.com/watch?v=dR-DWrmCba0&t
Lee, S. (16. září 2025). Vícefrontové úložiště v systému Windows: Nový stack pro vysoce výkonný úložný hardware. Získáno 29. prosince 2025 z konference vývojářů SNIA: https://www.snia.org/sites/default/files/2025-10/SNIA-SDC25-Lee-Storage-Multi-Queue-On-Windows.pdf
Shekar, Y. (15. prosince 2025). Oznámení nativního NVMe v systému Windows Server 2025: Zahajujeme novou éru výkonu úložišť. (Microsoft) Získáno 29. prosince 2025 z 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
Asociace průmyslu síťových úložišť. (nd). Co je SCSI? Získáno 30. prosince 2025 z Asociace průmyslu síťových úložišť: https://www.snia.org/education/what-is-scsi




Amazon