Lokales NVMe oder Netzwerkspeicher im VPS?

Lokales NVMe oder Netzwerkspeicher auf einem VPS

Lokales NVMe oder Netzwerkspeicher auf einem VPS ist eine Entscheidung, die sich hinter zwei Produktbezeichnungen verbirgt. Eine lokale NVMe-Disk ist Flash-Speicher in derselben physischen Maschine, auf der Ihre virtuelle Maschine läuft, und wird über PCIe angesprochen. Ein Netzwerk-Volume befindet sich in anderen Maschinen, wird über das Netzwerk des Providers angesprochen und üblicherweise auf zwei oder drei dieser Maschinen geschrieben, bevor der Schreibvorgang bestätigt wird.

Beide Produkte werden als „NVMe SSD“ beworben, und beide Angaben sind korrekt. Der Flash-Speicher in einem Storage-Cluster besteht tatsächlich aus NVMe-Flash. Was das Datenblatt nicht angibt, ist der Pfad zwischen Ihrem Prozess und diesem Flash-Speicher. Diesen Pfad spüren Sie in der Praxis.

Die beiden Pfade, die ein Schreibvorgang nehmen kann

Bei lokalem Speicher ist der Pfad kurz. Ihr Prozess ruft write() und anschließend fsync() auf. Der Gastkernel übergibt die Anfrage an ein virtio-Gerät. Der Hypervisor leitet sie an die Blockschicht des Hosts weiter, die sie über PCIe an ein Flash-Gerät im selben Gehäuse sendet. Das Gerät speichert die Daten, bestätigt den Vorgang, und die Bestätigung läuft über denselben Stack zurück.

Bei Netzwerkspeicher kommt ein Netzwerk hinzu. Auf dem Host läuft ein Client für das Speichersystem. Ceph RBD und iSCSI sind die gängigen Varianten. NVMe over Fabrics (NVMe-oF, das NVMe-Protokoll über ein Netzwerk) wird inzwischen ebenfalls häufiger eingesetzt. Der Client ermittelt, auf welchen Knoten Ihre Daten liegen, sendet den Schreibvorgang über die NIC und einen Switch an diese Knoten und wartet. Ein Cluster mit drei Replikaten bestätigt den Schreibvorgang erst, wenn genügend Kopien dauerhaft gespeichert sind. Erst dann läuft die Bestätigung zu Ihrem Prozess zurück.

Das ist kein Fehler. Die zusätzlichen Stationen ermöglichen Eigenschaften, die der kurze Pfad nicht bieten kann. Jede Station kostet jedoch Zeit, und diese Kosten fallen bei jeder Operation an.

Warum die Latenzuntergrenze die entscheidende Zahl ist

Lesen Sie den zweiten Pfad noch einmal und zählen Sie die Wartezeiten. Zwischen dem Host und einem Storage-Knoten fällt mindestens ein Netzwerk-Roundtrip an. Dazu kommen die eigene Geräte-Servicezeit dieses Knotens sowie die Wartezeit auf die vom Anbieter geforderte Anzahl an Replikaten. Ein lokaler Schreibvorgang verursacht die Geräte-Servicezeit und kaum weitere Kosten.

Veröffentlichte Werte ordnen die Bestätigung eines lokalen NVMe-Schreibvorgangs im Bereich von einigen zehn Mikrosekunden ein. Bei einem replizierten Netzwerk-Schreibvorgang liegen sie im Bereich von einigen hundert Mikrosekunden bis zu wenigen Millisekunden. Betrachten Sie diese Werte als Angaben von Herstellern und aus der Community, nicht als Messwerte Ihres VPS. Entscheidend ist die Form des Unterschieds. Die beiden Designs haben unterschiedliche Untergrenzen. Keine noch so starke Parallelisierung senkt eine Untergrenze. Parallelisierung erhöht die Obergrenze.

