Windows Server nimmt NVMe endlich ernst, doch die Storage-Leute trauen dem Braten noch nicht

Es gibt wenig Befriedigenderes in der Infrastruktur, als zuzusehen, wie eine alte Annahme von einem Benchmark eins auf die Mütze bekommt. Jahrelang trug Windows Server in Storage-Kreisen einen Ruf, der von "okay für bestimmte Workloads" bis "warum ist das immer noch so?" reichte. Linux bekam zuerst das coole Storage-Spielzeug, es bekam die sauberere NVMe-Story, und es bekam den effizienten Netzwerk-Stack, das User-Space-Treiber-Ökosystem und die SPDK-Dynamik. Wer sich für rohe Storage-Performance interessierte, wartete also kaum darauf, dass Microsoft die Parade anführt.

Dann taucht Windows Server 2025 in Benchmark-Form auf, mit nativen NVMe-Verbesserungen, Änderungen am Storage-Stack und Ergebnissen, die stark genug sind, um selbst manche abgehärtete Skeptiker innehalten zu lassen. Der ursprüngliche Beitrag verwies auf StorageReviews natives NVMe-Testing für Windows Server 2025, und die Diskussion wurde schnell größer als der Benchmark selbst: Microsofts Storage-Stack, NVMe-oF-Frust, Linux-Vergleiche, Drittanbieter-Initiatoren, Windows' langfristige Zukunft und die Frage, ob irgendjemand bei klarem Verstand das schon in Produktion laufen lassen sollte.

Emotional läuft im Thread eine einfache Spannung mit: Die Leute wollen, dass Windows Server besser wird, sie wollen nur nicht diejenigen sein, die es auf die harte Tour beweisen.

Der Benchmark war beeindruckend, aber Vertrauen lässt sich nicht sauber benchmarken

Die interessanteste Reaktion war Überraschung, und blinder Jubel blieb aus. Eine Stimme gab zu, ernsthaft beeindruckt zu sein, und sagte, es sei selten, dass jemand die Erwartungen so übertreffe. Man war auch überrascht, dass Windows im Folgevergleich Linux übertreffen konnte, weil Linux traditionell bei Storage- und Netzwerk-Effizienz die Nase vorn hatte. Solche Sätze treffen, weil sie von genau der Sorte Mensch kommen, die Microsoft normalerweise keinen leichten Sieg gönnt.

Storage-Leute sind nämlich nicht sentimental gegenüber Betriebssystemen. Sie interessieren sich für Latenz, Durchsatz, CPU-Effizienz, Kompatibilität, Observability und Ausfallverhalten. Wenn Windows echte Zahlen liefert, verdienen diese Zahlen Aufmerksamkeit. Eine Überarbeitung des Storage-Stacks, die tatsächlich die native NVMe-Performance verbessert, ist mehr als ein kosmetisches Detail. Sie legt nahe, dass Microsoft zumindest eine Ebene anfasst, von der viele Admins annahmen, sie sei vernachlässigt worden, während der Konzern Azure, KI und Abo-Umsätze jagte.

Benchmarks sind trotzdem nur der Anfang, weil Infrastruktur-Vertrauen unter hässlichen Bedingungen verdient wird und nicht in kontrollierten Tests. Was passiert nach Monaten im Dauerbetrieb, was passiert über verschiedene Firmware-Versionen hinweg, und was passiert, wenn NIC-Treiber, Storage-Treiber, Multipathing, Failover und Hersteller-Targets alle in einem einzigen miesen Support-Fall aufeinandertreffen? Was passiert, wenn das System an einem Dienstag gepatcht wird und die Storage-Latenz plötzlich spukt?

Deshalb konnten manche die Ergebnisse bewundern und sich trotzdem weigern, überstürzt loszulegen. Ein Kommentator sagte, selbst wenn das Feature bald käme, würde er mindestens ein Jahr warten, bevor er einen Produktionseinsatz erwägt, weil er lieber andere Leute für Microsoft in Produktion betatesten lassen wolle. Mit Feigheit hat das wenig zu tun, eher mit Überlebensinstinkt.

NVMe-oF ist das fehlende Puzzleteil, über das alle schimpfen

