Hohe IO-Verzögerung auf allen ZFS-Pools bei Backup eines einzelnen Pools

[w.reimer]

Guten Tag Zusammen,

wir haben bei uns das Problem das bei einem Backup von einer einzigen Virtuellen Maschine (Fileserver) die sich auf einem eigenen Dataset befindet ebenfalls auch die anderen Maschinen auf dem anderem Dataset eine extrem hohe IO Verzögerung aufweisen. Müssten bei zwei verschiedenen Datasets nicht die Zugriffszeiten unabhängig voneinander sein? Ist da gegebenenfalls etwas falsch konfiguriert oder stehe ich irgendwo anders auf dem Schlauch? Wäre froh wenn mir hier jemand einen Tipp geben könnte.

Wir setzen seit kurzem in unserer Organisation auf einen Proxmox Server, basierend auf einem Dell Poweredge R7515 der neuesten Generation mit dem RAID-Controller im HBA Modus, 256GB DDR4 ECC RAM und einem AMD EPYC 7313P. Auf Grund von Budget-Beschränkungen (Sind ein Gemeinnütziger Verein) haben wir Hauptsächlich Festplatten verbaut:
- 1x kleine Consumer SSD für OS
- 2x 18TB Western Digital Gold als ZFS Mirror wo unser Fileserver drauf läuft
- 6x 2TB Seagate NAS Platten als ZFS Stripe mit 3x2TB Mirror für höhere IOPS für die Restlichen VMs
- 1x Enterprise MLC SAS SSD als ZIL / LOG Device für die beiden oben genannten Pools

Als Backup Server (Proxmox Backup Server) nutzen wir unseren alten Dell Server, beide sind direkt miteinander via 10GBit SFP+ verbunden.

Beide ZFS Datasets haben Thin Provisioning aktiviert und eine Blockgröße von 64k. Kompression und die ganzen restlichen Einstellugen sind in den Standardeinstellungen, abgesehen von relatime welches auf beiden Datasets aktiviert ist.

Unsere VMs sind allesamt mit folgenden Festplatten Einstellungen eingerichtet:
- SCSI Controller: VirtIO SCSI Single
- Bus/Device: SCSI
- Cache: Direct Sync
- Discard: Ja
- IO Thread: Ja
- Async IO: threads

Diese Einstellungen haben wir nach langem Probieren als die Stabilsten für uns festgestellt, da andere bei Hohem IO zu Freezes / Kernel Panics / Bluescreens in den Virtuellen Maschinen geführt haben. Die Maschinen sind ausschließlich Windows Server 2022 und Debian 11 Systeme mit den aktuellsten Treibern/Guest Tools.

Vielen Dank im Voraus für jeden der mir hier weiterhelfen kann

 

[aaron]

Müssten bei zwei verschiedenen Datasets nicht die Zugriffszeiten unabhängig voneinander sein?

Wenn Sie am gleichen Pool liegen nicht.

Kann natürlich sein, dass wir ein bisschen aneinander vorbeireden. Soweit ich das verstehe, habt ihr 2 ZFS Pools für VMs. Liegen die VMs auf den verschiedenen Pools? Sprich, VM auf dem 2x 18TB Mirror pool wird gesichert, und die VMs die auf dem 6x 2TB RAID10 like Pool liegen haben Probleme mit IO wait?

Kannst du bitte den Output von folgenden Befehlen innerhalb von [code][/code] Tags posten?

zpool status
zfs list

 

[Dunuin]

Guten Tag Zusammen,

wir haben bei uns das Problem das bei einem Backup von einer einzigen Virtuellen Maschine (Fileserver) die sich auf einem eigenen Dataset befindet ebenfalls auch die anderen Maschinen auf dem anderem Dataset eine extrem hohe IO Verzögerung aufweisen. Müssten bei zwei verschiedenen Datasets nicht die Zugriffszeiten unabhängig voneinander sein? Ist da gegebenenfalls etwas falsch konfiguriert oder stehe ich irgendwo anders auf dem Schlauch? Wäre froh wenn mir hier jemand einen Tipp geben könnte.

Wir setzen seit kurzem in unserer Organisation auf einen Proxmox Server, basierend auf einem Dell Poweredge R7515 der neuesten Generation mit dem RAID-Controller im HBA Modus, 256GB DDR4 ECC RAM und einem AMD EPYC 7313P. Auf Grund von Budget-Beschränkungen (Sind ein Gemeinnütziger Verein) haben wir Hauptsächlich Festplatten verbaut:
- 1x kleine Consumer SSD für OS
- 2x 18TB Western Digital Gold als ZFS Mirror wo unser Fileserver drauf läuft
- 6x 2TB Seagate NAS Platten als ZFS Stripe mit 3x2TB Mirror für höhere IOPS für die Restlichen VMs
- 1x Enterprise MLC SAS SSD als ZIL / LOG Device für die beiden oben genannten Pools

Als Backup Server (Proxmox Backup Server) nutzen wir unseren alten Dell Server, beide sind direkt miteinander via 10GBit SFP+ verbunden.