Deshalb können zwei Benchmarks derselben Festplatte gegensätzliche Ergebnisse liefern. Ein Test mit einer Queue Depth von 32 macht die Untergrenze unsichtbar, weil sich die Wartezeiten der 32 gleichzeitig laufenden Anforderungen überlappen. Ein Test mit einer Queue Depth von 1 macht sie sichtbar, weil jede Anforderung auf die vorherige wartet. Führen Sie beide Tests selbst aus: einen VPS-Datenträger mit fio bei einer Queue Depth von 1 und anschließend bei hoher Queue Depth messen ist die einzige Möglichkeit, das Verhalten Ihres Systems zu ermitteln, statt sich auf die Angaben einer Produktseite zu verlassen.

Warum Datenbanken und kleine Schreibvorgänge die Auswirkungen zuerst spüren

Ein Datenbank-Commit ist ein kleiner synchroner Schreibvorgang. PostgreSQL hängt die Transaktion an das Write-Ahead-Log an, ruft fsync() auf und meldet dem Client erst danach den Erfolg. Solange fsync() nicht zurückkehrt, bleibt die Verbindung untätig und wartet. Die Commit-Rate einer Verbindung ist daher durch 1 geteilt durch die Commit-Latenz begrenzt. Ein Limit von 0.1 ms ermöglicht ungefähr die zehnfache Commit-Rate einer einzelnen Verbindung im Vergleich zu einem Limit von 1 ms. Das ist reine Arithmetik und erklärt, warum sich eine Anwendung bei einem Anbieter schnell anfühlt, bei einem anderen mit identischen angegebenen technischen Daten jedoch langsam.

Parallelität schwächt diesen Effekt ab. PostgreSQL bündelt parallele Commits in einem gemeinsamen Flush, sodass hundert ausgelastete Verbindungen nicht hundert separate Wartezeiten verursachen. Langsam bleibt alles, was seriell abläuft: etwa eine Migration, die für jede Zeile einen Commit ausführt, oder ein Queue-Worker, der einen Auftrag abschließt, bevor er den nächsten startet.

Dasselbe Muster betrifft alles, was fsync() häufig aufruft: etcd, Redis mit appendfsync always, SQLite im standardmäßigen Journal-Modus, einen Mailserver, der in Maildir schreibt, und einen CI-Runner, der Tausende kleiner Dateien entpackt. Leseintensive Workloads, deren Working Set in den RAM passt, bemerken davon kaum etwas, weil der Page Cache die meisten Lesezugriffe beantwortet und die Festplatte überhaupt nicht erreicht.

Durchsatz wird durch das Netzwerk begrenzt, nicht durch das Gerät

Der sequenzielle Durchsatz stößt bei jedem Design an eine andere Grenze. Ein einzelnes modernes NVMe-Gerät verarbeitet mehrere Gigabyte pro Sekunde. Ein Netzwerk-Volume kann die Bandbreite der Verbindung, über die es angebunden ist, nicht überschreiten. Davon müssen Protokoll-Overhead und der Datenverkehr abgezogen werden, den andere Mandanten zu diesem Zeitpunkt über denselben Switch übertragen. Eine Verbindung mit 10 Gbit/s erreicht auf Leitungsebene vor dem Overhead etwa 1.25 GB/s. Ein Backend, das vollständig aus schnellem Flash besteht, kann daher beim sequenziellen Durchsatz trotzdem hinter einem einzelnen lokalen Laufwerk zurückbleiben.

Anbieter geben diese Grenzen bei Netzwerk-Volumes üblicherweise offen an: als Bandbreitenlimit und als IOPS-Limit (Input/Output Operations per Second), häufig abhängig von der Volume-Größe. Manchmal gibt es zusätzlich ein Burst-Kontingent, das sich mit der Zeit wieder auffüllt. Ein von der Größe abhängiges Limit bedeutet, dass sich ein 20-GB-Volume und ein 2-TB-Volume deutlich unterschiedlich verhalten, obwohl die Produktseite beide als dasselbe Produkt bezeichnet. Lokale Laufwerke sind nur selten auf diese Weise begrenzt. Stattdessen werden ihre Ressourcen geteilt. Das ist ein anderes Problem.

