Daten kopieren zwischen ProxmoVE zu ProxmoVE zu langsam.

[Kundo]

Hallo,
ich habe ein kleines Problem, welches ich entweder nicht verstehe oder beheben kann.

Ich habe zwei ProxmoxVE Server, einen Hauptserver und einer als Notsystem, für die wichtigen VMs/LXCs.
Damit das Notsystem schnell einsatzbereit ist, kopiere ich zu unterschiedlichen Zeiten die Backups und spiele diese auf das Notsystem zurück.
Soweit funktioniert das auch alles und das ist auch nicht der Punkt über den ich diskutieren, mich rechtfertigen möchte.

Das Problem um das es geht, ist die Geschwindigkeit beim direkten Kopieren von Dateien zwischen den beiden Servern.

Wenn ich mit den Clients auf die Samba Freigaben zugreife und Dateien kopiere, dann werden die mit den richtigen Geschwindigkeiten, entsprechend der Netzwerkverbindung, kopiert. Also mit dem 2,5 Gbit Netzwerk entspricht das diesem, wie auch beim 10 Gbit, auch Iperf3 sagt, dass alles passt.

Wenn jedoch die Backups vom PVE0 (10 Gbit) auf den PVE1 (2,5 Gbit) kopiert werden, dann enspricht das nur einem 1 Gbit Netzwerk. Ich hatte auch im PVE1 eine baugleiche, vom selben Hersteller, 10 Gbit SFP Netzwerkkarte, also 10 Gbit zu 10 Gbit und trotzdem blieb es bei einer Kopiergeschwindigkeit wie auf dem Bild.



Warum werden die Daten zwischen den beiden so langsam kopiert?



Wie geschrieben, alle Geschwindigkeiten passen, nur diese Eine nicht, aber warum?

Danke.

 

[meyergru]

Von welchen / auf welche Typen von Datenträgern kopierst Du? Welche Dateisysteme? Und mit welchen Werkzeugen (Samba, NFS, rsync, scp)?

Festplatten oder Raids haben oft Limits, die man erst nicht so checkt, beispielsweise ist ein RAID-Z2 aus 8 HDDs beim Lesen bei fast 1 GByte/s, beim Schreiben aber limitiert auf die Geschwindigkeit einer HDD, also ca. 180 MByte/s.

Wenn Deine Clients Windows nutzen, dann nutzen sie wahrscheinlich eine neuere Samba-Version mit Multistream-Technik.

Der Samba-Client unter Linux ist ziemlich langsam, da wäre NFS vermutlich performanter. Und wenn Du rsync nutzt, wird implizit ein (einziger!) SSL-Stream genutzt, der auch nicht so super schnell ist, weil er Totzeiten für ACKs hat.

Samba zu tunen (auch für Windows) ist eine Wissenschaft für sich.

 

[Kundo]

Ich kopiere von einer Seagate IronWolf HDD

auf eine WD


Hier ein Auszug aus dem Script...


Den NFS Server bekomme ich, warum auch immer, nicht installiert...

und damit hätte ich wieder ein Problem, mit dem ich mich jetzt nicht beschäftigen möchte, weshalb ich SAMBA gewählt habe.

 

[waltar]

Ggf. hast du dein cpu limit mit smbd 100% usage erreicht, schon mal mit "top" auf beiden Seiten geschaut ?
Anderenfalls könnte es auch dein Filesystem beim Lesen oder auf der anderen Seite beim Schreiben sein, siehe mit "iostat -xm 1".
Oder du kopierst versehentlich ggf. per smb config über den corosync link mit 1Gb, siehe mit "sar -n DEV 1" ?

 

[meyergru]

Naja, die einzelne HDD als Quelle macht sowieso maximal 180 MB/s. Aber wenn der Mountpunkt mit Samba eingehängt wurde, dann würde ich darauf tippen.

Für NFS-Fehler kann man mit journalctl -xe den genauen Fehler analysieren. Meist sind es Berechtigungen auf Mountpunkten.

 

[Kundo]

Ggf. hast du dein cpu limit mit smbd 100% usage erreicht, schon mal mit "top" auf beiden Seiten geschaut ?
Anderenfalls könnte es auch dein Filesystem beim Lesen oder auf der anderen Seite beim Schreiben sein, siehe mit "iostat -xm 1".
Oder du kopierst versehentlich ggf. per smb config über den corosync link mit 1Gb, siehe mit "sar -n DEV 1" ?

