[Sammelthread] ZFS Stammtisch

[McStarfighter]

Danke für die klare Antwort, damit ist es eindeutig!

 

[besterino]

Was ist denn aktuell (und langfristig) die beste Basis (OmniOS, Illumos, ...?) für einen Solarish "Schmalspur-Fileserver" als ESXi-VM, also für wirklich nur zentrale Storage-Dienste und vor allem iSCSI?

Gerade einfaches/komfortables iSCSI-Management ist für mich besonders wichtig, da ich die iSCSI-Freigaben für Windows-Anbindungen brauche (SMB3 - selbst wenn es funktioniert - ist noch kein vollwertiger Ersatz).

Bei Oracle Solaris nervt mich zunehmend, dass die Hardwareauswahl leider immer schwieriger wird. Weder für meinen HBA (9305-24i) noch für die Mellanox Connectx-4 gibt es native Solaris Treiber, was Passthrough und SR-IOV unter ESXi leider unmöglich macht.

 

[Digi-Quick]

Wenn es sich allerdings um SMR Varianten handelt, dann sind die absolut untauglich für ein NAS und Raid Betrieb.

Hmm, kann ich so nicht bestätigen!
Mein Raidz3 aus 19 Seagate Archive 8TB läuft seit fast 4 Jahren ohne Auffälligkeiten unter NAS4Free (noch kein XigmaNAS), Zugriffsmuster mittlerweile 98% lesen, 2% Schreiben, wenig löschen oder Ändern.
Das sind allerdings HDDs die 24/7 und laut Seagate für größere HDD Shelfs geeignet sind (Laut Produktbeschreibung)

Damals waren diese HDDs mit großem Abstand die günstigste Variante!
Ich würde Stand heute (bzw. schon länger) eher zu Seagate Exos 7E8 oder X12/14/16 greifen (wobei die Skyhawk AI auch geeignet sein müßte, da ZFS im ggs. zu Hardware-Raid kein TLER erfordert - jedenfalls nach meinen Recherchen vor einigen Jahren)

 

[ludwinator]

Das glaube ich sofort, denn genau dafür wurden die Platten ja entwickelt.
Allerdings ist SMR ja nur beim schreiben schwach (insbesondere random) und bei deinen 2% ist das locker drin.
Interessant wird's allerdings, wenn du mal einen Ausfall haben solltest und eine ersetzen musst. Der Resilver wird vermutlich ewig dauern, wenn du noch nicht auf aktuellem ZFS Stand bist.

cu

 

[kandamir]

Eine Frage zur Vorgehensweise zur Verschlüsselung:
Ich setze einen Backup Server auf, die Napp-It VM läuft (SunOS napp-it030 5.11 omnios-r151030-521a1fc4d1 i86pc i386 i86pc OmniOS v11 r151030ab). Es hängen zwei gleichartige Storage-Platten darin. Platte 1 enthält einen ZFS Pool mit mehreren Dateisystemen. Das ist das Backup des produktiven Servers. Alles unverschlüsselt. Da nachträgliche Verschlüsselung ja nicht möglich ist, kommt nun die zweite Platte ins Spiel. Dorthin sollen die Dateisysteme der ersten Platte übernommen werden - aber verschlüsselt. Sofern ich das richtig verstehe, wird per Dateisystem verschlüsselt, richtig? Oder per Pool?

Was wären die Schritte?

Pool auf Platte anlegen -> verschlüsselte Dateisysteme im neuen Pool anlegen -> Alle Snapshots per 'zfs send ... | zfs receive ...' von Platte 1 auf Platte 2 in die verschlüsselten Dateisysteme übertragen?

Anschließend soll der Pool mit dem verschlüsselten Backup erweitert werden um den Platz von Platte 1 (Stripset).

Geht das soweit?

Danke und Gruß

Kandamir

 

[gea]

