NVMe vs. SATA-SSD: Server-Storage-Leistung im Vergleich

Die Platten hinter Ihren Servern machen selten Schlagzeilen, doch sie entscheiden im Stillen, ob sich eine Datenbank augenblicklich oder träge anfühlt, ob ein Virtualisierungs-Host zwanzig VMs trägt oder vierzig und ob sich ein Storage-Upgrade rechnet oder nur die Rechnung aufbläht. Die Wahl zwischen NVMe und SATA- oder SAS-SSDs steht dabei im Mittelpunkt. Im Regal sehen sie ähnlich aus, beide sind Flash, beide Solid State, doch die Art, wie sie an das System angebunden sind, macht einen tiefgreifenden Unterschied bei der Leistung und einen ebenso wichtigen bei den Kosten.

Dieser Beitrag vergleicht beide anhand der entscheidenden Kennzahlen, IOPS, Latenz, Durchsatz und Lebensdauer, und macht daraus einen praktischen, gestuften Ansatz, mit dem Sie Storage zu jedem Workload passend wählen, ohne für Leistung zu zahlen, die Sie nie nutzen.

Der grundlegende Unterschied ist die Schnittstelle, nicht der Flash

Es ist ein verbreiteter Irrtum, NVMe sei einfach eine schnellere Art von Flash-Speicher. Das ist es nicht. Die Flash-Chips in einem NVMe-Laufwerk und in einer SATA-SSD können identisch sein. Was sich unterscheidet, sind das Protokoll und der Bus, über die sie mit der CPU sprechen.

SATA und SAS wurden vor Jahrzehnten für rotierende Festplatten entworfen. Gerade SATA trägt die Annahmen einer Zeit, in der Speicher mechanisch und langsam war: eine einzige Befehlswarteschlange, bescheidene Warteschlangentiefe und ein Controller-Pfad für Geräte, die Millisekunden zum Antworten brauchten. SAS ist das Enterprise-Geschwister mit Dual-Port, besserer Fehlerbehandlung und höheren Warteschlangentiefen, sitzt aber weiterhin auf einer Schnittstelle, die für rotierende Medien gedacht war.

NVMe (Non-Volatile Memory Express) wurde von Grund auf für Flash entworfen. Es bindet direkt über den PCIe-Bus an, dieselben Hochgeschwindigkeitslanes, die auch GPUs nutzen, und spricht ein Protokoll, das auf massive Parallelität ausgelegt ist. Während SATA eine einzige Warteschlange mit 32 Befehlen bietet, unterstützt NVMe Zehntausende Warteschlangen, jede Tausende Befehle tief. Dieser architektonische Unterschied, nicht der Flash selbst, ist die ganze Geschichte.

Leistung: IOPS, Latenz und Durchsatz

Übersetzt man diese Architektur in Zahlen, wird der Abstand offensichtlich.

Durchsatz

Eine SATA-III-SSD endet bei rund 550 MB/s, eine harte Obergrenze durch die 6-Gbit/s-Schnittstelle. SAS verdoppelt oder vervierfacht das mit 12- oder 24-Gbit/s-Verbindungen. NVMe zieht an beiden vorbei: Ein einzelnes PCIe-4.0-Laufwerk liefert bequem 5.000 bis 7.000 MB/s, eine Größenordnung jenseits von SATA, und PCIe-5.0-Laufwerke legen noch zu.

IOPS

Bei den zufälligen Operationen mit kleinen Blöcken, die reale Workloads dominieren, ist der Unterschied noch deutlicher. Eine gute SATA-SSD schafft vielleicht 90.000 bis 100.000 zufällige IOPS. Enterprise-NVMe-Laufwerke liefern routinemäßig Hunderttausende bis weit über eine Million. Wenn Dutzende VMs oder Datenbankverbindungen den Speicher mit gleichzeitigen kleinen Lese- und Schreibvorgängen bombardieren, halten die tiefen parallelen Warteschlangen von NVMe mit, während SATA einbricht.

