PVE 5.1 Backup per nfs freeze

[s.gruner]

Hallo zusammen,

ich habe unseren Produktivcluster auf PVE 5.1 aktualisiert und habe seitdem ein sehr eigenartiges Problem.
Ich kann keine Backups mehr erstellen.
Genauer gesagt: Ich konnte nach aufsetzen des neuen Clusters in der Version 5.1 zwar lesend auf das nfs Target zugreifen und die Backups der Maschinen wieder einspielen, aber wenn ich versuche ein neues Backup zu machen, bleibt es bei 1% stehen:

INFO: starting new backup job: vzdump 127 --remove 0 --compress lzo --mode stop --storage backup --node proxmox02
INFO: HOOK: job-start
INFO: Starting Backup of VM 127 (qemu)
INFO: status = stopped
INFO: update VM 127: -lock backup
INFO: backup mode: stop
INFO: ionice priority: 7
INFO: VM Name: flexlicense
INFO: include disk 'virtio0' 'san-storage:vm-127-disk-1' 50G
INFO: HOOK: backup-start stop 127
INFO: creating archive '/mnt/pve/backup/dump/vzdump-qemu-127-2017_12_12-16_15_46.vma.lzo'
INFO: starting kvm to execute backup task
INFO: started backup task 'bc3bcdad-42b1-4eea-9fcc-d5e7ce15bf67'
INFO: status: 1% (809631744/53687091200), sparse 1% (760492032), duration 3, read/write 269/16 MB/s

die Virtuellen Maschinen laufen zwar weiter, wenn ich aber auf der Server Konsole z.b. einen "df -h" absetzen will, friert die Konsole ein, das Backup-Storage ist dann unresponsive. Ich muss dann auf einer neuen Konsole folgendes machen, um den backup-prozess gekillt zu bekommen:

qm unlock 127
qm stop 127
umount -f /mnt/pve/backup
kill -9 <prozess-id des vzdump-prozesses>

das ist die einzige möglichkeit den backupprozess zu killen. die Oberfläche regiert nicht auf "Stop" im Backup Dialog.

Ich habe alle Netzwerkverbindungen mehrfach geprüft, alles korrekt. Mit dem selben Setup und selber Hardwareausstattung hat es in Version 3.4 / 4.4 / 5.0 ohne Probleme funktioniert. Ich bin recht ratlos. irgendwelche ideen?

Ich bin für jede Hilfe dankbar !

mfg
gruner

pveversion:

proxmox-ve: 5.1-25 (running kernel: 4.13.4-1-pve)
pve-manager: 5.1-35 (running version: 5.1-35/722cc488)
pve-kernel-4.13.4-1-pve: 4.13.4-25
libpve-http-server-perl: 2.0-6
lvm2: 2.02.168-pve6
corosync: 2.4.2-pve3
libqb0: 1.0.1-1
pve-cluster: 5.0-15
qemu-server: 5.0-17
pve-firmware: 2.0-3
libpve-common-perl: 5.0-20
libpve-guest-common-perl: 2.0-13
libpve-access-control: 5.0-7
libpve-storage-perl: 5.0-16
pve-libspice-server1: 0.12.8-3
vncterm: 1.5-2
pve-docs: 5.1-12
pve-qemu-kvm: 2.9.1-2
pve-container: 2.0-17
pve-firewall: 3.0-3
pve-ha-manager: 2.0-3
ksm-control-daemon: 1.2-2
glusterfs-client: 3.8.8-1
lxc-pve: 2.1.0-2
lxcfs: 2.0.7-pve4
criu: 2.11.1-1~bpo90
novnc-pve: 0.6-4
smartmontools: 6.5+svn4324-1
zfsutils-linux: 0.7.2-pve1~bpo90
openvswitch-switch: 2.6.2~pre+git20161223-3

 

[fireon]

Hmm, klingt komisch. Haben hier auch alles auf NFS, keine Probleme. Weder mit 4.x noch mit 5.x. Kannst denn auf das NFS von PVE aus schreiben? Mach mal ein "touch /mnt/pve/deinNFS/test.txt"

Auf was läuft denn dein NFS-Server?

 

[s.gruner]

moin,

ja schreiben kann er generell schon, er legt beim backup auch das temp verzeichnis und die vma.dat an, aber dann bleibt er eben bei 1% stehen.
Ich hatte testhalber mal so ein backup über nacht laufen lassen, dann war er bei 3%, trotzdem kann das ja nicht sein. die Maschine war nur 100GB groß, normalerweise brauch er dafür nur wenige Minuten.

NFS läuft auf einem debian stable 9.3

dpkg -l |grep nfs