Der lauteste Frust im Thread drehte sich um NVMe-oF. Ein Kommentator meinte, man solle ihn anrufen, sobald Microsoft es endlich für NVMe-oF hinbekomme und der Storage-Stack "im aktuellen Jahrzehnt ankomme". Diese Zeile hat Biss, weil NVMe over Fabrics seit Jahren keine obskure Zukunftsidee mehr ist. In High-Performance-Storage-Umgebungen gehört es zum modernen Standard, und wenn Windows im ernsthaften Storage-Umfeld relevant bleiben will, reichen native NVMe-Geräte allein nicht. Fabric-Konnektivität zählt genauso.

Die Antwort darauf war differenzierter. Jemand sagte, das Gerüchteregal deute darauf hin, dass NVMe-oF vielleicht im Herbst kommen könnte, warnte aber davor, das als gegeben hinzunehmen. Dann kam die tiefergehende Kritik: Windows fehlt ein richtiger Polling-Modus, es fehlen interrupt-lose Operationen und User-Mode-Storage-Treiber der Art, die High-Performance-Storage-Stacks anderswo effizient machen. Deshalb wurde SPDK unter Windows quasi als Witz beschrieben, bei dem das Erreichen ähnlicher IOPS-Werte die CPU-Auslastung durch die Decke treibt.

Das ist die eigentliche technische Beschwerde, und sie reicht über ein simples "Microsoft ist spät dran" hinaus. Windows hat bestimmte moderne Storage-Ansätze historisch schwerer gemacht, als sie sein müssten. Die Linux-Welt war schon immer der natürlichere Ort für User-Space-Storage-Experimente, Kernel-Bypass und hocheffiziente Pfade. Windows kann durchaus schnell vorankommen, wenn Microsoft es ernst genug meint. Aber im Storage-Bereich haben viele Ingenieure das Gefühl, dass die Plattform einen schweren Legacy-Karren hinter sich herzieht.

Es gab auch einen praktischen Blick auf Drittanbieter. Ein Kommentator schlug vor, den StarWind-NVMe-oF-Initiator auszuprobieren, und sagte, er nutze ihn seit über sechs Jahren und könne damit doppelte 100-Gbit-NICs bei Sub-Millisekunden-Latenz auslasten. Eine andere Person antwortete, sie kenne das Tool, sei aber nicht sicher, ob sie die Kronjuwelen ihres Unternehmens darauf verlassen wolle. Dieser Austausch bringt das ganze Problem auf den Punkt, denn Drittanbieter-Tools können Lücken füllen und sogar gut performen. Sobald der Workload wichtig genug ist, fühlen sich native Unterstützung und Vertrauen auf Plattformebene aber anders an. Niemand möchte, dass sich der wichtigste Datenpfad wie ein cleverer Workaround anfühlt.

Windows Server hat auch ein Glaubwürdigkeitsproblem

Die härtesten Kommentare zielten kaum auf NVMe, sie zielten auf Windows Server als Produkt. Eine Person sagte, Windows sei frustrierend, weil es sich als Server-Betriebssystem rückständig und zäh in der Weiterentwicklung anfühle. Eine andere ging noch weiter und fragte, warum Microsoft überhaupt noch so tue, als entwickle man Windows aktiv weiter, und schlug vor, man solle zu einem Linux- oder BSD-Kernel wechseln und allen das Leid ersparen. Das ist hart, spiegelt aber jahrelang angestaute Verärgerung wider.

Der Gegenpunkt war pragmatisch. Microsoft hat immer noch eine riesige Basis an Firmenkunden, die von Windows abhängig sind. Würde der Konzern offen signalisieren, dass Windows keine Zukunft hat, würden Kunden mit dem Portemonnaie abstimmen und ihre Business-Apps zu Linux oder SaaS verlagern. Jemand verglich diese Art von Plattform-Unsicherheit mit den alten DEC-Alpha- oder Sun-SPARC-Momenten, wo der Exodus begann, sobald die Kunden die Schrift an der Wand sahen.

Deshalb hält Microsoft Windows in Bewegung, auch wenn Teile der technischen Community glauben, die Energie sei anderswo hingewandert. Windows hängt an einem ganzen Ökosystem aus Anwendungskompatibilität, Unternehmensrichtlinien, Management-Tools, Authentifizierungsmustern, Hersteller-Support-Matrizen und Jahrzehnten an Business-Software. Man kann dieser Welt nicht einfach beiläufig sagen, sie solle weiterziehen.

