Hohe Prozessorauslastung bei ZFS Encryption

[Bohnenhans]

Ja genau ich habe das ZFS auf einem Luks Crypt laufen.

Das ZFS bekommt von dem LUKS Crypt ja gar nichts mit - d.h. alle zfs Funktionen funktionieren ganz normal wie auf einem unverschlüssetlten device.

Wenn die Übertragung verschlüsselt sein soll muss ich das halt "extern" z.B. VPN etc crypten.

Hmm vielleicht ist halt meine CPU einfach insgesamt etwas stärker? Ist halt ein echter 4-Kerner mit 1,5 bzw 2,5 GHz

 

[polyphase]

Und wie machst du dein Backup?
Die ZFS Snapshots zum Remote "Backup" Server sind doch unverschlüsselt.

Also ich würde gerne die ZFS Backups auf einem Remote Server (Offsite) verschlüsselt ablegen.

 

[Bohnenhans]

Ich synce immer per rsync (und syncthing) damit das Ziel und Ursprungssystem auch komplett unterschiedlich sein können und das nicht nur mit ZFS<->ZFS funktioniert - auch wnen aktuell die meisten Systeme ZFS haben (FreeBSD+ZFS auf den grossen Servern - Linux+ZFS auf dem kleinen)

rsync geht ja auch per ssh wenn man will.

Man kann ja mit rsync auch problemlos auf verschlüsselte Systeme schreiben, dem ist das ja egal

Nachteil ist natürlich wenn man Dateien verschiebt/umbenennt etc die werden dann wieder übertragen.... aber was soll's weit über 98% meiner Serverinhalte bleiben zwischend den Syncs sicher gleich ....

Zwischen den grossen Servern nutze ich 10 GBit da kommt es mit auf ein paar (auch ein paar hundert) GByte mehr oder weniger nicht so an

 

[polyphase]

Aha, einen Flaschenhals habe ich noch gefunden 🤔

Wenn ich über den Dateimanager (Nemo) von meinem Rechner auf das SMB Share kopiere kommt ich ja nur auf ca. 90Mbyte/s.
Mache ich das aber per rsync auf das SMB Share komme ich auf 112,6Mbyte/s 👍

Zwischen den grossen Servern nutze ich 10 GBit da kommt es mit auf ein paar (auch ein paar hundert) GByte mehr oder weniger nicht so an

Ha, das hätte ich auch gerne. Mein Backup hängt leider nur an einer schnöden VDSL Leitung.
Das heißt, das erste Backup muss ich in meinem Netzwerk machen und dann das "Remote" Gerät an den anderen Standort bringen. Sonst dauert das ewig!

So jetzt muss ich nur noch den Raspberry Pi 4 fertig machen und ordentlich testen.
Dann können die Synology's endlich in Rente 😍

 

[Bohnenhans]

Das ist natürlich super wenn man den ersten Stand lokal syncen kann.

Auch wenn solche Fertig NAS fraglos gut sind - sobald man selber optimieren will wird man wohl fast immer an Grenzen kommen und 90% der Funktionen brauche ich zumindest eh nicht.

 

[polyphase]

Mir gefällt aktuell die Richtung die Synology geht nicht!
Immer mehr Einschränkungen und immer mehr Datenabfluss.
Des Weiteren werden die Dinger per Update immer langsamer.

Ich meine die DS216+ hat mitm Celeron N3050 jetzt nicht gerade einen lahmen ARM SoC verbaut und den RAM hatte ich auch aufgerüstet.

Ich werde mir auf jeden Fall nochmal die Mühe machen und mit TrueNAS Scale die AES Performance zu testen.

Edit:
Die Benchmarks aufm Pi 4 sehen vielversprechend aus:

# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1       400831 iterations per second for 256-bit key
PBKDF2-sha256     633198 iterations per second for 256-bit key
PBKDF2-sha512     504123 iterations per second for 256-bit key
PBKDF2-ripemd160  331827 iterations per second for 256-bit key
PBKDF2-whirlpool  124121 iterations per second for 256-bit key
argon2i       4 iterations, 323553 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
argon2id      4 iterations, 326031 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
#     Algorithm |       Key |      Encryption |      Decryption
        aes-cbc        128b        23.0 MiB/s        76.5 MiB/s
    serpent-cbc        128b        33.8 MiB/s        35.1 MiB/s
    twofish-cbc        128b        53.4 MiB/s        55.0 MiB/s
        aes-cbc        256b        17.3 MiB/s        58.2 MiB/s
    serpent-cbc        256b        34.8 MiB/s        35.2 MiB/s
    twofish-cbc        256b        55.2 MiB/s        54.7 MiB/s
        aes-xts        256b        83.1 MiB/s        74.5 MiB/s
    serpent-xts        256b        35.8 MiB/s        37.3 MiB/s
    twofish-xts        256b        59.5 MiB/s        60.6 MiB/s
        aes-xts        512b        64.9 MiB/s        56.8 MiB/s
    serpent-xts        512b        37.3 MiB/s        37.3 MiB/s
    twofish-xts        512b        61.8 MiB/s        60.5 MiB/s

 

[foofoobar]

Wenn ich über den Dateimanager (Nemo) von meinem Rechner auf das SMB Share kopiere kommt ich ja nur auf ca. 90Mbyte/s.

per gvfs oder per mount -t cifs ?

 

[polyphase]

gemounted über die fstab

 

[polyphase]

@Bohnenhans
Also die Tests sind durch.
In TrueNAS Scale ist AES noch nicht zu 100% gefixt.
Die Geschwindigkeit liegt im Schnitt bei 100Mbyte/s bricht aber immer wieder auf ca. 63Mbyte ein.
Bleibt also nicht konstant.

Ich habe das ganze noch mal mit OMV 6 (Debian) + Luks + ZFS getestet.
Da sind ähnlich hohe Geschwindigkeiten wie bei Ubuntu + Luks + ZFS möglich.

Also werde ich wohl deine Variante verwenden, mit Luks für die Verschlüsselung.
Jetzt muss ich nur noch überlegen ob ich das ganze mit Ubuntu Server oder OMV 6 mache 🤔

Ich bräuchte auch noch KVM, wegen einer einzigen virtuellen Maschine, die ich auch nicht ersetzen kann 🤯

 

[foofoobar]

gemounted über die fstab

Wie verhält sich smbclient?

Ergänzung (19. Dezember 2022)

@Bohnenhans
Also die Tests sind durch.
In TrueNAS Scale ist AES noch nicht zu 100% gefixt.
Die Geschwindigkeit liegt im Schnitt bei 100Mbyte/s bricht aber immer wieder auf ca. 63Mbyte ein.
Bleibt also nicht konstant.

Ohne die von mir beschriebenen Analysen lässt sich wenig bis nichts dazu sagen.

Ich habe das ganze noch mal mit OMV 6 (Debian) + Luks + ZFS getestet.
Da sind ähnlich hohe Geschwindigkeiten wie bei Ubuntu + Luks + ZFS möglich.

Also werde ich wohl deine Variante verwenden, mit Luks für die Verschlüsselung.
Jetzt muss ich nur noch überlegen ob ich das ganze mit Ubuntu Server oder OMV 6 mache 🤔

Kannst du die bisherigen Ergebnisse mal in einer Tabelle zusammenfassen.

Ich bräuchte auch noch KVM, wegen einer einzigen virtuellen Maschine, die ich auch nicht ersetzen kann 🤯

Schieb doch auch den Filer in eine VM,

 

[Bohnenhans]

Hmmm schade dass es noch keinen echten Fix zu geben scheint.

Naja Du kennst Dich denke ich richtig gut mit Linux etc aus - finde dann ist der Server meist doch die bessere Wahl, dann macht man das was man wirklich will und hat nicht ganz so viel unnötiges Zeugs.

Das sicher gut gemacht - aber meist braucht man doch 90% gar nicht und die Sachen die wirklich individuell sind muss man dann trotzdem per Hand machen.

KVM habe ich nicht laufen ( also als Dienst - als Gerät schon den PiKVM ) denke da findet man für Ubuntu sicher zig hunderte howtos ich lass bei mir virtualbox laufen, einfnach weil ich die Images dann zwis+chen den Systemen (Windows, Linux, FreeBSD) einfacher tauschen kann - und ich die virtuellen Maschinen praktisch sowieso nie wirklich brauche, den Rest lass ich nativ laufen.


Ja wenn du das je mal zusammenfasst dann wäre cool mit den genutzen Befehlen dann kann ich das evtl auch mal 1:1 gegenchecken wäre ja interessant auch für dann irgendwann retests mit btrfs evtl etc xD