Eine Frage zur Vorgehensweise zur Verschlüsselung:
Ich setze einen Backup Server auf, die Napp-It VM läuft (SunOS napp-it030 5.11 omnios-r151030-521a1fc4d1 i86pc i386 i86pc OmniOS v11 r151030ab). Es hängen zwei gleichartige Storage-Platten darin. Platte 1 enthält einen ZFS Pool mit mehreren Dateisystemen. Das ist das Backup des produktiven Servers. Alles unverschlüsselt. Da nachträgliche Verschlüsselung ja nicht möglich ist, kommt nun die zweite Platte ins Spiel. Dorthin sollen die Dateisysteme der ersten Platte übernommen werden - aber verschlüsselt. Sofern ich das richtig verstehe, wird per Dateisystem verschlüsselt, richtig? Oder per Pool?

ZFS Verschlüssellung arbeitet per Dateisystem (mit einem eigenen Schlüssel per Dateisystem). Verschlüssellung wird ab OmniOS 151032 stable unterstützt. Die Vorgehensweise wäre also.

1. Update von napp-it (Menü About > Update)
auf Version 19.10 home oder 19.dev

2. Update von OmniOS 151030 auf 151032

http://www.napp-it.org/doc/downloads/setup_napp-it_os.pdf

3. Update des Pools auf aktuelle Version
entweder per napp-ot Menü Pools und auf die Version klicker oder zpool upgrade
Jetzt kann man verschlüsselte Dateisystem anlegen, ein neuer Pool wird nicht benötigt.

Anschließend Daten in das verschlüsselte Dateisystem verschieben.
Kann man auch mit midnight commander mc auf der Konsole.

Beitrag automatisch zusammengeführt: 02.01.2020

Hmm, kann ich so nicht bestätigen!
Mein Raidz3 aus 19 Seagate Archive 8TB läuft seit fast 4 Jahren ohne Auffälligkeiten unter NAS4Free (noch kein XigmaNAS), Zugriffsmuster mittlerweile 98% lesen, 2% Schreiben, wenig löschen oder Ändern.

Prinzipiell ist es ZFS egal, um was für Platten es sich handelt. MSR Platten können vor allem im Raid bei höherer Schreiblast mit kleinen Blöcken aber übel einbrechen. Seagate hat die MSR Platten auf der Open-ZFS Developper Konferenz 2014 vorgestellt. Ich erinnere mich an die Diskussion ob ZFS an diese Platten angepasst werden sollte, da der Performanceeinbruch bis zu einem Timeout mit Disk offline führen kann. Am Ende war niemand da, der Anpassungen vornehmen wollte oder das als sinnvoll erachtete. Es wurde von der Verwendung von MSR Platten im (ZFS) Raid generell abgeraten.

 

[kandamir]

Danke für die schnelle Antwort! Beim Verschieben werden die vorhandenen Snapshots dann mit übertragen oder gehen die verloren?

 

[ludwinator]

Ich würde an dieser Stelle nicht Files kopieren, sondern mit zfs send/receive arbeiten.
Also in dieser Art
zfs snapshot pool/unencrypted@base
zfs send pool/unencrypted@base |zfs recv -o encryption=on -o keyformat=passphrase -o keylocation=file:///pfad/zur/passphrase pool/encrypted

hier lassen sich natürlich Bespielsweise mit -o compression=LZ4 oder/und -o dedup=on noch weitere Optionen einstellen.
cu

 

[gea]

Snapshots gehören zu einem Dateisystem. Die bleiben wo sie sind.

Replikation ist eine Option, überträgt aber Snaps nur mit der Option -R oder -I bei incrementellen Transfers (dann die dazwischenliegenden Snaps)

 

[Trambahner]

Btw, weil ich "Dedup" lese, würde ich daheim verzichten. Bringt in aller Regel recht wenig, kann aber den Ram-Bedarf ziemlich erhöhen.

 

[gea]

Btw, weil ich "Dedup" lese, würde ich daheim verzichten. Bringt in aller Regel recht wenig, kann aber den Ram-Bedarf ziemlich erhöhen.

