Hohe i/o Werte

[pointde]

Hallo zusammen. Ich bin ein absoluter Neuling in Sachen Proxmox, aber vom bisherigen System und den Möglichkeiten begeistert.

Das System läuft mit folgenden VM´s: opnSense, fhem, omada Controller, 3CX Telefonanlage und dem Problemkind, einem Windows Server.
Wenn hier größere Mengen drauf kopiert werden, steht das komplette Netzwerk (Glasfaser Inhouse Verkabelung). Es ist eine WD Red verbaut (Datenablage). Die VM´s selber liegen auf einer SSD.
Ich hänge mal einen Screenshot an. Was mich wundert, ist dass die Swap Größe sich nicht ändert. Würde es nicht schneller werden, wenn z. B. auf der SSD ausgelagert werden würde. Von der Windows Seite aus kopiert er mit "anständigen" Werten, Dann bricht er plötzlich auf 0 MB/sek ein, wartet ein paar Sekunden, wieder mit guten Werten weiter usw.
Der IO delay Wert liegt beim kopieren bei ca. 70-80%.

CPU BOGOMIPS: 27199.24
REGEX/SECOND: 4527835
HD SIZE: 93.93 GB (/dev/mapper/pve-root)
BUFFERED READS: 426.11 MB/sec
AVERAGE SEEK TIME: 0.09 ms
FSYNCS/SECOND: 124.30
DNS EXT: 82.24 ms
DNS INT: 22.36 ms (klein.local)

Könnt ihr mir evtl. ein paar Tips geben, was ich machen könnte?

Mar 07 19:29:05 proxmox zed[1881644]: eid=65 class=deadman pool='WDRed14TB' vdev=ata-WDC_WD140EFGX-68B0GN0_Y5KUDWRC-part1 size=8192 offset=6909186076672 priority=3 err=0 flags=0x184880 delay=352541105ms bookmark=216:1:0:251604636
Mar 07 19:29:05 proxmox zed[1881646]: eid=66 class=deadman pool='WDRed14TB' vdev=ata-WDC_WD140EFGX-68B0GN0_Y5KUDWRC-part1 size=8192 offset=6909186068480 priority=3 err=0 flags=0x184880 delay=352541097ms bookmark=216:1:0:251604635
Mar 07 19:29:05 proxmox zed[1881648]: eid=67 class=deadman pool='WDRed14TB' vdev=ata-WDC_WD140EFGX-68B0GN0_Y5KUDWRC-part1 size=8192 offset=6909186060288 priority=3 err=0 flags=0x184880 delay=352541088ms bookmark=216:1:0:251604634
Mar 07 19:29:05 proxmox zed[1881650]: eid=68 class=deadman pool='WDRed14TB' vdev=ata-WDC_WD140EFGX-68B0GN0_Y5KUDWRC-part1 size=8192 offset=6909186052096 priority=3 err=0 flags=0x184880 delay=352541080ms bookmark=216:1:0:251604633
Mar 07 19:30:06 proxmox zed[1882633]: eid=70 class=deadman pool='WDRed14TB' vdev=ata-WDC_WD140EFGX-68B0GN0_Y5KUDWRC-part1 size=8192 offset=6909329080320 priority=3 err=0 flags=0x184880 delay=352602540ms bookmark=216:1:0:251763541
Mar 07 19:30:06 proxmox zed[1882635]: eid=72 class=deadman pool='WDRed14TB' vdev=ata-WDC_WD140EFGX-68B0GN0_Y5KUDWRC-part1 size=8192 offset=6909329063936 priority=3 err=0 flags=0x184880 delay=352602524ms bookmark=216:1:0:251763539
Mar 07 19:30:06 proxmox zed[1882631]: eid=69 class=deadman pool='WDRed14TB' vdev=ata-WDC_WD140EFGX-68B0GN0_Y5KUDWRC-part1 size=8192 offset=6909329088512 priority=3 err=0 flags=0x184880 delay=352602549ms bookmark=216:1:0:251763542
Mar 07 19:30:06 proxmox zed[1882637]: eid=71 class=deadman pool='WDRed14TB' vdev=ata-WDC_WD140EFGX-68B0GN0_Y5KUDWRC-part1 size=8192 offset=6909329072128 priority=3 err=0 flags=0x184880 delay=352602532ms bookmark=216:1:0:251763540
Mar 07 19:31:08 proxmox zed[1885975]: eid=74 class=deadman pool='WDRed14TB' vdev=ata-WDC_WD140EFGX-68B0GN0_Y5KUDWRC-part1 size=8192 offset=6909565890560 priority=3 err=0 flags=0x184880 delay=352663979ms bookmark=216:1:0:251930175
Mar 07 19:31:08 proxmox zed[1885974]: eid=73 class=deadman pool='WDRed14TB' vdev=ata-WDC_WD140EFGX-68B0GN0_Y5KUDWRC-part1 size=8192 offset=6909565898752 priority=3 err=0 flags=0x184880 delay=352663987ms bookmark=216:1:0:251930176
Mar 07 19:31:08 proxmox zed[1885978]: eid=76 class=deadman pool='WDRed14TB' vdev=ata-WDC_WD140EFGX-68B0GN0_Y5KUDWRC-part1 size=8192 offset=6909565874176 priority=3 err=0 flags=0x184880 delay=352663962ms bookmark=216:1:0:251930173
Mar 07 19:31:08 proxmox zed[1885979]: eid=75 class=deadman pool='WDRed14TB' vdev=ata-WDC_WD140EFGX-68B0GN0_Y5KUDWRC-part1 size=8192 offset=6909565882368 priority=3 err=0 flags=0x184880 delay=352663970ms bookmark=216:1:0:251930174
Mar 07 19:32:09 proxmox zed[1887258]: eid=77 class=deadman pool='WDRed14TB' vdev=ata-WDC_WD140EFGX-68B0GN0_Y5KUDWRC-part1 size=8192 offset=6909727395840 priority=3 err=0 flags=0x184880 delay=352725417ms bookmark=216:1:0:251949893

 