ii nfs-common 1:1.3.4-2.1 amd64 NFS support files common to client and server
ii nfs-kernel-server 1:1.3.4-2.1 amd64 support for NFS kernel server

wie gesagt, von allen anderen Clustern in der anderen Versionen funktioniert es einwandfrei, auch zum jetzigen Zeitpunkt noch, hab es extra nochmal getestet.

Ich bin weiterhin für jede idee offen,
danke für die Hilfe

mfg
gruner

 

[s.gruner]

mit scp lässt sich das problem auch nachvollziehen.

z.B.:
von proxmox01 10.0.2.11 auf backup 10.0.2.8 werden daten geschrieben, aber nur mit knapp 10 MB/s nach kurzer Zeit -stalled-
umgekehrt von backup 10.0.2.8 auf proxmox01 10.0.2.11 Daten schreibend funktioniert ohne Probleme mit ca 100 MB/s

Das Problem lässt sich auch auf einem zweiten storageserver nachbilden. Routing haben wir kontrolliert, scheint auch zu stimmen, alle server kommunizieren direkt miteinander, ohne Hop dazwischen.

 

[fireon]

Poste doch bitte mal "dmesg" und lspci (nur die Netzwerkkarte). Von PVE auf das Backupdevice mit z.B. rsync gehts normal? Also jetzt ohne NFS direkt über SSH.
Post auch bitte eine "exports" vom NFSserver. Es könnte schon auch ein Treiberproblem mit aktuellen Kernel geben... oder hast vielleicht sowas wie "iommu=on" in grub stehen?

 

[s.gruner]

Moin,

dmesg liefert nichts außer meldungen vom multipathing, beispielhaft nachfolgend aufgeführt:

[511565.053435] sd 3:0:0:0: alua: supports implicit TPGS
[511565.053446] sd 3:0:0:0: alua: device naa.600c0ff0001dc41882dcf85901000000 port group 1 rel port 5
[511565.069847] sd 3:0:0:0: alua: port group 01 state N non-preferred supports tolusNA
[511565.133461] sd 4:0:0:0: alua: supports implicit TPGS
[511565.133470] sd 4:0:0:0: alua: device naa.600c0ff0001dc41882dcf85901000000 port group 0 rel port 2
[511565.145813] sd 4:0:0:0: alua: port group 00 state A preferred supports tolusNA

lspci:

08:00.0 Ethernet controller: QLogic Corp. cLOM8214 1/10GbE Controller (rev 54)
08:00.1 Ethernet controller: QLogic Corp. cLOM8214 1/10GbE Controller (rev 54)
0e:00.0 Ethernet controller: Emulex Corporation OneConnect 10Gb NIC (be3) (rev 01)
0e:00.1 Ethernet controller: Emulex Corporation OneConnect 10Gb NIC (be3) (rev 01)

Es sind jeweils 2x10Gbit/s über OVS gebondet und werden dann in die VMs gebridged. Der Proxmox selbst nutzt einen OVS-IntPort für seine eigenen Schnittstellen. Ohne NFS habe ich bereits getestet. Deswegen hatte ich noch ergänzt, dass sich das Problem mit scp auch nachvollziehen lässt. Da wird über SSH getunnelt, trotzdem das selbe Fehlerbild.

nachfolgend die /etc/exports:

/mnt/proxmox 10.0.2.8/24(rw,sync,no_root_squash,no_subtree_check,insecure)
/mnt/proxmox 192.168.0.0/16(rw,sync,no_root_squash,no_subtree_check,insecure)

hierzu soll gesagt sein, ich habe sowohl sync als auch async getestet, ohne Änderung des Ergebnisses
Kernelprobleme hatte ich auch bereits vermutet. der NFS-Server ist auf dem selben aktuellen Kernel wie PVE 5.1 (kernel 4.13)

ich bin offen für weitere ideen

mfg gruner

 

[fireon]

dmesg liefert nichts außer meldungen vom multipathing, beispielhaft nachfolgend aufgeführt:

Brauchst du das? Also liegen die VM's auf ner Storage über Fibrechannel oder so...? Oder ISCSI über 10Gigabit? Ansonsten bin ich leider super ratlos.

 

[s.gruner]

Hi,

ja ich brauche das, meine struktur ist ein cluster aus mehreren servern mitt einer hp msa 2040 als zentrales san storage.
Dieses ist wird per iscsi mit multipathing angesteuert und dann als lvm group im cluster zur verfügung gestellt.

d.h.

2x 10Gbit/s -> OVS Bond -> OVS IntPort für den Server selbst -> iscsi + multipathing -> SAN-Storage

2 x10Gbit/s -> OVS Bond -> OVS IntPort (vlan tagged) für den Server selbst -> normales Netzwerk

|-> OVS Bridge (tagged) -> alle Netze für VMs​