Bisher galt nur Oracle Solaris mit dedup2 als brauchbar. Das neue Open-ZFS Feature special vdev könnte eine Wende bringen. Damit kann man die Dedup Tabelle auf NVMe legen (aktuelles Illumos wie OmniOS/OI oder neuestes Linux ZoL).

 

[Luckysh0t]

Gibt es eigentlich ein Tool, was man über seine Shares laufen lassen kann welches den möglichen einzusparenden Speicherplatz anzeigt/errechnet ? Rückgängig machen ist ja nicht.

 

[VirtuGuy]

Schau dir mal "zdb -S" an.

Sollte bezüglich Dedup nicht noch Code von Panzura Storage kommen?

 

[ludwinator]

Das werden wir sehen:

"Panzura will be open-sourcing some parts of their self-contained ZFS implementation of temporal dedup on Github. There is hope from Panzura that this will be integrated within OpenZFS but at least for now there are no concrete plans of getting this code upstreamed without volunteers.

Question: What is temporal dedup?

A dedup scheme that groups blocks by the time that they are created/modified etc... Grouping blocks in such way should allow for faster access to the data due to caching based on temporal locality"

cu

 

[Fernando2471]

Ich nutze ZFS seit einigen Jahren

 

[martingo]

Das freut uns. Hast Du auch eine konkrete Frage?
Oder beziehst Du Dich dabei hauptsächlich auf den Startpost von vor elf Jahren?

 

[Fernando2471]

Upps 🤓

 

[kandamir]

Nochmal zum Thema Daten von unverschlüsseltem Filesystem auf verschlüsseltes Filesystem migrieren.

@ludwinator: hast Du das, was Du vorschlägst schon einmal gemacht? Denn ein Blick in die Dokumentation von ZFS zeigt mir, dass ich kein unverschlüsselten Dateisystem an ein verschlüsseltes Dateisystem mittels zfs send/recv senden kann...

Currently, you cannot send an unencrypted dataset stream and receive it as an encrypted stream even if the receiving pool's dataset has encryption enabled

D.h. ich werde meine Snapshots in jedem Falle verlieren, da dann tatsächlich nur cp -r o.ä. Übrig bleibt. Das betrifft leider nicht nur meine Backup Platte, sondern auch meinen produktiven Server. Denn dort sind die Dateisysteme ebenfalls nicht verschlüsselt und ich kann sie nicht per zfs send / receive auf den (dann verschlüsselten) Backup Server transferieren. Oder liege ich daneben? Ich müsste die Daten also zuerst dort auf verschlüsselte Filesysteme kopieren und würde da schon die Sbapshots verlieren. Das wäre ein echtes Manko. Danach könnte ich erst mein Backup auf verschlüsseltes Filesystem durchführen.

Liege ich daneben? Oder gibt es noch einen alternativen Weg?

 

[gea]

Ich habe das noch nicht selber probiert, aber nach meinem Wissenstand sollte ein zfs send (unverschlüsselt ) > zfs receive (verschlüsselt) funktionieren, entweder indem das Ziel-Parent Dateisystem verschlüsselt aber unlocked ist oder man per receive manuell ein verschlüsseltes Dateisystem anlegt.


Einfach mal probieren (send mit Parameter -R) und berichten.

ZFS Encrypted Send · Issue #7966 · openzfs/zfs

It'd be great if we could send a snapshot in an encrypted form, even if the source snapshot is not encrypted. The main motivation for this is encrypted, incremental backups of unencrypted datasets....

github.com

Added encryption support for zfs recv -o / -x · openzfs/zfs@d9c460a

One small integration that was absent from b52563 was support for zfs recv -o / -x with regards to encryption parameters. The main use cases of this are as follows: * Receiving an unencrypted stre...

github.com

 

[martingo]

