Proxmox VM Stun bei Snapshot

D

devops01

New Member
Proxmox Subscriber
Mar 26, 2024
6
0
1
Hallo,

in unserem Cluster beobachten wir das Phänomen, dass beim erstellen eines Snapshots die VM kurzzeitig einfriert und für einige Pings nicht erreichbar ist.
Als Storage Lösung verwenden wir eine NetApp mit NFS 4.2 der Cluster ist derzeit noch auf Version 8.4.1.
(pve-manager/8.4.1/2a5fa54a8503f96d (running kernel: 6.8.12-11-pve))

Die NetApps mit SSD Storage sind mit einem aktiv aktiv 10G Bond (802.3ad) angebunden und hätten noch einiges an Luft nach oben bezüglich Auslastung.

Ich konnte dieses Verhalten inzwischen auch auf einem neuen, unabhängigen Host mit lokalem ZFS-SSD-Storage, 512GB RAM und Version 9.1.4 reproduzieren.
(pve-manager/9.1.4/5ac30304265fbd8e (running kernel: 6.17.4-2-pve))

Der Host hat bis jetzt zwei Test VMs und kaum Auslastung.

Damit können wir die NetApp-Anbindung, NFS 4.2 und Workload als Ursache vermutlich ausschließen.

Das Problem tritt mit und ohne Include RAM auf.
Umso größer die VM umso länger ist sie nicht erreichbar.

Host 8.4.1 Storage CFG
Code: 
dir: local
  path /var/lib/vz
  content vztmpl,backup,iso
  prune-backups keep-last=3

zfspool: local-zfs
  pool rpool/data
  content images,rootdir
  nodes
  sparse 1

nfs:
  export
  path
  server
  content rootdir,images,vztmpl,iso,snippets,backup,import
  options nconnect=4,noatime,nodiratime,vers=4.1
  prune-backups keep-all=1

nfs:
  export /
  path /mnt/pve/netappProx
  server
  content images,iso
  nodes
  options nconnect=8,noatime,nodiratime,vers=4.2
  prune-backups keep-all=1

nfs:
  export
  path
  server
  content images,iso
  options nconnect=16,noatime,nodiratime,vers=4.2
  prune-backups keep-all=1

nfs:
  export
  path
  server
  content images,iso
  options nconnect=16,noatime,nodiratime,vers=4.2
  prune-backups keep-all=1

pbs:
  datastore
  server
  content backup
  fingerprint
  namespace
  prune-backups keep-all=1
  username

Host 9.1.4
Code: 
dir: local
    path /var/lib/vz
    content snippets,backup,iso,import,vztmpl

zfspool: local-zfs
    pool rpool/data
    content rootdir,images
    sparse 1

zfspool: local-6T-zfs
    pool local-ssd
    content rootdir,images
    mountpoint /local-ssd
    sparse 0
 

Attachments

Last edited:
Wie groß ist denn so eine VM? Beim erstellen (eigentlich immer ohne RAM) sehe ich gar nix beim Ping und beim löschen sehe ich mal einen etwas höheren Ping, aber keine Aussetzer.
 
Die zwei die ich jetzt zum testen verwendet habe 512 und 549GB.

Habe es gerade noch bei einer kleiner VM mit 92G getestet.

Normal sind wir bei um die 0.25ms.

time=0.189 ms
time=0.232 ms
time=6335 ms
time=5311 ms
ime=4287 ms
time=3264 ms
time=2240 ms
time=1216 ms
time=192 ms
time=0.329 ms
time=0.216 ms
 
Last edited:
OK, ein halbes TB RAM ist eher selten. Wenn du da Snapshots mit RAM machst, ist es zu erwarten dass es zu Einschränkungen kommt.
Ohne RAM sollte der Impact eigentlich auch nicht so groß sein.

Das mit der kleinen VM kann ich gar nicht nachvollziehen. Da habe ich sogar in meiner kleinen Testumgebung mit SATA SSDs und nur 10G Netzwerk niemals so viel Latenz. Das Verhältnis CPU Cores + RAM macht beim Snapshot auch einiges aus. Auf vSphere hatte ich auch mal eine VM mit 32vCPUs und 512GB RAM, da hatte auch jeder Snapshot die VM zum hängen gebracht, und das hat beim Backup immer weh getan.

Das wird bei KVM nicht viel anders sein als bei einem ESXi.
 
Sorry, da war ich gerade bei der Disk Size.

Beim RAM reden wir von 32 GB bzw. 16 GB, und bei der kleinen VM von 4 GB.

Das Problem tritt sowohl mit als auch ohne Include RAM auf :/.

Auf unserem Produktiv-Cluster ist die VM ohne RAM während der gesamten Snapshot-Dauer stunned, mit RAM sind es hingegen nur ein paar verlorene Pings.

Macht eigentlich keinen Sinn.
 
OK, also normale VMs.
Da soetwas normalerweise nicht auftritt, vermute ich mal die CPU ist überlastet und erzeugt Latenzen.
Bei dem PVE9 hast du Graphen für I/O Pressure und CPU Pressure, bei dem PVE 8 kannst du mal cat /proc/pressure/cpu abfragen.
 
Guten Morgen,

während eines Snapshots sehen wir durchaus erhöhten I/O-Wait auf den CPUs.
Teilweise liegen die Werte dabei über 10, , während sie ohne Snapshot konstant bei 0 % liegen.

Ich habe dir den Output einmal angehängt.
Würdest du sagen, dass diese Werte schon problematisch sind?
 

Attachments

Was mir auffällt ist der hohe iowait. Kannst du während einem Snapshot erstellen oder kurz danach noch einmal cat /proc/pressure/io ausführen.
Da siehst du den Wert, der letzten 10 Sekunden, letzten 60 und letzten 300 Sekunden. Damit hat man ein gutes Bild, wie der Wert im Schnitt in den letzten 5 Minuten war und wie beim erstellen des Snapshots.
Da der CPU Pressure quasi nicht vorhanden war, scheint das Problem doch aus dem I/O Pfad zu kommen.
 
Das sieht auch OK aus. Ich kann mir das jetzt nicht erklären, eventuell hat noch jemand anderes eine Idee.
 
  • Like
Reactions: devops01
You must log in or register to reply here.
Top Bottom
Back