[BUG?] PBS Sync (pull) ignoriert Bandbreiteneinstellung komplett

[yummiweb]

Backup Server 4.1.4 (andere Versionen nicht getestet)

Der Sync zwischen meinen PBS (offsite Backups) läuft mit sturen 8 Mbits, egal was in /etc/proxmox-backup/sync.cfg gesetzt ist (Einstellung per GUI).

Eine externe Beschränkung scheidet aus, weil auch ein niedrigerer Wert (z.B. 1 MBits) ebenso ignoriert wird. Auch bei einer Einstellung von 1MBits läuft der Trandfer mit c.a 8 MBits. Auch ein nicht gesetzter Wert wird ignoriert.

Getestet mit Ausführung des Jobs in der GUI auf Anforderung (Klick) , per Zeitplan (GUI) und per Ausführung des Jobs in der Konsole - macht alles keinen Unterschied.

Ich habe testweise einen komplett neuen Syncjob angelegt, auch dieser ignoriert jede Bandbreiteneinstellung.

Kann jemand dieses Verhalten reproduzieren? Bevor ich das als BUG irgendwo (wo?) melde?

Gruss Yummiweb

 

[UdoB]

Auch in englisch: https://forum.proxmox.com/threads/bug-pbs-sync-pull-completely-ignores-bandwidth-setting.181430/

 

[Bu66as]

Zeig mal bitte den Inhalt von /etc/proxmox-backup/sync.cfg, damit man sieht was da tatsächlich als rate-limit drinsteht. Und wie sind die beiden PBS verbunden, direkt übers Netz oder per VPN?
Die 8 Mbit klingen halt so als wär das einfach die Leitungsgeschwindigkeit und das Limit greift gar nicht. Wenn selbst 1 MBit/s ignoriert wird, ist das schon verdächtig.
Kannst du testweise mal nen manuellen Pull mit proxmox-backup-manager pull und explizitem --rate-limit Parameter machen und schauen ob das was ändert? Damit kann man eingrenzen obs am Job/Config-Parsing liegt oder generell am Rate-Limiter.
Bugs meldest du übrigens über den Bugtracker: https://bugzilla.proxmox.com

 

[yummiweb]

Zeig mal bitte den Inhalt von /etc/proxmox-backup/sync.cfg, damit man sieht was da tatsächlich als rate-limit drinsteht.

sync: s-1a22b33c-4dd0
comment Zeitgleiche sshuttle Verbindung erforderlich, siehe crontab Eintrag
encrypted-only false
ns
owner pbs_user_org@pbs
rate-in 16 MiB
remote PBS_ORG
remote-ns
remote-store PBS_ORG_LOCAL
remove-vanished false
resync-corrupt true
store PBS_ORG_GAST
transfer-last 3
verified-only false

Und wie sind die beiden PBS verbunden, direkt übers Netz oder per VPN?

SShuttle übers internet

Die 8 Mbit klingen halt so als wär das einfach die Leitungsgeschwindigkeit und das Limit greift gar nicht.

100/50er Leitung an der Quelle, 60/40 am Ziel. Die Leitung ist nicht das Problem, es geht ja auch zusätzlicher anderer Traffic drüber. Ich hatte den Jobs früher mal (PBS Vorversion) eine Begrenzung auf 8MBits gegeben, aber weil ich kurzfristig grössere Mengen syncen muss, habe ich die Begrenzung angehoben und bemerkt, dass das nichts ändert (damals hatte das immer funktioniert).

Wenn selbst 1 MBit/s ignoriert wird, ist das schon verdächtig.

Ja eben, wenn auch runtersetzen nichts ändert, kann es ja nicht an einem Bandbreitenlimit liegen.

Kannst du testweise mal nen manuellen Pull mit proxmox-backup-manager pull und explizitem --rate-limit Parameter machen und schauen ob das was ändert? Damit kann man eingrenzen obs am Job/Config-Parsing liegt oder generell am Rate-Limiter.
Bugs meldest du übrigens über den Bugtracker: https://bugzilla.proxmox.com