Ich bilde mir ein, dass ich die Datenmigration von zfs unter Linux (Harddisks verschlüsselt aber unencrypted zfs datasets) nach Solaris (encrypted datasets) ebenfalls per zfs send/recv gemacht hatte.

 

[ludwinator]

Nochmal zum Thema Daten von unverschlüsseltem Filesystem auf verschlüsseltes Filesystem migrieren.

@ludwinator: hast Du das, was Du vorschlägst schon einmal gemacht? Denn ein Blick in die Dokumentation von ZFS zeigt mir, dass ich kein unverschlüsselten Dateisystem an ein verschlüsseltes Dateisystem mittels zfs send/recv senden kann...

Ja habe ich, funktioniert!
Wenn du von "Dokumentation" sprichst, welche genau meinst du?

cu

 

[VirtuGuy]

Bisher galt nur Oracle Solaris mit dedup2 als brauchbar. Das neue Open-ZFS Feature special vdev könnte eine Wende bringen. Damit kann man die Dedup Tabelle auf NVMe legen (aktuelles Illumos wie OmniOS/OI oder neuestes Linux ZoL).

Wir planen dazu auch genauere Tests da mit Veeam der DDT Speicherbedarf ja erheblich höher ist als die oft genannten 5Gb Ram pro TB Daten. Wobei RAM aktuell im Vergleich zu den großen Optane Platten nicht teurer wäre - aber woher die vielen Slots nehmen...

Das ist eines der wenigen Dinge wo Btrfs richtig gut dasteht, ein Offline Dedup wäre für unseren Bedarf deutlich angenehmer.

 

[kandamir]

Danke für Eure Rückmeldungen!

