Replication Timeout

[OsvaldoP]

Hallo

Leider komme ich nicht weiter bzw schaffe es nicht mal das Log zu finden welches mir weiterhelfen kann
Ich habe ein Cluster in welchen die VM mittels Replication auf den jeweils anderen Node gesynct werden.
Leider erhalte ich immer wieder Timeouts und ich kann nicht rausfinden woran es liegt. Nicht mal wirklich ob Netzwerk oder Disk

Kann mir jemand auf die Sprüngen helfen wie ich zu weiteren Details bez eines spez Replication Job komme?

Beide Server haben im Frontend 2x 10Gbit Karten im LACP Bond und Samsung PM SSD Disks

Fehler der per Mail zugestellt wird:

 command 'zfs snapshot zfs1/vm-115-disk-0@__replicate_115-0_1633486557__' failed: got
timeout

Danke & sg Roland

 

[fabian]

das deutet im normalfall auf zu hohe last auf ZFS seite hin.

 

[OsvaldoP]

Hallo Fabian!

Danke für die Info.
Das klingt als sollte ich die Übertragungsrate der Replikationen begrenzen. Nun stellt sich die Frage, wie erfahre ich welches Limit Mbit das beste für mich ist?

Kann ich die Menge an der Replizierten Datenmenge beim letzten sync feststellen? Um ca ein gefühl zu bekommen wie viel Daten übertragen werden

Danke

 

[fabian]

nein - das snapshot machen ist ja der erste schritt noch vor dem generieren des send/recv streams. das snapshot anlegen ist eine synchrone operation, die laeuft offenbar in den timeout weil die I/O last hoch ist. was sagt denn iostat/atop bzgl der auslastung der platten? und parallel zpool iostat -v zfs1 10?

 

[OsvaldoP]

Hy Fabian

Interpretiere ich das korrekt? Der Fehler tritt bereits beim Snapshot auf?

* Im Anhang ein Screenshot von atop

* iostat des Datastores:
(Ich weiss EVO Disks sind nicht optimal, aber wurden wir bei diesen Systemen auf Auge gedrückt)

capacity operations bandwidth pool alloc free read write read write -------------------------------------------------- ----- ----- ----- ----- ----- ----- rpool 7.69G 224G 0 48 983 606K mirror 7.69G 224G 0 48 983 606K nvme-eui.00253857019df0c4-part3 - - 0 23 502 303K nvme-eui.00253857019df0c5-part3 - - 0 24 481 303K -------------------------------------------------- ----- ----- ----- ----- ----- ----- zfs2101 597G 2.90T 116 883 1.35M 24.8M mirror 597G 2.90T 116 883 1.35M 24.8M nvme-SAMSUNG_MZQLB3T8HALS-00007_S438NA0N101761 - - 58 441 692K 12.4M nvme-SAMSUNG_MZQLB3T8HALS-00007_S438NA0N101764 - - 58 442 693K 12.4M -------------------------------------------------- ----- ----- ----- ----- ----- ----- zfs2102 1.90T 7.19T 351 379 1.80M 5.92M raidz1 1.90T 7.19T 351 379 1.80M 5.92M ata-Samsung_SSD_860_EVO_2TB_S3YVNB0N806984X - - 70 74 368K 1.19M ata-Samsung_SSD_860_EVO_2TB_S3YVNB0N806982V - - 70 76 368K 1.18M ata-Samsung_SSD_860_EVO_2TB_S4X1NJ0N806295Z - - 70 78 368K 1.18M ata-Samsung_SSD_860_EVO_2TB_S3YVNB0N806985H - - 70 75 368K 1.18M ata-Samsung_SSD_860_EVO_2TB_S3YVNB0N806989J - - 70 74 368K 1.18M -------------------------------------------------- ----- ----- ----- ----- ----- -----

Anbei iostat während ein Replikat durchgeführt wurde:
zpool iostat -v zfs2101 10

capacity operations bandwidth pool alloc free read write read write -------------------------------------------------- ----- ----- ----- ----- ----- ----- zfs2101 595G 2.90T 0 495 0 12.1M mirror 595G 2.90T 0 495 0 12.1M nvme-SAMSUNG_MZQLB3T8HALS-00007_S438NA0N101761 - - 0 246 0 6.03M nvme-SAMSUNG_MZQLB3T8HALS-00007_S438NA0N101764 - - 0 249 0 6.03M -------------------------------------------------- ----- ----- ----- ----- ----- ----- capacity operations bandwidth pool alloc free read write read write -------------------------------------------------- ----- ----- ----- ----- ----- ----- zfs2101 595G 2.90T 0 532 0 10.7M mirror 595G 2.90T 0 532 0 10.7M nvme-SAMSUNG_MZQLB3T8HALS-00007_S438NA0N101761 - - 0 265 0 5.34M nvme-SAMSUNG_MZQLB3T8HALS-00007_S438NA0N101764 - - 0 267 0 5.34M -------------------------------------------------- ----- ----- ----- ----- ----- ----- ######################## Snapshot wurde gestartet ############################## capacity operations bandwidth pool alloc free read write read write -------------------------------------------------- ----- ----- ----- ----- ----- ----- zfs2101 595G 2.90T 1 818 31.2K 19.6M mirror 595G 2.90T 1 818 31.2K 19.6M nvme-SAMSUNG_MZQLB3T8HALS-00007_S438NA0N101761 - - 0 407 15.6K 9.82M nvme-SAMSUNG_MZQLB3T8HALS-00007_S438NA0N101764 - - 0 410 15.6K 9.82M -------------------------------------------------- ----- ----- ----- ----- ----- ----- capacity operations bandwidth pool alloc free read write read write -------------------------------------------------- ----- ----- ----- ----- ----- ----- zfs2101 595G 2.90T 0 795 0 16.6M mirror 595G 2.90T 0 795 0 16.6M nvme-SAMSUNG_MZQLB3T8HALS-00007_S438NA0N101761 - - 0 397 0 8.31M nvme-SAMSUNG_MZQLB3T8HALS-00007_S438NA0N101764 - - 0 397 0 8.31M -------------------------------------------------- ----- ----- ----- ----- ----- ----- ######################## Snapshot wurde Beendet und als OK markiert ############################## capacity operations bandwidth pool alloc free read write read write -------------------------------------------------- ----- ----- ----- ----- ----- ----- zfs2101 595G 2.90T 0 530 0 14.1M mirror 595G 2.90T 0 530 0 14.1M nvme-SAMSUNG_MZQLB3T8HALS-00007_S438NA0N101761 - - 0 262 0 7.07M nvme-SAMSUNG_MZQLB3T8HALS-00007_S438NA0N101764 - - 0 267 0 7.07M -------------------------------------------------- ----- ----- ----- ----- ----- ----- capacity operations bandwidth pool alloc free read write read write -------------------------------------------------- ----- ----- ----- ----- ----- ----- zfs2101 595G 2.90T 0 488 0 13.3M mirror 595G 2.90T 0 488 0 13.3M nvme-SAMSUNG_MZQLB3T8HALS-00007_S438NA0N101761 - - 0 242 0 6.64M nvme-SAMSUNG_MZQLB3T8HALS-00007_S438NA0N101764 - - 0 245 0 6.64M -------------------------------------------------- ----- ----- ----- ----- ----- -----

 