Trotzdem hat die Kritik Gewicht. Mehrere Leute argumentierten, die eigentliche technische Schwerkraft innerhalb von Microsoft habe sich Richtung Azure und neuere Goldgräber-Bereiche verlagert, wodurch Windows Server unterversorgt wirke. Ein Kommentator behauptete, Leute mit Microsoft-Kontakten hätten gesagt, dass eine Zeit lang kaum noch ein echtes Kern-Windows-Team übrig geblieben sei, weil viele Leute entlassen, in Rente gegangen oder in Azure- und KI-Arbeit verschoben worden seien. Das mag eher Gerüchte-Niveau als belegte Tatsache sein, aber die Wahrnehmung zählt, weil Admins Plattformen zum Teil danach beurteilen, wohin sie die Aufmerksamkeit des Herstellers gerichtet sehen. Ein Benchmark kann beweisen, dass sich ein Codepfad verbessert hat, er kann aber nicht sofort beweisen, dass Microsoft sich wieder kümmert.

Der Linux-Neid sitzt immer noch mit im Raum

Die Windows-versus-Linux-Debatte wurde schnell philosophisch. Eine Person argumentierte, die meisten Unternehmen verließen sich nicht so sehr auf den Windows-Kernel selbst wie auf Userland und die Hooks in den Kernel. Sie verwies auf Wine als Beleg dafür, dass eine Win32-Abstraktionsschicht funktionieren kann, und argumentierte, Microsoft habe bereits große Software wie SQL Server auf Linux portiert. Aus ihrer Sicht könnte Microsoft den Kernel fallen lassen, auf eine Abstraktionsschicht umsteigen und weitermachen.

Die Antwort darauf war bodenständiger. Wine-artige Kompatibilität funktioniert bei einfacheren Win32-Mustern, aber sobald Anwendungen stark auf Memory-Mapped-I/O, Completion Ports, APCs und andere zutiefst Windows-spezifische Verhaltensweisen setzen, wird es hässlich. Je "windowsiger" eine Anwendung wirklich ist, desto schwerer lässt sie sich zu Linux verschieben, ohne Performance oder Stabilität zu verlieren. Manchmal ist es leichter, neu zu schreiben, als das Ding hinüberzuschleppen.

Dieser Austausch trifft den Kern dessen, warum Windows Server überlebt. Die technische Szene mag von einer saubereren Linux-basierten Zukunft träumen, aber die Enterprise-Realität ist klebrig. Anwendungen sind eigenartig, Abhängigkeiten sind alt, Hersteller zertifizieren langsam, und interne Teams fürchten Migrationen mehr, als sie Ineffizienz hassen. Kompatibilität ist unelegant und trotzdem mächtig.

Storage steckt in derselben Zwickmühle. Linux wirkt oft wie die Plattform, auf der moderne Storage-Ideen zuerst ankommen. Windows bleibt tief in Unternehmensumgebungen verankert, die weiterhin bessere Storage-Performance, bessere NVMe-Unterstützung und bessere Integration mit modernen Fabrics brauchen. Aufgeben kann Microsoft den Stack also nicht; der Konzern muss ihn genug modernisieren, um Windows-Workloads glaubwürdig zu halten. Deshalb zählen diese Benchmark-Ergebnisse: Sie legen nahe, dass Windows Server technisch immer noch überraschen kann, auch wenn Überraschung noch keine Dominanz ist.

Die QA-Angst blockiert den Produktionseinsatz am stärksten

Der stärkste Grund, nicht in Produktion zu stürzen, war QA-Angst. Ein Kommentator warnte, ein Jahr Wartezeit könnte sogar optimistisch sein, angesichts der wahrgenommenen mangelnden Qualitätssicherung bei Microsoft und des Verlusts von Leuten, die früher Plug-Tests, herstellerübergreifende Validierung und Interoperabilitätsarbeit übernommen hatten. Man verglich das mit der eigenen Erfahrung, seit etwa 2018 oder 2019 einen Drittanbieter-NVMe-oF-Initiator zu betreiben, der erst nach Jahren voller Kompatibilitätsprobleme über Targets, Treiber und NIC-Firmware hinweg wirklich brauchbar geworden sei.

Genau diese Art von Narbe nehmen Storage-Teams ernst. NVMe ist inzwischen mehr als schnelles lokales Medium, und sobald Fabrics ins Spiel kommen, explodiert die Fehlermatrix. Initiatoren, Targets, NIC-Firmware, Switches, Treiber, Multipath-Verhalten, Timeout-Handling, Congestion, Firmware-Updates und Betriebssystem-Patches werden alle Teil der Geschichte. Ein Benchmark zeigt den Happy Path, die Produktion zeigt, ob das Ökosystem schon Zahnspuren trägt.

