Am 15. Dezember 2025 kündigte Microsoft an, dass Windows Server 2025 den NVMe-Standard endlich nativ in seine Speicherarchitektur integrieren wird. NVMe-Speicher ist jedoch schon seit vielen Jahren ein gängiges Speicherformat für Server, Workstations und PCs und bietet seit Windows Server 2012 R2 und Windows 8.1 integrierte Betriebssystemkompatibilität. Vor diesem Hintergrund mag die Ankündigung einer „nativen“ NVMe-Unterstützung zunächst nicht wichtig oder gar berichtenswert erscheinen, doch wir versprechen Ihnen, dass mehr dahinter steckt.
Was bedeutet „Native NVMe“ überhaupt?
In früheren Versionen der Windows-Speicherarchitektur für Privat- und Servernutzer wurden Befehle zum Lesen und Schreiben von Daten unabhängig von den zugrunde liegenden Hardwareprotokollen stets in SCSI-Befehle übersetzt. Der Small Computer System Interface (SCSI)-Standard stammt aus den frühen 1980er-Jahren und wurde entwickelt, um Peripheriegeräte und Speicherlaufwerke mit Computern zu verbinden (Storage Networking Industry Association, o. J.). Er bildet die Grundlage für zahlreiche moderne Speicherprotokolle, die für verschiedene Anwendungsfälle eingesetzt werden, darunter netzwerkbasierte Protokolle wie iSCSI (Internet Small Computer System Interface) und FCP (Fibre Channel Protocol) sowie lokale Speicherschnittstellen wie SAS (Serial Attached SCSI) und UASP (USB Attached SCSI).
Der alte Weg
Durch die Umwandlung verschiedener Protokolle in SCSI-Befehle vereinheitlichte Microsoft die Speicherbefehle auf höheren Ebenen des Betriebssystems. Allerdings wurden dabei viele der Skalierbarkeits- und Leistungsverbesserungen moderner Speicherarchitekturen geopfert. Der alte Ablauf für E/A-Operationen sah folgendermaßen aus:
- Lese- und Schreibvorgänge finden im oberen Speicherstapel auf Dateisystemebene statt.
- Die Befehle werden an den Disk.sys-Treiber weitergeleitet.
- Disk.sys übersetzt generische Speicherbefehle in SCSI-Befehle.
- Storport empfängt die SCSI-Befehle und sendet sie an den entsprechenden Miniport-Treiber (z. B. StorAHCI.sys für SATA-Laufwerke).
- Der zugehörige Miniport-Treiber kommuniziert direkt mit dem Speichermedium und übersetzt die Befehle wieder in das entsprechende Speicherformat.
Andere SCSI-Konventionen, wie z. B. LUNs (Logical Unit Numbers), die zur Identifizierung von Datenpartitionen auf einem Speichermedium verwendet werden, wurden in den Windows-Speicherstack übernommen, obwohl neuere Konzepte wie NVMe-Namespaces schon seit geraumer Zeit existieren (Hands, Worley, & Lakhveer Kaur, o. J.).
Der neue Standard
Die neueste Speicherarchitektur von Microsoft für Windows Server 2025 ermöglicht neue Funktionen in Storport und ersetzt Disk.sys durch NVMeDisk.sys. Dadurch entsteht ein skalierbares, zukunftssicheres und leistungsstarkes Framework.
- Lese- und Schreibvorgänge finden im oberen Speicherstapel auf Dateisystemebene statt.
- Die Befehle werden direkt von NVMeDisk.sys an den neuen StorMQ-Code innerhalb von Storport weitergeleitet.
- StorMQ generiert für jeden Lese- und Schreibvorgang die entsprechenden NVMe-Befehle (oder Befehle für andere Speichertypen) und sendet diese direkt an die Hardware.
(Abbildung aus Scott Lees Präsentation auf der SNIA Developer Conference am 16. September 2025)
Dieser neue Standard für Laufwerksoperationen unter Windows Server 2025 eliminiert eine Übersetzungsebene und integriert sich vollständig in die Speicherbefehlswarteschlangen von NVMe-, RAID- und HBA-Geräten. Die Optimierung des Windows-Speichersystems bietet weitere Vorteile, wie z. B. eine geringere CPU-Auslastung durch den Wegfall unnötiger Speicherbefehlsübersetzungen und eine verbesserte Auslastung logischer Prozessoren. Die neue Architektur unterstützt weitere NVMe-Spezifikationen, wie NVMe-Namespaces und Plug-and-Play. Sie ermöglicht die Erstellung hersteller- oder gerätespezifischer Speicher-Miniport-Treiber, die in Windows integriert werden können, um eine höhere Kompatibilität und Leistung mit neuen Speichergeräteklassen zu erzielen (Lee, SNIA SDC 2025 – Storage Multi-Queue on Windows, 2025).
Bereit zum Testen?
In seiner Präsentation auf der SNIA Developer Conference am 16. September 2025 gab Scott Lee bekannt, dass Microsoft bereits eng mit Herstellern zusammenarbeitet, um neue Treiber für Geräte wie RAID-Karten und HBAs zu entwickeln. Dies deutet darauf hin, dass die Verbesserungen an StorMQ in Kürze verfügbar sein werden oder auf vielen Speichergeräten bereits aktiviert sind. Die Funktion wurde im vergangenen Dezember als allgemein verfügbar angekündigt, der neue Speicherstack ist jedoch nur optional und erfordert das Hinzufügen eines Registrierungsschlüssels. Die Schritte zur Aktivierung finden Sie hier: Microsofts Ankündigungsartikel zu nativem NVMe.
Warnung: Eine fehlerhafte Änderung der Registrierung kann schwerwiegende Probleme verursachen. Testen Sie dies daher unbedingt zuerst auf einem nicht kritischen Server. Mehrere Benutzer, die diese Funktion aktiviert haben, berichteten von Problemen mit NVMe-Laufwerken, bei denen die Deduplizierung aktiviert ist. Obwohl ein offizieller Fix von Microsoft in Kürze verfügbar sein wird, erfolgt die Durchführung auf eigenes Risiko!
Testen von nativem NVMe auf Windows Server 2025
Unsere Testplattform zur Evaluierung von nativem NVMe unter Windows Server 2025 (OS Build 26100.32370) bestand aus einem Dual-SP5-Server mit zwei 128-Kern-AMD-EPYC-9754-Prozessoren. Neben den Mehrkernprozessoren verfügte der Server über beeindruckende 768 GB DDR5-Speicher mit einer Übertragungsrate von 4800 MT/s.
Hinweis: Laut Yash Shekar von Microsoft wurde für Windows Server 2025 bereits eine Zwischenverbesserung veröffentlicht, die nicht mit nativem NVMe zusammenhängt und möglicherweise eine zusätzliche Leistungssteigerung für den nicht-nativen Speicherstapel bewirkt hat, wodurch die potenziellen Ergebnisunterschiede verringert wurden.
Um das Potenzial des neuen Speichersystems zu bewerten, verwendeten wir fünfzehn 30.72 TB Solidigm P5316 NVMe SSDs mit PCIe 4.0 in einer JBOD-Konfiguration. Wichtig zu beachten ist, dass der Solidigm P5316 eine Indirektionseinheit von 64 Kilobyte besitzt. Dies führt dazu, dass Schreibergebnisse bei kleineren Blockgrößen (z. B. 4K-Tests) oft schlechter als erwartet ausfallen. Angesichts dieser größeren Indirektionseinheit führten wir FIO-Benchmarks mit Lese- und Schreibtests für zufällige 4K-, zufällige und sequentielle 64K- sowie sequentielle 128K-Blockgrößen durch, um die Gesamtgeschwindigkeit über verschiedene Blockgrößen hinweg zu vergleichen. Zusätzlich überwachten wir die CPU-Auslastung während der Tests, um die von Microsoft behauptete höhere Effizienz zu überprüfen.
Highlights
- Massiv erhöhte Bandbreite und IOPS beim zufälligen Lesen von 4K- und 64K-KB-Daten.
- Niedrigere Latenzzeiten beim zufälligen Lesen von 4K- und 64K-Daten
- Deutliche Reduzierung der CPU-Auslastung bei sequenziellen Lese- und Schreibvorgängen über verschiedene Blockgrößen hinweg.
| Metrisch | Zufällige 4K | Zufällige 64K | Sequenziell 64K | Sequenziell 128K | ||||
|---|---|---|---|---|---|---|---|---|
| Nicht-Einheimischer | Ureinwohner | Nicht-Einheimischer | Ureinwohner | Nicht-Einheimischer | Ureinwohner | Nicht-Einheimischer | Ureinwohner | |
| Lesen Sie mehr | ||||||||
| Bandbreite (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 |
| Durchschnittliche Latenz (ms) | 0.169 | 0.104 | 0.239 | 0.207 | 0.809 | 0.812 | 0.613 | 0.608 |
| Gesamte CPU-Auslastung (%) | 72.67 | 74.22 | 68.44 | 65.11 | 44.89 | 37.11 | 61.56 | 49.56 |
| Metrisch | Zufällige 4K | Zufällige 64K | Sequenziell 64K | Sequenziell 128K | ||||
|---|---|---|---|---|---|---|---|---|
| Nicht-Einheimischer | Ureinwohner | Nicht-Einheimischer | Ureinwohner | Nicht-Einheimischer | Ureinwohner | Nicht-Einheimischer | Ureinwohner | |
| Schreiben | ||||||||
| Bandbreite (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 |
| Durchschnittliche Latenz (ms) | 0.992 | 1.028 | 3.814 | 3.816 | 0.399 | 0.558 | 1.022 | 1.149 |
| Gesamte CPU-Auslastung (%) | 26.00 | 20.67 | 12.22 | 9.33 | 70.44 | 57.78 | 58.44 | 47.33 |
Analyse der Ergebnisse
Beginnend mit Benchmarks für zufällige 4K- und 64K-Lesezugriffe beobachteten wir deutlich höhere Lesegeschwindigkeiten. Der Unterschied zwischen dem nativen und dem nicht-nativen Speichersystem betrug beim zufälligen 4K-Lesezugriff fast 4 GiB/s, beim zufälligen 64K-Lesezugriff sogar fast 16.9 GiB/s. Auch bei sequenziellen 128K-Lesezugriffen stellten wir eine deutliche Steigerung fest; unsere Tests ergaben eine um etwa 5.8 GiB/s höhere Bandbreite.
Interessanterweise konnten wir bei unseren Tests der zufälligen und sequenziellen Schreibbandbreite keine signifikanten Steigerungen feststellen. Der einzige nennenswerte Unterschied war eine Erhöhung der sequenziellen Schreibgeschwindigkeit um etwa 5.4 GiB/s bei 64-KB-Schreibvorgängen. Die meisten unserer Ergebnisse lagen innerhalb einer Spanne von 100 MiB/s, was darauf hindeutet, dass die Leistung des neuen Speichersystems zumindest in Fällen, in denen keine Verbesserung erzielt wurde, mit der des alten vergleichbar ist.
Da der Durchsatz typischerweise mit der Latenz korreliert, beobachteten wir auch deutliche Rückgänge der durchschnittlichen Latenz beim zufälligen Lesen sowohl bei 4K- als auch bei 64K-Tests. Wir stellten eine Verringerung der Latenz beim nicht-nativen zufälligen Lesen von 4K um 38.46 % fest, von 0.169 Millisekunden auf 0.104 Millisekunden. Bei den Tests mit zufälligem Lesen von 64K fiel der Rückgang mit rund 13.39 % geringer aus. Die Latenz veränderte sich bei sequenziellen Leseoperationen nicht drastisch, jedoch stiegen zufällige und sequenzielle Schreiboperationen durchweg an, trotz ähnlichem oder höherem Durchsatz.
Neben der Steigerung der zufälligen Lesegeschwindigkeiten zeigte sich in unseren FIO-Tests ein weiterer interessanter Trend: eine deutliche Reduzierung der gesamten CPU-Auslastung bei sequenziellen Lese- und Schreibvorgängen mit 64 KB und 128 KB. Die deutlichsten Unterschiede zeigten sich bei den sequenziellen Schreibtests mit einem durchschnittlichen Rückgang der CPU-Auslastung um 12.66 % bei 64 KB und einem nahezu identischen Rückgang um 11.11 % bei 128 KB. Auch der von uns durchgeführte sequenzielle Lesetest mit 128 KB ergab eine entsprechende Reduzierung der Auslastung um 12 %, während der Rückgang beim sequenziellen Lesen mit 64 KB nur 7.78 % betrug. Zu berücksichtigen ist, dass bei einer ausreichend schnellen CPU in manchen Fällen beide Stacks das volle Potenzial eines Speichermediums ausschöpfen können; in diesem Fall würde der Durchsatz möglicherweise nicht steigen, die CPU-Ressourcenauslastung aber sinken.
Takeaways
Obwohl viele unserer Ergebnisse nach Aktivierung des neuen Speichersystems innerhalb der üblichen Schwankungsbreite lagen, konnten wir viele Aussagen von Microsoft bestätigen, darunter eine höhere Lesebandbreite bei geringerer Latenz und eine insgesamt reduzierte CPU-Auslastung. Da es sich hierbei um eine grundlegende Änderung des jahrzehntealten Windows Server-Speichersystems handelt, wird Microsoft natives NVMe zunächst standardmäßig in Windows Server vNext aktivieren. Glücklicherweise lässt sich die Funktion in Windows Server 2025 mit einer einfachen Registry-Änderung oder einer Gruppenrichtlinie aktivieren, sodass mutige Serveradministratoren die Vorteile des neuen Systems bereits heute nutzen können (nachdem sie die damit verbundenen Risiken erkannt haben).
Wir freuen uns darauf, dass native NVMe-Unterstützung standardmäßig auf der Windows Server-Plattform aktiviert wird, und hoffen auf die Unterstützung der Hersteller von NVMe-SSDs, RAID-Karten und HBAs, die die Verbesserungen von Microsoft auf die nächste Stufe heben können sollten!
Referenzen
Hands, J., Worley, D. & Lakhveer Kaur. (o. J.). NVMe-Namensräume. Abgerufen am 30. Dezember 2025 von NVM Express: https://nvmexpress.org/resource/nvme-namespaces/
Lee, S. (15. September 2025). SNIA SDC 2025 – Storage Multi-Queue unter Windows. San Tomas, CA, USA: Storage Networking Industry Association. Abgerufen am 29. Dezember 2025 von [URL einfügen]. https://www.youtube.com/watch?v=dR-DWrmCba0&t
Lee, S. (16. September 2025). Storage Multi-Queue unter Windows: Ein neuer Stack für Hochleistungsspeicherhardware. Abgerufen am 29. Dezember 2025 von der SNIA Developer Conference. https://www.snia.org/sites/default/files/2025-10/SNIA-SDC25-Lee-Storage-Multi-Queue-On-Windows.pdf
Shekar, Y. (15. Dezember 2025). Ankündigung von nativem NVMe in Windows Server 2025: Beginn einer neuen Ära der Speicherleistung. (Microsoft) Abgerufen am 29. Dezember 2025 von 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. (o. J.). Was ist SCSI? Abgerufen am 30. Dezember 2025 von der Website der Storage Networking Industry Association. https://www.snia.org/education/what-is-scsi
Amazon