Auf beiden Seiten dümpelt die CPU Last während des kopierens bei 7-15% bzw. 9-11%.
"iostat -xm 1" in den Linux LXCs ausgeführt...

 

[Kundo]

Für NFS-Fehler kann man mit journalctl -xe den genauen Fehler analysieren. Meist sind es Berechtigungen auf Mountpunkten.

Ich kann da machen was ich will, es bleibt bei dieser Fehlermeldung
Failed to mount proc-fs-nfsd.mount - NFSD configuration filesystem.

Nach einem Neustart dann
Aug 31 15:16:10 NFS-Pmox-Backup login[255]: PAM unable to dlopen(pam_lastlog.so): /usr/lib/security/pam_lastlog.so: cannot open shared object file: No such file or directory
Aug 31 15:16:10 NFS-Pmox-Backup login[255]: PAM adding faulty module: pam_lastlog.so
Aug 31 15:16:14 NFS-Pmox-Backup login[255]: pam_unix(login:session): session opened for user root(uid=0) by root(uid=0)
Aug 31 15:16:14 NFS-Pmox-Backup login[255]: pam_systemd(login:session): Failed to create session: Seat has no VTs but VT number not 0
Aug 31 15:16:14 NFS-Pmox-Backup login[461]: ROOT LOGIN on '/dev/tty1'

Habe schon genügend Anleitungen aus dem Internet befolgt.

Also könnte die Kopiergeschwindigkeit demnach korrekt sein?

 

[waltar]

Erst erzählst du von pve0+1 backup kopieren ... und nun ist es zwischen 2 LXC's wo jeder disk I/O request durch die Virtualisierung hoch und runterläuft, na da wundert mich dein limit auch nicht mehr.

 

[meyergru]

Was heißt "korrekt"? Normal mit nicht optimiertem Samba, würde ich sagen. Und nein, ich kann nicht sagen, welche Optionen den Knoten ggf. platzen lassen. Ich bin froh, dass ich unter Windows einigermaßen Speed bekomme.

Dass unprivilegierte LXCs Probleme mit NFS haben, ist bekannt. Versuch es mal mit dem PVE host selbst. In einem LXC würde ich kein NFS betreiben, höchstens das per NFS gemountete Share per "lxc.mount.entry" oder "mp0" an den LXC durchreichen.

 

[Kundo]

zwischen 2 LXC's

Warum 2 LXCs?

PVE0 stelt per Samba LXC dem PVE1 die internen Backupdateien vom Verzeichnis /mnt/pve/Seagate-IR-4TB/dump "Storage 'Seagate-IR-4TB' auf Knoten 'pve'" zur Verfügung.
Der PVE1 holt sich diese Backups dann das eingebunde Storage (SMB/CIF) und legt diese in das Verzeischnis /mnt/pve/WD-6TB/dump

Wo laufen dafür dann zwei LXCs? Es läuft 1 LXC, damit ich das Verzeichnis zum kopieren der Backups freigeben kann, oder gibt es dafür eine besser Lösung, ohne dass ich über einen Proxmox BS gehen muss?

 

[waltar]

Auf beiden Seiten dümpelt die CPU Last während des kopierens bei 7-15% bzw. 9-11%.
"iostat -xm 1" in den Linux LXCs ausgeführt...

Hast du selbst geschrieben ... "... in den LXCs ..." was idR Mehrzahl ist.
Und wenn sowieso beides unter /mnt/pve/... tralala für Quelle und Ziel separat ..., dann nimm doch einfach "cp" auf dem pve - Junge Junge, man kann sich das Leben aber auch wirklich unendlich unbequem machen, aber warum einfach, wenn's auch kompliziert geht ... ?!?

 

[Kundo]

Hast du selbst geschrieben ... "... in den LXCs ..." was idR Mehrzahl ist.
Und wenn sowieso beides unter /mnt/pve/... tralala für Quelle und Ziel separat ..., dann nimm doch einfach "cp" auf dem pve - Junge Junge, man kann sich das Leben aber auch wirklich unendlich unbequem machen, aber warum einfach, wenn's auch kompliziert geht ... ?!?

Das sind zwei getrennt Rechner, die übers Netzwerk verbunden sind, wie soll ich also ohne Freigabe die Dateien von dem einen auf den anderen kopieren?

Ja, ich habe von "... in den LXCs ..." geschrieben, weil der PVE0 die Backups dem PVE1 zur Verfügung stellt, wie auch in die andere Richtung, wo dann der PVE1 dem PVE0 diese zur Verfügung stellen würde.
Es wird aber nichts zwischen den beiden LXCs (Samba Freigabe) gleichzeitig kopiert.

 