Wie ein „Noisy Neighbour“ jeweils aussieht

Lokaler NVMe-Speicher nutzt ein Gerät und einen Host gemeinsam. Wenn ein anderer Gast auf Ihrem Host einen umfangreichen Job mit zufälligen Schreibzugriffen ausführt, werden Ihre Anfragen hinter dessen Anfragen eingereiht und Ihre Latenz steigt. Der Wirkungsbereich beschränkt sich auf diesen Host. Einige Provider begrenzen die I/O-Leistung pro Gast im Hypervisor. Dadurch wird die Störung zu einer festen Obergrenze, die Sie regelmäßig erreichen, statt zu einer zufälligen Verzögerung, die nur gelegentlich auftritt.

Netzwerkspeicher verteilt Ihre Daten auf viele Knoten, sodass ein lauter Mandant weniger Auswirkungen hat. Dafür sind Sie von Ereignissen im gesamten Cluster betroffen. Wenn ein Knoten ausfällt, startet eine Wiederherstellung, bei der die fehlenden Kopien neu erstellt werden. Diese Wiederherstellung konkurriert im gesamten Cluster mit dem Client-Datenverkehr. Eine Netzwerküberlastung oder ein Wartungsfenster an einem Speicherrack kann Mandanten verlangsamen, die selbst nichts verursacht haben.

Innerhalb des Gasts können Sie zwischen „mein Datenträger ist ausgelastet“ und „mein Datenträger wartet“ unterscheiden, ohne das Backend zu kennen. Führen Sie iostat -x 1 aus dem Paket sysstat aus und vergleichen Sie aqu-sz (durchschnittliche Warteschlangengröße) mit r_await und w_await (durchschnittliche Wartezeit pro Lese- beziehungsweise Schreibanforderung). Die aktuelle Version von sysstat gibt die kombinierte Spalte await nur in ihrem kurzen Layout iostat -x -s 1 aus. Ein hoher Wert für w_await oder r_await, während aqu-sz klein bleibt, bedeutet, dass die Zeit unterhalb Ihrer Instanz verbraucht wird. Ihre eigene Auslastung ist nicht tief genug, um die Warteschlange zu erklären. cat /proc/pressure/io zeigt dasselbe als Anteil der Blockierungszeit: Ein steigender Wert von some avg10 bedeutet, dass Tasks auf I/O warten. Speicher- und CPU-Störungen treten häufig gemeinsam auf. Steal Time ist das entsprechende Signal auf der CPU-Seite.

Was bei einer Live-Migration passiert

Hier spielt Netzwerkspeicher seinen Vorteil aus. Wenn Ihr Datenträger in einem Cluster liegt, müssen beim Verschieben Ihres VPS auf einen anderen Host nur CPU-Zustand und RAM kopiert werden. Der Datenträger wird nicht verschoben, weil er nie auf dem Host lag. Moderne Hypervisoren erreichen das mit einer Pause von wenigen Millisekunden. In der Regel erfahren Sie davon eher über eine Statusseite als über Ihr Monitoring.

Wenn der Datenträger lokal liegt, muss auch er verschoben werden. Der Hypervisor spiegelt das Blockgerät auf den Zielhost, während die Maschine weiterläuft und weiterhin Blöcke verändert. Daher dauert das Kopieren mindestens so lange wie die Datenübertragung und länger, wenn währenddessen Schreibzugriffe erfolgen. Einige Provider führen die Migration trotzdem auf diese Weise durch. Viele tun das nicht, und in ihrer Wartungsankündigung steht, dass ein Reboot erforderlich ist. Dieser Unterschied in der Formulierung ist ein guter Hinweis auf die zugrunde liegende Architektur.

