Unraid als rsync Ziel für eine Synology - Geschwindigkeit ist extrem niedrig.

[mb96]

Moin zusammen, ich habe mir gerade Unraid 6.9.2 (Testversion) auf einem alten PC installiert und wollte ausprobieren, was Unraid als Backup-Ziel (via rsync) für meine Synology DS1621+ (DSM 7.0.1) taugt. Momentan verwende ich da ein Xpenology-System als Ziel, aber wie man hört, haben "andere Mütter auch schöne Töchter" 😁, sprich es gibt ja auch Unraid und Truenas, daher wollte ich das mal ausprobieren.

 

Der Unraid-PC ist ein alter Core i7-860 (4C/8T) mit 8GB RAM, 2x 4TB Daten-HDD, 1x 4TB Parity-HDD und 1x 250 GB Samsung Evo 840 als Cache. Die Einrichtung der Parity wurde laut Dashboard mit ~130 MB/s Durchschnitt abgeschlossen. Netzwerk ist 1 GBit LAN laut Unraid Dashboard und Linkangabe im Managed Switch. Auf der Unraid-Installation hab ich rsync via dem folgenden Thread eingericht (Link), lief auf Anhieb, kann von Hyperbackup auf der Synology ohne Probleme gefunden und angesprochen werden.

 

Ohne jetzt besonders viel in Unraid verstellt/eingerichtet zu haben, kann ich von meinem Haupt-PC mit ca. 90 MB/s per SMB auf einen Share des Unraid-PCs kopieren, was ja in Ordnung ist. In Hyperbackup auf der Synology schaffe ich es per Aufgabe über "rsync-kompatibler Server" (Verschlüsselung und Kompression sind deaktiviert) aber nur mit ca. 30 Mbps, also ~ 3,5 MB/s auf das Unraid-System zu schreiben. Die einzelnen Threads auf dem Unraid-Server langweilen sich, keiner mehr als temporär 15% Auslastung. Die Testaufgabe waren auch eigentlich nur alles große Mediendateien, daran sollte es auch nicht liegen. Der niedrige Speed bleibt konstant, auch nach einer halben Stunde Laufzeit noch.

 

Hab ich irgendwas übersehen, was man noch einstellen muss, oder geht die Kombi "rsync über Synology Hyperbackup" auf "Unraid rsync Ziel" einfach nicht schneller? Vielleicht hat ja einer eine Idee, danke im Voraus! 

 

 

[mgutt]

19 hours ago, mb96 said:

Die einzelnen Threads auf dem Unraid-Server langweilen sich, keiner mehr als temporär 15% Auslastung.

Zeig mal bitte Screenshots von top und htop (WebTerminal) während ein Transfer läuft. 

[mb96]

Danke für deine Antwort, ich hatte gerade eben wieder Zeit für einen Test: Screens sind im Anhang. 😀

 

Durchschnittsgeschwindigkeit beim rsync-Backup von der Synology auf das Unraid-System liegt dabei - auch heute 😁 - immer noch bei um die ca. 3MB/s. Ich hab noch die beiden Screens bei einem SMB-Transfer von meinem Windows-PC auf das Unraid-System dazugepackt, welcher mit stabil 80 MB/s läuft. Ich hatte danach noch die Cache-SSD rausgeschmissen, aber das macht keinen Unterschied.

 

Hätte ja sein können, dass das ein typisches rsync-Problem ist oder man noch etwas konfigurieren muss, was ich bislang bei meinen Recherchen übersehen hatte. Ich hab demnächst wahrscheinlich noch ein anderes System auf Basis eines i3-8300 da, da könnte ich es ggf. auch mal testen. Hätte allerdings gedacht, dass die Intel-Generation "eins vor Sandy-Bridge" noch nicht so veraltet war.

 

[mgutt]

SMB und SSHFS sind Single Threaded. Du hast ein Leistungsproblem. Das kannst du aber in den Griff bekommen, in dem du nicht auf/von  /mnt/user transferierst, sondern /mnt/diskX nutzt. Dann fallen alle SSHFs Prozesse weg.

[mb96]

Danke für deine Einschätzung, so etwas hatte ich schon befürchtet. Bei Synologys DSM sind Single-Threaded-Prozesse auch gelegentlich ein Problem, u.a. bei der Verschlüsselung, wobei da aber AES-NI hilft. Ein i3-8300 hat im Passmark Single Thread allerdings auch "nur" 80% mehr Performance als ein i7-860, sprich da würde es dann per rsync auf vielleicht 5-6 MB/s hinauslaufen. Ist also anscheinend ein grundsätzliches Problem, ein schnelleres System wird nicht helfen.

 