[Kundo]

Ich bin froh, dass ich unter Windows einigermaßen Speed bekomme.

Unter Windows 11 sieht es an meinem MSI Cubi mit 2,5Gbit so aus...

PVE0 10Gbit Netzwerk > LXC Samba Freigabe auf MSI Cubi mit 2,5Gbit


Und so vom Cubi zum PVE0


Deshalb bin ich so verwundert...

 

[Kundo]

Ja, NFS beschleunigt die ganze Sache...


Nachdem ich nun auf einem unprivilegierten LXC diesen NFS Server installieren konnte, sieht das mit der Übertragung schon etwas schöner aus, nun kommt der auf 192 MB/s.
Ist schon deutlich besser, wenn man das auch die Anzahl der zu kopierenden Backups sieht. Mit dem NFS war damit ein guter Tipp, Danke.
Mal schauen, ob ich den NFS Server auch ohne LXC nutzen kann...

 

[meyergru]

Nur so als Tipp: vzdump als komprimiertes Tarfile war gestern. Sieh Dir mal Proxmox Backup Server an. Da werden oft genug die Daten weder übertragen noch wirklich gespeichert. Durch die Deduplizierung wird der normale Backup um Größenordnungen schneller und auch noch sparsamer. Das gilt auch für Syncs zwischen verschiedenen PBS-Servern, falls Du eine 3-2-1 Backupstrategie fährst.

 

[Kundo]

Sieh Dir mal Proxmox Backup Server an

Muss ich mir nicht ansehen, habe ich auch im Einsatz. Als VM und PC mit 10 Gbit Netzwerk. Ich weiß auch, dass das Backup aller VMs wie LXCs um die 40 Minuten dauert, ich weiß aber auch, dass ich durch den ProxmoxBS schon Daten verloren habe, weil die Wiederherstellung des LXC nicht funktioniert hatte. Deshalb hatte ich diesen ProxmoxBS bis zur aktuellen Version nicht mehr im Einsatz und werde mich auch jetzt nicht auf diesen als einzige Backup-Möglichkeit verlassen.

Nun nochmal zurück zum Thema NFS Server im LXC oder direkt unter Proxmox...
Ich habe den NFS Server jetzt direkt unter Proxmox installiert, die LXC Geschichte deaktiviert und das Ergebnis ist eindeutig...


215 MB/s hatte ich bis jetzt nicht, damit habe ich mein Ziel erreicht und habe wieder einiges gelernt. Nochmals einen großen Dank wegen dem Tipp mit dem NFS Server und dass ich auf die LXC Geschichte verzichten sollte.
Nun bin ich echt am überlegen, on der PVE1 jetzt auch noch eine 10Gbit Netzwerkkarte bekommt...

 

[meyergru]

Been there - done that. Wie gesagt, wenn Ziel des Transfers eine HDD oder ein HDD-basiertes RAID ist, liegt die maximale Geschwindigkeit bei der einer Einzelplatte. Aktuell ist Dein Limit wohl eher durch den Datenträger als durch das Netzwerk begründet.

Und mit heutigen Festplatten geht das alles locker mit 2.5 GBit/s. Der einzige theoretische Vorteil von 10 GBit/s liegt ggf. in der Anbindung eines Trunk für mehrere VLANs, wo es Inter-VLAN-Traffic zwischen VMs oder LXCs gibt. LAGG ist Blödsinn für Non-Enterprise-Umgebungen, weil die meisten Switches maximal auf Basis des TCP-Streams verteilen und es meist nur einer pro Verbindung ist. Das funktioniert also nur bei einer großen Anzahl von Clients über die Statistik. Man kann aber ggf. durch Verteilung der VLANs auf mehrere 2.5 GBit/s Interfaces den selben oder besseren Effekt erzielen als mit einem LAGG. 10 GBit/s ist normalerweise weniger energieffizient und (viel) teurer - meist ohne messbaren Effekt. Das gilt insbesondere für 10 GbE - DAC ist etwas besser.

Das PBS-Problem mit dem LXC wundert mich - ich stelle oft eher fest, dass es zu Inkonsistenzen bei Backups kommt, weil bei laufender Maschine gebackupt wird und der Zustand im RAM natürlich mit der Platte korrespondiert. Nimmt man dann Dateisysteme wie ext4 oder UFS anstelle von ZFS, sind die Probleme vorprogrammiert. "Kein ZFS" ist auch immer wieder Quell von Freude bei OpnSense....