NVMe vs. SATA-SSD für VPS: Leistung, Workloads und Kosten

Zwei Tarife können dieselbe Zahl an vCPU und denselben Arbeitsspeicher aufweisen, und doch schließt der eine eine Datenbankmigration in Minuten ab, während der andere eine Stunde lang hängt. Der Unterschied liegt meist im Speicherpfad: NVMe-Laufwerke, angebunden über PCIe, gegenüber SATA- oder SAS-SSDs hinter einem klassischen Controller.

Dieser Leitfaden erklärt, was die beiden tatsächlich unterscheidet, welche Workloads von NVMe profitieren und welche nicht, wie Sie einen Server vor einer Festlegung selbst mit fio messen und warum Transferkontingente und Standort in dieselbe Entscheidung gehören.

Was sich tatsächlich unterscheidet: Schnittstelle, Protokoll und Warteschlangen

Der Unterschied liegt darin, wie das Laufwerk mit der CPU kommuniziert. SATA-SSDs nutzen das für rotierende Festplatten entwickelte AHCI-Protokoll über eine Verbindung, die bei 6 Gbps endet, was in der Praxis rund 550 MB/s sequenziellen Durchsatz bedeutet. SAS hebt die Verbindung auf 12 Gbps an und ergänzt Enterprise-Funktionen wie Dual Porting, läuft aber weiterhin über einen Host Bus Adapter oder RAID-Controller.

NVMe-Laufwerke sind direkt an PCIe-Lanes angebunden. Der wichtigste Unterschied für Server ist das Queuing: AHCI bietet eine Befehlswarteschlange mit 32 Einträgen, während NVMe bis zu 64K Warteschlangen mit jeweils bis zu 64K Befehlen erlaubt.

Auf einem VPS sieht das Gastsystem das physische Laufwerk nicht direkt. Eine gute Host-Konfiguration erhält den Großteil des NVMe-Vorteils. Eine schlechte Konfiguration, starkes Overcommitment oder aggressive I/O-Limits können ihn zunichtemachen.

IOPS, Latenz und Queue Depth, erklärt für Einkäufer

Drei Kennzahlen beschreiben die Speicherleistung, und sie hängen zusammen. IOPS ist die Zahl der pro Sekunde abgeschlossenen Lese- oder Schreiboperationen, meist mit kleinen 4-KB-Blöcken gemessen. Latenz ist die Dauer einer einzelnen Operation. Queue Depth ist die Zahl der gleichzeitig ausstehenden Operationen.

Diese Werte verbindet eine einfache Regel: IOPS entsprechen ungefähr der Queue Depth geteilt durch die Latenz. Ein Laufwerk, das bei Queue Depth 1 in 100 Mikrosekunden antwortet, liefert etwa 10.000 IOPS. Die beworbenen IOPS-Werte werden fast immer bei hoher Queue Depth angegeben, was Laufwerke unter Bedingungen schönt, die viele Anwendungen nie erzeugen.

Eine transaktionale Datenbank, die eine Transaktion nach der anderen committet und jeweils auf fsync wartet, arbeitet nahe an Queue Depth 1. In diesem Fall zählt Latenz mehr als Spitzen-IOPS. NVMe senkt die Gerätelatenz gegenüber SATA in der Regel, und der kürzere Softwarepfad beseitigt weiteren Overhead, sodass sich die Verbesserung auch dann zeigt, wenn die Anwendung nicht viele parallele Anfragen stellt.

Die Tail-Latenz verdient die meiste Aufmerksamkeit. Achten Sie beim Vergleich von Servern auf die Abschlusslatenz beim 99. und 99,9. Perzentil.

Workloads, die von NVMe profitieren

NVMe lohnt sich, wenn die Anwendung durch Speicherlatenz oder durch viele gleichzeitige kleine Operationen begrenzt ist. Die eindeutigsten Fälle sind:

