Lokales NVMe vs. Netzwerk-Storage: der ehrliche Vergleich
Bei der Wahl eines Servers entscheidet der Storage oft mehr über die gefühlte Geschwindigkeit als die CPU. Dieser Ratgeber vergleicht lokales NVMe mit Netzwerk-Storage (SAN, Ceph, Cloud-Volumes) — nach Latenz, Durchsatz, Persistenz und Anfälligkeit für laute Nachbarn — und zeigt, warum Datenbanken und Build-Server auf einem Cloud-Server mit lokalem NVMe spürbar schneller laufen.
Cloud-Server mit lokalem NVMeLokales NVMe ist eine SSD, die direkt über PCIe im selben Host steckt, auf dem auch deine VM läuft. Netzwerk-Storage — ob SAN, verteiltes Ceph oder ein Cloud-Volume — liegt dagegen auf separaten Systemen und wird über ein Netzwerk angebunden. Dieser eine Unterschied im Datenpfad erklärt fast alle Vor- und Nachteile, die folgen.
Lokales NVMe vs. Netzwerk-Storage: die Grundlagen
Beim lokalen NVMe ist der Weg zu den Daten kurz: CPU, RAM und Flash sitzen in derselben Maschine. Beim Netzwerk-Storage muss jede Anfrage über das Netz zu einem Storage-Knoten und wieder zurück — plus der Overhead des Storage-Clusters. Das kostet Latenz, bringt aber einen entscheidenden Vorteil bei der Persistenz.
Latenz und Durchsatz
Für viele kleine, zufällige Zugriffe zählt vor allem die Latenz — und die ist bei lokalem NVMe um Größenordnungen niedriger, weil keine Netzwerk-Hops dazwischenliegen. Beim sequenziellen Durchsatz kann gut angebundenes Netzwerk-Storage näher herankommen, wird aber durch den Uplink begrenzt. Wer viele parallele Random-Writes hat, spürt den Unterschied am deutlichsten.
| Kriterium | Lokales NVMe | Netzwerk-Storage (SAN/Ceph) |
|---|---|---|
| Latenz | Sehr niedrig (direkt über PCIe) | Höher (Netzwerk-Hops) |
| Zufalls-IOPS | Sehr hoch | Vom Netz und den Nachbarn abhängig |
| Durchsatz | Volle lokale Bandbreite | Durch den Uplink begrenzt |
| Persistenz bei Host-Ausfall | An den Host gebunden | Unabhängig vom Compute-Host |
| Live-Migration | Eingeschränkt | Einfach |
| Laute Nachbarn | Nur lokale VMs | Geteiltes Storage-Cluster |
| Ideal für | Datenbanken, Builds, Caches | Hochverfügbarkeit, große geteilte Volumes |
Der Persistenz-Trade-off
Hier gewinnt Netzwerk-Storage fair und ehrlich: Weil die Daten vom Compute entkoppelt sind, überstehen sie den Ausfall eines einzelnen Hosts und ermöglichen Live-Migration und einfache Skalierung. Lokales NVMe ist dagegen an seinen Host gebunden — fällt der aus, sind die Daten dort. Die Antwort darauf sind saubere Backups und, wo nötig, Redundanz auf Anwendungsebene.
Laute Nachbarn auf dem SAN
Ein geteiltes Storage-Cluster hat dasselbe Grundproblem wie ein überbuchter Host: Wenn ein Nachbar das Storage mit IO flutet, spüren es alle anderen. Das ist die Storage-Variante der Überbuchung — nur eben für IOPS statt für CPU-Takte. Lokales NVMe teilst du dir höchstens mit den wenigen VMs auf demselben Host, nicht mit einem ganzen Cluster.
Warum lokales NVMe für Datenbanken und Builds gewinnt
- Datenbanken (PostgreSQL, MySQL): profitieren massiv von niedriger Latenz bei vielen kleinen Random-Writes — die Commit-Latenz sinkt.
- CI/CD- und Build-Server: viele kleine Dateizugriffe (node_modules, Compiler-Caches) laufen auf lokalem NVMe deutlich schneller.
- Caches und Suchindizes (Redis-Persistenz, Elasticsearch): niedrige Latenz hält die Antwortzeiten stabil.
- Analyse-Workloads: hoher sequenzieller Durchsatz ohne Netzwerk-Flaschenhals.