Beide ZFS Datasets haben Thin Provisioning aktiviert und eine Blockgröße von 64k. Kompression und die ganzen restlichen Einstellugen sind in den Standardeinstellungen, abgesehen von relatime welches auf beiden Datasets aktiviert ist.

Unsere VMs sind allesamt mit folgenden Festplatten Einstellungen eingerichtet:
- SCSI Controller: VirtIO SCSI Single
- Bus/Device: SCSI
- Cache: Direct Sync
- Discard: Ja
- IO Thread: Ja
- Async IO: threads

Diese Einstellungen haben wir nach langem Probieren als die Stabilsten für uns festgestellt, da andere bei Hohem IO zu Freezes / Kernel Panics / Bluescreens in den Virtuellen Maschinen geführt haben. Die Maschinen sind ausschließlich Windows Server 2022 und Debian 11 Systeme mit den aktuellsten Treibern/Guest Tools.

Vielen Dank im Voraus für jeden der mir hier weiterhelfen kann

Liegt das eine Dataset auf dem einen Pool und das andere Dataset auf dem anderen Pool?
Wenn beide Datasets auf dem selben Pool liegen würden, dann könnten sie sich leicht gegenseitig ausbremsen, wenn die HDDs ins IOPS Limit kommen.

Falls die Datasets auf getrennten Pools laufen kann es sein, dass da dein SLOG ausbremst, da sich ja beide Pools das SLOG teilen. Und du scheinst ja Sync Writes zu erzwingen (Direct Sync) dass da alles über das SLOG laufen muss. Lastet da ein Pool das SLOG aus, dann muss der andere Pool eben warten, dass da das SLOG wieder Kapazitäten hat.

 

[w.reimer]

@aaron
Vielen Dank für die Schnelle Antwort, sry, hab mich mit den Begrifflichkeiten vertan, ich meinte natürlich zwei Datasets auf verschiedene Pools, und genau die Situation die du gerade geschildert hast.

Hier der zpool status:

  pool: VM-Fileserver
 state: ONLINE
  scan: scrub repaired 0B in 19:23:55 with 0 errors on Sun Jun 12 19:47:57 2022
config:

        NAME                                    STATE     READ WRITE CKSUM
        VM-Fileserver                           ONLINE       0     0     0
          mirror-0                              ONLINE       0     0     0
            ata-WDC_WD181KRYZ-01AGBB0_3WJ47TML  ONLINE       0     0     0
            ata-WDC_WD181KRYZ-01AGBB0_3WHGDKNJ  ONLINE       0     0     0
        logs
          sdf1                                  ONLINE       0     0     0

errors: No known data errors

  pool: VM-XXXXX
 state: ONLINE
config:

        NAME                                 STATE     READ WRITE CKSUM
        VM-XXXXX                        ONLINE       0     0     0
          mirror-0                           ONLINE       0     0     0
            ata-ST2000VN000-1HJ164_W720Q4KJ  ONLINE       0     0     0
            ata-ST2000VN000-1HJ164_W720Q45L  ONLINE       0     0     0
          mirror-1                           ONLINE       0     0     0
            ata-ST2000VN000-1HJ164_W720Q4QH  ONLINE       0     0     0
            ata-ST2000VN000-1HJ164_W720Q4J2  ONLINE       0     0     0
          mirror-2                           ONLINE       0     0     0
            ata-ST2000VN000-1HJ164_W720NL49  ONLINE       0     0     0
            ata-ST2000VN000-1HJ164_W720Q403  ONLINE       0     0     0
        logs
          sdf2                               ONLINE       0     0     0

Und zfs list:

NAME                          USED  AVAIL     REFER  MOUNTPOINT
VM-Fileserver                8.22T  8.02T       96K  /VM-Fileserver
VM-Fileserver/vm-102-disk-0   108K  8.02T      108K  -
VM-Fileserver/vm-102-disk-1  8.22T  8.02T     8.22T  -
VM-Fileserver/vm-102-disk-2    68K  8.02T       68K  -
VM-XXXXX                1.52T  3.80T       96K  /VM-XXXXX
VM-XXXXX/vm-100-disk-0  13.4G  3.80T     13.4G  -
VM-XXXXX/vm-101-disk-0  11.7G  3.80T     11.7G  -
VM-XXXXX/vm-105-disk-0  11.9G  3.80T     11.9G  -
VM-XXXXX/vm-106-disk-0  18.8G  3.80T     18.8G  -
VM-XXXXX/vm-107-disk-0  4.02G  3.80T     4.02G  -
VM-XXXXX/vm-108-disk-0  8.06G  3.80T     8.06G  -
VM-XXXXX/vm-112-disk-0  24.0G  3.80T     24.0G  -
VM-XXXXX/vm-112-disk-1   213G  3.80T      213G  -
VM-XXXXX/vm-131-disk-0  16.5G  3.80T     16.5G  -
VM-XXXXX/vm-132-disk-0  22.2G  3.80T     22.2G  -
VM-XXXXX/vm-132-disk-1   182G  3.80T      182G  -
VM-XXXXX/vm-141-disk-0   432G  3.80T      432G  -
VM-XXXXX/vm-151-disk-0   591G  3.80T      591G  -
VM-XXXXX/vm-152-disk-0  2.31G  3.80T     2.31G  -