• Relationale Datenbanken. PostgreSQL, MySQL und ähnliche Engines schreiben bei jedem Commit in ein Log und lesen zufällige Seiten, wenn das Working Set den Arbeitsspeicher übersteigt. Geringere Schreiblatenz erhöht die Commit-Rate, und schnellere zufällige Lesezugriffe verkürzen Abfragen, die den Buffer Cache verfehlen.
• Such- und Analyseindizes. Elasticsearch, OpenSearch und ähnliche Engines führen Segmente zusammen, aktualisieren Indizes und lesen viele kleine Dateien. NVMe verkürzt die Indexierungszeit und hält die Abfragelatenz auch während der Merges stabil.
• Build- und CI-Server. Das Kompilieren großer Codebasen, das Auflösen von Abhängigkeiten und das Ausführen von Testsuiten erzeugen Tausende kleiner Lese- und Schreibzugriffe. Builds, die auf dem Papier CPU-gebunden sind, warten in der Praxis oft auf den Speicher.
• Key-Value-Stores mit Persistenz. Systeme, die Snapshots oder Append-only-Logs auf die Festplatte schreiben, profitieren von schnellen Flushes, die die für Nutzer spürbare Pause während der Persistierung verkürzen.
• Container- und Virtualisierungshosts. Das Laden von Images, das Starten vieler Container und der Betrieb mehrerer ausgelasteter Dienste auf einer Maschine vervielfachen die I/O-Parallelität, und genau dort hilft das Queuing von NVMe.
• Datenverarbeitungsjobs. ETL-Schritte, die sortieren, auf die Festplatte auslagern oder Zwischendateien umverteilen, laufen schneller, wenn der temporäre Speicher NVMe ist.

Workloads, für die SATA- oder SAS-SSDs ausreichen

Viele Workloads zeigen wenig oder keinen Unterschied, weil Speicher nicht ihr Engpass ist.

• Websites mit wirksamem Caching. Eine Content-Website, die überwiegend aus dem Arbeitsspeicher, einem Page Cache oder einem CDN ausgeliefert wird, liest nach dem Aufwärmen nur sehr wenig von der Festplatte.
• Zustandslose Anwendungsserver. API- und Web-Tiers, die Daten in einer separaten Datenbank halten, verbringen ihre Zeit mit CPU und Netzwerk.
• Bandbreitenintensive Auslieferung. Dateiverteilung, Streaming-Origins und Download-Mirrors lesen große Dateien sequenziell. Eine SATA-SSD mit rund 550 MB/s übertrifft bereits, was ein 1-Gbps-Port übertragen kann (etwa 125 MB/s).
• Backup-Ziele und Archive. Sequenzielle Schreibvorgänge großer Objekte machen Kapazität pro Dollar wichtiger als Latenz.
• Kleine Datenbanken, die in den Arbeitsspeicher passen. Liegt das gesamte Working Set im RAM, greifen Lesezugriffe selten auf die Festplatte zu, und moderate Commit-Raten liegen deutlich innerhalb der SATA-Grenzen.
• Interne Tools mit wenig Traffic. Wikis, Ticketsysteme und Monitoring-Dashboards mit einigen Dutzend Nutzern erzeugen selten nennenswerten I/O-Druck.

Hier ist das Budget oft besser in Enterprise-SATA- oder SAS-SSD-Kapazität, Arbeitsspeicher oder unbegrenzte Bandbreite investiert.

So messen Sie mit fio, bevor Sie sich festlegen

fio ist das Standard-Open-Source-Werkzeug für Speicher-Benchmarks unter Linux und in den Paketquellen aller großen Distributionen verfügbar. Führen Sie es auf einem Test- oder neu bereitgestellten Server aus, gegen eine Testdatei auf demselben Dateisystem, das Ihre Anwendung nutzen wird, und niemals gegen ein Rohgerät, das Daten enthält.

Beginnen Sie mit einem Random-Read-Test bei mittlerer Nebenläufigkeit, der einem ausgelasteten Datenbank- oder Suchknoten nahekommt: fio --name=randread --filename=/var/tmp/fiotest --size=4G --rw=randread --bs=4k --ioengine=libaio --direct=1 --iodepth=32 --numjobs=4 --runtime=60 --time_based --group_reporting.

