Push Sync mit Encryption

[JensF]

Push Sync von einem PBS zum zweiten funktioniert gut, aber mit aktivierter Verschlüsslung wird es ewig langsam.

Kurz zum Aufbau: 2x PBS auf dem neuesten Stand (no-sub repo) über Gigabit im selben Netz verbunden.
Die Hardware bei beiden ist schon etwas älter, spielt aber in diesem Fall tatsächlich keine Rolle.
Ein Push Sync ohne Verschlüsslung läuft mit rund 900MBit/s mit einem Worker. Alles prima.
Sobald man aber die Verschlüsselung aktiviert sind es nur noch max. 200MBit/s.
Der verschlüsselnde PBS hat zwei 4-Core CPUs welche sich während des Jobs langweilen. Es wird nur ein Thread der 16 vorhandenen genutzt.
Nur wenn man die Worker des Sync-Jobs erhöht (z.B. auf 8), wird auch wieder die Ursprungsgeschwindigkeit erreicht.
Das ist zwar zu Anfangs noch recht schnell, da mehrere Backups gleichzeitig verschlüsselt und synchronisiert werden.
Aber nach und nach sind dann die kleinen Backups abgeschlossen und es ist nur noch ein großes Backup zu synchronisieren.
Welches dann aber wieder nur mit 200MBit/s läuft.
Daher meine einfache Frage: Kann man den Sync-Job so einstellen, dass auch bei einem Worker mehr als ein Thread zum Verschlüsseln verwendet wird?

 

[Falk R.]

Push Sync von einem PBS zum zweiten funktioniert gut, aber mit aktivierter Verschlüsslung wird es ewig langsam.

Kurz zum Aufbau: 2x PBS auf dem neuesten Stand (no-sub repo) über Gigabit im selben Netz verbunden.
Die Hardware bei beiden ist schon etwas älter, spielt aber in diesem Fall tatsächlich keine Rolle.
Ein Push Sync ohne Verschlüsslung läuft mit rund 900MBit/s mit einem Worker. Alles prima.
Sobald man aber die Verschlüsselung aktiviert sind es nur noch max. 200MBit/s.
Der verschlüsselnde PBS hat zwei 4-Core CPUs welche sich während des Jobs langweilen. Es wird nur ein Thread der 16 vorhandenen genutzt.
Nur wenn man die Worker des Sync-Jobs erhöht (z.B. auf 8), wird auch wieder die Ursprungsgeschwindigkeit erreicht.
Das ist zwar zu Anfangs noch recht schnell, da mehrere Backups gleichzeitig verschlüsselt und synchronisiert werden.
Aber nach und nach sind dann die kleinen Backups abgeschlossen und es ist nur noch ein großes Backup zu synchronisieren.
Welches dann aber wieder nur mit 200MBit/s läuft.
Daher meine einfache Frage: Kann man den Sync-Job so einstellen, dass auch bei einem Worker mehr als ein Thread zum Verschlüsseln verwendet wird?

Hi, die Verschlüsselung läuft immer auf einem Core pro Job. Wenn deine CPU keine Hardware Encryption kann und alles berechnen muss, dann wird das folglich langsam.

 

[JensF]

Auf einen Thread pro Job! Und jupp, Hardware Encryption ist nicht vorhanden, aber dafür 15 sich langweilende Threads.
Daher war ja meine Frage, lässt sich das ändern?

 

[Bu66as]

Nee, dafür gibts kein Tunable. Die Parallelisierung beim Sync läuft nur über die Gruppen (also deine Worker), innerhalb einer Gruppe läuft alles sequenziell und die Krypto klebt an dem einen Thread. Heißt: skalieren kannst du nur in die Breite, und beim letzten dicken Backup bringt dir das genau nichts. PBS fährt fest AES-256-GCM, ohne AES-NI ist da halt Ende.

Wenn die beiden Kisten sowieso im selben Netz stehen, würde ich die Verschlüsselung eine Ebene tiefer legen: ZFS native encryption oder LUKS unter dem Ziel-Datastore statt clientseitiger Backup-Verschlüsselung. Dann läuft der Sync wieder mit voller Leitung und die Daten liegen trotzdem at rest verschlüsselt. Der Transport ist dann nur noch durch TLS geschützt, im eigenen LAN meist verschmerzbar. Nebeneffekt: die Cross-Host-Dedup bleibt dir erhalten, die killst du dir mit der Backup-Verschlüsselung ja auch.

Was sind das denn für CPUs konkret? Bei wirklich altem Zeug ohne AES-NI passen die 200 MBit/s leider gut ins Bild.

 

[JensF]

Den Zieldatenträger mit Luks verschlüsselt hatte ich eine Weile. Nur dann muss der kleine Ziel-PBS mit seinen zwei Cores (ohne HT) verschlüsseln.
Das macht noch weniger Spaß.
Haupt-PBS mit 2x Xeons X5560 und Ziel PBS mit 1x Pentium G4400.
Ja, ich weiß. Alter Scheiß. Aber für 650GB über Nacht auf RDX 1TB HDDs schreiben reicht's für uns.

 

[Bu66as]

X5560 ist noch Nehalem, AES-NI kam bei Xeon erst mit den X5600ern. Und der G4400 hat auch keins, Intel hat AES-NI bei den Skylake-Pentiums/Celerons rausgeschnitten. Beide Kisten rechnen AES also komplett in Software, damit passt dein Bild einfach perfekt.

Bei LUKS musst du aber nicht zwingend bei AES bleiben. Ohne AES-NI ist Adiantum/XChaCha20 in Software um Faktoren schneller, das war ja genau für solche CPUs gedacht. Miss das mal gegeneinander: cryptsetup benchmark für den AES-XTS-Wert und dann cryptsetup benchmark -c xchacha20,aes-adiantum-plain64 -s 256. Wenn der Unterschied deutlich ausfällt, legst du das Ziel-Volume einfach damit an:

cryptsetup luksFormat --cipher xchacha20,aes-adiantum-plain64 --key-size 256 /dev/sdX

Dazu kommt, dass dm-crypt im Gegensatz zur PBS-Krypto pro CPU eine Workqueue fährt, die beiden Cores werden also beide benutzt. Für eine einzelne RDX-HDD sollte das locker reichen, die Platte ist da eh der Flaschenhals und nicht die CPU.

Falls das adiantum-Modul nicht geladen ist, vorher modprobe adiantum, sonst meckert cryptsetup nur unspezifisch rum.