Wenn ich das richtig verstanden habe, landen bei Nutzung von Disk Shares anstelle von User Shares die Daten auch nur auf einer physischen HDD. Ich würde ja das Unraid-System primär als Backup-Ziel nehmen, d.h. sobald die Backupdaten (inkl. Versionierung) mal größer als die entsprechende Disk werden, kann man es knicken. Wenn ich also ein Unraid-"Speichersystem" so wie ein RAID/SHR betreiben möchte, sprich wo alle Laufwerke ein einziges großes flexibles Volumen bilden, dann bleiben ja nur die User Shares.

 

Was ich allerdings nicht ganz kapiere, ist, warum SMB-Transfers auf den User Share so viel schneller als ein rsync-Transfer auf auch einen User Share sind. Der eine SHFS-Prozess hat ja bei rsync eine deutliche höhere CPU-Last als bei SMB. Gut, rsync dürfte ja auch nur Single-Threaded sein, aber für den wäre ja laut htop noch "Luft nach oben". 

Ich werde noch mal etwas probieren, aber anscheinend ist Unraid dann wohl nicht das richtige System für meinen Anwendungszweck ... auch eine Erkenntnis. 😁

[mgutt]

8 hours ago, mb96 said:

rsync dürfte ja auch nur Single-Threaded

SMB auch.

 

Ich tippe darauf, dass rsync viel mehr kleine Dateien verarbeitet als beim Test mit SMB? Das ist nämlich meist die Hauptursache für die Überlastung durch SSHFS.

 

Wenn du in den Unraid Server eine ausreichend große SSD packst, könntest du auch nach /mnt/cache/backups sichern und der Mover übernimmt anschließend die Verteilung nach den Regeln, die der backups Share besitzt.

 

Allerdings sieht rsync dann nicht die bereits übertragenen Dateien, die ins Array verschoben wurden. Ist also nur was für Vollbackups und keine sich wiederholenden rsync Kommandos, wo nur neue Dateien transferiert werden sollen. Evtl ginge dann aber "rsync -a --compare-dest=/mnt/user/backups /quelle /mnt/cache/backups". Muss man testen. EDIT: Ne dann würde er geänderte Dateien auf dem Cache erstellen und der Mover würde sie nicht ins Array verschieben, da sie dort bereits vorhanden sind (der Mover überschreibt grundsätzlich keine Dateien).

[mb96]

On 2/27/2022 at 7:53 AM, mgutt said:

Ich tippe darauf, dass rsync viel mehr kleine Dateien verarbeitet als beim Test mit SMB? Das ist nämlich meist die Hauptursache für die Überlastung durch SSHFS.

Bingo, das scheint der Kern des Problems zu sein.

 

Synology hat bei seinem HyperBackup mit DSM 6.0 (iirc) eine neues Konzept zur Speicherung eingeführt, bei dem die Daten nicht mehr 1:1 per rsync auf das Ziel geschrieben werden, sondern bei dem die Daten in einer Datenbank auf dem Zielsystem landen. Das hat einige Vorteile wie z.B. eine Versionierung, Deduplizierung etc., aber die Daten landen alle in einzelnen Blöcken auf dem Ziel und man braucht eine Synology oder ein Windows-Programm zum Zugriff auf die Backupdaten, womit ich aber gut leben kann. Auf dem Ziel bzw. in der Datenbankstruktur werden die Daten in 50 MB Dateien abgelegt, und jeder dieser Blöcke hat dann eine 200 kB Datei daneben, vermutlich Index oder Checksum. Es gibt dann in älteren Backups einen Berg von 8 MB Dateien, aber initial scheinen die 50+0,2 MB Häppchen geschrieben zu werden. Man kann auch weiterhin das alte Verfahren ("rsync Einzelversion") nutzen, bei dem die Daten direkt 1:1 per rsync auf das Ziel geschoben werden. Bislang hab ich für meine Tests immer das "neue" Verfahren genutzt.

 

Ich hab jetzt einmal Hyperbackup über das alte rsync-Einzelversions-Verfahren probiert und siehe da: Das Backup rennt mit Gigabit-Speed. Verwende ich mit den gleichen Daten (mehrere Hundert MB große mkv-Dateien) das neue Datenbank-basierte Verfahren, wieder 3 MB/s. Das hat mich jetzt tatsächlich etwas überrascht, denn Hyperbackup ist jetzt auch zwischen Synology-Plus-Modellen nicht gerade ein Rakete, aber so 30-40 MB/s waren auch mit Beteiligung einer Synology mit Dualcore-Celeron schon i.d.R. möglich. Richtig rennen tut Hyperbackup aber auch erst jetzt zwischen der DS1621+ und dem Xpenology-System mit Core 8th Gen CPU. 😁 

 

Ok, wieder ein Stück schlauer 😉 ... bzw. bestätigt, dass die Stärken von Unraid eher nicht bei der Storage-Performance liegen. 

 

[mgutt]

29 minutes ago, mb96 said:

bestätigt, dass die Stärken von Unraid eher nicht bei der Storage-Performance liegen. 

Das ist ja eigentlich kein Geheimnis. Ich bekämpfe das mit massig RAM, hoher Single Thread Leistung und 2TB großer NVMe ^^