[fabian]

koenntest du mir noch pveversion -v output liefern? danke!

 

[OsvaldoP]

Sorry hab noch dran gedacht ob ich es nicht gleich machen soll. Aber denke es liegt eher an der Umgebung als wie am Code

proxmox-ve: 6.4-1 (running kernel: 5.4.128-1-pve) pve-manager: 6.4-13 (running version: 6.4-13/9f411e79) pve-kernel-5.4: 6.4-5 pve-kernel-helper: 6.4-5 pve-kernel-5.4.128-1-pve: 5.4.128-2 pve-kernel-5.4.78-2-pve: 5.4.78-2 pve-kernel-5.4.65-1-pve: 5.4.65-1 pve-kernel-5.4.34-1-pve: 5.4.34-2 ceph-fuse: 14.2.22-pve1 corosync: 3.1.2-pve1 criu: 3.11-3 glusterfs-client: 5.5-3 ifupdown: residual config ifupdown2: 3.0.0-1+pve4~bpo10 ksm-control-daemon: 1.3-1 libjs-extjs: 6.0.1-10 libknet1: 1.20-pve1 libproxmox-acme-perl: 1.1.0 libproxmox-backup-qemu0: 1.1.0-1 libpve-access-control: 6.4-3 libpve-apiclient-perl: 3.1-3 libpve-common-perl: 6.4-3 libpve-guest-common-perl: 3.1-5 libpve-http-server-perl: 3.2-3 libpve-storage-perl: 6.4-1 libqb0: 1.0.5-1 libspice-server1: 0.14.2-4~pve6+1 lvm2: 2.03.02-pve4 lxc-pve: 4.0.6-2 lxcfs: 4.0.6-pve1 novnc-pve: 1.1.0-1 proxmox-backup-client: 1.1.13-2 proxmox-mini-journalreader: 1.1-1 proxmox-widget-toolkit: 2.6-1 pve-cluster: 6.4-1 pve-container: 3.3-6 pve-docs: 6.4-2 pve-edk2-firmware: 2.20200531-1 pve-firewall: 4.1-4 pve-firmware: 3.2-4 pve-ha-manager: 3.1-1 pve-i18n: 2.3-1 pve-qemu-kvm: 5.2.0-6 pve-xtermjs: 4.7.0-3 qemu-server: 6.4-2 smartmontools: 7.2-pve2 spiceterm: 3.1-1 vncterm: 1.6-2 zfsutils-linux: 2.0.5-pve1~bpo10+1

 

[fabian]

ja ich vermute auch - das anlegen des snapshots scheint aufgrund der grundlast (manchmal?) nicht schnell genug durchzulaufen.. es erfordert leider einiges an umbauten um hier ohne unerwuenschte seiteneffekte ein hoeheres timeout einzubauen (diese umbauten sind aber geplant)..

 

[OsvaldoP]

Hallo Fabian!

hast du eine Art Workaround für uns und ist absehbar bis wann die Änderungen prod eingesetzt werden können?

sg
Roland

 

[fabian]

https://git.proxmox.com/?p=pve-stor...18783eab37c1d7f9ac0f51e59c7f68d6;hb=HEAD#l181 dort wird der timeout auf 5s gesetzt - wenns auf dem system nur ein bisschen laenger dauert laesst sich der wert eventuell leicht erhoehen. zu hoch kann den umgekehrten effekt haben - synchrone API calls (die nicht in einem eigenen task worker laufen) haben ein timeout von 30s inkl. error handling, wenn die ZFS operation dann 25s braucht bricht der API call eventuell ohne error handling ab (ein API call kann auch mehrere ZFS requests inkludieren).

eine prognose fuer einen generellen fix kann ich nicht geben.

 

[OsvaldoP]

Klingt nach einem größeren Eingriff welchen ich ungern in einem Prod System einsetzen möchte.
Ich habe mal für Downtime von 2 Servern angefragt um diese auf einen anderen Cluster verschieben zu können
2Vm und 2 Replikate weniger könnten ja schon helfen.

 

[fabian]

klar, last reduzieren hilft eventuell auch