Hier muss Microsoft mehr tun, als nur ein Feature auszuliefern. Der Konzern muss beweisen, dass sich das Feature über Hersteller und Updates hinweg vorhersehbar verhält, und das bedeutet Dokumentation, Zertifizierung, Referenzarchitekturen, klare Support-Grenzen und genug Praxis-Historie, damit Kunden sich nicht mehr wie unbezahlte Validierungslabore fühlen.

Storage-Admins haben gelernt, eine unspektakuläre Frage zu stellen: Wer hat das schon so oft schlecht laufen lassen, dass die Bugs gefunden wurden? Solange es darauf keine gute Antwort gibt, gewinnt die Vorsicht.

Natives NVMe ist ein Anfang, aber die Storage-Welt ist längst weitergezogen

Die nativen NVMe-Verbesserungen in Windows Server 2025 sind wirklich bedeutsam. Lokale NVMe-Performance zählt für Datenbanken, Analytics, Hyper-V-Umgebungen, Edge-Workloads, Caching, Storage-Spaces-Szenarien und jedes System, bei dem latenzarmer lokaler Flash-Speicher das Anwendungsverhalten verändert. Ein saubererer, schnellerer Windows-Storage-Stack kann echten Kunden helfen.

Die Storage-Welt dreht sich aber längst nicht mehr nur um lokale Laufwerke. Moderne Infrastruktur handelt zunehmend von disaggregiertem Storage, Fabrics, gebündelter Performance, geteiltem Flash, Cloud-nahen Architekturen und Hochgeschwindigkeitsnetzwerken, die entfernten Storage für ernsthafte Workloads lokal genug wirken lassen. Daher rührt der NVMe-oF-Frust. Die Leute lesen an diesem Feature ab, ob Windows Server in der nächsten Storage-Architektur vollwertig mitspielen kann.

Ein Kommentator wies darauf hin, dass Microsoft sein iSCSI-Target vor Jahren von String Bean Software übernommen hat, während der iSCSI-Initiator ursprünglich intern entwickelt wurde. Diese kleine Geschichtsstunde zählt, weil Windows schon früher sowohl auf interne als auch auf zugekaufte Bausteine gesetzt hat, um Storage-Lücken zu schließen. Die Frage ist jetzt, ob Microsoft moderne NVMe-oF-Unterstützung tief genug baut, um sich wie ein First-Class-Bürger anzufühlen, oder ob der Markt weiter auf Drittanbieter und Workarounds angewiesen bleibt. Ein natives Feature kann die Wahrnehmung schnell ändern, wenn es funktioniert, und ein halbgares kann die Leute noch zynischer machen. Auf diesem schmalen Grat wandelt Microsoft gerade.

Die seltsamste Reaktion war Optimismus

Unter all dem Spott steckte im Thread etwas fast Hoffnungsvolles. Leute scherzten über Bier-Care-Pakete, nachdem StorageReview mit Linux-gegen-Windows-Tests nachgelegt hatte. Der ursprüngliche Poster gab zu, beeindruckt und überrascht zu sein. Selbst manche Skeptiker klangen weniger danach, als wollten sie, dass Windows scheitert, sondern eher erschöpft davon, darauf zu warten, dass es aufholt.

Hinter dem Frust der Storage-Community mit Windows steckt oft eher Enttäuschung als Hass. Windows läuft überall, es betreibt ernsthafte Workloads, und es sitzt in Unternehmen, die nicht alles zu Linux verlagern können oder wollen. Wenn Microsoft Storage besser macht, profitieren viele Leute davon.

Dieser Nutzen hängt aber an Vertrauen. Storage-Teams brauchen nicht, dass Microsoft jeden Benchmark gewinnt, sie brauchen moderne Storage-Features, die stabil, effizient, gut dokumentiert, supportet und in der Produktion langweilig sind. Langweilig ist hier das Kompliment: Niemand beobachtet, wie die CPU-Auslastung hochschießt, weil der Pfad ineffizient ist, Firmware-Kombinationen werden nicht zur Archäologie, und NVMe-oF braucht keinen Forenthread, keinen Drittanbieter-Initiator und kein Stoßgebet.

Die nativen NVMe-Ergebnisse von Windows Server 2025 sind vielleicht das erste wirklich interessante Zeichen seit Langem, dass Microsoft den Storage-Stack noch voranbringen kann. Der Applaus ist echt, das Misstrauen ist es genauso, und im Enterprise-Storage hat das Misstrauen die letzte Stimme im Change-Control-Prozess.