Was beim Ausfall eines Speicherknotens passiert

Netzwerkspeicher übersteht den Verlust eines Knotens, weil die Kopien an anderer Stelle liegen. Für den Mandanten zeigt sich das als Unterbrechung und nicht als Datenverlust: Die I/O wird blockiert, während der Cluster ermittelt, welche Kopie maßgeblich ist. Dauert die Unterbrechung lange genug, meldet sich der Gastkernel. dmesg gibt Zeilen wie diese aus:

INFO: task jbd2/vda1-8:311 blocked in I/O wait for more than 120 seconds.
I/O error, dev vda, sector 1050624 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0
EXT4-fs (vda1): Remounting filesystem read-only

Ältere Kernel formulieren die ersten beiden Zeilen etwas anders: In der Zeile zum hängenden Task fehlt „in I/O wait“, und die Fehlerzeile beginnt mit blk_update_request:. Suchen Sie in Ihren Logs nach beiden Formen.

Ein Dateisystem, das in den Nur-Lese-Modus gewechselt ist, bleibt dort, bis Sie es erneut einhängen oder neu booten. Deshalb kann ein vom Provider sauber behobener Speichervorfall trotzdem einen Neustart Ihrer VPS erfordern. Wenn das Gerät eine Erhöhung des Gast-I/O-Timeouts unterstützt, vergrößert diese nur das Zeitfenster, in dem der Gast still wartet, statt einen Fehler zu melden.

Lokaler NVMe-Speicher fällt anders aus. Ein ausgefallenes Flash-Gerät lässt sich überstehen, wenn der Host auf einen gespiegelten Verbund schreibt. Deshalb lohnt es sich, bei jedem Tarif mit lokalen Datenträgern nach RAID 10 auf dem Host zu fragen. Der Ausfall des Hosts lässt sich auf diese Weise nicht überstehen: Ihre Daten bleiben auf Flash-Speicher erhalten, auf den niemand zugreifen kann, bis die Maschine zurückkehrt. Wenn sie nicht zurückkehrt, sind auch die Daten nicht verfügbar. Lokaler NVMe-Speicher bleibt für viele Workloads die richtige Wahl, sofern Sie den Wiederherstellungsweg selbst beherrschen. Der Unterschied zwischen einem Snapshot und einem Backup wird in diesem Fall genau dann erkannt, wenn es zu spät ist.

Was Ihnen Netzwerkspeicher ermöglicht

Sofortige Snapshots sind das anschaulichste Beispiel. Ein Snapshot in einem Cluster ist ein Copy-on-Write-Marker. Deshalb ist er unabhängig von der Volume-Größe nach etwa einer Sekunde abgeschlossen, weil beim Auslösen keine Daten kopiert werden. Auf einer lokalen Festplatte bedeutet ein Snapshot das Kopieren echter Blöcke. Das benötigt auf demselben Host tatsächlich Zeit und Speicherplatz.

Das Trennen eines Volumes von einer Instanz und das Anhängen an eine andere ist nur möglich, wenn das Volume nicht fest mit einem Gehäuse verbunden ist. Ein Volume über das größte Laufwerk des Providers hinaus zu vergrößern, ist aus demselben Grund möglich. Das gilt auch für Thin Provisioning. Dadurch kann ein Panel Ihnen 5 TB bereitstellen, ohne dass heute jemand 5 TB für Sie in ein Rack einbauen muss. Wenn Kapazität und nicht Latenz der begrenzende Faktor ist, ist diese Flexibilität der entscheidende Vorteil. Block-Volumes im Vergleich zu Object Storage für günstige Terabytes erläutert, wohin das Geld tatsächlich fließt.

So ermitteln Sie, welche Variante Sie haben