[cwt]

Lese ich das richtig, dass Du 5 VMs auf einer einzigen SSD laufen läßt und eine einzelne HDD für Daten? Dann ist es kein Wunder, dass alles krückelt und Dein Netzwerk steht. Der Cache der SSD wird gnadenlos einbrechen, ebenso der der HDD. Dadurch werden die anderen VMs mit runtergezogen, auch deine OPNSense. Und wenn die „freezed“, geht auch im LAN nix mehr.

 

[Falk R.]

Der hohe I/O Delay spricht für ein Problem in Richtung Storage. Was für eine SSD ist das denn?
Eine einfache Consumer SSD ist ganz schnell am Limit, eine günstige NVMe kann schon etwas mehr, aber wenn du dauerhaft gute Leistung haben möchtest, brauchst du eine Enterprise SSD. Diese gibt es auch gebraucht für bezahlbares Geld.

 

[pointde]

Danke für die Meldungen. Kann ich diese dann einfach ausbauen und "clonen" wieder einbauen - läuft? Oder wie ist hier der Workaround? Falls ihr sagt, es macht Sinn würde ich evtl. auch noch eine zweite einbauen. Ist eine Samsung Pro, also keine Enterprise SSD. Könntet ihr mir evtl auch ein Modell empfehlen?

 

[Falk R.]

Du hast eine Samsung QVO, das ist eine Quad Level Cell SSD. Die sind nur für Dateiablage geeignet, da die extrem langsam sind beim Schreiben. Für Virtualisierung sollte man nie QLC Nand benutzen.
Klonen geht.

 

[pointde]

Ich habe aber eigentlich nur die VMs auf der SSD. Die Datenablage ist ja auf der WD Red HDD. Ist dann nicht die der Flaschenhals? Auf die wird ja kopiert??
Könntest du mir bitte einige Enterprise SSD Modelle empfehlen?

 

[Falk R.]

Kommt drauf an welches Interface und welche Größe. Ich nehme gern gebrauchte von HPE, DELL oder anderen Servern.

 

[pointde]

Ich hätte mir die hier auch mal angeschaut: https://www.kingston.com/de/ssd/dc500-data-center-solid-state-drive
Die SEDC500M.
Zu Post #6 hätte ich nochmal die Frage. Bringt mir das überhaupt was, wenn auf der SSD "nur" die VM´s liegen? Die Daten der des virtuellen Windows Server liegen ja auf der HDD...
PS: Wegen deiner Frage. Geht nur SATA als Interface

 

[Dunuin]

Die DC500M wird hier im Forum von vielen genutzt. Damit sollten die VMs selbst dann schnell genug laufen. Alles was du von der HDD liest/schreibst bleibt natürlich gleich langsam. Wenn du keine ZFS Features für die HDD brauchst, könntest du ein simpleres Dateisystem nehmen, was weniger Overhead verursacht. Z.B. ext4 oder LVM-Thin mit ext4. HDDs sind halt höllisch langsam für alles was kein sequentielles lesen/schreiben ist. Da hilft es dann höchstens die HDD durch eine SSD zu ersetzen, oder halt sehr viele kleine HDDs in ein Raid0/Raid10 zu packen.

 

[pointde]

Ich habe mir jetzt mal die oben genannte SSD bestellt. Kann ich für die HDD nicht irgendwie die SSD auch als Cache benutzen? Diese Performance Einbrüche kenne ich so überhaupt nicht. Vorher war ja der Windows Server genauso wie jetzt nativ installiert. Aber daß das ganze System nicht mehr benutzbar ist, wenn ein Backup auf die Platte läuft ist schon krass...

 