Führen Sie dann einen Test durch, der Datenbank-Commits nachbildet: fio --name=commit --filename=/var/tmp/fiotest --size=1G --rw=randwrite --bs=4k --ioengine=libaio --direct=1 --iodepth=1 --numjobs=1 --fsync=1 --runtime=60 --time_based.

Führen Sie abschließend einen sequenziellen Test mit --rw=read und --bs=1M durch, um den Durchsatz für Backups und die Arbeit mit großen Dateien zu bestätigen. Halten Sie beim Auswerten IOPS, Bandbreite und die Perzentile der Completion Latency (clat) bei p50, p99 und p99.9 fest. Auf gemeinsam genutzter Infrastruktur sind konstante Ergebnisse über mehrere Läufe hinweg ebenso wichtig wie der Spitzenwert, weil sie zeigen, wie gut der Host die Nachbarn voneinander isoliert.

Löschen Sie danach die Testdatei. Keine schweren Benchmarks auf Produktionsservern während der Geschäftszeiten: Sie bremsen den realen Traffic.

Transferkontingente, Ports mit unbegrenztem Traffic und Gesamtkosten

Ein Tarif ist nur dann günstig, wenn seine Transferkonditionen zu der Datenmenge passen, die Sie tatsächlich bewegen.

Ein 1-Gbps-Port überträgt etwa 125 MB pro Sekunde, bei voller Auslastung rund 10,8 TB pro Tag oder etwa 324 TB pro Monat. Ein monatliches Kontingent von 3 TB entspricht im Durchschnitt nur etwa 9 Mbps Dauerlast, 16 TB etwa 49 Mbps.

Tarife mit begrenztem Transfervolumen eignen sich für Workloads, bei denen die Speicherleistung im Vordergrund steht und der Traffic moderat und vorhersehbar ist. Prüfen Sie, was bei Überschreitung des Kontingents passiert: Mehrkosten pro Terabyte, Drosselung auf eine niedrigere Geschwindigkeit oder ein erzwungenes Upgrade. Tarife mit unbegrenztem Traffic berechnen einen Festpreis für den Port und eignen sich für Workloads mit hohem oder unvorhersehbarem ausgehendem Traffic. Klären Sie die Portgeschwindigkeit, ob der Port dediziert oder geteilt ist, und etwaige Fair-Use-Bedingungen.

Schätzen Sie den monatlichen Egress anhand aktueller Logs oder Abrechnungsdaten des Anbieters, schlagen Sie eine Reserve für Wachstum und den vom Server ausgehenden Backup-Traffic auf und vergleichen Sie die monatlichen Gesamtkosten einschließlich Mehrverbrauch über alle Optionen hinweg. Manchmal ist die richtige Architektur eine Aufteilung des Workloads: NVMe für die Datenbankschicht mit moderatem Kontingent und SSD-Server mit unbegrenztem Traffic für die Auslieferungsschicht.

Den Standort eines VPS wählen

Der Standort beeinflusst Latenz, Compliance und Kosten. Licht legt in Glasfaser etwa 200 km pro Millisekunde zurück, sodass jede 100 km Glasfaser vor jedem Routing-Overhead etwa 1 ms Round-Trip-Zeit hinzufügen. Reale Pfade sind länger als die Luftlinie, weshalb ein Server auf einem anderen Kontinent häufig 100 bis 250 ms pro Round Trip hinzufügt.

• Server nahe an den Nutzern platzieren. Messen Sie die Round-Trip-Zeit aus den Regionen, aus denen der meiste Traffic kommt, mit ping, mtr oder synthetischem Monitoring.
• Gesprächige Komponenten zusammenhalten. Ein Anwendungsserver und seine Datenbank sollten am selben Standort liegen. Schneller NVMe-Speicher ist verschwendet, wenn jede Abfrage einen Ozean überquert.
• Datenresidenz prüfen. Vorschriften und Kundenverträge können verlangen, dass Daten in einem bestimmten Land bleiben. Klären Sie, wo der Server, seine Backups und alle Replikate gespeichert werden.
• Für regionale Ausfälle planen. Ein zweiter Standort für Backups oder ein Warm Standby schützt vor dem Ausfall eines einzelnen Rechenzentrums.
• Regionale Preise und Transferkonditionen vergleichen. Dieselbe Konfiguration kann in verschiedenen Regionen unterschiedliche Kontingente und Kosten haben.