Der Gerätename innerhalb des Gasts beweist nichts. Nahezu jede VPS stellt ihren Datenträger über virtio als /dev/vda bereit, unabhängig vom darunterliegenden Speicher. cat /sys/block/vda/queue/rotational gibt für einen virtio-blk-Datenträger den Wert 1 aus, selbst wenn die Blöcke auf Flash-Speicher liegen. Der Linux-Treiber für virtio-blk markiert jeden von ihm erstellten Datenträger als rotierend und entfernt diese Markierung nie. Nur eine udev-Regel im Image kann das ändern. Bei virtio-scsi folgt der Wert der Rotationsrate, die der Hypervisor bekannt gibt. Eine 0 bedeutet dort daher meist, dass jemand die SSD-Emulation aktiviert hat, und nicht, dass der Datenträger lokal ist. lsblk -o NAME,SIZE,ROTA,TRAN,MODEL zeigt für virtio-blk häufig ein leeres MODEL und für virtio-scsi QEMU HARDDISK. Keine der beiden Zeichenfolgen zeigt, wo die Blöcke tatsächlich liegen.

Eine Prüfung liefert, sofern sie anwendbar ist, eine verlässliche Antwort:

ls /sys/class/nvme/
cat /sys/class/nvme/nvme0/transport

Wenn Ihr Datenträger als /dev/nvme0n1 erscheint, gibt transport für ein Gerät am lokalen PCIe-Bus pcie aus. Für NVMe over Fabrics gibt es tcp, rdma oder fc aus. Dabei handelt es sich um Netzwerkspeicher mit einem NVMe-Namen. Das Auftreten von /dev/nvme0n1 beweist daher allein keinen lokalen Datenträger. Wenn /sys/class/nvme/ nicht existiert, verwenden Sie virtio, und diese Prüfung ist für Sie nicht anwendbar. Weitere Prüfungen auf Kernel-Seite finden Sie unter Bestätigen eines NVMe-Datenträgers unter Linux aus dem Gast heraus.

Damit bleiben Verhalten und Vertragsunterlagen. Sie sind zuverlässiger als Gerätenamen:

• Können Sie den Datenträger abtrennen und an eine andere Instanz anschließen? Dann handelt es sich um ein Netzwerk-Volume.
• Ist ein Snapshot eines großen Datenträgers innerhalb von Sekunden fertig? Dann wird er fast sicher per Copy-on-Write in einem Cluster erstellt.
• Können Sie den Datenträger im laufenden Betrieb vergrößern oder einen Datenträger bestellen, der größer als jedes einzelne Laufwerk ist? Dann gilt dieselbe Schlussfolgerung.
• Verspricht der Provider Host-Wartungen ohne Neustart? Dafür muss der Datenträger an seinem aktuellen Ort bleiben.
• Wird der zusätzliche Datenträger pro Gigabyte und Monat als eigener Posten berechnet? Provider berechnen Netzwerk-Volumes auf diese Weise, weil sich ihre Kapazität tatsächlich von der Maschine trennen lässt.

Fragen Sie anschließend den Support mit klaren Worten. Eine kurze Frage führt häufiger zu einer direkten Antwort als erwartet: „Liegt die Systemplatte als lokaler NVMe-Datenträger im Host, oder ist sie ein Volume aus einem verteilten Speichersystem?“ Fragen Sie separat nach der Root-Disk und nach jedem zusätzlichen Volume. Eine VPS verfügt häufig über beides: eine lokale Root-Disk für das Betriebssystem und ein Netzwerk-Volume für Massendaten.

Messen Sie abschließend selbst. Ein Test mit zufälligen Schreibzugriffen und einer Warteschlangentiefe von 1 sagt mehr über das Design aus als jedes Datenblatt. Die fio-Rezepte für die korrekte Ausführung dieses Tests finden Sie an einer Stelle, statt sie hier zu wiederholen.

Einen deutschen Tarif lesen, der „Cloud“ oder „VPS“ sagt

