pve-ha-lrm I/O Wait ...

[jms1000]

Hallo,

nach ständiger Fehlersuche, bin ich langsam mit meinem Latein am Ende (siehe auch die anderen Posts von mir bzw. Markus zum gleichen Thema).

Problem: Mit dem täglichen Backup geht der I/O auf dem Proxmoxsystemen bis auf über 30/40% hoch. Das ist ja zunächst nicht so schlimm, er geht jedoch nach dem Backup nicht wieder runter. Das einzige was zu sehen ist, ist dasder pve-ha-lrm im Status "D" fest hängt. Alle Nodes (LXC+VM) funktionieren ohne Probleme weiter, nur die Proxmox Funktionen (start/stop/migration) funktionieren nicht mehr. Da brauche ich auch kein Proxmox

Das Problem tritt bei 3 von 4 Proxmoxsystemen auf, die alle 10GB Mellanox Karten verbaut haben. Wobei es egal ist, ob die 10GB aktiv verwendet werden. Es dabei auch egal, ob ich das Backup lokal auf eine Disk im Proxmoserver oder auf das NFS schiebe.

Abhilfe ist Moment, dass ich die Proxmoxserver einmal täglich booten muss - oder ich mache keine Backups mehr.

Falls es doch jemanden gibt der wertvolle Tips hat, ich bin für alles dankbar.

MfG. Jörg

PS. Auf allen System läuft eine aktuelle 5'er Version, keine Fehler im Netzwerk /Interfacen/Speicher/usw...

 

[jms1000]

Hallo,

tja, keine Hinweise aus dem Forum zum Thema ?

