Windows Server - Festplatte verkleinern fordert gesamten Host

[Alvin2k8]

Guten Tag an alle,

wir haben ein komisches Phänomen:

Blech mit 2x AMD Epic 7282 , 512GB Ram und 8x SSDs als ZFS Storage im RaidZ2.
Maschine läuft gut, alles easy.

Wenn wir aber auf einer Virtuellen Windows Umgebung die Festplatte verkleinern, "stirbt" der Host fast ab.
CPU Auslastung nahezu 100% und IO Verzögerung teilweise nicht mehr messbar.

VMs sind mi iSCIS Single und IO Threat aktiv.

Ist das ein normales Verhalten?

 

[mira]

Nur um das richtig zu verstehen, ihr verkleinert die Partition einer DIsk innerhalb von Windows?

Könntest du den Output folgender Befehle hier posten?
pveversion -v
qm config <VMID>
cat /etc/pve/storage.cfg

 

[Alvin2k8]

Nur um das richtig zu verstehen, ihr verkleinert die Partition einer DIsk innerhalb von Windows?

Könntest du den Output folgender Befehle hier posten?
pveversion -v
qm config <VMID>
cat /etc/pve/storage.cfg

proxmox-ve: 7.3-1 (running kernel: 5.15.85-1-pve)
pve-manager: 7.3-6 (running version: 7.3-6/723bb6ec)
pve-kernel-helper: 7.3-8
pve-kernel-5.15: 7.3-3
pve-kernel-5.15.102-1-pve: 5.15.102-1
pve-kernel-5.15.85-1-pve: 5.15.85-1
ceph-fuse: 14.2.21-1
corosync: 3.1.7-pve1
criu: 3.15-1+pve-1
glusterfs-client: 9.2-1
ifupdown: residual config
ifupdown2: 3.1.0-1+pmx3
ksm-control-daemon: 1.4-1
libjs-extjs: 7.0.0-1
libknet1: 1.24-pve2
libproxmox-acme-perl: 1.4.4
libproxmox-backup-qemu0: 1.3.1-1
libpve-access-control: 7.3-2
libpve-apiclient-perl: 3.2-1
libpve-common-perl: 7.3-2
libpve-guest-common-perl: 4.2-3
libpve-http-server-perl: 4.1-6
libpve-storage-perl: 7.3-2
libspice-server1: 0.14.3-2.1
lvm2: 2.03.11-2.1
lxc-pve: 5.0.2-2
lxcfs: 5.0.3-pve1
novnc-pve: 1.4.0-1
proxmox-backup-client: 2.3.3-1
proxmox-backup-file-restore: 2.3.3-1
proxmox-mail-forward: 0.1.1-1
proxmox-mini-journalreader: 1.3-1
proxmox-offline-mirror-helper: 0.5.1-1
proxmox-widget-toolkit: 3.5.5
pve-cluster: 7.3-2
pve-container: 4.4-2
pve-docs: 7.3-1
pve-edk2-firmware: 3.20221111-1
pve-firewall: 4.2-7
pve-firmware: 3.6-4
pve-ha-manager: 3.5.1
pve-i18n: 2.8-3
pve-qemu-kvm: 7.2.0-8
pve-xtermjs: 4.16.0-1
qemu-server: 7.3-4
smartmontools: 7.2-pve3
spiceterm: 3.2-2
swtpm: 0.8.0~bpo11+3
vncterm: 1.7-1
zfsutils-linux: 2.1.9-pve1




balloon: 0
boot: order=scsi0
cores: 4
cpu: host
hotplug: disk,network,usb,memory,cpu
ipconfig0: ip=xxx.xxx.xxx.xxx/xx,gw=xxx.xxx.xxx.x
ipconfig1: ip=xx.xx.x.x/xx
memory: 8192
meta: creation-qemu=7.0.0,ctime=1668085785
name: Name der VM
net1: virtio=XX:XX:XX:XX:XX:XX,bridge=vmbrx,tag=xx
numa: 1
onboot: 1
ostype: win10
scsi0: datastore:vm-xx-disk-0,cache=unsafe,format=raw,iothread=1,mbps_rd=115,mbps_rd_max=300,mbps_wr=115,mbps_wr_max=300,size=1100G,ssd=1
scsihw: virtio-scsi-single
smbios1: uuid=59ae716a-a009-4ea4-ab58-e3aabb9523dc
sockets: 1
tablet: 1
vga: std
vmgenid: 3e195005-0bfa-47e0-8d00-d952441d4c99