@Dunuin
Kann das wirklich ein Problem sein wenn das SLOG groß genug ist? Selbst bei zwei zufälligen Zugriffen von unterschiedlichen Pools ist die SSD doch deutlich schneller als die Platten und sollte nicht zum Flaschenhals werden, oder irre ich mich hier? Bin noch relativ neu in dem ganzen Thema

@edit: Der zweite Pool ist jetzt lange nicht so träge wie der erste wenn bei diesem ein Backup durchgeführt wird, aber doch deutlich merkbarer unterschied als wenn grad kein Backup auf dem anderen Pool läuft.

 

[Dunuin]

Naja, so super schnell ist eine SSD bei Sync Writes auch nicht. Aber ja, hätte auch gedacht, dass da eher die HDDs der Flaschenhals wären.
Wäre aber eine Erklarung für das Problem, also wollte ich das mal nennen. Du könntest testweise mal das SLOG von einem Pool entfernen und gucken ob das Problem nicht mehr auftritt. Falls das Problem immer noch besteht kannst du die Partition wieder als SLOG hinzufügen. Oder falls es am SLOG lag, dann eine zweite SSD holen und die als SLOG nutzen.

Und der L2ARC kann ebenfalls bremsen. Die eine SSD cacht dann ja auch für beide Pools.

 

[w.reimer]

Naja, so super schnell ist eine SSD bei Sync Writes auch nicht. Aber ja, hätte auch gedacht, dass da eher die HDDs der Flaschenhals wären.
Wäre aber eine Erklarung für das Problem, also wollte ich das mal nennen. Du könntest testweise mal das SLOG von einem Pool entfernen und gucken ob das Problem nicht mehr auftritt. Falls das Problem immer noch besteht kannst du die Partition wieder als SLOG hinzufügen. Oder falls es am SLOG lag, dann eine zweite SSD holen und die als SLOG nutzen.

Werde ich auf jeden Fall bei nächster Gelegenheit zumindest mal ausprobieren, danke für den Tipp.

Ist auch schonmal gut zu wissen das der IO-Delay eigentlich bei unterschiedlichen Pools unabhängig voneinander sein sollte, hatte schon Sorge das ich irgendwas beim ZFS so ziemlich falsch verstanden / übersehen habe.

Gibt es denn eine Möglichkeit für Backups (nicht für normale VM Lese/Schreibzugriffe) ein Bandbreitenlimit pro VM/Pool zu setzen? So das ich im Notfall sagen kann ich begrenze die Lesegeschwindigkeit für die Fileserver VM/Pool auf 100MiB, so das parallel Leute immernoch auf der VM halbwegs vernünftig arbeiten können ohne das diese komplett ausgelastet und träge durch das Backup wird?

 

[Dunuin]

Für Backups kann man die Bandbreite begrenzen. Nutzt du PBS oder Vzdump für Backups? Siehe z.B. "bwlimit" in der "/etc/vzdump.conf".

Auch nicht vergessen ebenfalls den L2ARC mit dem SLOG zu entfernen, da der auch geteilt wird und bremsen könnte. Aber zum Glück lassen sich SLOG and L2ARC ja nach belieben hunzufugen und entfernen.

 

[w.reimer]

Ich nutze den Proxmox Backup Server, zieht der sich die Einstellungen auch aus dem bwlimit der vzdump.conf? Ist das dann für Lese- und Schreibzugriffe gleich oder gibt es unterschiedliche Parameter?

Also wenn ich jetzt bwlimit=100000 eintrage, wären das maximal 100MB Lese/Schreibzugriff beim Backup pro VM über den PBS?

 

[Dunuin]

Bei PBS weiß ich gerade nicht. Da müsste ich zuhause mal gucken. Ich meine auch irgendwo in der PVE oder PBS GUI eine Einstellung zur Bandbreitenbegrenzung gesehen zu haben.

Wenn du vom VM Pool auf den Backup Pool sicherst, dann kann es aber auch sein, dass da dein VM Pool einfach einen hohen IO delay hat, weil die Lesezugriffe vom Backup-Prozess schon ausreichen, um die HDDs ans IOPS Limit zu bringen. HDDs sind halt echt nicht empfehlenswert für einen VM Storage, selbst wenn das Budget knapp ist.
Konntest du mal testen indem du auf dem Backup Pool ein PBS Verify Job laufen lässt um diesen auszulasten. Der sollte ja nur L2ARC und den Backup Pool lesend belasten und nicht den SLOG oder VM Pool.

 

[Dunuin]

So, habe mal nachgeguckt, Im PBS-WebUI unter "Configuration -> Traffic-Control" kannst du Regeln erstellen, zu welcher Uhrzeit/Tag mit wieviel Bandbreite gesichert/wiederhergestellt werden darf.