[Dunuin]

ZFS hat SLOG und L2ARC als SSD Cache. wird aber beides nicht viel helfen. SLOG hilft nur bei Sync Writes und L2ARC hilft nur in bestimmten Fällen, wo du auf bestimmte Dateien sehr oft lesend zugreifst, die Dateien aber zu groß für den ARC im RAM sind.
Was man machen könnte wäre eine Partition auf der SSD erstellen und diese als Special Device für den Pool mit der HDD benutzen. Dann müsste deine HDD keine Metadaten mehr schreiben/lesen und wäre daher entsprechend etwas entlastet. So ein Special Device ist aber kein Cache. Fällt dir da die SSD aus, dann sind auch alle Daten der HDD weg, was natürlich sehr ungünstig wäre, wenn du die HDD für Backups der SSD nehmen willst.

 

[pointde]

Meine neue SSD ist da. Hab die "alte" vom Server ausgebaut und versucht zu klonen. Leider ist die Kingston um rund 150 MB kleiner, somit kann ich sie mit keiner Software klonen. Habs mit Acronis, AOMEI, Partition Wizard usw. versucht. Meine Linux Kenntnisse reichen aber nicht aus. Könnte mir bitte wer helfen und ein paar Tipps geben, wie ich die SSD tauschen könnte. Muss ich Proxmox jetzt neu installieren? Falls ja: Hab gelesen, dass man die Einstellungen (Netzwerk etc. sichern kann. Die HDD fasse ich ja einstweilen nicht an....

 

[cwt]

Ich würde die neue SSD zusätzlich in den PVE bauen und die VMs darauf verschieben.

 

[anderl1969]

... ja, und bevor du alles umziehst erst mal testen, ob mit der neuen SSD das Ausgangsproblem beseitigt ist.

 

[pointde]

Ich habe mich jetzt dazu entschlossen, die Samsung erstmal als Träger der VM´s zu lassen, jedoch die Enterprise Kingston als Ersatz für die WD-RED Server HDD (oder Zusatz) zu benutzen.
Kann ich über die Funktion verschieben die Daten verschieben, obwohl die SSD weniger Platz zur Verfügung hat?
Siehe Screenshots. Vom belegten Speicherplatz her müsste es ja reichen.
Falls nicht, wie würdet ihr vorgehen?

 

[Falk R.]

Was Windows Anzeigt ist egal. Mit was hast du die Kingston formatiert?
Ich würde LVM-thin nutzen, dann belegt die virtuelle Disk nur so viel wie Daten da sind.
Das kann aber mehr sein, als Windows anzeigt. Wenn du Daten im Windows löschst wird das nur als gelöscht markiert und erst überschrieben, wenn die Disk bis zum Ende beschrieben wurde. Deshalb gibt es auch Funktionen wie Trim.
Mit 3,1 TiB belegt auf einer 3,5 TiB Disk, kann das ganz schnell knapp werden, wenn die virtuelle Disk so groß ist.

 

[pointde]

Mit LVM-Thin (siehe Screenshot). Also kann ich wie in meinem Screenshot oben beschrieben die Disk einfach verschieben?
Speicherplatz schaufle ich noch frei. Da liegen ohne Ende Images drauf, die lagere ich inzwischen aus und verschieben sie, wenn alles geklappt hat auf die WDRED.

 

[Falk R.]

Wenn du den qemu-Agent drauf hast und Discard eingeschaltet ist auf der Disk, sollte er auch wieder Platz freigeben.
Kleiner Tip, wenn du die vDisk auf die kleinere SSD verschiebst, im Windows die Partition verkleinern. Dann kann der nicht alles voll schreiben.

 

[pointde]

Hat leider nicht geklappt

moving disk with snapshots, snapshots will not be moved!
create full clone of drive scsi1 (WDRed14TB:vm-200-disk-0)
Formatting '/dev/sdb1/images/200/vm-200-disk-1.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off preallocation=metadata compression_type=zlib size=10995116277760 lazy_refcounts=off refcount_bits=16
transferred 0.0 B of 10.0 TiB (0.00%)
qemu-img: error while writing at byte 31589393408: No space left on device
TASK ERROR: storage migration failed: copy failed: command '/usr/bin/qemu-img convert -p -n -T none -f raw -O qcow2 /dev/zvol/WDRed14TB/vm-200-disk-0 zeroinit:/dev/sdb1/images/200/vm-200-disk-1.qcow2' failed: exit code 1

 

[Falk R.]

Bist du dir sicher, dass es lvm-thin ist?
Da müsste er automatisch RAW draus machen und nicht qcow2.