Ich habe jetzt hier nochmal gestetst und 400 GByte Serien auf den Daily kopiert (LUKS+ZFS) (ist ja bald X-Maz) der lief über samba sehr stabil bei 270.000 KByte laut Total Commander und war auch in der erwarteten Zeit fertig. Nur meine 2,5 GBit hat alle paar Stunden mal einen reconnect, das liegt aber vermute ich mal am Treiber (Netzwerkkabel habe ich bereits getauscht), das passiert auch im Nicht Copy Betrieb.

 

[foofoobar]

Das Thema ZFS auf Linux kann nur Oracle fixen:

And honestly, there is no way I can merge any of the ZFS efforts until I get an official letter from Oracle that is signed by their main legal counsel or preferably by Larry Ellison himself that says that yes, it's ok to do so and treat the end result as GPL'd.

-> https://www.realworldtech.com/forum/?threadid=189711&curpostid=189841

Hier ein Beispiel Problem was sich daraus ergibt:

https://www.phoronix.com/news/ZFS-On-Linux-Restoring-SIMD

 

[Bohnenhans]

Dadurch dass OpenZFS "ZFS für Linux" ersetzt hat, hat sich zumindest ja diese Aussage von Linus komplett gerändert.

"And as far as I can tell, it has no real maintenance behind it either any more, so from a long-term stability standpoint"

Schade dass halt die Lizenzen so inkompatibel sind - in dem Punkt hat FreeBSD halt einen Vorteil.

 

[foofoobar]

Schade dass halt die Lizenzen so inkompatibel sind - in dem Punkt hat FreeBSD halt einen Vorteil.

Nein, die Lizenzen von den BSDs sind der Grund der Zerfaserung.
Und Oracle hat sowieso keine Verwendung für ZFS mehr, also kann man es auch in die Freiheit entlassen.

 

[polyphase]

Ende der Woche habe ich Zeit, da schreibe ich die Zusammenfassung

 

[polyphase]

@Bohnenhans und @foofoobar

Hier die versprochene Aufschlüsselung

Es wurden alle Messungen mit Rsync direkt auf der Hardware ausgeführt.
Als Laufwerke standen eine SSD (ext4 formatiert) und ein ZFS Pool (Mirror) mit 2x HDD zur Verfügung.

Beim Test wurde eine 10 Gbyte große Testdatei von der SSD (ext4) auf das entsprechend konfigurierte ZFS Dataset geschrieben. Für den Lesetest wurde vom ZFS Dataset auf die SSD (ext4) geschrieben.

Damit wurde der Flaschenhals "Netzwerk" aus der Gleichnung entfernt!

Für den native ZFS Test wurde TrueNAS Scale 22.12 verwendet, da dieses einen AES-NI Patch enthält, was die Performance etwas verbessert.

	von ext4 zu ZFS (Schreiben)	von ZFS zu ext4 (Lesen)	CPU Auslastung	Hinweis
ZFS on Luks	Ø 147 Mbyte/s	Ø 346 Mbyte/s	8 - 25%
ZFS native Encryption	Ø 78 Mbyte/s	Ø 35 Mbyte/s	75 - 100%	starke Schwankung zw. 63 - 125 Mbyte/s beim Schreiben

Alle Zahlen sind zur einfacheren Lesbarkeit gerundet!

 

[Bohnenhans]

Mit Deiner CPU etc ist immerhin dann bei ZFS on Luks ein Gigabit Netzwerk ok.

Allerdings ab 2,5 GBit müsstest wohl upgraden xD

 

[polyphase]

Aber nur schreibend, lesend ist es arg langsam

 

[Bohnenhans]

Ja schade - wenn man Native ZFS Crypted auf der "kleinen" Hardware ohne AVX will kann man ja auch z.B, evtl FreeBSD statt Linux nehmen - muss ich mal austesten wie sich da mein Rechner verhält. Zum Glück habe ich von meinen "Kleinen" Rechnern mit J4105 ein paar rumliegen xD

Denke im FreeBSD Kernel ist das mit Crypt evtl anders gelöst und kommt ohne AVX aus.

 

[polyphase]

Da ich für einige Dinge leider ein natives Linux benötige, bleibt mir diese Alternative nicht.
Aber das macht nix, ZFS on Luks ist ja nicht schlecht 👍

Faszinierend finde ich das die Lesegeschwindigkeit so hoch ist, anscheinend ließt ZFS von beiden Platten gleichzeitig 🤔