Latenz

Bei der Latenz spüren Nutzer den Unterschied tatsächlich. NVMe-Antwortzeiten werden in zehn Mikrosekunden gemessen, SATA liegt im niedrigen dreistelligen Bereich. Das klingt belanglos, bis man es über Millionen Operationen multipliziert. Bei einer transaktionalen Datenbank, in der jede Abfrage auf den Speicher wartet, verkürzt geringere Latenz unmittelbar die Antwortzeit und erhöht die Zahl der Transaktionen pro Sekunde, die das System tragen kann.

Lebensdauer und Zuverlässigkeit

Leistung ist nur die halbe Wahrheit. Die Lebensdauer, also wie viele Daten sich über die Lebenszeit auf ein Laufwerk schreiben lassen, zählt beim richtigen Workload ebenso. Sie wird meist als DWPD (Drive Writes Per Day) oder TBW (Terabytes Written) angegeben.

Sowohl NVMe als auch SATA/SAS gibt es in lese-intensiven, gemischt genutzten und schreib-intensiven Klassen, sodass die Lebensdauer eher eine Frage der Laufwerksklasse als der Schnittstelle ist. Ein lese-intensives Laufwerk mit etwa 1 DWPD passt zu Boot-Volumes, Webinhalten und Analytik, die weit mehr liest als schreibt. Ein schreib-intensives Laufwerk mit 3 DWPD oder mehr ist für Transaktionslogs, Caching-Schichten und ausgelastete Datenbanken gebaut. Der zentrale Planungsfehler ist, einen schreiblastigen Workload auf ein lese-optimiertes Laufwerk zu legen, das es Jahre früher verschleißt. SAS behält bei bestimmten Enterprise-Zuverlässigkeitsmerkmalen einen Vorsprung, etwa der Dual-Port-Anbindung für redundante Pfade, weshalb es sich in manchen klassischen Arrays hält.

Kosten: wo der Aufpreis steckt

Wenn NVMe in jeder Leistungskennzahl gewinnt, warum kauft überhaupt noch jemand SATA? Wegen Kosten, Dichte und abnehmendem Grenznutzen.

Pro Gigabyte bleiben SATA-SSDs der günstigste Flash, den man kaufen kann, und sie erlauben es, große Kapazitäten wirtschaftlich in einen Server zu packen. NVMe trägt einen Aufpreis, weniger beim Flash als bei der Plattform: PCIe-Lanes sind auf jedem Mainboard eine endliche Ressource, und hochdichte NVMe-Server brauchen mehr Lanes, mehr Kühlung und mitunter teurere Gehäuse. Der Aufpreis ist stetig geschrumpft, doch für reine Kapazität, bei der rohe Geschwindigkeit belanglos ist, gewinnt SATA das Kostenargument klar.

Die wahre Verschwendung ist nicht, SATA zu kaufen, sondern NVMe für einen Workload zu kaufen, der es nicht nutzen kann. Ein Backup-Ziel oder ein Archiv schert sich nicht um Mikrosekundenlatenz; NVMe-Preise für kalte Daten zu zahlen ist verbranntes Geld.

Storage zum Workload passen: ein gestufter Ansatz

Die klügste Infrastruktur entscheidet sich nicht für eine einzige Technologie. Sie stuft den Speicher und leitet jeden Workload auf die passende Stufe, um über die gesamte Flotte Leistung und Kosten auszubalancieren.

Hot Tier: NVMe

Reservieren Sie NVMe für die Workloads, die wirklich am Speicher hängen. Transaktionale Datenbanken (PostgreSQL, MySQL, MongoDB unter Last), hochdichte Virtualisierungs-Hosts, auf denen viele VMs um I/O konkurrieren, Echtzeit-Analytik, Caching-Schichten und KI-Trainingspipelines, die hungrige GPUs füttern, rechtfertigen den Aufpreis allesamt. Hier übersetzt sich schnellerer Speicher direkt in mehr erledigte Arbeit pro Server, was oft weniger Server insgesamt bedeutet.