dir: local
path /var/lib/vz
content vztmpl,snippets
prune-backups keep-all=1
shared 0

zfspool: datastore
pool datastore
blocksize 64K
content images,rootdir
mountpoint /datastore
sparse 1

 

[mow]

Wenn wir aber auf einer Virtuellen Windows Umgebung die Festplatte verkleinern, "stirbt" der Host fast ab.

Mal ganz grundsätzlich: Warum tut ihr sowas? Die VM-Disks sind doch als sparse angelegt und belegen normalerweise nur wenig mehr als nötig. Wenn Du dagegen im Gast das Filesystem verkleinerst, müssen (ähnlich wie beim defrag, was man auch nicht tun sollte) etliche Blöcke umsortiert werden und landen dann in Bereichen, die vorher gar nicht belegt waren, was dazu führt, daß die VM-Disk sogar mehr real belegt als vorher. Und weil außerdem der Gast nichts von der Blockgröße des zfs weiß, sondern mit seiner eigenen Clustergröße arbeitet, ist das Diskimage im zfs hinterher fürchterlich fragmentiert, was zu erheblicher write amplification führen kann.

 

[Falk R.]

Vermutlich killt das im Zusammenspiel mit RaidZ2 die Disks.

 

[Neobin]

Blech mit 2x AMD Epic 7282 , 512GB Ram und 8x SSDs als ZFS Storage im RaidZ2.

CPU Auslastung nahezu 100% und IO Verzögerung teilweise nicht mehr messbar.

Frage mich, warum bei (Performance-)Problemen mit dem Storage, nie konkrete Angaben (mindestens mal die exakten Modellbezeichnungen/-nummern der Disks und ggf. des Controllers) zur verwendeten Storage-Hardware gemacht werden...

Und wie bereits gesagt wurde, RaidZ ist definitiv nicht optimal als Guest-Storage:
https://pve.proxmox.com/wiki/ZFS_on_Linux#sysadmin_zfs_raid_considerations

 

[Alvin2k8]

Mal ganz grundsätzlich: Warum tut ihr sowas? Die VM-Disks sind doch als sparse angelegt und belegen normalerweise nur wenig mehr als nötig. Wenn Du dagegen im Gast das Filesystem verkleinerst, müssen (ähnlich wie beim defrag, was man auch nicht tun sollte) etliche Blöcke umsortiert werden und landen dann in Bereichen, die vorher gar nicht belegt waren, was dazu führt, daß die VM-Disk sogar mehr real belegt als vorher. Und weil außerdem der Gast nichts von der Blockgröße des zfs weiß, sondern mit seiner eigenen Clustergröße arbeitet, ist das Diskimage im zfs hinterher fürchterlich fragmentiert, was zu erheblicher write amplification führen kann.

Hallo,

das müssen wir leider Kundentechnisch so machen. Da führt leider kein Weg dran vorbei.
Dabei geht es auch nicht um den Speicher am System selbst, sondern in der VM!
Die Platte an sich bleibt so groß wie Sie ist aber der "sichtbare Speicherplatz" wird reduziert in Windows!

 

[Alvin2k8]

Vermutlich killt das im Zusammenspiel mit RaidZ2 die Disks.

Okay, ja gut zu wissen.
Diese Anpassung kommt ja nicht täglich vor und kann auch in die Abendstunden verlegt werden, sofern nochmal nötig!

 

[Alvin2k8]

Frage mich, warum bei (Performance-)Problemen mit dem Storage, nie konkrete Angaben (mindestens mal die exakten Modellbezeichnungen/-nummern der Disks und ggf. des Controllers) zur verwendeten Storage-Hardware gemacht werden...

Und wie bereits gesagt wurde, RaidZ ist definitiv nicht optimal als Guest-Storage:
https://pve.proxmox.com/wiki/ZFS_on_Linux#sysadmin_zfs_raid_considerations

Hallo,

es sind Samsung 870 Evo mit 2TB. Dies 8x im ZFSZ2 Verbund.

 

[Falk R.]

Wieso arbeitet ihr nicht mit quotas?

 

[Alvin2k8]

Wieso arbeitet ihr nicht mit quotas?

Gute Frage.
Hatten wir so noch nicht auf dem Schirm da die bisherige Methode nie Probleme gemacht hat.
Und es geht auch selten rückwärts mit dem Speicher, sondern eher vorwärts....

Aber durchaus ein guter Ansatz sich das mal näher anzusehen!

Danke!

 

[Dunuin]

es sind Samsung 870 Evo mit 2TB. Dies 8x im ZFSZ2 Verbund.