Keiner der beiden Begriffe ist ein technischer Begriff. Auf dem deutschen Markt steht „Cloud“ in der Praxis für Produkte mit API, stundenweiser Abrechnung, Snapshots und einhängbaren Volumes. „VPS“ oder „vServer“ bezeichnet dagegen meist eine Maschine mit festem Monatspreis und festem Datenträger. Dieser Zusammenhang besteht tatsächlich. Er ist jedoch eine Marketingkonvention und keine Aussage über die Architektur. Anbieter ändern diese Zuordnung, ohne darüber zu informieren.

Lesen Sie die Angaben zum Speicher statt des Produktnamens. „Lokale NVMe-SSD“ oder „lokaler NVMe-Speicher“ bedeutet, dass sich der Datenträger im Host befindet. „Verteiltes Speichersystem“, „Netzwerkspeicher“, „Blockspeicher“ oder „dreifach redundant gespeichert“ bedeutet, dass der Schreibvorgang die Maschine verlässt. Die Formulierung zur Redundanz ist bereits ein starkes Signal. Eine einzelne lokale Festplatte in einem Host wird nicht an drei Stellen gespeichert.

Achten Sie auf den Satz, der in beiden Fällen zutrifft. „NVMe SSD storage“ beschreibt einen aus NVMe-Laufwerken aufgebauten Ceph-Cluster ebenso genau wie ein Laufwerk in Ihrem Host. Die Formulierung nennt das Speichermedium, sagt aber nichts über die Entfernung aus. Wenn eine Seite nur das Medium nennt, gehen Sie davon aus, dass diese Information noch fehlt, und fragen Sie nach. Dieselbe Lesedisziplin gilt für den restlichen Inhalt der Seite. Ein günstiges VPS-Angebot Zeile für Zeile zu lesen zeigt dieses Vorgehen. Der Unterschied zwischen einem Storage-VPS und einem regulären VPS behandelt kapazitätsorientierte Tarife, bei denen sich diese Frage erneut anders stellt.

Welche Workloads welchen Speicher rechtfertigen

Lokales NVMe lohnt sich, wenn ein kleiner synchroner Schreibvorgang auf dem Pfad liegt, auf dem Ihre Benutzer warten. Eine PostgreSQL- oder MySQL-Primary-Instanz mit einer realen Commit-Rate, etcd, eine Queue, deren Worker jeden Job committen, ein Mail-Store oder ein CI-Runner: Sie alle bewegen sich an der Latenzuntergrenze. Genau diese Untergrenze kaufen Sie. Dafür akzeptieren Sie, dass eine Kopie Ihrer Daten auf einem Host liegt. Replizieren oder sichern Sie die Daten außerhalb dieses Hosts. Überwachen Sie außerdem den Datenträger, den Sie erhalten haben. Dabei hilft die Überwachung des Datenträgerzustands innerhalb eines Gasts, soweit ein Tenant die relevanten Informationen tatsächlich sehen kann.

Netzwerkspeicher lohnt sich, wenn die Daten die Instanz überdauern müssen, wenn Sie mehr Kapazität benötigen, als auf einen Rechner passt, oder wenn Sie einen Server ohne geplante Unterbrechung verschieben, vergrößern und als Snapshot sichern möchten. Lesereplikate, Anwendungsserver, Backup-Ziele und Medienbibliotheken passen gut in diese Kategorie, weil sie nicht durch die Single-Thread-Commit-Latenz begrenzt werden.

Die meisten realen Setups sind gemischt: Die Root-Disk liegt auf lokalem NVMe, damit Betriebssystem und Datenbank schnell reagieren, und ein Netzwerk-Volume ist für Backups und große Dateien eingebunden. Diese Anordnung verursacht die wenigsten Überraschungen, weil jede Speicherart die Aufgaben übernimmt, für die sie geeignet ist. Wenn Sie sich vor der Topologie noch für das Medium entscheiden, ist der Vergleich von NVMe und SATA-SSD auf einem VPS die frühere Frage, die Sie klären sollten.