Warm Tier: SATA/SAS-SSD

Für die breite Mitte, Webserver, Anwendungsschichten, Dateifreigaben, Allzweck-VMs und die meisten Fachanwendungen, sind SATA- oder SAS-SSDs der ideale Punkt. Sie sind noch immer um ein Vielfaches schneller als jede rotierende Platte, vollkommen schnell genug, dass der Speicher nicht mehr der Engpass ist, und halten die Kosten pro Gigabyte niedrig.

Cold Tier: Kapazitätslaufwerke

Backups, Archive, Logs und selten genutzte Daten gehören auf SATA-SSDs hoher Kapazität oder sogar auf rotierende Platten, wo die Kosten pro Terabyte regieren und die Zugriffsgeschwindigkeit kaum zählt.

Wie sich das in einem verteilten Speichersystem auswirkt

In einer modernen Private Cloud hängt man Laufwerke selten isoliert an einen einzelnen Server. Speicher wird über Knoten hinweg von einem verteilten System gebündelt, und genau dort wird Tiering besonders wirkungsvoll. Eine Plattform wie Ceph erlaubt es, getrennte Pools mit unterschiedlichen Medien zu definieren: einen NVMe-gestützten Pool für latenzsensible Volumes und einen SATA-gestützten Pool für Massenkapazität, alles über dieselbe Schnittstelle bereitgestellt.

Ein verbreitetes und kosteneffizientes Muster nutzt NVMe nicht als Massenspeicher, sondern als Beschleunigungsschicht, die Write-Ahead-Logs, Metadaten und Caches vor einem größeren Pool günstigerer Laufwerke hält. So erhalten Sie viel von der Reaktionsfreude eines reinen NVMe-Flash, zahlen für die Kapazität aber SATA-Preise. Wer tiefer verstehen möchte, wie gebündelter, software-definierter Speicher das organisiert, findet in unserem Begleitbeitrag zu Ceph-Storage für die Private Cloud die Architektur im Detail.

Die Entscheidung treffen

Bringen Sie es pro Workload auf wenige Fragen herunter. Ist der Speicher der tatsächliche Engpass, oder limitieren CPU, Arbeitsspeicher oder das Netz? Wie latenzsensibel ist die Anwendung, Mikro- oder Millisekunden? Wie schreiblastig ist sie, und passt die Lebensdauerklasse des Laufwerks dazu? Und wie viel Kapazität brauchen Sie zu welchen vertretbaren Kosten? Beantworten Sie das ehrlich, und die richtige Stufe wählt sich meist von selbst.

Genau diese Entwurfsarbeit sollte vor dem Hardwarekauf geschehen, nicht danach. Bei clouditiv bauen wir OpenStack-Private-Clouds mit gestuftem, Ceph-gestütztem Storage und platzieren NVMe dort, wo Workloads wirklich I/O-gebunden sind, und Kapazitätslaufwerke dort, wo sie es nicht sind, damit Kunden für Leistung genau dort zahlen, wo sie sich auszahlt. Wie sich das in planbare Infrastruktur übersetzt, sehen Sie auf unserer Preisübersicht.

Das Wesentliche

NVMe ist keine geringfügig schnellere SATA-Platte, sondern eine andere Speicherarchitektur, die den Engpass alter Schnittstellen beseitigt und dort, wo Workloads sie nutzen können, Gewinne von einer Größenordnung bei IOPS und Latenz liefert. SATA und SAS bleiben die wirtschaftliche, vernünftige Wahl für alles, was nicht am Speicher hängt. Die siegreiche Strategie ist nicht, sich für eines zu entscheiden, sondern bewusst zu stufen: in NVMe zu investieren, wo es Antwortzeiten verkürzt und die Serverzahl senkt, und bei Kapazitätslaufwerken überall sonst zu sparen.