@ludwinator: Mein o.g. Zitat stammt aus den Oracle Docs von Solaris 11.3 (https://docs.oracle.com/cd/E53394_01/html/E54801/gkkih.html). Aber vermutlich, ist das gar nicht relevant, weil ich nicht unter Solaris sondern unter OmniOS arbeite?!

Ich habe das gestern Abend dann nochmal ausprobiert: Testweise ein verschlüsseltes Filesystem angelegt (Data/Test_enc) und versucht, ein nicht verschlüsseltes Filesystem auf das verschlüsselte (und entriegelte) Filesystem zu übertragen:

root@server> zfs send - R Data/test@current_snap  | zfs receive -F -d Data/Test_enc
cannot receive new filesystem stream: parent 'Data/Test_enc' must not be encrypted to receive unenecrypted property

Auch das Ergänzen von '-o encryption=on' beim receive Kommnado hat nur andere Fehlermeldung gebracht. Aber wenn Ihr einhellig der Meinung seid, dass das gehen müsste, stelle ich mich vermutlich nur zu doof an. Vielleicht brauche ich doch etwas detaillierte Hinweise zur Vorgehensweise...

 

[gea]

Wäre auch schade, wenn ZFS alles besser könnte und btrfs nicht das eine oder andere "Ehrentor" erzielen würde.

Andererseits muss btrfs auch beim Lesen seine Hashtabellen haben und die sollten idealerweise auch im RAM liegen - wie bei ZFS, https://btrfs.wiki.kernel.org/index.php/User_notes_on_dedupe

And the memory usage of dedupe grows with the dedupe hash pool size. Btrfs will not pre-allocating memory for dedupe at the enabling time. So it's possible to set a very huge dedupe pool size, as long as OOM is not triggered.

Ausserdem ist transparentes Echtzeit-Dedup für einzelne Dateisysteme (ohne separaten Dedup-Lauf) schon State of the Art. Der hohe RAM-Bedarf erfordert dann aber schon hohe dedup-Raten, damit sich das gegenüber LZ4 Compress lohnt.

 

[ludwinator]

Danke für Eure Rückmeldungen!

@ludwinator: Mein o.g. Zitat stammt aus den Oracle Docs von Solaris 11.3 (https://docs.oracle.com/cd/E53394_01/html/E54801/gkkih.html). Aber vermutlich, ist das gar nicht relevant, weil ich nicht unter Solaris sondern unter OmniOS arbeite?!

Ich habe das gestern Abend dann nochmal ausprobiert: Testweise ein verschlüsseltes Filesystem angelegt (Data/Test_enc) und versucht, ein nicht verschlüsseltes Filesystem auf das verschlüsselte (und entriegelte) Filesystem zu übertragen:

root@server> zfs send - R Data/test@current_snap  | zfs receive -F -d Data/Test_enc
cannot receive new filesystem stream: parent 'Data/Test_enc' must not be encrypted to receive unenecrypted property

Auch das Ergänzen von '-o encryption=on' beim receive Kommnado hat nur andere Fehlermeldung gebracht. Aber wenn Ihr einhellig der Meinung seid, dass das gehen müsste, stelle ich mich vermutlich nur zu doof an. Vielleicht brauche ich doch etwas detaillierte Hinweise zur Vorgehensweise...

Oracle Doku ist in vielen Bereichen nicht mehr relevant für open source ZFS.

1. Schritt: lege dir ein Textfile an mit der Passphrase drin. Unter /tmp/passphrase.txt
2. Schritt: zfs send -v Data/test@current_snap |zfs recv -o encryption=on -o keyformat=passphrase -o keylocation=file:///tmp/passphrase.txt Data/Test_enc
Option -R geht an dieser Stelle noch nicht.

Bitte vollständige Fehlermeldung liefern, wenns nicht geht.

 

[VirtuGuy]

Ausserdem ist transparentes Echtzeit-Dedup für einzelne Dateisysteme (ohne separaten Dedup-Lauf) schon State of the Art. Der hohe RAM-Bedarf erfordert dann aber schon hohe dedup-Raten, damit sich das gegenüber LZ4 Compress lohnt.

Am Ende hängt es natürlich immer von der jeweiligen Anforderung an. Uns bringt die Deduplication bei Backup/Archiv Speicher doch erheblich mehr als LZ4 alleine, +40% sind idR immer drin. Einfach mehr Platten zu verbauen KANN je nach Anforderung die einfachere/günstigere Lösung sein. Dazu braucht man am Ende aber auch den Platz, da sind 40% für uns ein Kostenfaktor.

Von daher wäre halt auch eine Task gesteuerte Dedup Lösung auch eine nette Alternative => das kann ggf außerhalb der Archivfenster erfolgen.

 

[gea]

Ich habs jetzt auchmal probiert.
Das Senden eines unverschlüsselten Dateisystems mit Erzeugen eines verschlüsselten Ziel-Dateisystems im receive mit -o encryption=on hat nicht geklappt.

Auch ein send -R (inkl enthaltene Snapshots) auf ein verschlüsseltes Parent Dateisystems hat nicht geklappt.

Funktioniert hat ein einfaches send auf ein verschlüsseltes aber unlocked Parent Dateisystem
zfs send tank/data@now | zfs receive tank/enc/data2


Bleibt das Problem der alten Snapshots.
Ich sehe da zunächst nur als beste Option, das alte unverschlüsselte Dateisystem eventuell auf einer Backupplatte zu erhalten bis die Snaps nicht mehr benötigt werden. Eventuell das alte Dateisystem als snapbackup umbenennen.

 

[Bzzz]

Interessant wird's allerdings, wenn du mal einen Ausfall haben solltest und eine ersetzen musst. Der Resilver wird vermutlich ewig dauern, wenn du noch nicht auf aktuellem ZFS Stand bist.

Mmh, wieso? Metadaten kratzt man Random zusammen, das sollten SMR-Platten aber schaffen. Sobald klar ist, wo was liegt, kann man wieder halbwegs sequentiell lesen, was SMR ja auch wunderbar kann.
Ich dachte, auf die Ersatzplatte wird nach Möglichkeit auch sequentiell geschrieben, u.a. weil ja Datenströme von X anderen Platten zusammenkommen, die richtig organisiert auch große sequentielle Blöcke darstellen. Warum sollte man gerade beim Resilver die üblichen 5s missachten und sofort wild wegschreiben, was man rekonstruiert hat? Umgekehrt müsste doch gerade ein geordneter Resilver der bessere Ausgangspunkt für eine SMR-Platte sein als eine 1:1-Kopie, die zwar 100% sequentiell geschrieben werden kann, aber dann einen fragmentierten Datenbestand enthält?

 

[gea]

Von daher wäre halt auch eine Task gesteuerte Dedup Lösung auch eine nette Alternative => das kann ggf außerhalb der Archivfenster erfolgen.

Ich sehe die zusätzliche CPU Last beim Echtzeit Dedup Schreiben eher als unerheblich an. Entscheidend ist der RAM Bedarf für die Dedup Tabelle. Den gäbe es auch bei nicht-realtime dedup weil man die Tabelle beim Schreiben und Lesen braucht. Bei 40% Platzeinsparung würde ich aber auch immer einen größeren Pool ohne dedup wählen - einfach weil man sich dann keine Gedanken im Betrieb machen muss.

Ein dedup ratio von 10 wäre eine andere Hausnummer.

Beitrag automatisch zusammengeführt: 04.01.2020

Mmh, wieso? Metadaten kratzt man Random zusammen, das sollten SMR-Platten aber schaffen. Sobald klar ist, wo was liegt, kann man wieder halbwegs sequentiell lesen, was SMR ja auch wunderbar kann.
Ich dachte, auf die Ersatzplatte wird nach Möglichkeit auch sequentiell geschrieben, u.a. weil ja Datenströme von X anderen Platten zusammenkommen, die richtig organisiert auch große sequentielle Blöcke darstellen. Warum sollte man gerade beim Resilver die üblichen 5s missachten und sofort wild wegschreiben, was man rekonstruiert hat? Umgekehrt müsste doch gerade ein geordneter Resilver der bessere Ausgangspunkt für eine SMR-Platte sein als eine 1:1-Kopie, die zwar 100% sequentiell geschrieben werden kann, aber dann einen fragmentierten Datenbestand enthält?

Resilver liest alle Matedaten (kleine random reads) und prüft ob die darin referenzierten Datenblöcke auf der alten Platte liegen. Ist dem so, wird der entsprechende Datenblock aus Redundanz rekonstruiert und auf die neue Platte kopiert. Entscheidend für die Resilver Zeit ist daher die io Leistung des Pools und die ist mit vielen Platten bei einem einzelnen Raid-Zn schlecht und beim Schreiben auf MSR nochmal schlechter.

Lediglich aktuelles ZFS (Solaris mit sequentiellem Resilver oder neues Open-ZFS (z.B. neuestes OmniOS, ZoL, noch nicht verfügbar bei FreeNAS oder XigmaNAS) bei dem das sorted resilver heißt ist da um Größenordnung schneller weil hier die Daten soweit wie möglich sequentiell gelesen werden (Metadaten lesen, sortieren, Daten lesen)

Die 5s Schreibcache gilt übrigens nur für Oracle Solaris. Open-ZFS arbeitet nicht mit einem festen Zeitfenster sondern abhängig vom Füllgrad. Ist der Schreibcache z.B. zu 50% gefüllt, wandert er auf Platte und die weiteren Writes gehen in den freien Bereich des Schreibcaches.

 

[Bzzz]

Jaja gea, aber die Frage ist doch, warum das für SMR-Platten schlecht sein soll? Die sollte man doch nur nicht random befüllen, weil sie sonst noch übler einbrechen als konventioneller Drehrost. Wenn ein Datenblock rekonstruiert ist, dann geht der doch in Gänze (idealerweise mit vielen anderen zusammen) auf die neue Platte und nicht in 4k-Häppchen, die dann SMR-intern wegen der des Layouts dann u.U. mehrfach neu geschrieben werden müssen?