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 sich ein lauter Nachbar jeweils auswirkt

Lokaler NVMe-Speicher nutzt dasselbe Gerät und denselben Host. Wenn ein anderer Gast auf Ihrem Host einen umfangreichen Job mit zufälligen Schreibzugriffen ausführt, werden Ihre Anforderungen hinter dessen Anforderungen eingereiht, und Ihre Latenz steigt. Der Wirkungsbereich ist auf diesen Host begrenzt. Einige Anbieter begrenzen die I/O-Rate pro Gast im Hypervisor. Dadurch wird die Störung zu einer festen Obergrenze, die Sie zuverlässig erreichen, statt zu einer zufälligen Grenze, die nur gelegentlich auftritt.

Netzwerkspeicher verteilt Ihre Daten über viele Knoten. Dadurch fällt ein einzelner lauter Mandant weniger ins Gewicht. Dafür sind Sie von clusterweiten Ereignissen betroffen. Der Ausfall eines Knotens löst eine Wiederherstellung aus, 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, obwohl sie selbst nichts verursacht haben.

Innerhalb des Gasts können Sie ohne Kenntnis des Backends zwischen „meine Festplatte ist ausgelastet“ und „meine Festplatte wartet“ unterscheiden. Führen Sie iostat -x 1 aus dem Paket sysstat aus und vergleichen Sie aqu-sz (durchschnittliche Warteschlangengröße) mit await (durchschnittliche Wartezeit pro Anforderung). Ein hoher Wert für await, während aqu-sz klein bleibt, bedeutet, dass die Zeit unterhalb Ihres Systems verbraucht wird. Ihre eigene Workload ist nicht tief genug, um die Warteschlange zu erklären. cat /proc/pressure/io zeigt dasselbe als Stillstandsprozentsatz: Ein steigender Wert für some avg10 bedeutet, dass Tasks auf I/O warten und dadurch blockiert sind. 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 passiert beim Ausfall eines Storage-Knotens

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

INFO: task jbd2/vda1-8:311 blocked for more than 120 seconds.
blk_update_request: I/O error, dev vda, sector 1050624
EXT4-fs (vda1): Remounting filesystem read-only

Ein Dateisystem, das in den Read-only-Modus gewechselt ist, bleibt Read-only, bis Sie es erneut einhängen oder das System neu starten. Daher kann ein vom Provider sauber behobener Storage-Vorfall trotzdem einen Neustart Ihrer VPS erforderlich machen. Eine Erhöhung des Gast-I/O-Timeouts, sofern das Gerät dies unterstützt, vergrößert lediglich das Zeitfenster, in dem der Gast still wartet, statt einen Fehler zu melden.

Der Ausfall einer lokalen NVMe äußert sich anders. Ein defektes Flash-Gerät lässt sich verkraften, wenn der Host auf einen gespiegelten Verbund schreibt. Deshalb sollten Sie bei jedem Tarif mit beworbenen lokalen Datenträgern nach RAID 10 auf dem Host fragen. Der Ausfall eines Hosts lässt sich nicht auf dieselbe Weise verkraften: Ihre Daten sind zwar weiterhin auf dem Flash-Speicher vorhanden, aber niemand kann darauf zugreifen, bis die Maschine zurückkehrt. Wenn sie nicht zurückkehrt, sind auch die Daten nicht mehr erreichbar. Lokale NVMe bleibt für viele Workloads die richtige Wahl, sofern Sie den Wiederherstellungspfad selbst verantworten. Genau hier zeigt sich zu spät der Unterschied zwischen einem Snapshot und einem Backup.

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 finden Sie heraus, welche Variante Sie haben

Innerhalb des Gasts sagt der Gerätename nichts aus. Fast jeder VPS stellt seine Festplatte über virtio als /dev/vda bereit, unabhängig davon, was sich dahinter befindet. cat /sys/block/vda/queue/rotational gibt bei fast allen diesen Systemen den Wert 0 aus, weil dort nur die Angaben des Hypervisors gemeldet werden. lsblk -o NAME,SIZE,ROTA,TRAN,MODEL zeigt bei virtio-blk üblicherweise ein leeres MODEL und bei virtio-scsi ein QEMU HARDDISK. Keine dieser Zeichenfolgen gibt an, wo die Blöcke tatsächlich gespeichert sind.

Eine Prüfung liefert eine konkrete Antwort, sofern sie anwendbar ist:

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

Wenn Ihre Festplatte als /dev/nvme0n1 erscheint, liest transport bei einem Gerät am lokalen PCIe-Bus den Wert pcie und bei NVMe over Fabrics den Wert tcp, rdma oder fc. NVMe over Fabrics bezeichnet Netzwerkspeicher, der unter einem NVMe-Namen erscheint. /dev/nvme0n1 ist daher allein kein Beleg für eine lokale Festplatte. Wenn /sys/class/nvme/ nicht existiert, verwenden Sie virtio. Diese Prüfung ist dann nicht anwendbar. Weitere Prüfungen auf Kernel-Ebene finden Sie unter eine NVMe-Festplatte unter Linux innerhalb des Gasts bestätigen.

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

• Können Sie die Festplatte von einer Instanz trennen und an eine andere Instanz anhängen? Dann handelt es sich um ein Netzwerk-Volume.
• Wird ein Snapshot einer großen Festplatte innerhalb von Sekunden erstellt? Dann verwendet der Cluster mit hoher Wahrscheinlichkeit Copy-on-Write.
• Können Sie die Festplatte im laufenden Betrieb vergrößern oder eine Festplatte bestellen, die größer ist als jedes einzelne Laufwerk? Dann gilt dieselbe Schlussfolgerung.
• Verspricht der Anbieter Host-Wartungen ohne Reboot? Dafür muss die Festplatte an ihrem aktuellen Speicherort verbleiben.
• Wird die zusätzliche Festplatte als eigener Posten pro Gigabyte und Monat berechnet? Anbieter bepreisen Netzwerk-Volumes auf diese Weise, weil sich ihre Kapazität tatsächlich unabhängig von der Maschine bereitstellen lässt.

Fragen Sie anschließend den Support mit einfachen Worten. Eine kurze Frage führt häufiger als erwartet zu einer direkten Antwort: „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-Festplatte und nach jedem zusätzlichen Volume. Ein VPS enthält sehr häufig beides: eine lokale Root-Festplatte für das Betriebssystem und ein Netzwerk-Volume für umfangreiche Daten.

Messen Sie schließlich selbst. Ein Test mit zufälligen Schreibvorgängen bei einer Queue Depth von 1 sagt über das Design mehr aus als jedes Datenblatt. Die fio-Rezepte zur korrekten Durchführung dieses Tests sind an einer Stelle zusammengefasst und werden hier nicht wiederholt.

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.