Das ist auch alles andere als performant.
8 Disk Raidz2 = IOPS Performance gleich schnell wie nur eine einzelne Disk, da das nur mit der Anzahl der vdevs aber nicht mit der Anzahl der Disks skaliert. Außerdem massig Padding Overhead (und damit weniger nutzbare Kapazität als mit einem Raid10), sofern du die Volblocksize nicht manuell auf mindestes 16K vergrößert hast.
Consumer SSDs ohne Power-loss Protection (PLP) = richtig miese Sync Write Performance die eher auf HDD-Niveau ist:

 

[Alvin2k8]

Das ist auch alles andere als performant.
8 Disk Raidz2 = IOPS Performance gleich schnell wie nur eine einzelne Disk, da das nur mit der Anzahl der vdevs aber nicht mit der Anzahl der Disks skaliert. Außerdem massig Padding Overhead (und damit weniger nutzbare Kapazität als mit einem Raid10), sofern du die Volblocksize nicht manuell auf mindestes 16K vergrößert hast.
Consumer SSDs ohne Power-loss Protection (PLP) = richtig miese Sync Write Performance die eher auf HDD-Niveau ist:

Was würdest du denn für eine ZFS Option empfehlen, bei den vorhandenen Platten?

 

[Dunuin]

Keine Option wird richtig tolle Performance liefern, da ZFS viel Sync Writes nutzt und die Evos ohne PLP da einfach schlecht sind.
Aber ein 8 Disk Striped Mirror mit ashift=12 und volblocksize=16K sollte wenigstens die 4-fache IOPS Performance erzielen. Dürfen dann aber halt nicht beide Disks eines vdevs ausfallen. Und man hätte sogar mehr nutzbare Kapazität als mit einem 8 Disk Raidz2 bei standardwerten (ashift=12 und volblocksize=8K).
"relatime=on" für den Pool kann auch noch Performance erhöhen, weil dann nicht jede Leseoperation automatisch auch eine zusätzliche Schreiboperation verursacht.

 

[Alvin2k8]

Wie stelle ich denn "relatime=on" ein?
Stehe gerade etwas auf dem Schlauch...

 

[Dunuin]

zfs set relatime=on YourPool

 

[Alvin2k8]

achja...danke!
Sehe ich richtig, wenn "atime=off, relatime=on" ist das gleiche wie "atime=off,relatime=off"
Also muss atime auch on sein?

Und muss ich das bei jeder Disk aktivieren oder reicht der ZFS Pool?

 

[Falk R.]

Striped Mirrors sollten deutlich besser laufen und atime=on, heißt er loggt jeden Zugriff. Das erzeugt massiv Writes und bremst mal richtig.
Ein RaidZ2 sollte mehr Netto Kapazität haben, aber ist wie schon vorher erwähnt deutlich langsamer und sollte nie für VMs genutzt werden. Für Backups ist das OK.

 

[Dunuin]

Sehe ich richtig, wenn "atime=off, relatime=on" ist das gleiche wie "atime=off,relatime=off"

Jup. Wenn man eh schon "atime=off" hat, dann macht "relatime=on" keinen Sinn. Und "atime=off" hätte noch bessere Performance, an hat dann ber halt auch keine atime mehr, was ja für viele Anwendungen benötigt wird (z.B. für einen PBS Datastore).

Und muss ich das bei jeder Disk aktivieren oder reicht der ZFS Pool?

ZFS optionen kann man nur für Pools, Datasets oder Zvols definieren, nicht für einzelne disks/vdevs.

 

[Dunuin]

Striped Mirrors sollten deutlich besser laufen und atime=on, heißt er loggt jeden Zugriff. Das erzeugt massiv Writes und bremst mal richtig.
Ein RaidZ2 sollte mehr Netto Kapazität haben, aber ist wie schon vorher erwähnt deutlich langsamer und sollte nie für VMs genutzt werden. Für Backups ist das OK.

Klingt für mich aber eher so, als hätte sich Alvin noch nicht richtig mit ZFS beschäftigt. Daher würde ich mal vermuten der Pool läuft noch mit Standardwerten (könntest du über zpool get ashift und zfs get volblocksize prüfen. Bei ashift=12 sollte volblocksize nirgends kleiner als 16K sein, bei ashift=13 nirgends volblocksize kleiner als 32K usw.) und dann würde man bei einem 8 Disk Raidz2 nur 2,66 von 8 Disks effektiv für VMs nutzen können, was dann deutlich schlechter als die 4 von 8 Disks von einem Raid10 wäre.