Entscheidungstabelle und Checkliste

Entscheidungstabelle: Jede Zeile ordnet einem Workload-Profil einen Speichertyp und ein Transfermodell zu.

• Transaktionale Datenbank, Working Set größer als der Arbeitsspeicher. Wählen Sie NVMe. Ein begrenztes Transferkontingent reicht meist aus, da der Datenbank-Traffic überwiegend intern bleibt.
• Such-Cluster oder Analyseindex. Wählen Sie NVMe mit genügend Arbeitsspeicher für den Dateisystem-Cache. Der Transferbedarf ist meist moderat.
• Build- oder CI-Server. Wählen Sie NVMe. Berücksichtigen Sie Downloads von Abhängigkeiten und Artefakten in der Transferschätzung.
• Gecachte Website oder zustandsloser API-Tier. SATA- oder SAS-SSD genügt. Wählen Sie unbegrenzten Traffic, wenn der öffentliche Traffic groß oder sprunghaft ist.
• Dateiauslieferung, Streaming-Origin oder Mirror. SSD mit hoher Kapazität und ein Port mit unbegrenztem Traffic. NVMe bringt wenig, weil das Netzwerk den Durchsatz begrenzt.
• Backup-Ziel oder Archiv. Kapazität zuerst. SSD oder Network Block Storage, dimensioniert für die Aufbewahrung, mit Transferkonditionen, die den Wiederherstellungstraffic abdecken.
• Gemischter Workload auf einer Maschine. Wählen Sie NVMe für die Datenschicht oder verteilen Sie die Schichten auf mehrere Server, damit jede das Speicher- und Transfermodell erhält, das sie braucht.

Gehen Sie vor der Unterschrift diese Checkliste durch:

• Bestimmen Sie anhand aktueller Monitoring-Daten den Engpass: Latenz, Durchsatz, CPU oder Netzwerk.
• Führen Sie fio-Tests für Random Read, fsync und sequenziellen Zugriff aus; dokumentieren Sie p99- und p99.9-Latenz.
• Tests zu verschiedenen Zeiten wiederholen, um geteilte Hosts zu prüfen.
• Schätzen Sie den monatlichen Egress aus Logs plus Wachstum und vergleichen Sie ihn mit Kontingent oder Portgeschwindigkeit.
• Lassen Sie sich Bedingungen zu Mehrverbrauch, Drosselung oder Fair Use schriftlich bestätigen.
• Round-Trip-Zeit von wichtigen Nutzerregionen zu jedem Standort messen.
• Land für Daten, Backups und Replikate klären.
• Prüfen Sie Hypervisor, Festplattenschnittstelle und veröffentlichte I/O-Limits pro Tarif.
• Planen Sie Backups an einen zweiten Standort und testen Sie eine Wiederherstellung.

Wie Vonahost unterstützen kann

Die NVMe-VPS-Linie läuft auf KVM mit bis zu 8 vCPU, 32 GB Arbeitsspeicher und 500 GB NVMe sowie 3 bis 16 TB monatlichem Transfervolumen, in der Region Ihrer Wahl. Die SSD-VPS-Linie nutzt Enterprise-SSD mit bis zu 12 Kernen, 64 GB Arbeitsspeicher und 800 GB Speicher, unbegrenztem Traffic und Linux oder Windows, in der Region Ihrer Wahl. Für Workloads, die einem VPS entwachsen, bieten Single-Tenant-Dedicated-Server lokales NVMe (2 x 960 GB) mit einem dedizierten 1-Gbps-Port und unbegrenztem Traffic.

Jedes Angebot nennt Konfiguration, Standort, Verantwortlichkeiten und Monatspreis in US-Dollar, und Sie wählen das Land jedes Servers.