Erfahrungen mit LVM (thick) + iSCSI Multipath (Pure Storage) und Volume-Chain Snapshots unter Proxmox VE 9

[Johannes S]

I do enjoy diving into these kinds of topics, but I also like to fully understand what I’m doing — and so far, all of this has been completely new territory for me after 15 years of working with VMware.

Understandable for me it's the opposite: Linux is my main driver for 15 years at least, I maintain Linux servers for a living for a decade now (if you include student jobs). In the last years it happened that my work notebook runs on Windows and i also need to maintain some Windows servers. For them I have similiar reaction like yours "why is this all so complicated and not working as I expect". Guess this is just normal if you need to learn some new tricks.

As mentioned, we have support, and I plan to contact Proxmox on Monday to ask what they think is the best approach for our environment. I’ll explain our sup, and then they can tell me whether I should continue as I am or convert everything to RAW.

Sounds like a plan. If you don't mind could you share their recommendation and your course of action afterwards? This might be of interest for other people with similiar setups and environments like yours.

 

[Falk R.]

Was hier auch zur Sprache kam und ich auch mehrfach beobachtet habe, die iSCSI Performance ist bei All Flash Arrays verschiedener Hersteller schlechter als bei VMware. VMware hat da etwas mehr Hirnschmalz ins Tuning gesteckt und im Linux Kernel beachtet eh keiner mehr iSCSI, da das alte Technik der letzten Jahrzehnte ist. Daher empfehle ich immer auf NVMe over TCP zu gehen. Dann ist die Performance in der Regel deutlich besser als vSphere + iSCSI.
Bei Powerstores habe ich das mehrfach getan, Pure Storages habe ich bei keinem Kunden mit iSCSI, die haben da immer FC und DataCore hat jetzt auch in der Preview NVMe over TCP veröffentlicht und der erste Test sieht sehr gut aus, doppelte Performance zum Namespace als vorher zur LUN vom selben Diskpool.

 

[bbgeek17]

Die Frage nach dem Leistungsvorteil von iSCSI, NVMe/TCP, FC usw. hängt stets von der Implementierung des Herstellers sowie von der Client-Konfiguration ab. Selbst die beste Implementierung des Herstellers nützt wenig, wenn der Client beispielsweise ein 15 Jahre alter Dual-Prozessor-Rechner ist.

Deshalb bieten wir bei Blockbridge unseren Kunden Client-Host-Optimierung an, um die Software optimal nutzen zu können.

Zudem haben wir zahlreiche Leistungsmessungen durchgeführt – wenn auch mit älteren PVE-Versionen – und PVE hat sich stets als besonders leistungsstark erwiesen, sofern es clientseitig (PVE) korrekt konfiguriert war:

https://kb.blockbridge.com/technote/proxmox-vs-vmware-nvmetcp/

https://kb.blockbridge.com/technote/proxmox-iscsi-vs-nvmetcp/index.html

---

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox

 

[PwrBank]

Zudem haben wir zahlreiche Leistungsmessungen durchgeführt – wenn auch mit älteren PVE-Versionen – und PVE hat sich stets als besonders leistungsstark erwiesen, sofern es clientseitig (PVE) korrekt konfiguriert war:

---

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox

Anecdotally, just got the 100GbE networking configured from PVE to the Pure array, and I'm very impressed with Proxmox.

This is even totally untuned iSCSI. Windows VM with a disk on the iSCSI running CrystalDiskMark.

 

[Bu66as]

@PwrBank,

Die 9464 MB/s beim sequenziellen Lesen sind beeindruckend – du lastest damit die 100GbE-Verbindung effektiv aus (~75,7 Gbit/s Daten + Protokoll-Overhead). Das bestätigt definitiv deinen Punkt, dass iSCSI den rohen Durchsatz liefern kann.

Allerdings zeigt die Schreibgeschwindigkeit (2933 MB/s) eine deutliche Asymmetrie im Vergleich zum Lesen. Während FlashArrays typischerweise "Write Penalties" haben, deutet ein Verhältnis von ~30% (Schreiben zu Lesen) bei 100GbE oft darauf hin, dass Multipath-Richtlinien (z. B. queue_depth, rr_min_io) oder TCP-Window-Limits den Schreibprozess ausbremsen.

Wie @bbgeek17 erwähnte, liegt der Hauptvorteil von NVMe/TCP nicht unbedingt in den großen sequenziellen Zahlen (die du ohnehin schon ausgereizt hast), sondern in der 4K Random-Leistung und der CPU-Effizienz. Deine 4K Q32-Ergebnisse (~746 MB/s) sind solide, aber genau hier holt NVMe/TCP durch das Umgehen des SCSI-Layers oft noch mal 20–30 % mehr IOPS und geringere Latenzen heraus.

Hast du zufällig die CPU-Last (IO wait/System time) auf dem PVE-Host während des CrystalDiskMark-Laufs geprüft? Bei 100GbE verbraucht iSCSI oft deutlich mehr CPU-Zyklen als NVMe-oF.