FAQ

Woran erkenne ich, ob der Datenträger meiner VPS lokaler NVMe-Speicher oder Netzwerkspeicher ist?

Der Gerätename innerhalb des Gasts sagt nichts aus, weil virtio für beides /dev/vda bereitstellt. Falls /dev/nvme0n1 vorhanden ist, lesen Sie /sys/class/nvme/nvme0/transport aus: pcie steht für den lokalen PCIe-Bus, während tcp oder rdma für NVMe over Fabrics steht, also für Netzwerkspeicher. Andernfalls beurteilen Sie das Verhalten. Sofortige Snapshots eines großen Datenträgers, das Abhängen eines Volumes und Anhängen an anderer Stelle, eine Online-Vergrößerung oder Wartungsarbeiten ohne Reboot erfordern sämtlich Netzwerkspeicher. Fragen Sie den Support anschließend getrennt nach dem Root-Datenträger und nach jedem zusätzlichen Volume, da ein Rechner häufig beides verwendet.

Bedeutet „NVMe“ im Datenblatt, dass sich der Datenträger in meinem Server befindet?

Nein. Die Bezeichnung beschreibt das Medium, nicht die Entfernung. Ein verteilter Storage-Cluster aus NVMe-Laufwerken wird korrekt als NVMe-Speicher bezeichnet. Jeder Schreibvorgang durchquert dennoch das Netzwerk und wartet auf die Bestätigungen der Replikate. Achten Sie auf Angaben zum Speicherort der Daten, beispielsweise „lokal“ im Gegensatz zu „verteilt“ oder „redundant gespeichert“, und nicht auf die Bezeichnung des Mediums.

Warum ist meine Datenbank auf einer VPS langsam, obwohl NVMe angegeben ist?

Jeder Commit ruft fsync() auf und wartet. Eine Verbindung kann daher nicht schneller committen als mit dem Kehrwert der Latenz der Schreibbestätigung. Netzwerkspeicher fügt jedem dieser Wartevorgänge eine Netzwerk-Rundreise und die Bestätigungen der Replikate hinzu. Serielle Verarbeitung ist davon besonders betroffen, beispielsweise eine Migration mit einem Commit pro Zeile oder ein Single-Thread-Worker. Gleichzeitige Commits werden zu einem Flush zusammengefasst. Mehr Parallelität kann daher einen großen Teil des Durchsatzes zurückbringen, auch wenn jeder einzelne Commit weiterhin langsam bleibt.

Ist Netzwerkspeicher sicherer als lokaler NVMe-Speicher?

Er ist gegenüber Hardwareausfällen ausfallsicherer, weil sich die Kopien auf getrennten Rechnern befinden und ein ausgefallener Knoten automatisch wiederhergestellt wird. Er ist kein Backup. Eine gelöschte Tabelle oder eine fehlerhafte Migration wird sofort auf jede Kopie repliziert. Bei lokalem NVMe-Speicher liegt die Verantwortung für die Datensicherheit bei Ihnen. Das ist schlechter, wenn Sie nichts dagegen unternehmen, und völlig ausreichend, wenn Sie auf einen anderen Host replizieren oder dort Backups erstellen.

Kann ich eine Produktionsdatenbank auf Netzwerkspeicher betreiben?

Ja, das ist üblich. Rechnen Sie mit einer höheren Mindestlatenz für Commits und richten Sie das Design darauf aus: Bündeln Sie Schreibvorgänge, sofern die Anwendung dies zulässt, und prüfen Sie, ob der Anbieter die IOPS anhand der Volume-Größe begrenzt, da ein kleines Volume möglicherweise nur ein niedriges Limit hat. Wenn die Commit-Rate eines Single-Thread-Prozesses für Ihre Benutzer entscheidend ist, testen Sie vor der Entscheidung beide Designs mit einer Queue Depth von 1.