Bisher laufen die Syncs per:
/usr/sbin/proxmox-backup-manager sync-job run s-1a22b33c-4dd0

Leider bekomme ich in den pull Befehl den fernen User nicht eingebunden und kann auf die Schnelle die Berechtigungsmatrix nicht ändern.

Auch wenn es unlogisch klingt, habe ich noch etwas anderes versucht:
Wenn ich die sshuttle Verbindung mit der Option "--no-latency-control" starte, erhalte ich gewaltige Spikes im Transfer wo sonst ein eher gleichmässiger Fluss war.

Auf diese Weise sehe ich 35MBits fliessen (zumindest in der Spitze) OBWOHL im Job ein Limit von 16Mbits steht.
Allerdings sehe ich diese Spitzen auch wenn ich im Job ein Limit von 1Mbits eintrage und insgesamt schein sich das auszumitteln, d.h. Im Durchschnitt betrachtet, würde ich dennoch von den bisherigen 8MBits ausgehen.

Es mag natürlich sein, dass die Sensorik der BW Begrenzung im PBS nicht mit dem Puffer der sshuttle Verbindung harmoniert, aber ich müsste je nach BW Limit zumindest geringfügige Unterschiede sehen - und die sehe ich nicht. Und frpher ging es ja auch, deshalb hatte ich die BW Begrenzung im Job ja eingeführt.

 

[yummiweb]

Nachtrag:
Per rsync von derselben PBS Maschine (mit dem ich auch Dateibackups offsite sichere) kann ich die Bandbreite sauber nach oben und unten bestimmen - es liegt also nicht an irgendwelchen anderen Netzwerkbeschränkungen. Rsync uns Sshuttle laufen über dieselben Ports von denselben Quellen zu denselben Zielen, der Transfer wäre ssomit elbst für den Provider nicht auseinanderzuhalten, entsprechend kommt auch der nicht als Grund infrage.

 

[yummiweb]

Und noch ein Nachtrag - und wohl die Lösung

Ich habe die "--no-latency-control" Option wieder aus dem sshuttle Befehl entfernt und die sshuttle verbindung neu gestartet, seitdem läuft der job mit einer Geschwindigkeit von ca. 40 Mbits (bzw Fullspeed) OBWOHL er eine BW Begrenzung von 16 eingetragen hatte.

Daher habe ich mal etwas genauer hingesehen und es scheint mir, dass ich hier einfach einen Irrtum bzgl. der Grössenordnung hatte - denn die verwendete Einheit ist ja (bei genauerem Hinsehen) "MiB/s" und nicht "MBit/s"

Aber wie kam es zu den identischen Messwerten bei den Tests?
Für meine Tests hatte immer zwischen 1 und 16 eingestellt wobei immer nur 8MBits. über die Leitung gingen.
Die max. 8 MBits mögen irgendwie durch das sshuttle verursacht worden sein - beim dem der Knoten offenbar grad geplatzt ist.
Allerdings, bei einer BW Einstellung von "1 MiB/s" würden ja korrekt ebenso nur 8Mbits übertragen - zufälligerweise der Wert den der sshuttle Knoten verursachte. Entsprechend konnte kein Unterschied sichtbar werden.

Nachdem ich sshuttle jetzt einen grösseren Buffer mitgegeben habe (--latency-buffer-size=131072), erreiche ich in etwa die zu erwartenden Werte. Mit der Einstellung 2 Mebibyte(!) laufen jetzt etwa 16MBits über die Leitung.

Das Problem sass also vor dem Bildsschirm und hatte wohl zu müde Augen - wobei mir immer noch nicht klar ist, warum es damals in MBits Entsprechnung funktionierte? Wurden die Einheiten in der Version4 geändert?

Danke fürs Mitmachen und MItdenken!