Ich habe zwischenzeitlich mal ein wenig weiter gespielt ... dazu habe ich das Proxmox-Backup zunächst abgeschaltet. Und dann anstelle dessen ein lokales Backup innerhalb der VM und der LXC angelegt. Dieses lokale Backup (Datenbanken, Logfiles, /home/*) erzeugt so eine etwas höhere Last, die auf in Folge in die Images auf via NFS geschrieben wird. Ergebnis ist gleich: der pve-ha-lrm hängt im Status "D" und der I/O-Wait geht am Ende auf 25% und bleibt dort. Damit ist der Proxmox-Node in seinen Funktionen praktisch tot.

Die CPU, I/O, usw. auf dem NFS-Raid zeigt minimale Last, im Netzwerk komme ich nicht mal ein die 1GB Grenze während die Backups laufen ...


MfG. Jörg

 

[Alwin]

Liegen Image und Backup auf NFS? Ausgehend davon, wie sind der NFS und die PVE Server angeschlossen? Tritt das nur bei PVE Hosts auf die in einer HA Gruppe sind? Auf welchem Stand sind alle Nodes (pveversion -v)?

 

[jms1000]

Images und Backups liegen auf dem gleichem NFS, in zwei verschiedenen Exports. PVE und NFS sind direkt (ohne Switch) mit 10GB Mellanox Karten angeschlossen. der I/O Wait geht sowohl bei HA- als auch bei nicht-HA Nodes hoch. Er geht auch hoch, wenn nicht das Proxmox-Backup, sondern ein lokales Backup (innerhalb der Nodes) auf das NFS gesichert wird.

Proxmox ist auf dem aktuellen Stand:

proxmox-ve: 5.1-31 (running kernel: 4.13.8-3-pve)
pve-manager: 5.1-40 (running version: 5.1-40/ea05b379)
pve-kernel-4.13.4-1-pve: 4.13.4-26
pve-kernel-4.10.17-2-pve: 4.10.17-20
pve-kernel-4.13.8-3-pve: 4.13.8-30
pve-kernel-4.13.13-1-pve: 4.13.13-31
pve-kernel-4.10.17-3-pve: 4.10.17-23
libpve-http-server-perl: 2.0-8
lvm2: 2.02.168-pve6
corosync: 2.4.2-pve3
libqb0: 1.0.1-1
pve-cluster: 5.0-19
qemu-server: 5.0-18
pve-firmware: 2.0-3
libpve-common-perl: 5.0-25
libpve-guest-common-perl: 2.0-14
libpve-access-control: 5.0-7
libpve-storage-perl: 5.0-17
pve-libspice-server1: 0.12.8-3
vncterm: 1.5-3
pve-docs: 5.1-12
pve-qemu-kvm: 2.9.1-5
pve-container: 2.0-18
pve-firewall: 3.0-5
pve-ha-manager: 2.0-4
ksm-control-daemon: 1.2-2
glusterfs-client: 3.8.8-1
lxc-pve: 2.1.1-2
lxcfs: 2.0.8-1
criu: 2.11.1-1~bpo90
novnc-pve: 0.6-4
smartmontools: 6.5+svn4324-1
zfsutils-linux: 0.7.3-pve1~bpo9

 

[Alwin]

Wie viele Nodes hat das Cluster und wie viele greifen auf den NFS Server zu? Wie ist das Storage konfiguriert? Wie schaut die HA Konfiguration aus und wie viele PVE Nodes nehmen daran teil? Was steht in den Logs zum Zeitpunkt des pve-ha-lrm Ausstiegs?

pve-ha-lrm stop
pve-ha-lrm start -debug 1

Folgende Kommandos für die weitere Analyse, damit bleibt der pve-ha-lrm im Vordergrund.

 

[jms1000]

Auf jedem der 3 betroffenen Proxmox Server liegen ca. 5-6 VM/LXC. Die Last der Systeme selbst ist mehr gering. Das NFS ist auf Betriebssystemebene via fstab eingebunden und im Proxmox als Shared-Directory (data-raid):

dir: dataraid
path /mnt/data-raid
content rootdir,vztmpl,backup,images,iso
maxfiles 7
shared 1

zfspool: zfs-local
pool rpool/data
content images,rootdir
nodes prx2,prx1,prx3,prx4
sparse 0

dir: local
disable
path /var/lib/vz
content images,iso,rootdir,vztmpl
maxfiles 0
shared 0

Wie schon geschrieben steht nichts in den Logfiles. Irgendwann fängt das Backup an (egal ob lokal oder Proxmox) und der I/O Wait geht hoch. Nach dem Backup geht er nicht wieder runter. Der pve-ha-lrm steht im Status "D".

Ein Stop der pve-ha-lrm klappt, der Neustart jedoch nicht:

Dec 27 10:32:19 prx1 pve-ha-lrm[5340]: received signal TERM
Dec 27 10:32:19 prx1 pve-ha-lrm[5340]: restart LRM, freeze all services
Dec 27 10:32:29 prx1 pve-ha-lrm[5340]: watchdog closed (disabled)
Dec 27 10:32:29 prx1 pve-ha-lrm[5340]: server stopped
Dec 27 10:32:54 prx1 pve-ha-lrm[16940]: starting server
Dec 27 10:32:54 prx1 pve-ha-lrm[16940]: status change startup => wait_for_agent_lock
Dec 27 10:33:04 prx1 pve-ha-lrm[16940]: successfully acquired lock 'ha_agent_prx1_lock'
Dec 27 10:33:04 prx1 pve-ha-lrm[16940]: watchdog active
Dec 27 10:33:04 prx1 pve-ha-lrm[16940]: status change wait_for_agent_lock => active

Nachtrag: ohne den "debug -1" startet der pve-ha-lrm wieder ...

 

[Alwin]

Was sagt dmesg? Mit welchen Optionen ist /mnt/data-raid gemountet? Tritt das gleiche auf, wenn der NFS durch PVE direkt (NFS storage) gemountet wird?

journalctl -u pve-ha-lrm.service

Im Journal ist auch nix zu finden?

 

[jms1000]

- dmesg sagt nix (jedenfalls nicht was zum Fehler gehört, nur Bootmeldungen usw.)

- gemoutet ist default, nfs4:
192.168.101.2:/volume1/Share-PRX on /mnt/data-raid type nfs4 (rw,relatime,vers=4.0,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.101.1,local_lock=none,addr=192.168.101.2)

- ob der Fehler auch bei einem direktem Zugriff (NFS Storage) auftritt kann ich nicht sagen, das bekomme ich mit meinem Setup nicht hin. alle Proxmox-Nodes haben eine direkte Verbindung (und somit in Folge eine eigene IP-Addr) zum NFS-Raid. Für das HA-NFS müssten ja alle die gleiche IP-Addr zum NFS-Raid haben ...

- journalctl ist wie dmesg, nichts was man wissen will, bzw. was mit dem pve-ha-lrm zu tun hat.

 

[Alwin]

- dmesg sagt nix (jedenfalls nicht was zum Fehler gehört, nur Bootmeldungen usw.)

Hm... also auch keine NFS Meldungen? Ist am NFS Server in den Logs etwas zu erkennen?

- gemoutet ist default, nfs4:

Der PVE Storage Manager mounted mit NFS3.

Für das HA-NFS müssten ja alle die gleiche IP-Addr zum NFS-Raid haben ...

Ja stimmt. Als alternatives Setup könnte der NFS Server eine IP auf einer Linux Bridge haben und alle NIC Ports sind teil der Bridge.

Eine Vermutung wäre, dass das Verhalten durch den NFS Server ausgelöst wird. Vielleicht zu wenig NFS Prozesse oder Probleme beim Locking.

 

[jms1000]

Das NFS-Raid ist ein Synlogic DS3615 ... dort ist nicht in den Logfiles zu sehen. Die Last ist - abgesehen vom Backup - auch sehr gering.

Anzumerken wäre noch, das Setup (Netzwerk, Verkabelung) ist gleich wie bei Proxmox V4, die Probleme gibt es erst seit der Umstellung auf die 5'er Version (Neuinstallation allerNodes).

Eine Bridge kann das Teil nicht. Ich könnte nur versuchen, das über das Routing und eine Dummy-IP zu lösen. Mal schauen.

 

[jms1000]

Routing verbiegen ist einfach ... jetzt habe ich gemeinsames NFS via Proxmox auf allen Nodes.

Aber wie verschiebe ich die LXC/VM jetzt dahin um?
Die root-disk bzw. das Laufwerk liegen ja auf dem "alten" Raid das via Shared-Dierectory gemountet ist.
Geht das nur via Löschen und Restore aus dem Backup?

 

[Alwin]

Aber wie verschiebe ich die LXC/VM jetzt dahin um?

Das sollte mit "move disk" bei jeder VM disk einzeln gehen.

 

[jms1000]

ok, move disk bei der VM tut (man muss eben nur lesen was da steht) - und was mache ich bei den LXC ?

 

[Alwin]

Backup -> Restore oder CT image auf dem NFS verschieben und das Storage in der vmid.conf anpassen. Beides ist 'offline only'.

 

[jms1000]

Ich habe jetzt mal einen Proxmox-Server vollständig auf das NFS im Proxmox umgestellt (also ohne shared directory). Das Ergebniss ist gleich - nach dem die Backups gelaufen sind, bleibt der I/O Wait oben 50% stehen. Der pve-ha-lrm steht wie bisher im Status "D",

6785 ? Ss 0:05 pve-ha-lrm
10838 ? D 0:00 pve-ha-lrm
18809 ? D 0:00 pve-ha-lrm
31560 ? D 0:00 pve-ha-lrm

im Syslog ist zu lesen:

Dec 28 12:17:16 prx2 pve-ha-lrm[14347]: starting service vm:20110
Dec 28 12:17:17 prx2 pve-ha-lrm[14347]: service status vm:20110 started
Dec 28 12:18:06 prx2 pve-ha-lrm[29542]: stopping service vm:20114
Dec 28 12:18:09 prx2 pve-ha-lrm[29542]: service status vm:20114 stopped
Dec 28 12:18:36 prx2 pve-ha-lrm[1995]: starting service vm:20114
Dec 28 12:18:37 prx2 pve-ha-lrm[1995]: service status vm:20114 started
Dec 28 12:41:46 prx2 kernel: [ 4109.202683] INFO: task pve-ha-lrm:18809 blocked for more than 120 seconds.
Dec 28 12:47:48 prx2 kernel: [ 4471.698945] INFO: task pve-ha-lrm:18809 blocked for more than 120 seconds.
Dec 28 12:47:48 prx2 kernel: [ 4471.698994] pve-ha-lrm D 0 18809 6785 0x00000000

und im Dmesg steht:

[ 4955.027247] INFO: task pve-ha-lrm:18809 blocked for more than 120 seconds.
[ 4955.027269] Tainted: P O 4.13.13-2-pve #1
[ 4955.027282] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 4955.027300] pve-ha-lrm D 0 18809 6785 0x00000000

Alle anderen Proxmox-Server laufen wie bisher weiter. Also keine neuen Erkenntnisse, außer das es egal ist ob NFS3 oder NFS4, ob Sharded-Directory oder NFS.

 

[Alwin]

Was ist auf dem vierten Host anders Konfiguriert als auf den drei Betroffenen? Oder ist auf dem vierten weniger IO? Um die Synology auszuschließen, wäre ein anderes Storage zum Testen hilfreich. Da 1 GbE für Backup und VM disk Zugriff, je nach IO Last zu wenig ist. Das könnte dazu führen, das pve-ha-lrm in den Status "D" geht.

 

[jms1000]

Der 4.Host hat nur eine kleine alte CPU, keine 10GB Karte und nur zwei LXC die keine Last machen. Ansonsten ist die Konfig bei allen 4 Systemen gleich.

Das Backup und die VM/LXC laufen über 10GB auf das NFS, verwendet kommen jedoch (während das Backup läuft) nur auf 2-3GB in der Spitze. Wenn es NFS4 aktiv ist (shared directory) komme ich - nebenbei gesagt - auf 3-4GB in der Spitze, was auch unlogisch ist, da NFS3 viel weniger overhead hat ...

Ein anders Raid zum Testen ist nicht so einfach da
Ich könnte ja mal auf die Proxmox-Server untereinander ein NFS frei geben und da Backup drauf ziehen.

Anderer Versuch: LXC läuft lokal auf einem ZFS (mit Raid 10 darunter). Backup via Proxmox-NFS auf das Raid ... nach dem Backup bliebt der I/O Wait bei 25% stehen ...

 

[Alwin]

Um weitere Analyse zu betreiben, könnte man mit strace dem pve-ha-lrm während des Backups zuschauen.

strace -o trace.txt pve-ha-lrm start -debug

Eine Vermutung wäre, dass die Leitung während des Backups komplett dicht ist und der VM Status nicht mehr abgefragt werden kann.

 

[jms1000]

trace läuft ...

Die Vermutung das die Leitung dicht ist, teile ich nicht ganz, da die Leitung während des Backups zum einem nicht voll ist und zum anderen ist sie nach dem Backup ja wieder "leer".

Ich frage im Monitoring fortlaufend "pvecm status" und "pvecm nodes" ab - hier gibt es während des Backups keine Änderungen. Und via GUI werden im HA-Status alles Nodes mit aktiver Zeit und als "Aktive" während des Backups angezeigt.


Fest steht:
- NFS3(via Proxmox NFS) und NFS (via Shared-Directory) machen keinen Unterschied
- der I/O Wait geht nach dem Backup via Proxmox nicht wieder runter
- der I/O Wait geht nach dem Backup aus den LXC/VM nicht wieder runter
- der I/O Wait geht nach Messungen mit iperf und dd wieder auf den Normalwert (kleiner 10) runter, hier ist die Last auf dem NFS/Netzwerk/Disk auch noch viel höher als beim backup ...
- das Netzwerk und auch der Disk I/O werden via Proxmox nicht ausgelastet (via iperf messe ich knappe 9gb und via dd knappe 800 mb/s)

 

[jms1000]

trace mit backup ist durch ... am Ende habe ich 51% und ein paar Prozesse mehr:

11563 ? D 0:00 pve-ha-lrm
23932 pts/4 S+ 0:02 strace -o trace.txt pve-ha-lrm start -debug
23934 ? Ss 0:04 pve-ha-lrm
27267 ? D 0:00 pve-ha-lrm

Trace anbei.